Thinking forward LFS-7.0
thomas at equinox.homelinux.org
Sat Mar 19 13:50:59 PDT 2011
Uuuuhi, what a large threat suddenly :-)
On Monday 14 March 2011 05:39:04 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.
Not (now) for LFS.
KISS is the way to go for LFS, i think. That is the great "feature" of LFS,
(nearly) everyone can learn and understand how things are going. It would be
no longer that clear when taken under the umbrella of a more or less
> * DESTDIR - Been mentioned several times and actually this is not too
> disruptive (I did a POC about 3 years ago).
I would definetly prefer this one over any other kind of package management.
It is easy to understand and needs no additional programs which do some magic
Moreover, I think that the DESTDIR idea should be primarily addressed by the
BLFS book. The LFS idea is basically to show how an OS can be bootstraped
(its still the idea of LFS, isn't it?) Later on, when enough experiences in
doing LFS has been made, LFS is "small" enough to be scripted (btw, a
reanimation of jhalfs would be great even the latest svn works really fine).
So in case of upgrading, a new core LFS can be setup quite quick.
In BLFS, there are so much packages, tiny ones and fat ones, a real benefit
could be reached in having them as binaries. It lasts for days to have a full
featured desktop again after starting from scratch with a new LFS. Simply
"extracting" one binary after the other (which all has been created by the
instructions given by the book) would be quite fast. So in my opinion, PM goes
Btw, what is POC ?
> * 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.
Dynamic in th meaning of defining dependend services by the boot script itself
(like apache needs network first)? If yes: ++
> * Multi-lib - Shunned previously, but there are many projects that
> expect this environment.
> * 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.
No idea as I dont know eglibc. Whats the benefit of that alternative?
> * Modular *.d/ directories - I'm pretty sure this is already covered in
> another thread, but it should be done by default where possible.
> * Anything else that I've missed
> -- DJ Lucas
More information about the lfs-dev