| Newsgroups |
gmane.linux.lfs.beyond.devel,gmane.linux.lfs.devel |
| Message-ID |
<[email protected]> |
Am 10.09.25 um 13:42 schrieb lfs ([email protected] via lfs-dev
Mailing List):
/ snip /
> There should be a number (well, at least one) of old threads that
> floated the idea.
That's probably forgotten by now. Make a fresh start.
>
> 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.
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
- just one name to deal with
- just one git-repo
- just one dev- and support-list
- etc. pp.
A thought experiment may help to see the benefits of it: let's assume
LFS would have been like this up to this day - one book with two parts.
Now someone comes along and suggests to split LFS in two. How would
that idea be received?
>
> 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.
Well, as I've said: make a fresh start and open a new thread. Let's see
what others think. Don't cherish any illusions but at least my humble,
non-influential me is on your side.
Rainer
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page