[ 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: die »Stable«-, die »Testing«- und die »Unstable«-Distribution. Die »Testing«-Distribution kann zeitweise »Frozen« 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. 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 erfahrendsten 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. Jede Debian-Distribution, die sich
noch in der Entwicklung befindet, besitzt 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 jessie
(z.B. Debian GNU/Linux 8) und testing
ein symbolischer Link auf
stretch
. Dies bedeutet, dass jessie die derzeitige
Stable-Distribution und stretch die derzeitige
Testing-Distribution ist.
unstable
wiederum ist ein permanenter symbolischer Link auf
sid
, da Sid immer die instabile Distribution bleiben
wird (siehe dazu Was ist mit »Sid«?, Abschnitt 6.3).
Andere, bereits verwendete Codename 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 und Etch für Release 4.0.
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.
Sid war der Junge von nebenan, welcher immer die Spielzeuge kaputt machte.
Sid oder Unstable ist der Ort wo die meisten Pakete als erstes 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 ursprünglich aus dem Animationsfilm »Toy Story«: Sid war der Junge von Nebenan der immer Spielzeuge zerstörte :-)
[1]
stable/main/: Dieses Verzeichnis enthält die Pakete, welche zur Zeit die neuste Veröffentlichung des Debian GNU/Linux-Systems darstellen.
All diese Pakete entsprechen den Debian-Richtlinien für freie Software Debian Free Software
Guidelines
und sind damit frei benutzbar und verbreitbar.
stable/non-free/: Dieses Verzeichnis enthält Pakete welche auf die eine oder andere Art durch Copyright-Bedingungen eingeschränkt sind.
Einige Pakete z.B. haben Lizenzbedingungen welche die kommerzielle Nutzung verbieten. Wiederum andere können weitergegeben werden, sind aber eigentlich 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 welche frei im Sinne der DFSG und frei verteilbar sind, aber von Paketen abhängen, welche 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ängigkeiten geben, welche sie uninstallierbar machen würden. Des Weiteren müssen sie weniger veröffentlichungskritische Fehler aufweisen als die aktuelle Version in »Testing«. Auf diese Art erhofft man, dass Testing immer nahe daran ist ein Release-Kandidat zu werden.
Weitere Informationen über den Status von Testing und über die einzelnen Pakete
sind unter http://www.debian.org/devel/testing
verfügbar.
Sobald die »Testing«-Distribution weit genug fortgeschritten ist, erhält sie den »frozen«-Status durch den Release-Manager. Die normalen Verzögerungspausen der Aufnahme von Paketen nach »Testing« werden verlängert, um so weniger 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 in diesem Zustand während der »Testzyklen« verweilen, wenn die Veröffentlichung kurz bevor steht.
Alle Fehler in der »Testing«-Distribution die ein Paket an der Freigabe hindern
oder die ganze Veröffentlichung verhindern, werden mitprotokolliert. Um mehr
Details zu erfahren, siehe auch Debian »Testing«
Release-Informationen
.
Sobald die Anzahl der Fehler sich einem akzeptablen Wert nähert, wird die eingefrorene »Testing«-Distribution als »Stable« deklariert und mit einer Versionsnummer freigegeben.
Mit jedem neuen Release ist die vorhergegangene »Stable«-Distribution überholt
und wird in das Archiv verschoben. Für weitere Informationen, siehe auch
Distributions-Archive
.
Das »unstable«-Verzeichnis enthält eine Momentaufnahme des derzeitigen Entwicklungssystems. Benutzer dürfen dieses gerne benutzen und testen. Man sei aber gewarnt, dass es keine Garantie einer Lauffähigkeit gibt. Der Vorteil von »Unstable« liegt darin, dass alle Pakete aktuell sind. Wenn allerdings etwas kaputt geht: Pech gehabt :)
Natürlich gibt es in »Unstable« genauso die Verzeichnisse »main«, »contrib« und »non-free«, die, wie für das »stable«-Verzeichnis beschrieben, sortiert sind.
Die für Debian paketierte Software ist in einem von zahlreichen Verzeichnisbäumen auf jedem Debian-Spiegel verfügbar.
Das dists
-Verzeichnis ist die Abkürzung für »Distributionen« und
ist der übliche Weg, um auf die zurzeit verfügbaren Debian-Distributionen (und
deren Vorgänger) zuzugreifen.
Das pool
-Verzeichnis enthält die eigentlichen Pakete, siehe dazu
auch Was befindet sich im pool-Verzeichnis?,
Abschnitt 6.10.
Es gibt zahlreiche zusätzliche Verzeichnisse:
enthält DOS-Werkzeuge zum Erstellen von boot-Disketten, zur Partionierung, zum Packen/Entpacken von Dateien und um Linux zu booten
enthält die grundlegende Debian-Dokumentation, wie z.B. die FAQ, die Anleitung für die Fehlerdatenbank, usw.
enthält die Dateien der Paketbetreuer und Teile der Konfigurationen der Archiv-Skipte
enthält hauptsächlich Material für Entwickler und verschiedene Dateien
In jedem Hauptverzeichnis [2] gibt es drei Zusammenstellungen von Unterverzeichnissen, welche Indexdateien enthalten.
Da sind zum einen die binary-irgendwas-Verzeichnisse welche die Indexdateien für die Binärpakete für jede verfügbare Computerarchitektur enthalten, z.B. /binary-i386/ für Pakete welche auf der Intel x86-Architektur laufen oder /binary-sparc/ für Pakete welche auf Sun-SPARCStationen laufen.
Die vollständige Liste der verfügbaren Architekturen für jedes Release ist
unter der Veröffentlichungs-Webseite
verfügbar. Für die derzeit aktuelle Veröffentlichung siehe auch Auf welchen Hardware-Architekturen/Systemen
läuft Debian GNU/Linux?, Abschnitt 4.1.
Die Indexdateien in binary-* heißen Packages
(.gz
) und
enthalten eine Zusammenfassung jedes Binärpakets welches in dieser Distribution
zu finden ist. Die eigentlichen Binärpakete liegen direkt im pool- Verzeichnis.
Des Weiteren existiert ein Unterverzeichnis »source/«, welches Indexdateien für
die Quellpakete jeder Distribution beinhaltet. Die Indexdatei dafür heißt
Sources
(.gz
).
Zu guter Letzt existiert ein Satz von Unterverzeichnissen, welche die für das Installationssystem notwendigen Indexdateien beinhalten. Diese liegen in debian-installer/binary-architecture.
Der gesamte Quellcode für alles in Debian ist verfügbar. Es ist sogar so, dass die Lizenzbedingungen der meisten Programme des Systems es verlangen, dass der Quellcode zusammen mit dem eigentlichen Programm ausgeliefert wird oder wenigstens zur Verfügung steht.
Der Quellcode wird über das pool
-Verzeichnis (siehe Was befindet sich im 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, kann man z.B. apt-get
source Paketname verwenden.
Einige Pakete werden auf Grund von Einschränkungen in ihren Lizenzen nur als Quellcode verteilt. pine z.B ist ein solches Paket, siehe auch Wo ist pine?, Abschnitt 5.10.
Für Pakete in »contrib« und »non-free«, welche rein formal nicht Teil des Debian-Systems sind, kann der Quellcode verfügbar sein, muss es aber nicht.
Pakete werden in einem großen »Pool« gelagert, strukturiert nach dem Namen des Quellpaketes. Um dies zu verwalten, 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.
Es ist möglich, herauszufinden wo ein Paket platziert ist, indem man
apt-cache showsrc Paketname ausführt und dann die
»Directory:«-Zeile betrachtet. Beispielsweise liegt das
apache
-Paket in pool/main/a/apache.
Zusätzlich werden die lib*-Pakete extra behandelt, da es einfach sehr viele sind: z.B. sind libpaper-Pakete in pool/main/libp/libpaper/ gespeichert.
[3]
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 damit in das Archiv darf.
Im Normalfall 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 von dort per Hand zu holen, die GPG-Signatur
und MD5-Checksumme 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 eigene Debian-Pakete verteilen möchte, welche nicht vom Debian-Projekt
verteilt werden. Informationen und Anleitungen wie dies zu bewerkstelligen
ist, findet man im Debian-Depot-HOWTO
.
[ 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 8.0, 1 May 2015