Debian »Testing«-Distribution

Bezüglich grundlegender Informationen für Benutzer über die Testing-Distribution lesen Sie bitte die Debian-FAQ.

Ein wichtiges Detail, das beachtet werden sollte – sowohl von Benutzern als auch von Testing-Entwicklern – ist, dass Sicherheitsaktualisierungen für Testing nicht vom Sicherheitsteam verwaltet werden. Für weitere Informationen lesen Sie die FAQ des Sicherheitsteams.

Diese Seite behandelt primär die Aspekte von Testing, die für Debian-Entwickler wichtig sind.

Wie Testing arbeitet

Die Testing-Distribution ist eine automatisch generierte Distribution. Ein Satz von Skripten versucht, sie aus der Unstable-Distribution zu generieren, indem Pakete, die mit ausreichend hoher Wahrscheinlichkeit keine veröffentlichungs-kritischen Fehler enthalten, von Unstable nach Testing gebracht werden. Das läuft auf eine Art, die sicherstellt, dass die Abhängigkeiten von anderen Paketen in Testing immer aufgelöst werden können.

Ein Paket (eine bestimmte Version davon) wird nach Testing gebracht, wenn es alle folgenden Kriterien erfüllt:

  1. Es muss für 10, 5 oder 2 Tage in Unstable vorhanden sein, abhängig von der Dringlichkeit des Uploads;
  2. Es muss auf allen Architekturen übersetzt und aktuell sein, auf denen es zuvor für Unstable übersetzt war;
  3. Es darf keine veröffentlichungskritischen Fehler enthalten, die nicht die aktuell in Testing enthaltene Version ebenfalls hat (weiter unten finden Sie nähere Informationen);
  4. All seine Abhängigkeiten müssen entweder von Paketen erfüllt werden können, die sich bereits in Testing befinden, oder von der Gruppe der Pakete erfüllt werden, die zur gleichen Zeit installiert werden;
  5. Die Installation des Pakets in Testing darf keine Pakete beeinträchtigen, die sich augenblicklich in Testing befinden (weiter unten finden Sie weitere Informationen).

Ein Paket, das die ersten drei der oben angeführten Regeln erfüllt, wird Valid Candidate (gültiger Kandidat) genannt.

Das Update-Skript zeigt an, wann jedes Paket aus Unstable nach Testing eingebracht werden könnte. Die Ausgabe ist zweigeteilt:

Häufig gestellte/beantwortete Fragen

Was sind veröffentlichungskritische Fehler und wie werden sie gezählt?

Alle Fehler von einigen höheren Dringlichkeiten werden standardmäßig als veröffentlichungskritisch gezählt; im Augenblick sind das critical, grave und serious.

Von solchen Fehlern wird angenommen, dass sie eine Auswirkung auf die Chancen haben, dass ein Paket mit dem stabilen Release von Debian freigegeben wird; allgemein gesehen kommt ein Paket, das offene veröffentlichungskritische Fehler hat, nicht nach Testing, und wird infolgedessen nicht für Stable freigegeben.

Der Testing-Fehler-Zähler enthält alle veröffentlichungskritischen Fehler, die für Paket/Version-Kombinationen zutreffen, welche in Testing für eine Release-Architektur verfügbar sind.

Wie kann ein Paket, das nach Testing installiert wird, möglicherweise andere Pakete beeinträchtigen?

Die Distributionsarchive können jeweils nur eine Version eines Paketes enthalten; ein Paket ist durch seinen Namen definiert. Falls also das Quell-Paket acmefoo nach Testing installiert wird, gemeinsam mit seinen Binär-Paketen acme-foo-bin, acme-bar-bin, libacme-foo1 und libacme-foo-dev, wird die alte Version gelöscht.

Jedoch kann die alte Version ein Binär-Paket mit einer alten soname einer Bibliothek zur Verfügung stellen, wie libacme-foo0. Das Löschen der alten acmefoo wird libacme-foo0 löschen, was jedes Paket betrifft, das davon abhängig ist.

Offensichtlich betrifft dies hauptsächlich Pakete, die veränderliche Sätze von Binär-Paketen in verschiedenen Versionen zur Verfügung stellen (daher hauptsächlich Bibliotheken). Jedoch betrifft es ebenso Pakete, zu denen Versionsabhängigkeiten mit den Varianten ==, <= oder << definiert wurden.

Wenn die Menge der Binär-Pakete, die von einem Quellcode-Paket bereitgestellt werden, sich auf diese Weise ändert, müssen alle Pakete, die von den alten Binär-Dateien abhängen, aktualisiert werden, damit sie stattdessen von den neuen Binär-Dateien abhängen. Da die Installation eines solchen Quellcode-Pakets nach Testing alle Pakete in Testing beeinträchtigt, die von ihm abhängen, muss dabei sorgfältig vorgegangen werden: Alle abhängigen Pakete müssen aktualisiert werden und bereit für die Installation nach Testing sein, damit sie nicht beeinträchtigt werden. Wenn alles bereit ist, ist normalerweise auch noch das manuelle Eingreifen des Release-Betreuers oder eines Assistenten nötig.

Wenn Sie Probleme wie diese mit komplizierten Gruppen von Paketen haben, bitten Sie auf debian-devel oder debian-release um Hilfe.

Ich versteh' es immer noch nicht! Die Testing-Skripte sagen, dass dieses Paket ein gültiger Kandidat ist, aber es ist immer noch nicht in Testing.

Dies passiert meist dann, wenn die Installation des Paketes auf irgend eine Art – direkt oder indirekt – andere Pakete beeinträchtigen würde.

Vergessen Sie nicht, die Abhängigkeiten ihres Pakets zu bedenken. Nehmen wir an, ihr Paket ist von libtool abhängig, oder libltdlX. Ihr Paket wird nicht nach Testing kommen, solange die richtige Version von libtool nicht ebenfalls bereit ist, mitzukommen.

Das wiederum wird nicht passieren, bevor das Installieren von libtool keine Dinge beeinträchtigt, die sich bereits in Testing befinden. Anders ausgedrückt: bevor nicht alle anderen Pakete, die von libltdlY abhängig sind (wobei Y die frühere Version ist), neu übersetzt wurden und all deren veröffentlichungskritischen Fehler verschwunden sind usw., wird keines dieser Pakete nach Testing wandern.

Das ist der Punkt, an dem die textuelle Ausgabe [gzipped] nützlich ist: Sie gibt Hinweise (wenn auch nur sehr knappe), welche Pakete beeinträchtigt werden würden, wenn ein gültiger Kandidat zu Testing hinzugefügt wird (lesen Sie die Developer's Reference bezüglich weiterer Details).

Wieso ist es manchmal schwierig, Architecture: all-Pakete nach Testing zu bekommen?

Wenn ein Architecture: all-Paket installiert wird, muss es möglich sein, seine Abhängigkeiten auf allen Architekturen zu erfüllen. Wenn es von bestimmten Paketen abhängt, die sich nur auf einer beschränkten Anzahl der Debian-Architekturen übersetzen lassen, dann kann es dies nicht erfüllen.

Jedoch ignoriert Testing im Augenblick die Installationsmöglichkeit von Architecture: all-Paketen auf nicht-i386 Architekturen. (Es ist ein grober Hack und ich bin nicht wirklich damit zufrieden, ihn gemacht zu haben, aber hier ist er. –aj)

Mein Paket wird zurückgehalten, da es auf einigen Architekturen veraltet ist. Was kann ich tun?

Prüfen Sie den Status ihres Paketes in der Build-Log Datenbank. Falls sich das Paket nicht übersetzen lässt, wird es als failed markiert; untersuchen Sie das Build-Protokoll und beheben Sie die Probleme, die vom Quellcode ihres Pakets verursacht wurden.

Falls Sie bemerken, dass einige Architekturen die neue Version ihres Paketes gebaut haben, dies aber nicht in der Ausgabe der Testing-Skripte zu sehen ist, müssen Sie etwas geduldiger sein, bis der entsprechende buildd-Betreuer die Dateien in das Debian-Archiv hochlädt.

Falls Sie merken, dass einige Architekturen ihre neue Version des Pakets überhaupt nicht bauen – trotz der Tatsache, dass Sie eine Behebung für einen früheren Fehler hochgeladen haben – ist der Grund wahrscheinlich, dass es als auf Abhängigkeit wartend (Dep-Wait) markiert ist. Sie können sich auch die Liste dieser so genannten Möchte-bauen-Zustände ansehen, um sicher zu gehen.

Diese Probleme werden üblicherweise nach einiger Zeit behoben, aber falls Sie schon längere Zeit gewartet haben (sagen wir, zwei Wochen oder länger), informieren Sie den entsprechenden Portierungs-buildd-Betreuer, falls eine solche Adresse auf der Portierungs-Webseite angegeben ist, oder sonst die Mailingliste der Portierung.

Falls Sie explizit die Architektur aus der Architekturliste in der control-Datei entfernt haben und das Paket vorher auf dieser Architektur gebaut worden ist, müssen Sie beantragen, dass das alte Binärpaket für diese Architektur aus dem Unstable-Archiv entfernt wird, bevor Ihr Paket nach Testing wandern kann. Senden Sie dazu einen Fehlerbericht gegen das Pseudo-Paket ftp.debian.org. Aus Höflichkeit sollte stets die relevante Portierungsliste über diese Angelegenheit informiert werden.

Gibt es irgendwelche Ausnahmen? Ich bin sicher, dass acmefoo es gerade nach Testing geschafft hat, obwohl es nicht alle Anforderungen erfüllt hat.

Ein Release-Verwalter kann die Regeln auf zwei Arten umgehen:

Können Sie ein echtes, nicht-triviales Beispiel nennen?

Hier ist eines: Wenn das Quell-Paket apache nach Testing installiert wird, gemeinsam mit seinen Binär-Paketen apache, apache-common, apache-dev und apache-doc, wird die alte Version gelöscht.

Jedoch sind alle Apache-Module von apache-common (>= irgendeine), apache-common (<< irgendeine) abhängig, daher beeinträchtigt diese Änderung all diese Abhängigkeiten. Folglich müssen alle Apache-Module gegen die neue Version von Apache übersetzt werden, damit Testing aktualisiert werden kann.

Lassen Sie mich darauf etwas näher eingehen: Nachdem alle Module in Unstable aktualisiert wurden, um mit dem neuen Apache zusammenzuarbeiten, versuchen die Testing-Skripte apache-common und erkennen, dass das alle Apache-Module beeinträchtigen würde, da diese ein Depends: apache-common (<< die aktuelle Version) besitzen, und versuchen dann libapache-foo, um herauszufinden, dass es nicht installiert wird, weil es ein Depends: apache-common (>= die neue Version) hat.

Jedoch wird später eine andere Logik angewendet (manches Mal durch einen manuellen Eingriff ausgelöst): Sie ignoriert die Tatsache, dass apache-common gewisse Dinge beeinträchtigt, und fährt mit Dingen fort, die funktionieren; falls es immer noch nicht funktioniert, wenn alles erledigt ist, was getan werden kann – zu schade, aber vielleicht wird es funktionieren. Später werden all die zufälligen libapache-foo-Pakete ausprobiert und es stellt sich heraus, dass diese tatsächlich funktionieren.

Nachdem alles versucht wurde, wird geprüft, wie viele Pakete beeinträchtigt sind, bewertet, ob dies besser oder schlechter ist, als das was ursprünglich vorhanden war, und dann entschieden, ob entweder alles akzeptiert oder verworfen wird. Sie werden dies in update_output.txt in den recur:-Zeilen sehen.

Zum Beispiel:

         recur: [foo bar] baz

sagt grundsätzlich aus, habe bereits entdeckt, dass foo und bar Dinge verbessern und versuche nun baz, um zu sehen, was passiert, selbst wenn dies Dinge beschädigt. Die Zeilen von update_output.txt, die mit accepted beginnen, zeigen an, dass sich Dinge verbessern, und skipped-Zeilen verschlechtern die Dinge.

Die update_output.txt Datei ist komplett unleserlich!

Das ist keine Frage. ;-)

Nehmen wir ein Beispiel:

 skipped: cln (0) (150+4)
     got: 167+0: a-40:a-33:h-49:i-45
     * i386: ginac-cint, libginac-dev

Dies bedeutet, dass falls cln nach Testing kommt, ginac-cint und libginac-dev in Testing auf i386 nicht mehr installierbar sein werden. Beachten Sie, dass die Architekturen in alphabetischer Reihenfolge geprüft werden und nur die Probleme auf der ersten problematischen Architektur angezeigt werden – das ist der Grund, warum die Alpha-Architektur so oft angezeigt wird.

Die got-Zeilen beinhalten die Anzahl der Probleme in Testing auf den verschiedenen Architekturen (bis zur ersten Architektur, in der ein Problem gefunden wird – lesen Sie oben). Das i-45 bedeutet, dass falls cln nach Testing gebracht würde, würde es 45 nicht installierbare Pakete auf i386 geben. Einige der Einträge oberhalb und unterhalb von cln zeigen, dass es zurzeit 43 nicht installierbare Pakete in Testing auf i386 gibt.

Die skipped: cln (0) (150+4)-Zeile bedeutet, dass es immer noch 150 Pakete nach diesem Paket durchzuarbeiten gibt, bis diese Prüfung aller Pakete beendet ist, und dass 4 Pakete bereits gefunden wurden, von denen nicht geplant ist, sie zu aktualisieren, da sie Abhängigkeiten zerstören würden. Die (0) ist bedeutungslos, Sie können sie gefahrlos ignorieren.

Beachten Sie, dass es mehrere Tests für alle Pakete in einem Testing-Skript-Lauf gibt.

Jules Bean stellte ursprünglich die häufig gestellten Fragen und Antworten zusammen.

Zusätzliche Informationen

Die folgenden Seiten stellen zusätzliche Informationen über den aktuellen Zustand von Testing und die Migration von Paketen von Unstable nach Testing bereit:

Sie könnten auch daran interessiert sein, eine ältere E-Mail-Beschreibung zu lesen. Der einzige große Nachteil ist, dass sie den Paket-Pool nicht berücksichtigt, weil dieser von James Troup erst später implementiert wurde.

Der Testing-Code ist auf ftp-master verfügbar.

Anthony Towns gebührt der Dank für die Implementierung von Testing.