Testing branch proposal

Zack Winkles zwinkles at gmail.com
Mon Jul 5 10:49:49 PDT 2004


On Sun, 4 Jul 2004 23:02:49 -0600 (MDT), Nathan Coulson
<conathan at conet.dyndns.org> wrote:
> > Jeremy Utley wrote:
> >> Greetings, dev readers!
> >>
> >> Now that GCC 3.4.1 has been released, the time I believe has come to
> >> consider cutting LFS to a testing branch.  However, the question is,
> >> what to bring with us to the testing branch.  Here's the new things
> >> we're looking at for the new LFS 6.0 testing branch, from what I can
> >> see:
> >>
> >> 1) Kernel 2.6
> >> 2) NPTL
> >> 3) Newer Glibc version
> >> 4) GCC 3.4.x
> >> 5) Udev
> >> 6) Hotplug
> >
> > Also, readline has been added. This was supposed to be addressed
> > before unstable went to testing (seemed to have much controversy
> > last time the subject came up).

I would definitely vote in favor of bringing readline into the book. 
There are currently
three packages taking advantage of it (bash, inetutils [in particular,
ftp], debugfs).
The installation instructions have been banged on for quite a while
now, and it seems
to be rock-solid now.

> and the binutils version issue.  I dont remember any discussion on moving
> to 2.15.x.x, except that it was required for gcc at one time.

Binutils 2.15 can _suffice_ for our purposes, but it is _not_ ideal. 
The reason the
current use of HJL Binutils 2.15.91.0.1 is the presence of the -z
relro flag, which, as
Zeplin epxlained it on IRC, helps to protect data on the stack (thus
fewer overflows),
and also shrinks the code by aligning it differently.  I'm not a
programmer, so I don't
know too much about it, but it sounds _very_ good and Glibc has been seeking to
use it for almost 5 months now.  Only with version 2.15.91.0.1 did it
finally make it
into CVS.

As things stand right now, Binutils 2.15.91.0.1 presents obvious
advantages to 2.15.
So long as it can prove it's stability (through use in the testing
branch), I see absolutely
no reason it shouldn't/couldn't be used in the book.



More information about the lfs-dev mailing list