Tracks


[I've re-edited this message to unpdate its contents.]

From: Rick Moen rick@linuxmafia.com
To: linux-elitists@zgp.org
Subject: Re: [linux-elitists] sarge
Date: Wed, 24 Dec 2003 12:11:12 -0800
User-Agent: Mutt/1.5.4i

Quoting Seth David Schoen (schoen@loyalty.org):

> I, for one, would be glad to hear about this again, because I keep
> getting a bit confused by it. (I wish the Debian installers would
> point at a URL with a detailed explanation, too.)

I note with gratitude Adam Kessel's contribution to this thread. I'm not a Debian developer, but will try to explain further, anyway. I'm going to try for a comprehensive rundown, sufficient even for the completely un-initiated, in hopes of archiving it for reference.

If you look in ftp://ftp.debian.org/debian/dists/ , today, you'll see contents that include these:

drwxrwsr-x 5 1176 1176 4096 Nov 20 18:57 woody
drwxrwsr-x 5 1176 1176 4096 Dec 23 20:47 sarge
drwxrwsr-x 5 1176 1176 4096 Dec 23 20:47 sid

lrwxrwxrwx 1 1176 1176 5 Mar 25 2003 stable -> woody
lrwxrwxrwx 1 1176 1176 5 Mar 25 2003 testing -> sarge
lrwxrwxrwx 1 1176 1176 3 Mar 25 2003 unstable -> sid

lrwxrwxrwx 1 1176 1176 23 Nov 15 21:11 experimental -> ../project/experimental

lrwxrwxrwx 1 1176 1176 5 Nov 20 21:10 Debian3.0r2 -> woody


Debian has produced seven major "releases" of its software, and is working on an eighth. "Release" is a term of art, here — which point I'll return to, below.

Infomagic (a now-defunct mail-order CD house) screwed up the release of Debian 1.0, shipping CDs of broken development code, so there never was a 1.0 release. The other eight are:

buzz (release 1.1)
rex (1.2)
bo (1.3)
hamm (2.0)
slink (2.1)
potato (2.2)
woody (3.0) — current "stable" branch
sarge (3.1) — current "testing" branch

Plus, there is always:
sid — permanently-assigned track name for the "unstable" branch
skud — proposed track name for the "experimental" branch

Sid was the sadistic neighbour boy in "Toy Story" who liked to break toys. Skud was his dog, who enjoyed chewing on toys.

For purposes of this explanation, I'll call those Toy Story names "branches", in contrast to "tracks", a term I'll explain later.

When a branch gets started, it's assigned a name taken (thus far) from the movie "Toy Story" (in part because early Debian Project Leader Bruce Perens worked at Pixar Studios). As the branch nears release, it's also assigned a major version number, such as 3.0 for woody. The software contents of each branch at any given time is defined by what are in its part of the Debian package archives on the Net (e.g., within ftp.debian.org). At intervals decided by the Release Manager, a snapshot gets taken (and ISO9660 images made) for the convenience of CD vendors and similar, and assigned a minor version number, such as the Debian 3.0r2 shown above. You can thus ask a CD vendor "Is this Official Debian 3.0r2 you're selling, or are you doing some dodgy unofficial images of your own, the way Infomagic did back in 1995 with its so-called Debian 1.0?" ;->

What I'm calling "tracks" are implemented via those symbolic links ("stable", "testing", "unstable", and "experimental"), and indicate how far you wish to remain from the bleeding edge, as you apply updates retrieved from the Debian package repositories. Debian allows you to keep following the track you're on, as the symlink is progressively moved from one named branch to the other. Which is what will happen by default.

That is, someone who installed the Debian stable branch in 1998 would have initially gotten hamm/2.0, then more-or-less automatically progressed through slink/2.1, potato/2.2, and (currently) woody/3.0 as each in turn gained the "stable" symlink.[0] The day a named branch becomes the stable track (literally through a change of those symlinks), we speak of it being "released".


Roles of the tracks:

Stable: This track is intended to consist of highly reliable software, only. There are very few updates (other than the mass-replacement that occurs when a branch gets released); most are backports of security and essential bug-fixes. Remaining on stable is kept deliberately unexciting, by virtue of being very conservative — significantly more so than almost all other Linux distributions.

It should be noted that "stable" is the only track with comprehensive hands-off security updating, courtesy of the Debian Security Team. On the others, the local admin must manually oversee security to some degree.[1]

Unstable: This track (permanently pointed to the "sid" named branch) gives immediate access to all newly uploaded packages from Debian developers without delay — or significant quality checking. Accordingly, some of its offered packages may on occasion be exciting, in the worst senses of the word.

Testing: This track gives almost immediate access to packages in unstable, with the addition of automated package quarantining and quality checking, sufficient to catch most breakage. The Release Manager also sometimes intervenes manually to force or prevent inclusion of some packages, e.g., because otherwise dependencies would break because only some packages of a dependency group have cleared quarantine.

Experimental: This is a ghetto for software whose breakage might do great damage to systems — beyond the small-to-medium calamities that occasionally happen in unstable. If you're here, you were forewarned.


Daily operations:

This thread started because a poster asked whether he "should wait to switch from woody to sarge". Normally, such questions would never arise, because, when you install the (e.g.) current stable branch, its default maintenance/upgrade settings in /etc/apt/sources.list say, in effect "keep following the stable track". Thus, the local admin never needs to decide to switch branches; it's done for him automatically, following each release day. Like the theoretical fellow who installed hamm/2.0 in 1998, he's currently on woody/3.0 in late 2003, and will progress to sarge and beyond without really thinking about it.

You'll note this means that "releases" really don't amount to a hill of beans, once you have a Debian installation running. You might not ever notice them. You certainly don't have to reinstall. People coming from other distributions tend to be slow to realise this; it's a different way of thinking.

In normal circumstances, one would not specify a branch name in /etc/apt/sources.list, but rather a track name. E.g., it would say "stable" or "testing", not "woody" or "sarge". To do otherwise is to say "Please keep me on (e.g.) the woody versions of all packages, even after the branch gets mothballed." That would be rather perverse.

By contrast, one might naturally contemplate whether to switch from the stable to the testing track, or vice-versa.[2] That's the reason I asked the poster to clarify his objectives. "Stable" tends to remain about the same boringly trailing-edge, absolutely reliable system all the time. "Testing" is one judicious step back from the bleeding edge, and gives you early access to goodies. My systems tend to run either testing or be mixed testing/unstable systems. Testing is about as bleeding-edge as your average just-released distribution from the other major Linux distributors. Unstable is about as bleeding-edge as Mandrake Cooker.

Like Mandrake Cooker, Debian-unstable changes daily and is defined by what's available in Internet package repositories. Unlike the case with average just-released distributions from the other major Linux distributors, Debian-testing also evolves daily.

FYI: By contrast, turning a Debian-stable box into a mixture of stable and testing packages is a frequent bonehead error, and Not Recommended — because the resulting system is neither fish nor fowl. Instead, one can draw backports of recent software to the stable branch (recompiled to use its libraries and utilities) from unofficial repositories[3], if one is too timid to just take the obvious step of switching to testing.


General advice:

Stay on stable until you find yourself (1) whining softly (or otherwise) about its ancient architecture and lack of excitement, and (2) familiar with Debian's design and willing to solve occasional apt-get and dpkg glitches that arise on the testing branch. At that point, jump tracks.

And, if you want to really to help the project QA the software, join the developers on unstable, and file bug reports to the Debian BTS, http://bugs.debian.org/ aka http://www.debian.org/Bugs/ .

As Adam says, many people prefer unstable over testing because of fewer dependency snarls. Whether you encounter those snarls depends in part on how much you like certain notorious dependency hairballs (**cough** GNOME **cough** KDE **cough**). It's a tradeoff, involving the benefits and drawbacks of automated package quarantining.


-----

[0] See: "Gradual Upgrade" on http://linuxmafia.com/kb/Debian

It's also worth mentioning, since many Debian newcomers discover this only belatedly, that Debian's upgrading mechanisms will never move your system to a later kernel version without your telling it to; it will only retrieve revised packagings of the same kernel version. This is in sharp contrast to the many other Linux distributions that install a kernel package named (e.g.) "kernel" and blithely switch it to new versions without consulting the site admin. Debian never does this — as is hinted at by the fact that the kernel version number is part of the Debian package name.

So, if you originally installed Debian hamm/2.0, you thereby installed revision 4 of package "kernel-image-2.0.34". Maintenance updates would have fetched revisions 5 and up of that same 2.0.34 kernel package (as they became available), but would never — absent admin intervention — automatically progress to later 2.0.x (not to mention 2.2.x, 2.4.x, etc.) kernels.

Therefore, it is strongly in your interest to browse (e.g., via the aptitude utility) available kernel-image-* packages to find ones you might prefer to what you have. Note also, in particular, that the kernel you get at the end of Debian installation is customised for the needs of the installer, and sub-optimal for pretty much any other use. You should always replace the installation kernel with one of your choosing, immediately following Debian installation.

[1] See: "Testing Security" on http://linuxmafia.com/kb/Debian

[2] See: "Downgrading" on http://linuxmafia.com/kb/Debian

[3] See: "Unofficial Apt Repositories" on http://linuxmafia.com/kb/Debian.

-- 
Cheers,        "A raccoon tangled with a 23,000 volt line, today.  The results
Rick Moen       blacked out 1400 homes and, of course, one raccoon."
rick@linuxmafia.com                                  -- Steel City News