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 > ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
