unstable branch for LFS

Matthias Benkmann matthias at winterdrache.de
Tue Oct 15 06:44:19 PDT 2002

On Tue, 15 Oct 2002 15:28:25 +0200 "zigman2k" <zigman at gmx.net> wrote:

> thats what i think too... cvs is sometimes unstable.. everyone who tryes
> cvs know that it might not even compile.

That is true for software projects but not true for LFS. For LFS, most of
the time CVS was at least as stable as the last release. Often CVS is
better than the last release because bugs are fixed. If we sacrifice this,
then the quality of our releases will deteriorate. Suppose the current CVS
is turned into unstable. It gets all kinds of new packages (gcc 3.3,
glibc-2.3, coreutils, unstable tar, procps from CVS,...) how will you get
this into a decent state? Fork a stable LFS-4-1 branch? Not a good idea.
The first thing you'd have to do on that branch is to replace a lot of the
packages with stable ones. And where do you get the proper patches for
those? They are not in CVS as they are not needed for the unstable
packages. So in your LFS-4-1 branch you mostly have to start from scratch
trying to get the mess that is mainline into a usable state.
HEAD must be kept close to what's supposed to become the next release.
HEAD must be HEADed towards the next release. But the unstable playground
LFS I want can never do this. It is much more like a parallel independent
project that occasionally gives input to LFS.


Indecision is the key to flexibility.

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