<!-- Subversion revision of original English document "5280" -->
<chapt id="ftparchives">Die Debian FTP-Archive

<sect id="dists">Wie viele Debian-Distributionen gibt es?

<p> Es gibt drei große Distributionen: die »Stable«-, die »Testing«- und die
»Unstable«-Distribution. Die »Testing«-Distribution kann zeitweise »Frozen«
sein (siehe <ref id="frozen">). Daneben gibt es noch die Distributionen 
»Oldstable« und »Experimental«.

<p>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.

<p>Für Hilfe bei der Auswahl einer geeigneten Debian-Distribution lesen Sie 
bitte <ref id="choosing">.

<sect id="codenames">Was haben all diese Namen wie »Etch«, »Lenny«, usw. zu
bedeuten?

<p>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
<file>unstable</file> plötzlich in <file>stable</file> umbenannt werden würde,
würden eine Menge an Daten sinnloserweise erneut heruntergeladen werden).

<p>Zur Zeit ist <file>stable</file> ein symbolischer Link auf
<file>&releasename;</file> (z.B. &debian; &release;) und <file>testing</file> ein
symbolischer Link auf <file>&testingreleasename;</file>. Dies bedeutet, dass
<tt>&releasename;</tt> die derzeitige Stable-Distribution und
<tt>&testingreleasename;</tt> die derzeitige Testing-Distribution ist.

<p><file>unstable</file> wiederum ist ein permanenter symbolischer Link auf
<file>sid</file>, da <tt>Sid</tt> immer die instabile Distribution bleiben wird
(siehe dazu <ref id="sid">).

<sect1 id="oldcodenames">Welche Codenamen wurden in der Vergangenheit
verwendet?

<p>Andere, bereits verwendete Codename sind: <tt>Buzz</tt> für
Release 1.1, <tt>Rex</tt> für Release 1.2, <tt>Bo</tt> für Releases 1.3.x,
<tt>Hamm</tt> für Release 2.0, <tt>Slink</tt> für Release 2.1,
<tt>Potato</tt> für Release 2.2, <tt>Woody</tt> für Release 
3.0, <tt>Sarge</tt> für Release 3.1 und <tt>Etch</tt> für Release 4.0.

<sect1 id="sourceforcodenames">Woher stammen diese Codenamen?

<p>Bis jetzt wurden immer Charaktere des Films »Toy Story« von Pixar zur
Namensgebung herangezogen:
<list>
  <item><em>Buzz</em> (Buzz Lightyear) war der Raumfahrer,
  <item><em>Rex</em> war der Tyrannosaurus,
  <item><em>Bo</em> (Bo Peep) war das Mädchen, welches die Schafe gehütet
  hat,
  <item><em>Hamm</em> war das Sparschwein,
  <item><em>Slink</em> (Slinky Dog) war der Spielzeughund,
  <item><em>Potato</em> war, logischerweise, Mr. Potato,
  <item><em>Woody</em> war der Cowboy,
  <item><em>Sarge</em> war der Sergeant der grünen Plastiksoldaten,
  <item><em>Etch</em> war die Spielzeugtafel (Etch-a-Sketch),
  <item><em>Lenny</em> war das Fernglas.

<!-- SID should be the last line always -->
  <item><em>Sid</em> war der Junge von nebenan, welcher immer die
  Spielzeuge kaputt machte.
</list>

<!-- Q: Should we add the trademark info here? Maybe as a footnote
  Mr. Potato is a Registered Trademark of Playskool, Inc.,
    Pawtucket, R.I., a division of Hasbro Inc.
  Slinky Dog is a trademark of Poof Products of Plymouth, Mich.,
  Etch-a-Sketch is a trademark of The Ohio Art Company,
  other characters might also be registered trademarks...
  (jfs)
-->
<!--
  more info in http://www.pixar.com/featurefilms/ts/
  and  http://www.pixar.com/featurefilms/ts2/
  or better yet http://us.imdb.com/M/title-exact?Toy%20Story%20(1995)
  or actually:
    http://us.imdb.com/Title?0114709 for TS1
    http://us.imdb.com/Title?0120363 for TS2
  we shouldn't put the links in, Pixar needs no additional propaganda
-->
<!--
  characters not used from Toy Story (yet):
    - Andy (the kid)
    - Snake
    - Robot
    - Scud (Sid's dog)
    - Lenny the Binoculars
    - Three Eyed Alien
    - Rocky (the wrestling figure)
    - Roller Bob (the remote control car)
    - Legs (one of sid's mutant toys)
    - Hand-in-the-box (one of sid's mutant toys)
    - Duckie (one of sid's mutant toys)
  and additional characters from Toy Story 2, also not yet used:
    - Al (the propietor of Al's Toy Farm)
    - Jessie (the Yodelling Cowgirl)
    - Bullseye (Woody's toy horse)
    - Zurg (the Evil Emperor)
    - Wheezy (the penguin)
    - Hannah (owner of Jessie)
    - Stinky Pete the Prospector (the old fat guy)
    - Mrs. Davis (Andy's Mom)
    - Barbie (the Tour Guide, probably under (c))
    - Mrs. Potato Head
    - Heimlich the Caterpillar
-->
<!-- (jfs) Just in case somebody misses the "What do we do when we finish
with Toy Story characters" thread see:
http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg01133.html
I, suggested we followed with either Monster's Inc or "A Bug's life" :)
-->

<sect id="sid">Was ist mit »Sid«?

<p><em>Sid</em> oder <em>Unstable</em> 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 <em>Testing</em> eingefügt werden, um
dann später in <em>Stable</em> übernommen zu werden. Sid enthält Pakete für
bereits veröffentlichte und unveröffentlichte Architekturen.

<p>Der Name »Sid« kommt ursprünglich aus dem Animationsfilm »Toy Story«:
Sid war der Junge von Nebenan der immer Spielzeuge zerstörte :-)

<p><footnote>
<p>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, dass diese Verzeichnisse zum
Release-Termin verschoben werden mussten. Dies war extrem unpraktisch, da
das Verschieben sehr viel Bandbreite verbrauchte.

<p>Die Archiv-Administratoren umgingen dieses Problem jahrelang, indem 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.

<p>Mit der Einführung von Paket-Pools (siehe auch <ref id="pools">) 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).

</footnote>

<sect id="stable">Was enthält das »stable«-Verzeichnis?

<p><list>
  <item>stable/main/:
  Dieses Verzeichnis enthält die Pakete, welche zur Zeit die neuste
  Veröffentlichung des &debian;-Systems darstellen.

  <p>All diese Pakete entsprechen den Debian-Richtlinien für freie Software
  <url name="Debian Free Software Guidelines"
  id="http://www.debian.org/social_contract#guidelines"> und sind damit
  frei benutzbar und verbreitbar.

  <item>stable/non-free/: Dieses Verzeichnis enthält Pakete welche auf die
  eine oder andere Art durch Copyright-Bedingungen eingeschränkt sind.

  <p>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.

  <item>stable/contrib/: Dieses Verzeichnis enthält Pakete welche frei im
  Sinne der DFSG und <em>frei verteilbar</em> sind, aber von Paketen
  abhängen, welche <em>nicht frei</em> und deshalb nur in non-free zu
  finden sind.

</list>

<sect id="testing">Was enthält das »testing«-Verzeichnis?

<p>Pakete landen im <file>testing</file>-Verzeichnis, nachdem sie zu einem gewissen Grad
in <qref id="unstable">Unstable</qref> getestet wurden.

<p>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.

<p>Weitere Informationen über den Status von Testing und über die
einzelnen Pakete sind unter <url id="http://www.debian.org/devel/testing">
verfügbar.

<sect1 id="frozen">Wie erhält »Testing« den »frozen«-Status?

<p>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.

<p>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.

<p>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 <url name="Debian »Testing« Release-Informationen" 
id="http://www.debian.org/releases/testing/">.

<p>Sobald die Anzahl der Fehler sich einem akzeptablen Wert nähert, wird die
eingefrorene »Testing«-Distribution als »Stable« deklariert und mit einer
Versionsnummer freigegeben.

<p>Mit jedem neuen Release ist die vorhergegangene »Stable«-Distribution
überholt und wird in das Archiv verschoben. Für weitere Informationen,
siehe auch <url name="Distributions-Archive"
id="http://www.debian.org/distrib/archive">.

<sect id="unstable">Was enthält das »unstable«-Verzeichnis?

<p>
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 :)

<p>Natürlich gibt es in »Unstable« genauso die Verzeichnisse »main«,
»contrib« und »non-free«, die, wie für das »stable«-Verzeichnis
beschrieben, sortiert sind.

<sect id="dirtree">Was haben all die Verzeichnisse in den Debian-FTP-Archiven
zu bedeuten?

<p>Die für Debian paketierte Software ist in einem von zahlreichen
Verzeichnisbäumen auf jedem Debian-Spiegel verfügbar.

<p>Das <file>dists</file>-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.

<p>Das <file>pool</file>-Verzeichnis enthält die eigentlichen Pakete, siehe
dazu auch <ref id="pools">.

<p>Es gibt zahlreiche zusätzliche Verzeichnisse:
<taglist>
  <tag><em>/tools/</em>:
    <item>enthält DOS-Werkzeuge zum Erstellen von boot-Disketten, zur
    Partionierung, zum Packen/Entpacken von Dateien und um Linux zu booten
  <tag><em>/doc/</em>:
    <item>enthält die grundlegende Debian-Dokumentation, wie z.B. die FAQ,
    die Anleitung für die Fehlerdatenbank, usw.
  <tag><em>/indices/</em>:
    <item>enthält die Dateien der Paketbetreuer und Teile der
    Konfigurationen der Archiv-Skipte
  <tag><em>/project/</em>:
	<item>enthält hauptsächlich Material für Entwickler und verschiedene 
Dateien
</taglist>

<sect id="archsections">Was haben die ganzen Verzeichnisse in
<tt>dists/stable/main</tt> zu bedeuten?

<p>In jedem Hauptverzeichnis
<footnote><tt>dists/stable/main</tt>, <tt>dists/stable/contrib</tt>,
<tt>dists/stable/non-free</tt> und <tt>dists/unstable/main/</tt>,
etc.</footnote> gibt es drei Zusammenstellungen von Unterverzeichnissen,
welche Indexdateien enthalten.

<p>Da sind zum einen die <tt>binary-<var>irgendwas</var></tt>-Verzeichnisse
welche die Indexdateien für die Binärpakete für jede verfügbare
Computerarchitektur enthalten, z.B. <tt>/binary-i386/</tt> für Pakete
welche auf der Intel x86-Architektur laufen oder <tt>/binary-sparc/</tt>
für Pakete welche auf Sun-SPARCStationen laufen.

<p>Die vollständige Liste der verfügbaren Architekturen für jedes Release
ist unter der <url name="Veröffentlichungs-Webseite"
id="http://www.debian.org/releases/"> verfügbar. Für die derzeit aktuelle
Veröffentlichung siehe auch <ref id="arches">.

<p>Die Indexdateien in binary-* heißen <file>Packages</file>(<file>.gz</file>) und enthalten
eine Zusammenfassung jedes Binärpakets welches in dieser Distribution zu
finden ist. Die eigentlichen Binärpakete liegen direkt im <qref id="pools"><tt>pool</tt>-
Verzeichnis</qref>.

<p>Des Weiteren existiert ein Unterverzeichnis »source/«, welches
Indexdateien für die Quellpakete jeder Distribution beinhaltet. Die
Indexdatei dafür heißt <file>Sources</file>(.<file>gz</file>).

<p>Zu guter Letzt existiert ein Satz von Unterverzeichnissen, welche die
für das Installationssystem notwendigen Indexdateien beinhalten. Diese liegen
in <tt>debian-installer/binary-<var>architecture</var></tt>.


<sect id="source">Wo befindet sich der Quellcode?

<p>Der gesamte Quellcode für alles in Debian ist verfügbar. Es ist sogar
so, dass die Lizenzbedingungen der meisten Programme des Systems es
<em>verlangen</em>, dass der Quellcode zusammen mit dem eigentlichen Programm
ausgeliefert wird oder wenigstens zur Verfügung steht.


<p>Der Quellcode wird über das <file>pool</file>-Verzeichnis (siehe <ref
id="pools">), 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. <tt>apt-get
source <var>Paketname</var></tt> verwenden.


<p>Einige Pakete werden auf Grund von Einschränkungen in ihren Lizenzen nur
als Quellcode verteilt. <tt>pine</tt> z.B ist ein solches Paket, siehe auch
<ref id="pine">.

<p>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.  

<sect id="pools">Was befindet sich im <tt>pool</tt>-Verzeichnis?

<p>Pakete werden in einem großen »Pool« gelagert, strukturiert nach dem
Namen des Quellpaketes. Um dies zu verwalten, ist das <tt>pool</tt>-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.

<p>Es ist möglich, herauszufinden wo ein Paket platziert ist, indem man
<tt>apt-cache showsrc <var>Paketname</var></tt> ausführt und dann die
»Directory:«-Zeile betrachtet. Beispielsweise liegt das <package>apache</package>-Paket in
<tt>pool/main/a/apache</tt>.

<p>Zusätzlich werden die <tt>lib*</tt>-Pakete extra behandelt, da es
einfach sehr viele sind: z.B. sind libpaper-Pakete in
<tt>pool/main/libp/libpaper/</tt> gespeichert.

<!-- joeyh doesn't want to maintain it so it's dead; need to integrate it
     If you want more information, see the
     <url id="http://people.debian.org/~joeyh/poolfaq"
     name="Debian Package Pools FAQ">.
-->

<p><footnote>
<p>Historisch betrachtet wurden Pakete früher in einem Unterverzeichnis von
<tt>dists</tt>, abhängig von der Zugehörigkeit zu einer Distribution,
gelagert. Dies verursachte zahlreiche Probleme, z.B. großen
Bandbreitenverbrauch wenn größere Änderungen an einem Spiegel vorgenommen
wurden. Durch die Einführung des Paket-Pools konnten diese umgangen werden.

<p>Die <tt>dists</tt>-Verzeichnisse werden immer noch für die Indexdateien
von Programmen wie <tt>apt</tt> genutzt.
</footnote>

<sect id="incoming">Was ist »Incoming«?

<p>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.


<p>Im Normalfall sollte niemand etwas von dort installieren. Allerdings
gibt es seltene Notfälle. Das »incoming«-Verzeichnis ist unter <url
id="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.

<sect id="ownrepository">Wie erstelle ich mein eigenes, apt-taugliches Paketdepot?

<p>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 <url name="Debian-Depot-HOWTO"
id="http://www.debian.org/doc/manuals/repository-howto/repository-howto">.

