[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ weiter ]
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 zur Zeit 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 directory?,
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 für Entwickler relevante Dinge, wie z.B.:
Dieses Verzeichnis enthält Pakete und Werkzeuge, welche sich noch in der Entwicklung befinden und meist noch im Alpha-Status sind. Nutzer sollten keine der dort befindlichen Pakete nutzen, da diese selbst für erfahrene Nutzer gefährlich sein können.
dists
-Verzeichnis?Es gibt drei 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.6.1).
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 etch
(z.B. Debian GNU/Linux 4.0) und testing
ein symbolischer Link auf
lenny
. Dies bedeutet, dass etch die derzeitige
Stable-Distribution und lenny 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.4).
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 und Woody für Release 3.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 (R)) war der Spielzeughund,
Potato war, logischerweise, Mr. Potato (R),
Woody war der Cowboy,
Sarge war der Sergeant der grünen Plastiksoldaten,
Etch war die Spielzeugtafel (Etch-a-Sketch (R)).
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 current testing release
information
.
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
Debian
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.
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 (für /woody/ und folgende
Releases) 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. Für woody heißen diese disks-architecture; für sarge 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 directory?, 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« kann der Quellcode verfügbar sein, muss aber nicht.
Pakete werden in einem großen »Pool« gelagert, strukturiert nach dem Namen des Quellpaketes. Um dies zu verwalten, ist der Pool unterteilt in 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. Z.B. 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
Repository 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 4.0.4+nmu1, 3 January 2010