stable status

Robert Baker bobb at
Wed Sep 26 06:37:30 PDT 2007

In theory I agree with your sentiments regarding 2.4 versus 2.6 in terms 
of stability. In practice with the deprecation of linuxthreads in the 
current revisions of glibc it would seem there is more work to be done. 
Freezing what we have now for 2.4 is not feasible. After attempting 
builds with 2.5.1, 2.5 (with and without the debian patch), and 2.3.6 I 
am thinking 2.3.6 is the way to go. That change alone is going to do a 
lot to stabilize the core toolchain. I don't think making HLFS into a 
"giant hint" is the way to go because it would be difficult to cover the 
hardening process in a better format than what we currently have.

Historically as this conversation has been brought up there is 
undoubtedly someone who asks why not 2.6? citing everyone else who 
builds their stable products on that kernel. I would agree to some 
extent that there is plenty of precedent for using the more current 
kernel revisions in a stable manner. Most problematic portions of the 
kernel tend to be marked clearly as experimental, and can simply be 
avoided. It is also worth mentioning nearly everyone who uses 2.6 in 
their stable products is using heavily patched versions of the kernel 
not vanilla versions. For that and several other reasons including 2.6 
would increase the need for a maintainer, but it would assuage some of 
the sentiment that HLFS stable would be behind the times.

Nevertheless I do believe arriving at HLFS stable-1.0 is an important 
milestone that would help to encourage the further development of the 


Robert Connolly wrote:
> Hello. I'd like to hear opinions about the status of the -stable release. I'd 
> really be nice to have a stable release, and I think it would exclude the 
> uClibc book. Historically the Glibc book has always been fairly unstable, but 
> usable. uClibc itself, and ports for it, has kept the uClibc book from 
> becoming stabilized.
> I've jotted notes for a stable release goals on the wiki, but these can be 
> changed. The Glibc book isn't in bad shape, and before replacing Shadow with 
> Shadow-ssl it might be worth it to produce a stable release which lacks the 
> OpenSSL package and focuses mainly on toolchain modifications (default 
> CFLAGS). A major change to the -stable book change, compared to -unstable, 
> would be documentation of it's logic. It should be standalone, whereas 
> the -unstable book is often documented on this mailing list.
> The variable here is the goals for HLFS-1.0. Either keep plowing ahead, or 
> settle down and use what we have.
> A long time ago I decided the stable release will be maintained indefinitely 
> by bug fix patches. This is a project in itself, and should have it's own 
> dedicated maintainer. Meaning that whatever packages are in the -stable book 
> will be maintained on with updated 
> bugfix patches which add no new features and only security fixes. The only 
> way I see this happening is with the linux-2.4 kernel, because the linux-2.6 
> kernel demands modifications to userland for modifications from the new 
> kernel (new Udev, etc).
> I've never been able to think a lot about -stable because I never stop finding 
> more things to modify for security and uniformity. After all the work done 
> to -unstable, it would be a shame to have a simple toolchain modification 
> book for -stable, but focusing on documentation could be the plus.
> robert

More information about the hlfs-dev mailing list