Kapitel 6. Die Debian-Archive

Inhaltsverzeichnis

6.1. Wie viele Debian-Distributionen gibt es?
6.2. Was haben all diese Namen wie Etch, Lenny usw. zu bedeuten?
6.2.1. Welche Codenamen wurden in der Vergangenheit verwendet?
6.2.2. Woher stammen diese Codenamen?
6.3. Was ist mit »Sid«?
6.4. Was enthält das stable-Verzeichnis?
6.5. Was enthält das testing-Verzeichnis?
6.5.1. Wie erhält Testing den »frozen«-Status?
6.6. Was enthält das unstable-Verzeichnis?
6.7. Was haben all die Verzeichnisse in den Debian-Archiven zu bedeuten?
6.8. Was haben die ganzen Verzeichnisse in dists/stable/main zu bedeuten?
6.9. Wo befindet sich der Quellcode?
6.10. Was befindet sich in dem pool-Verzeichnis?
6.11. Was ist »Incoming«?
6.12. Wie erstelle ich mein eigenes, apt-taugliches Paketdepot?

6.1. Wie viele Debian-Distributionen gibt es?

Es gibt drei große Distributionen: »Stable«, »Testing« und »Unstable«. Die »Testing«-Distribution kann zeitweise »Frozen« (eingefroren) sein (siehe Abschnitt 6.5.1, „Wie erhält Testing den »frozen«-Status?“). Daneben gibt es noch die Distributionen »Oldstable« und »Experimental«.

Experimental wird für Pakete benutzt, die sich noch in der Entwicklung befinden und daher die Stabilität ihres Systems hochgradig gefährden können. Diese Distribution benutzen Entwickler, welche absolut brandneue Software untersuchen möchten. Normale Benutzer sollten keine Pakete aus Experimental verwenden, weil sich diese selbst für die erfahrensten Benutzer als gefährlich oder schädlich erweisen können.

Für Hilfe bei der Auswahl einer geeigneten Debian-Distribution lesen Sie bitte Kapitel 3, Eine Debian-Distribution auswählen.

6.2. Was haben all diese Namen wie Etch, Lenny usw. zu bedeuten?

Dabei handelt es sich einfach um Codenamen. Wenn sich eine Debian-Distribution noch in der Entwicklung befindet, besitzt sie keine Versionsnummer, aber einen Codenamen. Der Zweck dieser Codenamen ist es, das Spiegeln von Debian-Distributionen zu vereinfachen (wenn ein echtes Verzeichnis wie unstable plötzlich in stable umbenannt werden würde, würden eine Menge an Daten sinnloserweise erneut heruntergeladen werden).

Zur Zeit ist stable ein symbolischer Link auf bullseye (also Debian GNU/Linux 11) und testing ein symbolischer Link auf bookworm. Dies bedeutet, dass bullseye die derzeitige Stable-Distribution und bookworm die derzeitige Testing-Distribution ist.

unstable wiederum ist ein permanenter symbolischer Link auf sid, da sid immer die Unstable-Distribution ist (siehe dazu Abschnitt 6.3, „Was ist mit »Sid«?“).

6.2.1. Welche Codenamen wurden in der Vergangenheit verwendet?

Andere, zusätzlich zu Bullseye und Bookworm bereits verwendete Codenamen sind: Buzz für Release 1.1, Rex für Release 1.2, Bo für Releases 1.3.x, Hamm für Release 2.0, Slink für Release 2.1, Potato für Release 2.2, Woody für Release 3.0, Sarge für Release 3.1, Etch für Release 4.0, Lenny für Release 5.0, Squeeze für Release 6.0, Wheezy für Release 7, Jessie für Release 8, Stretch für Release 9 und Buster für Release 10.

6.2.2. Woher stammen diese Codenamen?

Bis jetzt wurden immer Charaktere des Films »Toy Story« von Pixar zur Namensgebung herangezogen:

  • Buzz (Debian 1.1) war der Raumfahrer Buzz Lightyear,

  • Rex (Debian 1.2) war der Tyrannosaurus,

  • Bo (Debian 1.3) war Bo Peep, das Mädchen, welches die Schafe gehütet hat,

  • Hamm (Debian 2.0) war das Sparschwein,

  • Slink (Debian 2.1) war Slinky Dog, der Spielzeughund,

  • Potato (Debian 2.2) war, logischerweise, Mr. Potato,

  • Woody (Debian 3.0) war der Cowboy,

  • Sarge (Debian 3.1) war der Sergeant der grünen Plastiksoldaten,

  • Etch (Debian 4.0) war die Spielzeugtafel (Etch-a-Sketch),

  • Lenny (Debian 5.0) war das Fernglas,

  • Squeeze (Debian 6) hießen die dreiäugigen Aliens,

  • Wheezy (Debian 7) war der Gummipinguin mit der roten Fliege,

  • Jessie (Debian 8) war das jodelnde Cowgirl,

  • Stretch (Debian 9) war der Gummioktopus mit den Saugern an seinen acht Armen.

  • Buster (Debian 10) war Andys Spielzeughund.

  • Bullseye (Debian 11) war Woodys hölzernes Spielzeugpferd.

  • Bookworm (Debian 12) war ein grüner Spielzeugwurm mit eingebauter Taschenlampe, der es liebt, Bücher zu lesen.

  • Trixie (Debian 13) war ein blauer Plastik-Triceratops.

  • Sid war der bösartige Junge von nebenan, der immer die Spielzeuge kaputt machte.

Die Entscheidung, Toy-Story-Namen zu benutzen, wurde von Bruce Perens getroffen, der zu der Zeit Debian-Projektleiter war und ebenfalls bei Pixar (der Firma, die die Filme produziert hat) arbeitete.

6.3. Was ist mit »Sid«?

Sid oder Unstable ist der Ort, wo die meisten Pakete erstmals hochgeladen werden. Es wird nie direkt veröffentlicht werden, da zu veröffentlichende Pakete erst in Testing eingefügt werden, um dann später in Stable übernommen zu werden. Sid enthält Pakete für bereits veröffentlichte und unveröffentlichte Architekturen.

Der Name »Sid« kommt ebenfalls aus dem Animationsfilm »Toy Story«: Sid war der Junge von Nebenan, der immer die Spielzeuge zerstörte.

[2]

6.4. Was enthält das stable-Verzeichnis?

  • stable/main/: Dieses Verzeichnis enthält die Pakete, welche zur Zeit die neueste Veröffentlichung des Debian GNU/Linux-Systems darstellen.

    All diese Pakete entsprechen den Debian-Richtlinien für freie Software und sind damit frei benutzbar und verteilbar.

  • stable/non-free/: Dieses Verzeichnis enthält Pakete, deren Copyright-Bedingungen die Verbreitung auf die eine oder andere Art einschränken.

    Einige Pakete z.B. haben Lizenzbedingungen, die eine kommerzielle Verbreitung verbieten. Wiederum andere können weitergegeben werden, sind aber tatsächlich Shareware und keine freie Software. Die Lizenzbedingungen jedes dieser Pakete müssen genau gelesen und wahrscheinlich verhandelt werden, bevor eines der Pakete verteilt werden darf, z.B. auf einer CD-ROM.

  • stable/contrib/: Dieses Verzeichnis enthält Pakete, die den DFSG entsprechen und frei verteilbar sind, aber von Paketen abhängen, die nicht frei und deshalb nur in non-free zu finden sind.

6.5. Was enthält das testing-Verzeichnis?

Pakete landen im »testing«-Verzeichnis, nachdem sie zu einem gewissen Grad in Unstable getestet wurden.

Diese Pakete müssen identisch für alle Architekturen vorliegen, auf denen sie gebaut wurden. Es darf auch keine Abhängigkeit vorliegen, welche sie uninstallierbar machen würde. Des Weiteren müssen sie weniger veröffentlichungskritische Fehler aufweisen als die aktuelle Version in Unstable. Auf diese Art hoffen wir, dass Testing immer nahe daran ist, ein Release-Kandidat zu werden.

Weitere Informationen über den Status von Testing und über die einzelnen Pakete finden Sie unter https://www.debian.org/devel/testing.

6.5.1. Wie erhält Testing den »frozen«-Status?

Sobald die Testing-Distribution weit genug fortgeschritten ist, erhält sie durch den Release-Manager den »frozen«-Status. Die Verzögerungszeiten bis zur Aufnahme von Paketen nach Testing werden verlängert, um so wenig wie möglich neue Fehler von Unstable nach Testing zu lassen.

Nach einiger Zeit wird die Testing-Distribution dann wirklich »frozen«, also eingefroren. Dies bedeutet, dass alle neuen Pakete, die nach Testing sollen, zurückgehalten werden, außer sie beheben veröffentlichungskritische Fehler. Die Testing-Distribution kann auch während sogenannter »Testzyklen« in diesem Zustand verweilen, wenn die Veröffentlichung kurz bevor steht.

Wenn Testing »frozen« wird, tendiert auch Unstable dazu, teilweise einzufrieren. Das kommt daher, dass die Entwickler sich dabei zurückhalten, in großem Stil neue Software nach Unstable hochzuladen, und zwar aufgrund der Möglichkeit, dass die eingefrorene Software in Testing noch kleinere Korrekturen benötigt oder veröffentlichungskritische Fehler behoben werden müssen, die verhindern, dass Testing zu Stable wird.

Alle Fehler in der Testing-Distribution, die ein Paket an der Freigabe hindern oder die ganze Veröffentlichung verhindern, werden mitprotokolliert. Um mehr zu erfahren, schauen Sie in die Debian Testing Release-Informationen.

Sobald die Anzahl der Fehler sich einem akzeptablen Wert nähert, deklariert man die eingefrorene Testing-Distribution zur Stable-Distribution und veröffentlicht sie mit einer Versionsnummer.

Der wichtigste Fehlerzähler ist der »Release Critical bug count«, der Zähler für die veröffentlichungskritischen Fehler. Sie können ihn auf der Statusseite für veröffentlichungskritische Fehler verfolgen. Gemeinsames Ziel für eine Veröffentlichung ist No RC Bugs (keine veröffentlichungskritischen Fehler), was bedeutet, dass die Distribution keine Fehlerberichte der Kategorien »critical« (kritisch), »grave« (gravierend) oder »serious« (ernst) haben soll. Eine vollständige Liste von Problemen, die als kritisch angesehen werden, finden Sie im RC-Policy-Dokument.

Mit jedem neuen Release ist die vorhergegangene »Stable«-Distribution überholt und wird in das Archiv verschoben. Weitere Informationen finden Sie im Distributions-Archiv.

6.6. Was enthält das unstable-Verzeichnis?

Das »unstable«-Verzeichnis enthält eine Momentaufnahme des derzeitigen Entwicklungssystems. Benutzer können die Pakete darin ohne weiteres ausprobieren oder verwenden, sollten aber darauf eingestellt sein, dass diese unter Umständen nur bedingt einsatzreif sind. Der Vorteil von Unstable liegt darin, dass alle Pakete immer auf dem aktuellsten Stand der GNU/Linux-Entwicklung sind. Wenn allerdings etwas kaputt geht, sollten Sie wissen, wie sie mit den Bruchstücken umgehen müssen.

Unstable enthält ebenfalls die Unterverzeichnisse main, contrib und non-free. Die Pakete werden darin nach den bei Stable beschriebenen Kriterien abgelegt.

6.7. Was haben all die Verzeichnisse in den Debian-Archiven zu bedeuten?

Diese Verzeichnisse beeinhalten die durch Debian GNU/Linux bereitgestellte Software und sind auf jedem Debian-Spiegel anzutreffen.

Der Verzeichnisname dists steht kurz für »Distributionen«. In diesem Verzeichnis sind die aktuellen und frühere Debian-Distributionen hinterlegt.

Das pool-Verzeichnis enthält die eigentlichen Pakete, siehe dazu auch Abschnitt 6.10, „Was befindet sich in dem pool-Verzeichnis?“.

Ergänzend gibt es folgende Verzeichnisse:

/tools/:

enthält DOS-Werkzeuge zum Erstellen von Boot-Disketten, zum Partionieren Ihrer Festplatte, zum Packen/Entpacken von Dateien und zum Booten von Linux.

/doc/:

enthält die grundlegende Debian-Dokumentation, wie z.B. diese FAQ, die Anleitungen zum Umgang mit der Fehlerdatenbank, usw.

/indices/:

enthält verschiedene Auflistungen, darunter eine der Paketbetreuer sowie override-Dateien mit gewissen Merkmalen der Pakete.

/project/:

enthält hauptsächlich Material für Entwickler und verschiedene Dateien.

6.8. Was haben die ganzen Verzeichnisse in dists/stable/main zu bedeuten?

In jedem Hauptverzeichnis[3] gibt es drei Zusammenstellungen von Unterverzeichnissen, die Dateien mit Auflistungen der Binärpakete enthalten.

Da sind zum einen die binary-irgendwas-Verzeichnisse, welche Dateien mit Auflistungen der Binärpakete aller verfügbaren Computerarchitektur enthalten, z.B. /binary-i386/ für Pakete der Intel x86-Architektur oder /binary-sparc/ für Pakete, die auf Sun SPARCStations laufen.

Die vollständige Liste, welche Architekturen bei den Debian-Veröffentlichungen berücksichtigt wurden, ist auf der Debian-Webseite zu finden. Für die derzeit aktuelle Veröffentlichung finden Sie Details unter Abschnitt 4.1, „Auf welchen Hardware-Architekturen/Systemen läuft Debian GNU/Linux?“.

Das Verzeichnis binary-* enthält in den »Packages(.gz, .bz2)« benannten Dateien eine Zusammenfassung von Informationen zu jedem einzelnen Paket der Distribution. Die eigentlichen Binärpakete liegen direkt im pool-Verzeichnis.

Des Weiteren existiert ein Unterverzeichnis namens »source/«, das Dateien beinhaltet, welche die Quellpakete der Distribution auflisten. Diese Dateien heißen Sources(.gz, .bz2).

Zu guter Letzt existiert ein Satz von Unterverzeichnissen mit Dateien, die vom Installationssystem benötigte Auflistungen der Pakete enthalten. Diese liegen in debian-installer/binary-architektur.

6.9. Wo befindet sich der Quellcode?

Für jede in die Debian-Distributionen aufgenommene Software wird auch der Quellcode bereitgestellt. Es ist sogar so, dass die zugehörigen Lizenzbedingungen meistens verlangen, dass der Quellcode zusammen mit dem eigentlichen Programm ausgeliefert wird oder zumindest zur Verfügung steht.

Der Quellcode wird über das pool-Verzeichnis (siehe Abschnitt 6.10, „Was befindet sich in dem pool-Verzeichnis?“), zusammen mit den architekturspezifischen Binärverzeichnissen, verteilt. Um den Quellcode zu erhalten, ohne sich um die Archiv-Verzeichnisstruktur kümmern zu müssen, können Sie z. B. apt-get source PAKETNAME verwenden.

Aufgrund von Einschränkungen in den Lizenzen könnte der Quellcode bei Paketen in »contrib« und »non-free« eventuell nicht verfügbar sein (diese Bereiche gehören aber formal gesehen auch nicht zum Debian-System). In einigen Fällen dürfen nur Binärdateien (»binary blobs«) ohne deren Quellcode verteilt werden (wie z.B. bei firmware-misc-nonfree); in anderen Fällen verbietet die Lizenz die Verteilung von im Vornherein gebauten Binärdateien, erlaubt jedoch Quellcode-Pakete, die die Benutzer dann selbst übersetzen können (wie z.B. bei dem Paket broadcom-sta-dkms).

6.10. Was befindet sich in dem pool-Verzeichnis?

Pakete werden in einem großen, letztlich nach den Namen der Quellpakete untergliederten »Pool« gelagert. Der besseren Handhabbarkeit wegen ist das pool-Verzeichnis unterteilt in die Abschnitte (»main«, »contrib« und »non-free«) und dann sortiert nach dem ersten Buchstaben des Quellpaketes. Diese Verzeichnisse enthalten zahlreiche Dateien: die Binärpakete für jede Architektur und die Quellpakete, von denen die Binärpakete erstellt wurden.

Wo ein Paket abgelegt ist, laßt sich herausfinden, indem man apt-cache showsrc PAKETNAME ausführt und dann in der »Directory:«-Zeile nachschaut. Beispielsweise liegt das apache-Paket in pool/main/a/apache.

Da es sehr viele Bibliothekspakete (mit Namen lib*) gibt, ist der Pool hier noch feiner unterteilt, beispielsweise sind libpaper-Pakete in pool/main/libp/libpaper/ gespeichert.

[4]

6.11. Was ist »Incoming«?

Nachdem ein Entwickler ein Paket hochgeladen hat, bleibt es für eine kurze Zeit in dem »incoming«-Verzeichnis, bis es auf seine Echtheit überprüft wurde und somit in das Archiv darf.

Normalerweise sollte niemand etwas von dort installieren. Allerdings gibt es seltene Notfälle. Das incoming-Verzeichnis ist unter https://incoming.debian.org/ verfügbar. Es ist möglich, Pakete per Hand von dort zu holen, die GPG-Signatur und MD5-Prüfsumme in den .changes- und .dsc-Dateien zu überprüfen und sie dann zu installieren.

6.12. Wie erstelle ich mein eigenes, apt-taugliches Paketdepot?

Wenn man eigene Debian-Pakete gebaut hat und diese mit den Standard-Debian-Paketwerkzeugen installieren möchte, so ist es möglich, ein eigenes apt-taugliches Paketarchiv zu erstellen. Dies ist auch nützlich, wenn man nicht bei Debian GNU/Linux erhältliche Paketes selbst zur Verfügung stellen möchte. Informationen und Anleitungen, wie Sie dies bewerkstelligen, finden Sie im Debian Wiki.



[2] When the present-day sid did not exist, the FTP site organization had one major flaw: there was an assumption that when an architecture is created in the current unstable, it will be released when that distribution becomes the new stable. For many architectures that isn't the case, with the result that those directories had to be moved at release time. This was impractical because the move would chew up lots of bandwidth.

The archive administrators worked around this problem for several years by placing binaries for unreleased architectures in a special directory called "sid". For those architectures not yet released, the first time they were released there was a link from the current stable to sid, and from then on they were created inside the unstable tree as normal. This layout was somewhat confusing to users.

With the advent of package pools (see Abschnitt 6.10, „Was befindet sich in dem pool-Verzeichnis?“), binary packages began to be stored in a canonical location in the pool, regardless of the distribution, so releasing a distribution no longer causes large bandwidth consumption on the mirrors (there is, however, a lot of gradual bandwidth consumption throughout the development process).

[3] dists/stable/main, dists/stable/contrib, dists/stable/non-free, dists/unstable/main/ usw.

[4] Früher lagen die Pakete in dem zur jeweiligen Distribution gehörenden Unterverzeichnis von dists. Dies verursachte verschiedene Probleme. So zogen Änderungen beträchtlichen Datenverkehr nach sich. Der Paket-Pool stellte hierfür die Lösung dar.

Die dists-Verzeichnisse werden weiterhin als Ort für die Listendateien verwendet, die von Programmen wie apt genutzt werden.