upcomming 0.2 release

Robert Connolly robert at linuxfromscratch.org
Sat Jan 8 05:22:33 PST 2005

On January 8, 2005 01:20 am, Archaic wrote:
> On Fri, Jan 07, 2005 at 04:31:04PM -0500, Robert Connolly wrote:
> > Do you want to put nls support for uClibc in, even though its only
> > partially working? It won't work for man-1.5o1, and maybe a couple other
> > packages.
> If it causes breakage, no. But then again, I would rather use glibc only
> as it is much more widely tested.

uClibc still has its advantages. You can install just want you need with 
uClibc, where as with Glibc you need to install everything. uClibc was made 
to be small while supporting almost everything. This causes both advantages 
and disadvantages.

The build method to support both is a bit different but I'm pretty sure the 
results are the same.. Glibc chapter 5 is built with a static-libgcc, but it 
is still built properly. After gcc and binutils are rebuilt the results of 
chapter 5 should be the same as with the typical lfs build method. There is 
no reason for it to be producing different results. The iproute2 package 
version is the only change made that affects the Glibc system, and this 
should get fixed shortly. And in my tests it looks like the uClibc system can 
be escaped, so building from uclibc to glibc, and vise versa, works.

As always the thing that worries me the most is the Linux kernel. We can't 
have an uptime of more than a month or two before more vulnerabilities are 
found. And the 2.6 maintainers keep adding new features to a stable branch.

I'm projecting a stable hlfs release around the time kernel 2.8 and gcc4 are 
released for the mainstream. Hopefully the 2.6 branch will be stabilized by 
then. gcc-3.4 has been doing well so far. glibc-2.3.4 should be stabilized by 
then too. Until then I would like to add as much as we can.. selinux patches, 
blowfish passwords, etc, optionally of course. If we want something that is 
truly stable before that it would mean downgrading the core packages, and I 
don't want to do that.


More information about the hlfs-dev mailing list