upcomming 0.2 release
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
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