| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
Am 11.09.25 um 05:38 schrieb Xi Ruoyao ([email protected] via lfs-dev
Mailing List):
> 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.
Alright, from your perspective you showed valid reasons why the
"all-in-one-book" idea should not or cannot be realized within
LFS/BLFS. This is no surprise and fits a pattern that all new ideas
have to deal with: "All very fine... but where's the weakness?" Few new
ideas survive this in the places where they are presented - however good
or even logical they may appear in hindsight. History is full of examples.
To me the idea of an "all-in-one LFS" seems natural and compelling. But
I acknowledge that it may not be feasible within the LFS/BLFS-project.
Like in other cases, a new project might be necessary for that,
"U-Linux" or so. But be assured: I don't have any such plans. ;)
Rainer
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page