Unofficial Debian Testing FAQ

1. What is the 'testing' distribution?

   The testing distribution is an automatically generated distribution. It is generated from the unstable distribution by a set of scripts which attempt to move over packages which are reasonably likely to lack important bugs, and to do so in a way which ensures that dependencies of other packages in testing are always satisfiable

2. How can I tell when a package might move from unstable into testing?

   Have a look at the testing home page, and, in particular, the update excuses and update output files.

3. What determines when a package moves into testing?

   A (particular version of a) package will move into testing when it satisfies all of the following criteria:

   1. It must have been in unstable for 10, 5 or 2 days, depending on the urgency of the upload;
   2. It must be compiled on (at least) every architecture which the corresponding version in testing was compiled on;
   3. It must have fewer release-critical bugs than, or the same number as, the version currently in testing;
   4. All of its dependencies must either be satisfiable by packages already in testing, or be satisfiable by the group of packages which are going to be installed at the same time;
   5. The operation of installing the package into testing must not break any packages currently in testing. (See below for more information)

   A package which satisfies the first four of the above is said to be a Valid Candidate.

4. How could installing a package into testing possibly break other packages?

   The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So, when the source package acmefoo is installed into testing, along with its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version will be removed. The old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages which depend on it.

   Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <= or << varieties.

5. I still don't understand! The testing scripts say that this package is a valid candidate, but it still hasn't gone into testing.

   I believe this is bound to be answered by question 4 above. In some way, directly or indirectly, installing the package will break some other package.

   Remember to consider your package's dependencies. Suppose your package depends on libtool, or libltdlX. Your package won't go into testing until the right version of libtool is ready to go in with it. That won't happen until installing libtool doesn't break things already in testing, in other words until all other packages which depend on libltdlY (where Y is the earlier version) have been recompiled, and all their release critical bugs are gone, etc.

6. Are there any exceptions? I'm sure acmefoo has just made it into testing despite not satisfying all of the points you listed.

   I believe the release manager can override the above in two ways. He is capable of deciding that the breakage caused by the installation of a new library will make things better rather than worse, and letting it go in along with its flotilla of dependents.

   He is also capable of manually removing packages from testing that would be broken, so that new stuff can be installed

(Preserved by Rick Moen to prevent Jules Bean's work from vanishing, now that it is no longer available at http://people.debian.org/~jules/testingfaq.html.)