Thinking forward LFS-7.0

Ken Moffat ken at
Mon Mar 14 13:45:35 PDT 2011

On Sun, Mar 13, 2011 at 11:39:04PM -0500, 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.

 If there is a move from LFS-6 to LFS-7, I expect to see a
significant change in the build.  From what you have listed,
some of these are *perhaps* major enough to justify it.  Personally,
I have no objection to releases numbered 6.10, 6.11, ...

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

 DESTDIR is part of package management.  I'll grant that it can
probably be fitted in without trashing everything else.

> * LSB Compliance - For LFS we are nearly there anyway.
 So, since you have raised this, what do you think needs to be done
that is a major change ?  More to the point, should we really care ?
I don't have any interest in letting people run binaries.

> * Dynamic boot script - No more static list of links, this kind of ties 
> into LSB Bootscripts, but there are other options.

 I don't know what you mean by this ? It's the first time I've heard
the phrase "dynamic boot script".  I hope this isn't anything to do
with upstart or systemd, what I've seen of those fills me with a
mixture of horror and disgust ;)

> * Multi-lib - Shunned previously, but there are many projects that 
> expect this environment.

 For people who build from source, which projects *expect* multilib on
x86_64 ?

 I will agree that building a bi-arch desktop (that is, both 32-bit
and 64-bit Xorg, with some applications as 32-bit and others as
64-bit), was a very educational exercise when I did it.  That was
back in the gnome-2.1x days - the real fun was in making some parts
of gnome 32-bit and others 64-bit).  Fun, but pointless.  On x64_64,
modern software runs fine as 64-bit.

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

 For a while, eglibc seemed to be dead (no releases).  It has become
alive again, but usually provides very little for i686/x86_64.

> * Modular *.d/ directories - I'm pretty sure this is already covered in 
> another thread, but it should be done by default where possible.

 I don't see this as an issue for LFS.  What is the problem with
jsut doing it ?

> * Anything else that I've missed
> -- DJ Lucas

das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-dev mailing list