[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dangers of "stable" in sources.list



On Fri, May 04, 2007 at 03:49:08AM -0400, Kevin Mark wrote:
> why I'd never use it. So I'd be for one of these two:
> -removing the public link to 'stable'
> -putting a strong warning in the Debian reference about the hazards of
>  using it.
> So if someone uses 'stable', do tell. And if so, would you want a newbie
> to use it?
> -k
If I'm building machines for work or anywhere that needs machines to 
stay static for a long time:

Change to release name _at the time of release_ to make sure that
I actually get the "new" stable. Immediately I'm installed - switch it 
to stable.

If I then come back to the machine six months later - cat 
/etc/apt/sources.list - think "OK, this one was installed as stable and
will just run". 

Code names were/are a convenience for developers and discussion 
and widespread use came about following Debian 1.0 :)

As my fairly regular message goes: stable/testing/unstable don't 
necessarily refer to stability of the apps. They do relate to how 
fast/far the archive changes over time: unstable may mean large package 
churn daily/weekly and testing will periodically receive very large 
changes. 

Stable, however, once released is designed to be unconditionally stable 
- new features/versions are NOT introduced. Security fixes are back 
ported to avoid unpleasant surprises mid-release cycle.

Stable serves a very useful purpose: it reminds me that the machine
is meant to be stable - "Etch" may not mean anything to anyone else
but "stable" does, especially to the ears of management :)
Two years from now, you may be struggling to recall codenames 
immediately but you will know the difference between Debian 3.0, 3.1 and 
4.0

It might be an idea to change policy for stable on just one package:
with the final release of say, Sarge (which came a few hours before the 
release of Etch) change the base configuration files so that they and
the /etc/apt/sources.list flip to oldstable. If the change is also 
publicised on the mailing lists etc. - those who don't want to get hit 
by the upgrade don't have to follow it immediately. If need be, add an 
optional little package "staystable" which does this change which 
conflicts/replaces "trackrelease" (this might be handled with a debconf 
question as an alternative).

Andy
> -- 
> |  .''`.  == Debian GNU/Linux == |       my web site:           |
> | : :' :      The  Universal     |mysite.verizon.net/kevin.mark/|
> | `. `'      Operating System    | go to counter.li.org and     |
> |   `-    http://www.debian.org/ |    be counted! #238656       |
> |  my keyserver: subkeys.pgp.net |     my NPO: cfsg.org         |
> |join the new debian-community.org to help Debian!              |
> |_______  Unless I ask to be CCd, assume I am subscribed _______|
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: