Debian »Testing«-Distribution

Für grundlegende Benutzer-gerichtete Informationen über die Testing Distribution lesen Sie bitte die Debian-FAQ.

Ein wichtiges Detail, das beachtet werden sollte, sowohl für Benutzer wie auch für die Entwickler von Testing, 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. Sie wird aus der Unstable-Distribution von einem Satz aus Skripten generiert, die versuchen Pakete hinüber zu bewegen, die ausreichend wahrscheinlich keine veröffentlichungs-kritischen Fehler enthalten. Sie machen es 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 der folgenden Kriterien erfüllt:

  1. Es muss in Unstable für 10, 5 oder 2 Tage 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öffentlichungskritische Fehler enthalten, die nicht die aktuell in Testing enthaltene Version ebenfalls hat (lesen Sie weiter unten für 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. Der Arbeitsgang des Installierens der Pakete nach Testing darf keine Pakete beeinträchtigen, die sich augenblicklich in Testing befinden. (Lesen Sie weiter unten für 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 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 ==, <= oder << Varianten 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, einige 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, bevor die richtige Version von libtool 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.

Dies ist es, wo die textuelle Ausgabe [gzipped] nützlich ist: Sie gibt Hinweise (obgleich 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 das 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 bleibt zurück, 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, aber dies 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 bemerken, 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 ebenfalls 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 für 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 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 Archiv entfernt wird, bevor Ihr Paket nach Testing übergehen kann. Sie müssen das Löschen der Pakete auf der entfernten Architektur aus dem Unstable-Archiv in einem Fehler gegen ftp.debian.org beantragen. 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.

Der 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 (>= etwas), apache-common (<< etwas) 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 werden sie später eine andere Logik anwenden (manches Mal durch einen manuellen Eingriff ausgelöst): Sie ignorieren die Tatsache, dass apache-common Sachen beeinträchtigt, und machen mit Dingen weiter, die funktionieren; wenn es immer noch nicht funktioniert, wenn wir mit allem fertig sind, was getan werden kann, zu schade, aber vielleicht wird es funktionieren. Später werden sie all die zufälligen libapache-foo-Pakete versuchen und sehen, dass diese tatsächlich funktionieren.

Nachdem alles versucht wurde, prüfen sie, wie viele Pakete beeinträchtigt wurden, bewerten, ob dies besser oder schlechter ist, als das was ursprünglich vorhanden war, um entweder alles zu akzeptieren oder es zu vergessen. 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 zerbricht. Die Zeilen von update_output.txt, die mit accepted beginnen, zeigen Dinge an, die 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 Architektur mit Problemen 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 der Migration von Paketen von Unstable nach Testing dar:

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 implementiert wurde, nachdem sie geschrieben war.

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

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