Moin moin und frohe Ostern. Anbei Kapitel 5 der FAQ -> ftparchives.sgml Grüße, André. -- André Appel .''`. Tannenhöhe 27 : :' : 38678 CLZ `. `'` http://www.family-appel.de/ `-
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 "distributions" 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 .
Es gibt zahlreiche zusätzliche Verzeichnisse:
Es gibt 3 Distributionen, die "stable", die "testing" und die "unstable" Distribution. Die "testing" Distribution kann zeitweise "frozen" sein (see ).
Dabei handelt es sich einfach um "Codenamen". Jeden 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 &releasename; (z.B. &debian; &release;) und testing ein symbolischer Link auf &testingreleasename;
Dies bedeutet, dass &releasename; die derzeitige stable-Distribution und &testingreleasename; die derzeitige testing-Distribution ist.
Unstable wiederum ist ein permanenter symbolischer link auf sid, da sid immer die unstable Distribution bleiben wird (siehe dazu ).
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 and woody für Release 3.0.
Bis jetzt wurden immer Charaktere des Films "Toy Story" von Pixar zur Namensgebung herangezogen:
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 :-)
Als es damals Sid noch nicht gab, besaß die Organisation der FTP-Sites eine große Schwachstelle: Es galt die Annahme, dass beim Erstellen einer Architektur im derzeitigen Unstable die Veröffentlichung erfolgte, sobald diese Distribution das neue Stable wurde. Allerdings ist dies für viele Architekturen nicht der Fall, mit dem Ergebnis das diese Verzeichniss zum Release-Termin verschoben werden mussten. Dies war extrem unpraktisch, da das Verschieben sehr viel Bandbreite verbrauchte.
Die Archiv-Administratoren umgingen dieses Problem jahrelang in dem sie Programme für unveröffentlichte Architekturen in einem speziellem Verzeichnis namens "sid" lagerten. Für diese unveröffentlichten Architekturen wurde, sobald sie dann veröffentlicht wurden, ein link vom derzeitigen stable auf sid gesetzt. Ab diesem Zeitpunkt wurden sie ganz normal innerhalb des "unstable" Zweiges erstellt. Diese Anordnung verwirrte allerdings die Benutzer.
Mit der Einführung von Paket-Pools (siehe auch ) wurden binäre Pakete an den vorschriftsmäßigen Orten des Pools gespeichert, unabhängig von der Distribution. Dadurch wird verhindert, dass mit der Veröffentlichung einer Distribution große Mengen an Bandbreite verbraucht werden (allerdings wird sukzessiv Bandbreite während der Entwicklung verbraucht).
All diese Pakete entsprechen den Einige Pakete z.B. haben Lizenzbedingungen welche die kommerzielle Nutzung verbieten. Wiederum andere können weitergegeben werden, sind aber eigentlich Shareware und keine Freeware. 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.
Pakete landen im testing Verzeichnis nachdem sie zu einem gewissen Grad in 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. Desweiteren müssen sie weniger release-kritische Fehler aufweisen als die aktuelle Version in testing. Auf diese Art erhofft man sich, dass "testing" immer nahe daran ist ein Release Kandidat zu werden.
Weitere Informationen über den Status von "testing" und über die einzelnen Pakete sind verfügbar unter 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 Bugs 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 release-kritische Fehler. Die "testing" Distribution kann auch in diesem Zustand während der "Testzyklen" verweilen, wenn der Release kurz bevor steht.
Alle Fehler in der "testing" Distribution die ein Paket an der Freigabe hindern oder den ganzen Release verhindern werden mitprotokoliert. Um mehr Details zu erfahren, siehe auch Sobald die Anzahl der Bugs sich einem akzeptablen Wert nähert wird die "testing" Distribution als "stable" deklariert und versehen 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
Das "unstable" Verzeichnis enthält eine Momentaufnahme des derzeitigen Entwicklungsystems. Benutzer dürfen dieses gerne benutzen und testen. Man sei aber gewarnt, dass es keine Garantie einer Betriebsfähigkeit gibt. Der Vorteil von "unstable" liegt darin, dass alle Pakete up-to-date sind. Wenn allerdings etwas kaputt geht: Pech gehabt :)
Natürlich gibt es in "unstable" genauso die Verzeichnisse "main", "contrib" und "non-free", die wie in "stable" beschrieben sortiert sind.
In jedem Hauptverzeichnis Da sind zu einem die binary-irgendwas Verzeichnisse welche die Index-Dateien für die Binary-Pakete 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 Archtitekturen für jeden Release ist unter Die Index Dateien in binary-* sind so genannte Pakete(.gz) und enthalten eine Zusammenfassung jedes Binary-Pakets welches in dieser Distribution zu finden ist. Die eigentlichen Binary-Pakete (für /woody/ und folgende Releases) liegen direkt in Desweiteren existiert ein Unterverzeichnis "source/", welches Index-Dateien für die Quellpakete jeder Distribution beinhaltet. Die Index-Datei dafür heißt Sources(.gz).
Zu guter Letzt existiert einen Satz von Unterverzeichnissen welche die für das Installationsystem notwendigen Index-Dateien 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 das der Quellcode zusammen mit dem eigentlichen Programm ausgeliefert wird oder wenigstens zur Verfügung steht.
Der Quellcode wird über das pool Verzeichnis (see ) verteilt, zusammen mit den architekturspezifischen Binärverzeichnissen. 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. pinez.B ist ein solches Paket, siehe auch .
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 Sektionen ("main, "contrib" und "non-free") und dann sortiert nach dem ersten Buchstaben des Quellpaketes. Diese Verzeichnisse enthalten zahlreiche Dateien: die Binär-Pakete für jede Architektur und die Quellpakete von denen die Binär-Pakete erstellt wurden.
Es ist möglich, herauszufinden wo ein Paket platziert ist, in dem 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.
Historisch betrachtet wurden Pakete früher in einem Unterverzeichnis von dists, abhängig davon zu welcher Distribution sie gehörten, gelagert. Dies verursachte zahlreiche Probleme, z.B. großen Bandbreitenverbrauch wenn größere Änderungen an einem Mirror vorgenommen wurden. Durch die Einführung des Paket-Pools konnte dies umgangen werden.
The dists directories are still used for the index files
used by programs like apt.
You may also still see paths containing dists/potato or
dists/woody in the Filename header field of some older packages.
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 Wenn man eigene Debian Pakete gebaut hat und diese mit den standard Debian Paketwerkzeugen installieren möchtest, 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 unter
Reply to: