The Debian Administrator's Handbook

Otherwise, this distribution frequently houses important modifications to base packages, whose integration into Unstable with serious bugs would have critical repercussions. It is, thus, a completely isolated distribution, its packages never migrate to another version (except by direct, express intervention of the maintainer or the ftpmasters).

1.5.2. The Unstable Status

Let us turn back to the case of a typical package. The maintainer creates an initial package, which they compile for the Unstable version and place on the ftp-master.debian.org server. This first event involves inspection and validation from the ftpmasters. The software is then available in the Unstable distribution, which is risky, but chosen by users who are more concerned with staying close to the cutting edge, with more up to date packages, than they are worried about serious bugs. They discover the program and then test it.

If they encounter bugs, they report them to the package's maintainer. The maintainer then regularly prepares corrected versions, which they upload to the server.

Every newly updated package is updated on all Debian mirrors around the world within less than six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. Most frequently, the maintainer has only one traditional PC and has compiled his package on i386 architecture (or amd64); the autobuilders take over and automatically compile versions for all the other architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.

Figure 1.2. Compilation of a package by the autobuilders

QUICK LOOK buildd, the Debian package recompiler

buildd is the abbreviation of “build daemon”. This program automatically recompiles new versions of Debian packages on the architectures on which it is hosted (cross-compiling not always being sufficient) .

Thus, to produce binaries for the sparc architecture, the project has sparc machines available (specifically, Sun brand). The program buildd runs on them continuously to create package binaries for sparc from source packages sent by Debian developers.

This software is used on all the computers serving autobuilders for Debian. By extension, the term buildd frequently is used to refer to these machines, which are generally reserved solely for this purpose.

1.5.3. Migration to Testing

A bit later, the package will have matured; compiled on all the architectures, it will not have undergone recent modifications. It is then a candidate for inclusion in the Testing distribution — a group of Unstable packages chosen according to some quantifiable criteria. Every day a program automatically selects the packages to include in Testing, according to elements guaranteeing a certain level of quality:

lack of critical bugs, or, at least fewer than the version currently included in Testing;

at least 10 days spent in Unstable, which is sufficient time to find and report any serious problems;

successful compilation on all officially supported architectures;

dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question.

This system is clearly not infallible; critical bugs are regularly found in packages included in Testing. Still, it is generally effective, and Testing poses far fewer problems than Unstable, being for many, a good compromise between stability and novelty.

NOTE Limitations of Testing

Very interesting in principle, Testing poses some practical problems: the tangle of cross-dependencies between packages is such that a package can never move there completely on its own. With packages all depending upon each other, it is necessary to move a large number simultaneously, which is impossible when some are uploading updates regularly. On the other hand, the script identifying the families of related packages works hard to create them (this would be an NP-complete problem, for which, fortunately, we know some good heuristics). This is why we can manually interact with and guide this script by suggesting groups of packages, or imposing the inclusion of certain packages in a group, even if this temporarily breaks some dependencies. This functionality is accessible to the Release Managers and their assistants.