Thinking forward LFS-7.0

Nathan Coulson conathan at
Sun Mar 13 23:25:05 PDT 2011

On Sun, Mar 13, 2011 at 10:44 PM, DJ Lucas <dj at> wrote:

>  On 03/14/2011 12:03 AM, Nathan Coulson wrote:
> 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.
> That is part of the problem that I see. We all have our own way of doing
> things. This is actually fine, but I can see the benefit of standardizing
> some items such as package upgrades in the way of a wiki entry. For
> instance, keeping a copy of s-ls, s-rm, s-cp, and s-install around for glibc
> updates (these would be statically linked copies of the s- tools) which
> hasn't been needed for years I'm told, and in fact I had proven not to long
> ago by doing an in-place upgrade of GLibC while Gnome was running. :-) I'm
> still weary of doing glibc upgrades like that on a live system, perhaps it
> is an unfounded fear, but I did it on a test system just for kicks and had
> absolutely no issues. I did do a reboot immediately afterward.

>   > * 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
> Yes, please! Another set of eyes and additional brain power is always
> welcome! You should still have commit privs so feel free to help yourself.
> The current 'stable' boot scripts are the remnants after we ripped out the
> i18n additions. Though they are stable, they still contain a lot of cruft
> such as boot_mesg which is largely unneeded. I wound up doing a complete
> rewrite of rc and a single conditional source of the configuration files in
> lsb-v3. IOW, at the cost of possibly faster conditional logic, they only get
> sourced by the script if running outside of rc in the lsb-v3 directory. I
> honestly don't remember what the 'stty sane' issue was caused by, but I have
> never been able to reproduce it since and saw no reason to source the files
> in every single sub-shell. BTW, Dan's initd-tools has moved. He is currently
> hosting them in his home directory on

something to do w/ delete or backspace turning into ^H, if I recall,    I
think it also prevent someone from pressing enter when something paused the
bootup.  Whatever it was, it was 5 years ago...  if not longer.

>   > * 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)
> Yes, unfortunately, the tool chain packages are not enough to do a real
> multi-lib system. For my own purposes, I need a working 32bit tool chain,
> 32bit X Libraries and server, and 32bit libs up through java. Most of this
> is for Android development. For LFS's purposes, the tool chain is enough
> however and pretty much what CLFS covers (this includes PPL, Cloog-PPL, GMP,
> MPFR, MPC. ZLib, Binutils, GLibC, and GCC). PERL is a real kicker that
> brings in more 32bit libs than the tool chain requirements. I haven't tried
> to build a multi-lib without it yet to see if it is needed by my own tools,
> but I suspect that a lot uses it. If a user is dabbling in multi-lib, then
> they should be able to figure out exactly what they need by using the
> existing instructions. This paired with DESTDIR style installations provides
> some protection to the user as well. BTW Nathan, I did use your page to
> figure out what exactly needed to be changed in the GCC drivers as opposed
> to sorting through the CLFS patch. I made changes, but that write-up was
> quite helpful. Thanks.

I should finish that writeup someday...  There was some change we made to
the gcc page that I couldn't quite make work w/ multilib, so I just used the
old way.

  > * 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

Yes, the end product of modular parts simply looks much cleaner.
> -- 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