[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ weiter ]
Es gibt drei große Distributionen: »Stable«, »Testing« und »Unstable«. Die »Testing«-Distribution kann zeitweise »Frozen« (eingefroren) sein (siehe Wie erhält Testing den »frozen«-Status?, Abschnitt 6.5.1). 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 Eine Debian-Distribution auswählen, Kapitel 3.
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 stretch (also Debian GNU/Linux 9) und testing ein symbolischer Link auf buster. Dies bedeutet, dass stretch die derzeitige Stable-Distribution und buster die derzeitige Testing-Distribution ist.
unstable wiederum ist ein permanenter symbolischer Link auf sid, da Sid immer die Unstable-Distribution ist (siehe dazu Was ist mit »Sid«?, Abschnitt 6.3).
Andere, zusätzlich zu stretch und buster 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 und Stretch für Release 9.
Bis jetzt wurden immer Charaktere des Films »Toy Story« von Pixar zur Namensgebung herangezogen:
Buzz (Buzz Lightyear) war der Raumfahrer,
Rex war der Tyrannosaurus,
Bo (Bo Peep) war das Mädchen, welches die Schafe gehütet hat,
Hamm war das Sparschwein,
Slink (Slinky Dog) war der Spielzeughund,
Potato war, logischerweise, Mr. Potato,
Woody war der Cowboy,
Sarge war der Sergeant der grünen Plastiksoldaten,
Etch war die Spielzeugtafel (Etch-a-Sketch),
Lenny war das Fernglas,
Squeeze hießen die dreiäugige Aliens,
wheezy (Debian 7) was the rubber toy penguin with a red bow tie,
jessie (Debian 8) was the yodeling cowgirl,
stretch (Debian 9) was the rubber toy octopus with suckers on her eight long arms.
buster (Debian 10) was Andy's pet dog.
bullseye (Debian 11) was Woody's wooden toyhorse.
bookworm (Debian 12) was a green toy worm with a built-in flashlight who loves reading books.
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.
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]
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.
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 http://www.debian.org/devel/testing
.
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
.
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.
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 Was befindet sich in dem pool-Verzeichnis?, Abschnitt 6.10.
Ergänzend gibt es folgende Verzeichnisse:
enthält DOS-Werkzeuge zum Erstellen von Boot-Disketten, zum Partionieren Ihrer Festplatte, zum Packen/Entpacken von Dateien und zum Booten von Linux.
enthält die grundlegende Debian-Dokumentation, wie z.B. diese FAQ, die Anleitungen zum Umgang mit der Fehlerdatenbank, usw.
enthält verschiedene Auflistungen, darunter eine der Paketbetreuer sowie override-Dateien mit gewissen Merkmalen der Pakete.
enthält hauptsächlich Material für Entwickler und verschiedene Dateien.
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 Auf welchen Hardware-Architekturen/Systemen
läuft Debian GNU/Linux?, Abschnitt 4.1.
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.
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 Was befindet sich in dem pool-Verzeichnis?, Abschnitt 6.10), zusammen mit den architekturspezifischen Binärverzeichnissen, verteilt. Um den Quellcode zu erhalten, ohne sich um die FTP-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).
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]
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 http://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.
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
.
[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ weiter ]
Die Debian GNU/Linux-FAQ
Version 9.0, 19 November 2020