| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
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.
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?
Limiting this to MLFS, LFS+BLFS merging would lead to issues in MLFS,
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.
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.
Apologies, though I do think your idea is interesting!
- Zeckma
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page