Re: [lfs-dev] Moving packages from/to BLFS to/from LFS

On Wed, 2025-09-10 at 23:42 +0200, Rainer Fiebig wrote:
> As I have understood your idea, leaving technicalities apart for now:
> - the two books are merged into one ("LFS") which would consist of
>   Part I (former LFS) and Part II (former BLFS)
> - the concepts of the two parts would stay like they are now
> - that means: users who just want a basic system can stop at
>   the end of Part I.  Users who want more, go on to Part II
> 
> If this is what you have in mind, I'm all for it.  It would make things
> simpler and easier in many ways:
> - for users: all in just one book
> 

It's not exactly what the OP has in mind, IIUC.  Quote from the OP:

"just make the individual "package" section XML source files consistent
across the two books"

IIUC it at least means you need to add required/recommended/optional
dependencies against all the LFS packages in the BLFS package sources,
or you cannot make them consistent (here I mean, simply the consistency
in form/style), nor make moving packages between LFS/part1 and
BLFS/part2 easier.

Thus the difficulty is strictly larger than moving intltool and
XML::Parser into BLFS.  And... I'm still unsure if I can successfully
move intltool and XML::Parser in this development cycle.  I used "I"
instead of "we" because literally no other editors want to spend time on
this.  So let's not be too optimistic about all the packages (including
intltool and XML::Parser).

I know you may counter my reasoning with "hey you are just speaking from
the editors' prospective, not the users" but ... the fact is it's the
editors who need to do all the work.  I'm pretty sure AI is not capable
for this thing, at least as at now.

Also it'd still raise more questions like if libxml2 and libunistring
should be a recommended dependency of gettext or just optional.  In BLFS
we always treat such dependencies that the book already contains and the
package will build a shipped copy if you omit as recommended.  But
moving libxml2 and libunistring into LFS (or "LFS part 1") would seem
unacceptable for many people (I consider doing so acceptable but I'm not
really enthusiastic to do it).

However if we'd not move them into part 1 after the merge, it would mean
there exist real, logical differences between part 1 and part 2 and I'd
not consider just making their form/style similar very meaningful then.

> - just one name to deal with

Rewriting the entire infrastructure on the server hosting the book :(.

> - just one git-repo

Making each "make" have to render both LFS and BLFS even if you just
fixed a typo in LFS changelog :( note that BLFS takes a much longer time
to be rendered than LFS).

> - just one dev- and support-list

I think it's unrelated to how we structure the book sources.

-- 
Xi Ruoyao <[email protected]>

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page