This appendix is intended for those of you who would like to take some of the skills you've learned in the body of this book and apply them to a Debian installation. While the body of this book is focused on Fedora and Red Hat, I encourage you to read it if you haven't already, as it provides the fundamentals required for any problem-solving endeavor. In this appendix you'll find explanations of those portions of Debian that catch many Fedora or Red Hat troubleshooters by surprise.
Debian is a multi-purpose distribution that aims to be "the universal operating system." Though the phrase itself is said tongue-in-cheek by Debian Developers, it's true that we maintain multiple distributions for different purposes. Each tree is independent of the others, and when somebody is running Debian, they're running exactly one of the trees described in the following sections.
Once every year or two, Debian releases what we call a stable release. CDs are pressed, mirrors are updated, and the announcement is made. Only the stable release of Debian has official CDs. The software contained in the stable release should be free of serious bugs, should be installable without difficulty, and has been proven reliable in the field.
Beware, though-Debian has its own meaning for the term stable. When we make a release, it's set in stone. The only updates we make to that software, once released, are of critical importance-bugs which affect security, data integrity, or the user's ability to install and use the package. We refer to these bugs as release-critical.
Once every three to six months, a revision for the last stable release is made. This is somewhat akin to a Windows service pack. In this revision, all security fixes that were released since the last revision or release are bundled together, and any other known release-critical bugs are fixed.
However, individual software packages aren't simply upgraded to the newest version available. Instead, the version that was released gets a patch that fixes only the serious problem(s). This allows for the most stable platform available, whether you're a developer, a systems integrator, a systems administrator, or even a user who really can't be bothered to go through a traumatic upgrade every six months. It may seem counterintuitive, but when you spend a few weeks working on a system and dealing with any oddities so that everything will work when you roll it out in a large environment, it's kind of a pain to have to do the same thing again six months down the line.
Debian/stable is primarily targeted at those individuals who want a stable platform to run their services on, whatever those might be-desktop, server or embedded device. Consider that even Debian/stable's relatively slow release cycle, one major release every year or two, isn't slow enough for everybody. Imagine a poor systems administrator with 2,000 individual systems that work perfectly fine, needing to upgrade them even once a year. That can be pretty time-consuming and expensive for even the largest of companies. Debian mitigates this issue by making sure that upgrades from an old Debian/stable to a newly-released Debian/stable can be done remotely without a great deal of effort on the part of the systems administrator.
As of this writing, the current Debian release is codenamed Woody, and rests at version 3.0r2. "3.0r2" translates to Debian 3.0, revision 2.
See the "Debian Archives Revisited-Official versus Unofficial" section of this appendix for a pointer on how to add updated packages to your Debian/stable installation via a popular unofficial Debian package repository.
Debian's testing tree isn't intended for use by regular end-users. It's a tree kept self-consistent and in a releasable state at all times. It doesn't get timely security updates. The exception to this rule is right before a release is going to be made; at that point, users are encouraged to test Debian/testing in an effort to find any last-minute bugs which might have slipped through quality assurance procedures.
I won't go into much detail about how Debian testing works, but it's worth mentioning that when it's decided that Debian is ready to make another stable release, this tree is given a version number and released. Right now, the testing tree is called Sarge. When our next release is made, Sarge will be released as the new Debian/stable. After this happens, a new Debian/testing tree will be created (a copy of the Debian/Sid tree described below), and it will be given a new codename.
When Sarge becomes Debian/stable, the old Debian/stable (currently Woody) will become Debian/old-stable. It will only be supported for a limited amount of time, typically a year, after which users are expected to seek external support or upgrade their systems.
I'll say again that this tree isn't meant for end-users. When it's safe for an end-user to install, public betas will be released. That happens nearer the end of a release cycle. Before the end of the release cycle, Debian/testing sees no timely security updates, and critical bugs in packages can go unfixed for weeks or longer.
The Sid tree, often referred to as the unstable tree, is the constantly-evolving branch of Debian which most Debian Developers and desktop users prefer. This tree contains the latest versions of software available in Debian, compared to Debian/stable, which contains older, tried-and-proven software. When a Debian Developer uploads a new or updated software package, they upload it to Sid.
It's rare, but very occasionally software packages will be updated in the Sid tree which might break a user's machine. Users commonly guard against this by asking other users if anything bad has happened to them, by checking for bug reports, or by tracking mailing lists or discussion groups. See the "Getting Help" section of this appendix for useful suggestions on how to track information which pertains to Sid.
Sid's codename is never changed; it will remain Sid for the foreseeable future. Only Debian/ stable and Debian/testing change codenames.