On Sun, 13 Mar 2011 23:39:04 -0500, DJ Lucas <d...@linuxfromscratch.org> 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.
Thanks for bringing these up, DJ. We're trying to stick to a ~6month cycle, but the changes below don't look (to my naive eye) as if they'd take any longer than that. So, here's my thoughts: > * Package Management - Always causes a good debate. -1 on this given the number of different ways this can be implemented, however... > * DESTDIR - Been mentioned several times and actually this is not too > disruptive (I did a POC about 3 years ago). +1 to this, simply because it acts as a good base for a number of different PM styles, including 'roll-your-own'. > * LSB Compliance - For LFS we are nearly there anyway. I think we've been 'nearly there' for years now :-) We'll never hit full compliance though, as I think LSB requires things like X these days. > * Dynamic boot script - No more static list of links, this kind of ties > into LSB Bootscripts, but there are other options. I don't have much to say on this really, as I've never really dabbled with the bootscripts. > * Multi-lib - Shunned previously, but there are many projects that > expect this environment. Again, I have no personal need for this so don't know anything about the steps involved. I'm happy to vet patches on the basis of their ease of explanation and implementation though :) > * 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. I'm not sure I'd be happy with this particular move. EGlibC's main advantages seem to come into play on embedded systems. Does it really buy us that much on typical LFS systems? > * Modular *.d/ directories - I'm pretty sure this is already covered in > another thread, but it should be done by default where possible. I'd like to see us move to this kind of configuration layout. As said elsewhere, it makes things look cleaner and more consistent with other packages in BLFS. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
