Thinking forward LFS-7.0
ken at linuxfromscratch.org
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
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