Thinking forward LFS-7.0

Bruce Dubbs bruce.dubbs at gmail.com
Mon Mar 14 18:56:36 PDT 2011


I've read about 15 messages on this topic and will try to incorporate 
the relevant areas in my response.

Ken Moffat wrote:
> 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, 

LFS 6.9 is scheduled for September 1st.  See the Roadmap in the wiki.

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.

I really don't have a problem with adding DESTDIR in Chapter 6.  In most 
cases I suspect it would only require a few more cp commands and an 
explanation in the Package Management section.  For BLFS to follow would 
be a much larger effort.

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

I've looked at this and made some posts about it in 2009.  LSB is a 
'trailing' standard and many new capabilities (e.g. Qt4, KDE4, etc are 
not adequately addressed in LSB.  We already address parts of LSB in 
section iv.  We also mention building non-wide Ncurses libraries.

I am not opposed to reworking the bootscripts to be more consistent with 
LSB and setting things up to build the boot order into the scripts 
instead of the Makefile.  Is this enough to relabel LFS to 7.0 instead 
of 6.x?  Perhaps, but I would lean towards no.

That said, the purpose of LSB is to ensure capabilities are in place for 
proprietary binaries to be dropped in place.  As an open source 
advocate, that is not very important to me.

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

This pretty much fits into the same category as above.  The only reason 
for lib64 to exist is for those proprietary packages that have not been 
updated for 64-bit operation.

VirtualBox?  A system owned by Oracle?  I don't think I'm interested. 
Besides, there is now a 64-bit version.  Does it use 32-bit libraries?

Wine?  So you can run proprietary WIN applications?  See my comments 
about proprietary binaries.

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

What does EGlibC offer that is not in glibc?  My understanding is that 
it is for embedded systems which are not a target of LFS.

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

We already do it in BLFS for /etc/profile.d and programs like apache can 
do it with its configuration file.  The only potential file I see in LFS 
is /etc/ld.so.conf.  Personally, I think having a bunch of files that 
each add one line (not counting comments) to a configuration file is a 
disadvantage, not an advantage.  Seeing all the lines in one place is 
much easier to understand than in several different files in a different 
directory.

   -- Bruce



More information about the lfs-dev mailing list