unstable branch for LFS

Matthias Benkmann matthias at winterdrache.de
Tue Oct 15 13:54:01 PDT 2002

On Tue, 15 Oct 2002 15:16:09 -0500 Archaic <archaic at comcast.net> wrote:

> UNSTABLE would use a version that wasn't stable, like 2.0 or something.

Not necessarily. I don't propose to make it the rule to use the most
current version. In fact I don't think the unstable LFS branch
should/needs to become a permanent installation. I just think we need an
unstable branch for the next 6 months to carry the major changes that are
coming up in that period that are (IMHO) too big for CVS LFS (which as
I've said multiple times should only become better). I'm thinking
specifically of


and probably some other long awaited packages such as the overdue new tar.

And of course when a new package is officially released it should be put
into unstable immediately.

In other words: unstable will contain the most recent _stable_ release
plus _a_few_selected_ development versions. A development version should
only be put into unstable if there's a benefit to it. gcc-3.3 for instance
is good to have because we know that it will break some stuff because of
incompatible changes (that are not bugs, meaning they won't be fixed) and
we can work on these issues asap. coreutils (is there a release already?)
is an inevitable change that requires a rewrite of parts of the book and
it's good to get this straightened out before putting it up for broader
testing in the stable branch. grub and the new tar are stable as far as we
know so it's also beneficial to use them.
We should certainly not use broken CVS HEADs of packages in LFS unstable
just because we can.


Who is this General Failure,
and why is he reading my disk ?

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