| Newsgroups |
gmane.linux.lfs.beyond.devel,gmane.linux.lfs.devel |
| Message-ID |
<[email protected]> |
Am 08.09.25 um 18:31 schrieb "Zeckma" ([email protected] via
blfs-dev Mailing List):
> On 9/8/25 10:08, Rainer Fiebig ([email protected] via blfs-dev Mailing
> List) wrote:
>> 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.
>
> I want to preface this by saying that I appreciate the suggestion.
> The short of my opinion here is that I don't think this a good idea
> for several reasons, and all of them stem from my experience working on
> my own books and helping out with MLFS.
>
To make it clear here: this is not my idea but that of "lfs". IMO, it's
a great and overdue idea but I don't want to falsely take the credit for it.
> While I'm a BLFS editor, this opinion doesn't come from me working on
> it as much as it is from my time working on GLFS, SLFS, and a little on
> MLFS. I think such a merge would make things much more confusing and
> even more hectic. Maybe the rest of the editors have a different
> stance. Perhaps if we all do, then another thread could get created?
Sorry, but I have no clue what all these acronyms stand for. Looks
somewhat inflationary to me, though.
I already recommended that "lfs" starts a new thread for it.
>
> Limiting this to MLFS, LFS+BLFS merging would lead to issues in MLFS,
Sorry, but this is not about "MLFS" or other derivatives. "lfs's" idea
is about merging LFS/BLFS into one book. The reverberations this might
have on concurrent projects are of no interest here.
> such as how do the editors of MLFS proceed? What decisions need to be
> made? Do they keep MLFS where it is and make it stay at a base? If
> there was a merge, would BLFS packages need a multilib version, and
> which and how many packages? I floated the idea of a Multilib-BLFS
> in my head for a little while, and I always shrugged it off because
> it is a HUGE undertaking. GLFS took me months to do and ensure it all
> worked. And that was a small sample of the BLFS packages. It'd be a big
> burden to maintain it.
I have no idea what MLFS or GLFS etc. are and frankly: I don't care.
This is only about LFS/BLFS.
>
> Spreading wings to GLFS and SLFS, the proposed merge would make it more
> the case that a user would be reinstalling software again to ensure
> compatibility. I brought up a proposal regarding libglvnd. I will not
> go over it here. But such a merge would make the probility of a user
> installing Mesa's OpenGL implementations higher, causing potential
> incompatibilities. If a user installed Mesa's OpenGL, then found out
> they wanna switch, the best bet really is to either painstakenly remove
> what needs to be removed and reinstall the necessary packages, or
> completely rebuild the system, wasting time. GLFS itself is propped up
> to be something to be done right after LFS/MLFS and helps with going
> into BLFS. So a merge would make things a bit confusing, as where would
> GLFS start from?
>
> SLFS would have less issues, moreso about the OpenGL shenanigans.
>
> I suppose the main thing is that the books would no longer conform to
> the form factor the combined LFS+BLFS book would take.
>
> That's just my mindset from working on the books outside LFS/BLFS. My
> experience is led primarily by them. Beyond them, I cannot gather if
> the idea has any merit. I just wanted to express my disagreement.
I have the impression that you are taking a rather self-centered,
inside-out view of a developer of certain derivatives. Try to take an
outside-in view, the perspective of the main audience for *LFS/BLFS*,
i. e. the average new user's perspective.
>
> Apologies, though I do think your idea is interesting!
Unfortunately not _my_ idea. ;)
Rainer
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page