unstable branch for LFS

Matthias Benkmann matthias at winterdrache.de
Tue Oct 15 07:10:28 PDT 2002


On Tue, 15 Oct 2002 23:40:12 +1000 Greg Schafer <gschafer at zip.com.au>
wrote:

> On Tue, Oct 15, 2002 at 02:15:30PM +0200, Matthias Benkmann wrote:
> > I think with all the changes going on right now with gcc-3.3 and
> > glibc-2.3.1 and other unstable packages that will become part of a
> > future LFS version (e.g. coreutils) we need an unstable branch of the
> > LFS book.
> 
> An interesting and good idea.. but I don't believe it is workable. In my
> estimation, there is simply not enuff manpower and/or knowledge to
> sustain the effort of maintaining what amounts to 2 separate books.

I don't think it would take that much additional effort. Checking in a new
patch now and then doesn't take much time. And it's effort that will be
saved later.
 
> PS - I have no idea why you're even bothering with gcc-3.3. 

There is a German proverb:"Was Du heute kannst besorgen, das verschiebe
nicht auf morgen." Roughly translates as: If you can do it today, don't
put it off until tomorrow.
Besides, I use gcc 3.x only to check if my own projects will compile with
it. I hope that by the time 3.3 is released most of the problems will be
resolved (both in gcc and other projects) so that I can finally upgrade.
I have no intention of upgrading to gcc 3.2.x.

> 2003. The next obvious upgrade for LFS will be gcc-3.2.x/glibc2.3.x
> which is what we should be testing.

Yes. This is a change appropriate for the stable CVS branch as these are
officially released packages. But this doesn't mean that it's wrong to
build bleeding edge systems with gcc 3.3. You're assuming that this pulls
off resources that would otherwise be used for testing gcc-3.2.x, but I
don't think this is true. It certainly does not apply to me.

MSB

-- 
Support bacteria - they're the only culture some people have.

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list