Hi, The testing scripts (aka "britney") seem to be a "black box" for some developers. The intent of this mail is to give some information to prevent common misunderstandings. outdated on some arches ~~~~~~~~~~~~~~~~~~~~~~~ "outdated" means for britney: There are different versions in unstable for the release architectures (except for the architectures in fuckedarches; fuckedarches is an list of architectures that don't keep up (in update_out.py), but currently, it's empty). "outdated" has nothing whatsoever to do with the architectures this package has in testing. Consider this example: foo | alpha | arm ---------+-------+---- testing | 1 | - unstable | 1 | 2 The package is out of date on alpha in unstable, and will not go to testing. And removing foo from testing would not help at all, the package is still out of date on alpha, and will not propagate to testing. However, if ftp-master removes a package in unstable (here on arm): foo | alpha | arm | hurd-i386 ---------+-------+-----+---------- testing | 1 | 1 | - unstable | 2 | - | 1 In this case, the package is up to date on all release architectures in unstable (and the extra hurd-i386 doesn't matter, as it's not a release architecture). Sometimes, the question is raised if it is possible to allow packages in that are not yet built on all architectures: No. Just plainly no. (Except if you maintain glibc or so, but then you probably know much more about britney than this mail tells you.) package removals ~~~~~~~~~~~~~~~~ Sometimes, a package is removed to allow another package in: This happens only to allow _another_ package to go in, that's ready in every other sense. Consider e.g. that a conflicts with the new version of b; than a may be removed to allow b in. Of course, there is another reason to remove a package from testing: It's just too buggy (and having a single RC-bug is enough to be in this state). circular dependencies ~~~~~~~~~~~~~~~~~~~~~ A situation that is not handled very well by britney is if package a depends on the new version of package b, and vice versa. An example of this is: | testing | unstable --+-----------------+------------ a | 1; depends: b=1 | 2; depends: b=2 b | 1; depends: a=1 | 2; depends: a=2 Package a is not considered for update, and package b also not. Currently, this requires some manual hinting from the release masters. Please, send mail to debian-release@lists.debian.org if that happens to one of your packages. exceptions ~~~~~~~~~~ Of course, there are hammers. But, the goal of britney is that testing is always in a releasable state, and if hammers are used too often, we'll just void that. So, the hammers are not for everyday use, and just because a hammer was used on another package, that doesn't mean that it'll also be used on your package. influence of package in testing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Generally, there is nothing that the status of a package in testing means for transition of the next version from unstable to testing, with two exceptions: If the RC-bugginess of the package goes down, it may go in even if it is still RC-buggy. The second exception is if the version of the package in testing is out of sync on the different arches: Then any arch might just upgrade to the version of the source package; however, this can happen only if the package was previously forced through, or the arch is in fuckedarches. In summary this means: The only influence that a package being in testing has on a new version of the same package is that the new version might go in easier. details ~~~~~~~ If you are interested in details, this is how britney works: 1. The packages are looked at to determine whether they are valid candidates. This gives the "update excuses". The most common reasons why a package is not considered are too young, RC-bugginess and out of date on some arches. For this part, the release managers have hammers of any size to force britney to consider a package. (Also, the base freeze is coded in that part of britney.) (There is a similar thing for binary-only updates, but I'll not cover that in this mail.) 2. Now, the more complex part happens: Britney tries to update testing with the valid candidates; first, each package alone, and then larger and even larger sets of packages together. Each try is accepted if sarge is not more uninstallable after the update as before. (Before and after this part, some hints are processed; but as only release masters can hint, this is probably not so important for you.) If you want to see more details, you can look it up on merkel:/org/ftp.debian.org/testing/update_out/ (or there in ~aba/testing/update_out to see a setup with a smaller packages file). Via web, it's at http://ftp-master.debian.org/testing/update_out_code/ The hints are available via http://ftp-master.debian.org/testing/hints/ and the general information about the testing distribution is at http://www.debian.org/devel/testing (and the information from this mail is added soon to the web site). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Attachment:
pgppeanOFdomu.pgp
Description: PGP signature