Thinking forward LFS-7.0

Nathan Coulson conathan at
Sun Mar 13 22:03:09 PDT 2011

On Sun, Mar 13, 2011 at 9:45 PM, DJ Lucas <dj at> wrote:

> On 03/13/2011 11:39 PM, DJ Lucas wrote:
> > Okay, so I was just thinking...<replaceable><Deity></replaceable>
> > help us! I figure we have at least 6 months, potentially a year until
> > the next major LFS release, and now seems like a pretty good time to
> > explore some of the ideas that have been shelved for previous releases,
> > and even some new ones. Here is a quick list to see if there is any
> > interest. I'll reply to my own post afterward to separate my own
> > suggestions from the initial list.
> >
> > * Package Management - Always causes a good debate.
> >
> > * DESTDIR - Been mentioned several times and actually this is not too
> > disruptive (I did a POC about 3 years ago).
> For me, these two go hand in hand. Package Management, historically, has
> always generated a fueled debate. There are many options here including
> conditional processing of the book's sources to allow for various forms
> of package management. I had previously suggested years ago that we move
> the default build instructions to include a very simple DESTDIR style
> installation, with the final installation done manually from the DESTDIR
> target. This method lends itself well to almost all forms of package
> management without the need of choosing a specific package manager. This
> method also gives us the option of pre-processing the book's source code
> for a specific package manager either by conditional logic (as I
> understand the new docbook is capable of), or in a simpler form, using a
> Makefile target to pre-process the book using sed or other standard unix
> tools if the instructions are split into pre-install, build, install,
> and post-install targets.

no comment here, although I've personally preferred less instructions to
more where possible.  (DESTDIR is not something I use) .  I usually throw
away systems when it's time to upgrade though, or just install newer libs
over the old.

> > * LSB Compliance - For LFS we are nearly there anyway.
> >
> > * Dynamic boot script - No more static list of links, this kind of ties
> > into LSB Bootscripts, but there are other options.
> >
> Again, these two go hand in hand for me. In the current lfs-bootscripts
> tarball, I've been working on and using exclusively the contrib/lsb-v3
> boot scripts for over 3 years now. They are an extension of something
> that Nathan Coulson and Alexander Patrakov had started on. These are
> completely lsb-v4 compliant as well and are IMO a huge improvement over
> the current boot scripts. I've been using Dan Nicholson's initd-tools
> package to provide the install_initd and remove_initd programs. Aside
> from the fact that there is no longer any need to maintain a list of
> symlinks for startup order, they add a lot of niceties, including
> boot-logging and conditional startup for trouble-shooting.

ah, I miss the bootscript days.  I'll have to take a look, and find out what
I have been missing out on

> > * Multi-lib - Shunned previously, but there are many projects that
> > expect this environment.
> I just kinda threw that in there. A couple of projects that I use beyond
> BLFS expect that environment now for 64bit builds, specifically AOSP,
> Wine, and VirtualBox, all of which forcefully exclude the official LFS
> as my daily driver now. I've been using the work of the CLFS devs for my
> own daily driver with some heavy modifications to match LFS proper as
> much as possible.

When I designed my own multilib system,  I had a few goals
- 32bit was not a essential part of my system.  Only reason I have it is for
wine, basically...
- I wanted /lib 64bit.   Therefore, I used /lib/32 for 32bit libs (although
/lib32 would probably be a better book choice).  [always bugged me that /lib
is normally the 32bit directory, especially since it is the default
installation choice]
- If possible, I would have liked to see multilib avaliable "after" building
lfs, but this is probably not feasable.
- I only install 32bit versions of glibc, zlib, ncurses, utillinux as
they're the only ones I actually needed for my 32bit uses.  May be worth
reviewing who would be using 32bit, and what applications it would be
supporting.  Multilib in the book would look nicer, if only
glibc/gcc/binutils had multilib tweaks.  (Enough to compile 32bit software)

> > * EGlibC - Seems like Debian and friends are moving to EGlibc, gives us
> > a couple of niceties but nothing major, not sure what other distros are
> > doing, but I've seen a lot of mentions of it recently. The work is
> > already done by the way, our fellow devs at CLFS already have it covered
> > for us.
> Same thing, I've seen lots of mentions of it so I'm throwing out the
> feelers. CLFS has already done this and I've used both. I have no real
> opinion either way yet. I did not have anything more than minor issues
> making GLibC proper conform to my expectations (/lib -> lib64/, /usr/lib
> -> /usr/lib64, /lib32, and /usr/lib32).
> > * Modular *.d/ directories - I'm pretty sure this is already covered in
> > another thread, but it should be done by default where possible.
> >
> As mentioned elsewhere recently, this gives a lot of options, and in
> fact are required by a few packages in BLFS. I see absolutely no reason
> to omit this as the default using the instructions currently in BLFS as
> a guideline for strict conformance.

using .d folders has made scripted builds much nicer, and It seems tidier to

> > * Anything else that I've missed
> >
> > -- DJ Lucas
> >
> -- DJ Lucas
> --
> This message has been scanned for viruses and
> dangerous content, and is believed to be clean.
> --
> FAQ:
> Unsubscribe: See the above information page

Nathan Coulson (conathan)
Location: British Columbia, Canada
Timezone: PST (-8)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the lfs-dev mailing list