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

Am 07.09.25 um 09:54 schrieb lfs ([email protected] via lfs-dev
Mailing List):
> On Friday, September 5th, 2025 at 19:11, Bruce Dubbs <[email protected]> wrote:
>>
>>
>> On 9/4/25 8:49 PM, Xi Ruoyao ([email protected] via lfs-dev Mailing List) wrote:
>>
>> [snip]
>>
>>> And sorry, things like supporting binary packages have nothing to do
>>> with B/LFS which I know as a member who was active in the project for
>>> the last 10 years too.
>>
>>
>> This is worded too strongly. From the beginning LFS and later BLFS were set up to
>> demonstrate how a user could set up a Linux system from source code. One place where
>> we are forced to use non-opensource files is in firmware, but we do try to minimize that.
>>
>> I think it is necessary for us to recognize that some users want to use
>> non-opensource packages. We also have users who want to use LFS on non-x86 based
>> hardware. The question here is how do we address issues brought up by these users.
>>
>> One way is to have versions of LFS such as MLFS and GLFS as well as versions of LFS
>> for the LoongArch and ARM architectures. Additionally, there are several translations
>> of the books to non-English languages (French, Brazilian-Portuguese, and Chinese come
>> to mind).
>>
>> Overall, the LFS and BLFS teams are small. The maintenance of just the x86 English
>> versions of LFS/BLFS takes a tremendous amount of effort. In addition, it is an
>> all-volunteer effort. For me personally, it is equivalent to a full time(+) job, but
>> that is not a complaint. I get satisfaction from users that learn from what we do.
>>
>> Given all that, the core LFS/BLFS books must be somewhat limited in scope. We really
>> can't address other architectures or non-source based applications in any detail.
>> That said, there is no reason that text cannot be inserted in the books describing
>> issues beyond the core targets possibly with links to where to get more information.
>>
>> -- Bruce
> 
> I know that this won't gain any traction, but I thought to run it up
> the flagpole once again, as I think it has some merit within the
> current context: that of expanding/contracting the LFS Book.
> 
> I have often wondered - occasionaly aloud on here - why the LFS and
> BLFS book sources are developed separately, and so with slightly 
> different source conventions, and not, given the interdependencies 
> between them, as two "volumes" within a set of Books. 
> 
> I am aware that re-tooling the XML sources to allow for such a change
> would require a good degree of effort, but I have done it, albeit for
> a limited set (my distro; my packages) of BLFS "extras", in the past.
> 
> Where I am going with this is that, if LFS and BLFS were two parts of
> the same set, then there might be less reason to have to move some
> packages into LFS, or perhaps even more packages, currently existing
> in just LFS, could have "recompilation" sections in the BLFS Book, to
> which people who wanted to build "full blown" versions, when building
> their LFS, could be easily referred.
> 
> As I say though, just floating the idea once again, in case it gets
> anyone thinking in a slightly different way about the proposed need 
> to add yet more packages into LFS.
I think merging the two books into just "LFS" is a good if not even a
great idea.  From a user's POV, the separation "feels" somewhat
unnatural and perhaps outdated anyhow.  And having to deal with just one
book (and just one name!) would make things easier and simpler, too.
Not only for users but for developers as well (I assume).

You're right: not much needed to be changed: "philosophies", text etc.
of the two parts/volumes could stay basically the same.

It would certainly require a non-negligible upfront development-effort
but I think that this would be outweighed by efficiency-gains in the
long run.

As I said: a good and important idea and as I see it right now, the pros
would clearly outnumber the cons.  I'm wondering why nobody else has
floated it before.

But this certainly deserves a discussion of its own, so I recommend that
you open a separate thread for it.

Rainer

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