| Newsgroups |
gmane.linux.lfs.beyond.devel,gmane.linux.lfs.devel |
| Message-ID |
<[email protected]> |
On Monday, September 8th, 2025 at 17:58, Rainer Fiebig <[email protected]> wrote:
>
> 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.
There should be a number (well, at least one) of old threads that
floated the idea.
At one point, I think a domain that I was hosting content at may
even have had a rendering of such a "combined" book that contained
the notes as to what I had done, although that would date back to
before you needed to install SystemD packages to get a SysV LFS,
(and to before the time when we didn't regularly top-post and we
trimmed replies!) and I have let the domain hosting, if not the
domain, lapse.
Just to be clear though, the idea is NOT to change the "core thrust"
of the LFS and BLFS Books, just make the individual "package" section
XML source files consistent across the two books, so with stuff like
xrefs to the packages.ent and other auxiliary files live at the same
places in the source trees, as that makes moving things around a lot
simpler.
As an example, I tend to leave the Meson build system (MesonBS)
packages out of my LFS build, and add them in as part of my BLFS,
usually at /opt/MesonBS, and to do that, I went back to using the
XML sources from the BLFS Book, from before the MesonBS packages
were moved into LFS.
I'll see if I can dig out my rendered Book (a single HTML file)
from back then, along with identifying the old thread(s), before
starting a new thread. Maybe I'll even re-start hosting the old
domain content.
FWIW, the way I had done things back then was really sub-optimal
but it did let me have the one source tree for my rendered Book:
so something slightly different to the idea here, in that, in
DocBook-speak, the LFS and BLFS Book could (and I emphasise the
"could") become Books in a Set.
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page