quick-reference/de/system.sgml

<!-- CVS revision of this document "$Revision: 1.8 $"  -->
<!-- CVS revision of original english document "1.41"  -->
<chapt id="system">Debian Grundlagen

<!-- 

Merged from 4 SGML files in FAQ February 2002
  ftparchives.sgml, 
  pkg_basics.sgml, 
  pkgtools.sgml, 
  uptodate.sgml

Then retitled under "Debian fundamentals" with 
 chapt moved to sect
 sect moved to sect1
 sect1 moved to sect2

Commented out reference to arches, should rewrite it to reference to 
release manual/install manual soon.
 
Pieces imported from other parts of FAQ.
 Small section from customizing.sgml regarding init/runlevel is added.
 Small section from customizing.sgml regarding diverse is added.
 Small section from software.sgml regarding non-English is added.

Merged from other SGML files in FAQ February 2002
  kernel.sgml

Then retitled under "Debian fundamentals" with 
 chapt moved to sect
 sect moved to sect1

Titles of sect/sect1 are changed to suit "Debian reference"

All minor edits I did left tracing information as comments.

Several sections were actually deleted since two consecutive -'s
made it impossible to comment out.

Also rewrote section to suit better for potato and woody.
Unless slink is used, how many people about dpkg-ftp :)

-->

<p>
Dieses Kapitel liefert grundlegende Informationen über das Debian System
für Nicht-Programmierer.  Für die ultimativen Informationen vergleiche:
<p>
<list compact>
<item>Debian Policy Manual
<item>Debian Packaging Manual (Potato)
<item>Debian Developer's Reference
<item>Debian New Maintainers' Guide
<p>
</list>
aufgeführt unter <ref id="references">.

<p>
Wenn Sie nach nicht allzu ausführlichen "wie geht" Erklärungen suchen,
wechseln Sie direkt nach <ref id="package"> oder in andere relevante Kapitel.
<p>
Dieses Kapitel besteht aus Dokumenten aus der "Debian FAQ", größtenteils
umgeschrieben, um dem gewöhnlichen Debian System Administrator den Einstieg
zu erleichtern.

<!-- 
"FTP archives" is now changed to simple "archives" since it can be reached 
through HTTP and other methods
-->

<sect id="ftparchives">Die Debian Archive

<sect1 id="dirtree">Verzeichnisstrukturen

<p>Die Software, welche für &debian; gepackt wurde, ist in einem der
vielen Verzeichnisbäume auf jedem
<url id="&mirror-site;" name="Debian Mirror">
durch FTP oder HTTP verfügbar.

<p>Die folgenden Verzeichnisse können auf jedem Debian Mirror unter
dem <tt>/debian/</tt> Verzeichnis gefunden werden:
<taglist>
  <tag><file>/dists/</file>:
    <item>Dieses Verzeichnis enthält die "Distributionen" und ist für
    den Zugriff auf die aktuell verfügbaren Pakete in Debian ausgelegt.
    Einige alte Pakete und die <tt>Packages.gz</tt> Dateien sind immer
    noch hier zu finden.
  <tag><file>/pool/</file>:
    <item>Die neue Position aller Debian Pakete.
  <tag><file>/tools/</file>:
    <item>DOS Hilfsmittel zum Erzeugen von Bootdisketten, Partitionieren
    der Festplatte, Komprimieren/Dekomprimieren von Dateien und zum
    Booten von Linux.
  <tag><file>/doc/</file>:
    <item>Die grundlegenden Debian Dokumentationen wie die FAQ's,
          Erläuterungen zum Fehler-Melde-System, usw.
  <tag><file>/indices/</file>:
    <item>Die Maintainer Datei und die Override Dateien.<!-- FIXME -->
  <tag><file>/project/</file>:
    <item>Hauptsächlich Material, welches nur für Entwickler von Interesse
          ist, wie z.B.:
    <taglist>
      <tag><file>project/experimental/</file>:
        <item>Dieses Verzeichnis enthält Pakete und Hilfsmittel, welche
        noch entwickelt werden und sich noch im Alpha-Stadium befinden.
        Benutzer sollten keine Pakete von hier verwenden, da sie selbst
        für den Erfahrensten gefährlich und schädlich sind.
      <tag><file>project/orphaned/</file>:
        <item>Pakete, welche von ihrem alten Maintainer aufgegeben wurden
        und aus der Distribution zurückgezogene Software.
    </taglist>
</taglist>

<sect1 id="dists">Debian Distributionen

<p>Normalerweise befinden sich drei Debian Distributionen im <tt>dists</tt> 
Verzeichnis. Dies sind die "stable", die "testing" und die "unstable"
Distribution. Manchmal gibt es auch eine "frozen" Distribution.  Jede
Distribution ist ein symbolischer Link in das entsprechende Verzeichnis
mit einem Kodenamen im <tt>dists</tt> Verzeichnis.

<sect1 id="stable">Die <tt>stable</tt> Distribution

<p>Pakete der <tt>stable</tt> Distribution, &stabledebian;, 
befinden sich im <tt>stable</tt> (symbolischer Link zu
<tt>&stablecodename;</tt>) Verzeichnis:
<list>
  <item><file>stable/main/</file>:
  Dieses Verzeichnis enthält die Pakete, welche formal die aktuellste Ausgabe
  des &debian; Systems bilden.

  <p>Diese Pakete entsprechen alle den <url name="Debian Free Software
  Leitlinien" id="&social-contract;#guidelines"> (auch verfügbar unter
  <file>&f-social-contract;</file> installiert durch 
  <package>&p-social-contract;</package>) und sind alle frei verfügbar
  und verteilbar.

  <item><file>stable/non-free/</file>:  Dieses Verzeichnis enthält Pakete,
  deren Weitergabe in gewisser Weise beschränkt ist. Genauere Informationen
  sind in den jeweiligen Copyright Hinweisen zu finden.

  <p>Zum Beispiel verbieten die Lizenzen einiger Pakete die kommerzielle
  Verteilung.  Andere können weitergegeben werden, aber nur als Shareware
  und nicht als freie Software.  Die Lizenzen all dieser Pakete müssen
  genau studiert und möglicherweise ausgehandelt werden, bevor die Pakete
  in irgendeiner Form (z.B. auf einer CD-ROM) weitergegeben werden.

  <item><file>stable/contrib/</file>: Dieses Verzeichnis enthält Pakete,
  welche DFSG-frei und <strong>frei verteilbar</strong> sind, aber irgendwie
  von einem Paket abhängen, das <strong>nicht</strong> frei verteilbar und
  somit nur im non-free Abschnitt zu finden ist.
</list>
Gegenwärtig befinden sich neue Pakete in Ergänzung zu obigen Verzeichnissen
unterhalb des <tt>pool</tt> Verzeichnisses (<ref id="pools">).  

<p>Der aktuelle Status von Fehlern der <tt>stable</tt> Distribution ist
unter der <url id="&stable-problems;" name="Stable Problems"> Web Seite
aufgeführt.

<sect1 id="testing">Die <tt>testing</tt> Distribution

<p>Pakete der <tt>testing</tt> Distribution, &testingdebian;, 
befinden sich im <tt>testing</tt> (symbolischer Link zu
<tt>&testingcodename;</tt>) Verzeichnis, nachdem sie einige Zeit in
<tt>unstable</tt> getestet wurden. Gegenwärtig befinden sich neue Pakete,
im Gegensatz zu den obigen Positionen, unterhalb des <tt>pool</tt>
Verzeichnisses (<ref id="pools">). Auch in <tt>testing</tt> gibt es die
<tt>main</tt>, <tt>contrib</tt> und <tt>non-free</tt> Unterverzeichnisse,
diese entsprechen den Verzeichnissen in <tt>stable</tt>.

<p>Diese Pakete müssen auf allen Architekturen auf denen sie zur Verfügung
stehen gleich aktuell sein und dürfen keine Abhängigkeiten aufweisen, welche
sie nicht installierbar machen; sie müssen auch weniger ausgabekritische
Fehler haben, als die Versionen in <tt>unstable</tt>. Auf diese Art hoffen
wir, dass <tt>testing</tt> fast immer zur Veröffentlichung bereit ist.
Mehr Details zu den Test Mechanismen sind  unter
<url id="&testing-notes;"> verfügbar.

<p>Der aktuellste Status der <tt>testing</tt> Distribution ist unter
folgenden Seiten aufgeführt:
<list compact>
<item><url id="&update-excuses;" 
         name="update Ausflüchte">
<item><url id="&testing-problems;" 
         name="testing Probleme">
<item><url id="&release-critical;" 
         name="ausgabekritische Fehler">
<item><url id="&qa-base-bugs;" 
         name="Basissystem Fehler">
<item><url id="&qa-standard-bugs;" 
         name="Fehler in Standard und Task Paketen">
<item><url id="&qa-bugs;" 
         name="andere Fehler und Bemerkungen zu Fehlerausmerzungs Parties">
</list>

<sect1 id="unstable">Die <tt>unstable</tt> Distribution

<p>Pakete, welche zur <tt>unstable</tt> Distribution <tt>sid</tt> gehören, 
werden unter <tt>unstable</tt> (symbolischer Link zu <tt>sid</tt>)
aufbewahrt, nachdem sie in das Debian Archiv geladen wurden und verbleiben
hier solange, bis sie nach <tt>testing</tt> verschoben werden.  Neue Pakete
befinden sich unterhalb des <tt>pool</tt> Verzeichnis (<ref id="pools">). 
Es gibt auch <tt>main</tt>, <tt>contrib</tt> und <tt>non-free</tt>
Unterverzeichnisse in <tt>unstable</tt>, welche dem selben Zweck dienen wie
in <tt>stable</tt>.

<p>Die <tt>unstable</tt> Distribution enthält ein Abbild des aktuellsten 
Entwickler Systems. Benutzer sind willkommen diese Pakete zu benutzen 
und zu testen, werden aber über den Status der Einsatzbereitschaft gewarnt.
Der Vorteil der Benutzung der <tt>unstable</tt> Distribution ist, dass man
immer auf dem Laufenden mit der aktuellsten &debian; Software ist &ndash;
geht jedoch etwas schief, so muss man auch damit umgehen können :-)

<p>Der aktuelle Status der Fehler in der <tt>unstable</tt> Distribution
wird auf der <url id="&unstable-problems;" name="Unstable Problems">
Web Seite aufgeführt.

<!-- Above was enough
<sect1 id="sid">The "sid" distribution

<p><strong>sid</strong> or <strong>unstable</strong> is the place where most of the packages
are initially uploaded. It will never be released directly, because packages
which are to be released will first have to be included in <strong>testing</strong>,
in order to be released in <strong>stable</strong> later on. sid contains packages
for both released and unreleased architectures.

<p>The name "sid" also comes from the "Toy Story" animated motion picture:
Sid was the boy next door who destroyed toys :-)
-->

<sect1 id="frozen">Die <tt>frozen</tt> Distribution

<p>Wenn die <tt>testing</tt> Distribution ausgereift ist, so wird aus ihr
frozen, was bedeutet, dass kein neuer Code mehr akzeptiert wird, nur noch
Bugfixes, wenn nötig.
Es wird auch ein neuer Verzeichnisbaum im <tt>dists</tt> Verzeichnis
angelegt und einem neuen Kodenamen zugeordnet. Die eingefrorene Distribution
durchläuft nun einige Monate lang Tests mit zwischenzeitlichen Updates und
Zwischenausgaben, welche "Test Zyklen" genannt werden.
(Der aktuelle <tt>woody</tt> Ausgabeprozess erzeugte keinen symbolischen
Link <tt>frozen</tt>, deshalb war <tt>frozen</tt> keine Distribution sondern
nur ein Entwicklungsschritt der <tt>testing</tt> Distribution.)

<p>Wir führen eine Liste aller Fehler in der frozen Distribution, welche
die Veröffentlichung eines Paketes verzögern können, sowie von Fehlern,
welche ähnliche Auswirkungen auf die gesamte Ausgabe haben. 
Sobald die Anzahl der Fehler den maximal zulässigen Wert unterschreitet,
wird aus der eingefrorenen Distribution stable, sie wird veröffentlicht und
die letzte stable Distribution veraltet (und wird ins Archiv verschoben).

<sect1 id="codenames">Debian Distributions-Kodenamen

<p>Verzeichnisnamen im <tt>dists</tt> Verzeichnis, wie
<tt>&stablecodename;</tt> und <tt>&testingcodename;</tt> sind nur
"Kodenamen". Wenn sich eine &debian; Distribution in der Entwicklung
befindet, besitzt sie keine Versionsnummer sondern nur einen Kodenamen.
Der Grund für diese Kodenamen ist das Spiegeln der &debian; Distributionen
zu vereinfachen (wenn ein Verzeichnis wie <tt>unstable</tt> plötzlich zu
<tt>stable</tt> umbenannt wird, so müsste vieles erneut heruntergeladen
werden).

<p>Zur Zeit ist <tt>stable</tt> ein symbolischer Link zu
<tt>&stablecodename;</tt> und <tt>testing</tt> ist ein symbolischer Link zu
<tt>&testingcodename;</tt>. Das bedeutet, dass <tt>&stablecodename;</tt> die
aktuelle stable Distribution und <tt>&testingcodename;</tt> die aktuelle
testing Distribution ist.

<p><tt>unstable</tt> ist ein permanenter symbolischer Link zu <tt>sid</tt>,
so wie <tt>sid</tt> ständig für die unstable Distribution steht. <!-- (see <ref id="sid">).-->

<sect1 id="oldcodenames">In der Vergangenheit verwendete Kodenamen

<p>Andere bereits verwendete Kodenamen sind: <tt>buzz</tt> für Ausgabe 1.1,
<tt>rex</tt> für Ausgabe 1.2, <tt>bo</tt> für die Ausgaben 1.3.x,
<tt>hamm</tt> für Ausgabe 2.0, <tt>slink</tt> für Ausgabe 2.1 und
<tt>potato</tt> für Ausgabe 2.2.


<sect1 id="sourceforcodenames">Die Herkunft der Kodenamen

<p>Bisher wurden Personen aus dem Film <em>Toy Story</em> von Pixar
verwendet.
<list compact>
  <item><strong>Buzz</strong> (Buzz Lightyear) war der Astronaut,
  <item><strong>Rex</strong> war der Tyrannosaurus,
  <item><strong>Bo</strong> (Bo Peep) war das Mädchen, welche sich um die
                            Schafe kümmerte,
  <item><strong>Hamm</strong> war das Sparschwein,
  <item><strong>Slink</strong> (Slinky Dog) war der Spielzeughund,
  <item><strong>Sarge</strong> was der Anführer der grünen Plastik Armee
                               Männer,
  <item><strong>Potato</strong> war natürlich Mr. Potato Head
                                (Mr. Kartoffelkopf),
  <item><strong>Woody</strong> war der Cowboy.
  <item><strong>Sid</strong> war ein Nachbarsjunge welcher Spielzeug
                             zerstörte.
</list>
<!--
  more info in http://www.pixar.com/feature/toystory/toystory.html 
  or better yet http://us.imdb.com/M/title-exact?Toy&percnt;20Story&percnt;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):
    - Sarge and The Green Plastic Army Men
    - Andy (the kid)
    - Etch (Etch-a-Sketch) (the blackboard)
    - Snake
    - Robot
    - Scud (Sid's dog)
  and additional characters from Toy Story 2, also not yet used:
    - Jessie (the Yodelling Cowgirl)
    - Zurg (the Emperor)
    - Wheezy (the penguin)
    - Hannah (owner of Jessie)
    - Stinky Pete the Prospector (the old fat guy)
    - Mrs. Davis (Andy's Mom)
    - Barbie
-->

<sect1 id="pools">Das <tt>pool</tt> Verzeichnis

<p>Früher wurden Pakete in dem Unterverzeichnis von <tt>dists</tt>
aufbewahrt, welches der verwendeten Distribution entsprach. Es stellte sich
heraus, dass dies einige Probleme verursachte, wie z.B. große
Bandbreitenverschwendung auf Mirrors nach einigen großen Änderungen.

<p>Pakete werden nun in einem großen "Pool" gespeichert, entsprechend dem
Namen des Quellpakets strukturiert. Um dies handhaben zu können, wurde der
Pool je nach Abschnitt (<tt>main</tt>, <tt>contrib</tt> und
<tt>non-free</tt>) sowie dem ersten Buchstaben des Quellpakets unterteilt.
Diese Verzeichnisse enthalten verschiedene Dateien: die Binärpakete für jede
Architektur und das Quellpaket von welchem die Binärpakete erzeugt wurden.

<p>Man kann herausfinden wo sich ein Paket befindet, indem man ein Kommando
wie <tt>apt-cache showsrc <var>Paketname</var></tt> aufruft und nach der
"Directory:" Zeile schaut. Das <package>apache</package> Paket wird z.B.
unter <file>pool/main/a/apache/</file> gespeichert. Da es sehr viele
<tt>lib*</tt> Pakete gibt, werden diese gesondert behandelt: das
<package>libpaper</package> Paket wird beispielsweise unter
<file>pool/main/libp/libpaper/</file> gespeichert.

<p>Die <tt>dists</tt> Verzeichnisse werden nach wie vor für die Index
Dateien, welche von Programmen wie <tt>apt</tt> verwendet werden, genutzt.
Ebenso wurden während dies geschrieben wird, ältere Distributionen noch nicht
angepasst um Pools zu nutzen, deswegen werden Sie auch Pfade finden, die
den Distributionsnamen wie <tt>potato</tt> oder <tt>woody</tt> im
"Filename" Feld enthalten.

<p>Normalerweise muss man sich um dies nicht kümmern, da neue <tt>apt</tt>
und wahrscheinlich ältere <tt>dpkg-ftp</tt> Programme (vergleiche
<ref id="howtocurrent">) dies problemlos handhaben. Sind Sie an weiteren
Informationen interessiert, so sei auf die <url id="&pool-faq;"
name="Debian Package Pools FAQ"> verwiesen.

<!-- bumped up from sect2 to sect1 -->
<sect1 id="sid-history">Historische Bemerkungen über <tt>sid</tt>

<p>Als das heutige <tt>sid</tt> noch nicht existierte, gab <!--FTP removed --> 
es im Debianarchiv nur einen Zweig für nicht ausgereifte Pakete: es gab die
Annahme, dass, wenn eine Architektur im aktuellen <tt>unstable</tt> hinzukam,
sie veröffentlicht wurde, wenn diese Distribution zum neuen <tt>stable</tt>
Zweig wurde. Für viele Architekturen war das nicht der Fall, was dazu führte,
dass diese Verzeichnisse während der Veröffentlichung verschoben wurden.
Dies war unpraktisch, da die Verschiebung zu einer großen Bandbreitenbelastung
führte.

<p>Die Archiv Administratoren umgingen das Problem einige Jahre, indem
sie Binaries für nichtveröffentlichte Architekturen in einem speziellen
Verzeichnis namens <tt>sid</tt> bereitstellten. Für solche noch nicht
veröffentlichte Architekturen wurde das erste Mal als sie veröffentlicht
wurden ein Link vom aktuellen <tt>stable</tt> zu <tt>sid</tt> angelegt, und
später wurden sie wie üblich unter <tt>unstable</tt> veröffentlicht.
Diese Vorgehensweise war zum Teil für die Anwender verworren.

<p>Mit Beginn der Paket Pools (vergleiche <ref id="pools">) während der 
Entwicklung der <tt>woody</tt> Distribution, wurden Binärpakete
unabhängig von der Distribution vorschriftsmäßig im Pool gehalten, so dass
die Veröffentlichung einer Distribution nicht länger zu einer großen
Bandbreitenverschwendung auf den Mirrors führte (es gibt dennoch
während der Entwicklung eine relativ große Bandbreitenauslastung).

<sect1 id="incoming">Heraufgeladene Pakete in <file>incoming</file>
<p>
Heraufgeladene Pakete befinden sich zunächst unter <url id="&incoming;"> 
nachdem sie überprüft wurden, um sicherzustellen, dass sie wirklich von
einem Debian Entwickler stammen, (und sie werden in das <file>DELAYED</file>
Unterverzeichnis verschoben, wenn das Paket nicht von einem Entwickler
stammt). Einmal pro Tag werden sie von <tt>incoming</tt> nach
<tt>unstable</tt> verschoben.
<p>
Im Notfall kann man Pakete aus <tt>incoming</tt> installieren, bevor sie
nach <tt>unstable</tt> kommen.
</sect1>

<sect1 id="snapshot">Wiederauffinden eines älteren Paketes
<p>
Während die aktuellsten Debian Distributionen unter dem <tt>debian</tt>
Verzeichnis auf jedem <url id="&mirror-site;" name="Debian Mirror"> zu
finden sind, werden die Archive für ältere Debian Distributionen wie Slink
unter <url id="&archivehome;"> oder unterhalb des <tt>debian-archive</tt> 
Verzeichnis auf jedem Debian Mirror gehalten.
<p>
Ältere <tt>testing</tt> und <tt>unstable</tt> Pakete befinden sich
auf <url id="&snapshothome;">.

</sect1>

<sect1 id="archsections">Architektur abhängige Verzeichnisse
<!--
What are all those directories inside <tt>dists/stable/main</tt>?
Simplified this !!!
-->

<p>Innerhalb jedes der wichtigen Verzeichnisbäume
(<file>dists/stable/main</file>, <file>dists/stable/contrib</file>,
<file>dists/stable/non-free</file>, <file>dists/unstable/main/</file>, etc.),
befinden sich die Einträge der Binärpakete in Unterverzeichnissen, deren
Namen die Prozessorarchitektur kennzeichnen, für die sie kompiliert wurden.

<list>
  <item><file>binary-all/</file>, für Pakete, welche Architektur unabhängig
    sind. Dies umschließt z.B. Perl Skripte oder Dokumentationen.
  <item><file>binary-<var>Plattform</var>/</file>, für Pakete, welche sich
    auf einer einzelnen Binärplattform starten lassen.
  <!-- Yes I simplified this -->
</list>

<p>Es ist anzumerken, dass die aktuellen Binärpakete von <tt>testing</tt>
und <tt>unstable</tt> sich nicht mehr länger in diesen Verzeichnissen,
dafür aber im <tt>pool</tt> Verzeichnis befinden. Die Index Dateien
(<file>Packages</file> und <file>Packages.gz</file>) befinden sich nach wie
vor für Abwärtskompatibilität dort.

<p>Für die aktuell unterstützten Binärarchitekturen vergleiche die
Release Notes der einzelnen Distributionen. Sie können unter der Release Notes
Seite für <url id="&stable-release;" name="stable"> und
<url id="&testing-release;" name="testing"> gefunden werden.

<!-- Removed, above release note shall be enough.
<p>See <ref id="arches"> for more information.
-->

<sect1 id="source">Der Quellcode

<p>Der Quellcode für alles im Debian System ist mit darin enthalten.
Außerdem <strong>fordern</strong> die Lizenzvereinbarungen der meisten
Programme im System, dass der Quellcode zusammen mit den Programmen
ausgeliefert wird, oder dass dem Programm Informationen beiliegen, wie er zu
erhalten ist.

<p>Normalerweise befindet sich der Quellcode in den <tt>source</tt>
Verzeichnissen, welche parallel zu allen Architektur spezifischen
Binärverzeichnissen sind oder aktueller im <tt>pool</tt> Verzeichnis
(vergleiche <ref id="pools">). Um den Quellcode zu erhalten, ohne sich mit
der Verzeichnisstruktur des <!--FTP--> Debian Archivs auseinandersetzen zu
müssen, kann ein Befehl wie <tt>apt-get source <var>Meinpaketname</var></tt>
genutzt werden.

<p>Einige Pakete wie z.B. <package>pine</package>, sind wegen deren
Lizenzbedingungen nur im Quellcode erhältlich.  (Kürzlich wurde das
<package>pine-tracker</package> Paket bereitgestellt, um die Pine
Installation zu vereinfachen.) Die Anweisungen beschrieben in <ref id="port">
und <ref id="packaging"> bieten einige Möglichkeiten, um ein Paket manuell
zu packen.

<p>Der Quellcode kann, muss aber nicht für Pakete in <file>contrib</file>
und <file>non-free</file> Verzeichnissen, welche formal nicht Teil des
Debian Systems sind, verfügbar sein.

<sect id="pkg-basics">Das Debian Paketverwaltungssystem

<sect1 id="package-basics">Überblick über Debian Pakete

<p>Pakete enthalten im allgemeinen all die Dateien, welche nötig sind um
eine Menge von zusammengehörigen Kommandos oder Eigenschaften zu
implementieren. Es gibt zwei Typen von Debian Paketen:
<list>
  <item><strong>Binärpakete</strong>, welche ausführbare Programme enthalten,
  Konfigurationsdateien, man/info Seiten, Copyright Informationen und andere
  Dokumentationen.
  Diese Pakete werden in einem Debian spezifischen Archivformat verteilt
  (vergleiche <ref id="deb-format">); sie zeichnen sich i.a. durch die
  <tt>.deb</tt> Dateierweiterung aus. Binärpakete können mit Debians
  <tt>dpkg</tt> Programm ausgepackt werden; Details sind in der Manual-Page
  beschrieben.
  
  <item><strong>Quellpakete</strong>, welche eine <tt>.dsc</tt> Datei
  enthalten, die das Quellpaket beschreibt (inklusive der Namen der folgenden
  Dateien), ebenso wie eine <tt>.orig.tar.gz</tt> Datei, welche den
  ursprünglichen unveränderten Quellcode in gzip-komprimiertem tar Format
  enthält und gewöhnlich eine <tt>.diff.gz</tt> Datei, die Debian spezifische
  Änderungen zu den Originalquellen enthält. Das Programm
  <tt>dpkg-source</tt> packt und entpackt Debian Quellpakete; Details sind
  in der Manual-Page enthalten.
</list>

<p>Die Installation der Software durch das Paketsystem nutzt
"Abhängigkeiten", welche sorgfältig vom Paketbetreuer bestimmt wurden.
Diese Abhängigkeiten sind in der <tt>control</tt> Datei, welche jedem Paket
zugeordnet wird, enthalten.
Das Paket, welches den GNU C Compiler enthält (<package/gcc/), "hängt" z.B.
von dem Paketen <package/binutils/ "ab", das den Linker und Assembler
enthält. Versucht ein Benutzer <package/gcc/ zu installieren, ohne zuvor
<package/binutils/ installiert zu haben, so wird das Paketverwaltungssystem
(dpkg) die Fehlermeldung ausgeben, dass es <package/binutils/ benötigt
und die Installation von <package/gcc/ abbrechen. (Dennoch kann dieses
Verhalten vom Nutzer geändert werden; vergleiche <manref name="dpkg"
section="8">.)  Für weitere Einzelheiten wird auf <ref id="depends">
verwiesen.

<p>Debian's Paketverwaltungstools können benutzt werden um:
<list>
  <item>Pakete oder Teile von Paketen zu manipulieren und handzuhaben,
  <item>dem Nutzer im Aufteilen von Paketen zu helfen, welche mittels
    kleiner Medien wie Disketten übertragen werden müssen,
  <item>Entwickler beim Erzeugen von Paketarchiven zu helfen und um
  <item>den Nutzern bei der Installation von Paketen, die sich auf
    entfernten <!--FTP-->Debian Archiven befinden, zu helfen.
</list>

<sect1 id="deb-format">Debian <!--Binär-->Paketformat

<p>Ein Debian "Paket" oder eine Debian Archivdatei enthält ausführbare
Dateien, Bibliotheken und Dokumentationen, welche einem bestimmten Programm
oder einer Menge von zugehörigen Programmen zugeordnet sind. Normalerweise
hat eine Debian Archivdatei einen Dateinamen der mit <tt>.deb</tt> endet.

<p>Die internen Einzelheiten dieses Debian Binärpaketformats werden in der
<manref name="deb" section="5"> Manual-Page beschrieben. Da dieses interne
Format in Zukunft geändert werden kann (zwischen verschiedenen Ausgaben von
&debian;), sollte stets <manref name="dpkg-deb" section="8"> für Änderungen
der <tt>.deb</tt> Dateien verwendet werden.

<!-- Below added by Osamu Not sure but should be right -->

<p>Zumindest in der Woody Distribution kann auf alle Debian Archivdateien
mit den Standard Unix Kommandos <prgn>ar</prgn> und <prgn>tar</prgn>
zugegriffen werden, auch wenn das <prgn>dpkg</prgn> Kommando nicht
verfügbar ist.

<sect1 id="pkgname">Namenskonventionen für Debians Paketdateinamen
<!--
Why are Debian package file names so long? 
-->
<p>Die Debian <!--binary--> Paketdateinamen folgen den Konventionen:
<example>
<var>foo</var>_<var>Versionsnummer</var>-<var>DebianRevisionsnummer</var>.deb
</example>
wobei <var>foo</var> für den Paketnamen steht. Zur Kontrolle kann man den
Paketnamen, welcher einer bestimmten Debian Archivdatei (<tt>.deb</tt> Datei)
zugeordnet ist, durch eine der folgenden Möglichkeiten bestimmen:
<list>
  <item>betrachten der "Packages" Datei in dem Verzeichnis, wo sich die
  <tt>.deb</tt> Datei im Debian <!--FTP--> Archiv befand. Diese Datei enthält
  für jedes Paket einen Eintrag, welcher es genau beschreibt; das erste
  Feld in jedem Eintrag ist der formale Paketname.
  
  <item>man benutzt das Kommando <tt>dpkg --info
  <var>foo_VVV-RRR</var>.deb</tt> (wobei <var>VVV</var> und <var>RRR</var>
  die Versions- bzw. Revisionsnummer des abgefragten Pakets sind). Dies
  zeigt unter anderen den Paketnamen an, welcher der zu entpackenden
  Archivdatei entspricht.
</list>

<p>Der <var>VVV</var> Teil ist die Versionsnummer, die vom Entwickler des
Programms vergeben wurde. Es gibt dafür kein allgemein gültiges Format,
sowohl "19990513" als auch "1.3.8pre1" ist denkbar.

<p>Der <var>RRR</var> Teil ist die Debian Revisionsnummer und wird vom
Debian Entwickler angegeben (oder von einem Nutzer, wenn dieser das Paket
selbst baut). Diese Nummer entspricht dem Revisionslevel des Debian Pakets;
eine neues Revisionslevel kennzeichnet in der Regel Änderungen in Debians
Makefile (<tt>debian/rules</tt>), in Debians Kontrolldatei
(<tt>debian/control</tt>), in Installations- oder Deinstallationsskripten
(<tt>debian/p*</tt>) oder in den Konfigurationsdateien, die mit dem Paket
genutzt werden.


<!-- This get too detailed
<sect1 id="controlfile">The Debian control file
-->

<sect1 id="conffile">Bewahren der lokalen Konfiguration
<!--
What is a Debian conffile
-->
<p>Die durch den Nutzer konfigurierbaren Dateien werden durch &debian;'s
"conffiles" Mechanismus bewahrt. Konfigurationsdateien (diese befinden sich
im Allgemeinen in <file>/etc</file>) werden in den <tt>conffiles</tt>
innerhalb von Debian's Paketsystem angegeben. Das Paketverwaltungssystem
garantiert, dass diese Dateien bei einer Paketaktualisierung (einem Upgrade)
nicht überschrieben werden.
<p>
Wenn es möglich ist, das System ohne Modifizierungen von Dateien anzupassen,
welche zu verschiedenen &debian; Paketen gehören, so ist es in der Regel
eine gute Idee, diese nicht zu verändern, selbst wenn es sich um 
"conffiles" handelt. Dies ermöglicht schnellere und sauberere
Aktualisierungen.
<!--
<p>Conffiles is a list of configuration files (usually placed in <tt>/etc</tt>)
that the package management system will not overwrite when the package is
upgraded. This ensures that local values for the contents of these files
will be preserved, and is a critical feature enabling the in-place upgrade
of packages on a running system.
-->
<p>Um zu bestimmen, welche Dateien während eines Upgrades bewahrt werden, 
kann man
<example>
dpkg --status <var>Paket</var>
</example>
ausführen und nach "Conffiles:" schauen.

<p>
Einzelheiten zum Inhalt einer Debian <tt>conffiles</tt> Datei sind im
Debian Policy Manual, Abschnitt 11.7 (vergleiche <ref id="references">)
zu finden.

<sect1 id="maintscripts">Debian Wartungsskripte
<!--
What is a Debian preinst, postinst, prerm, and postrm
  script?
-->
<p><!--These files--> 
Debian Wartungsskripte sind ausführbare Skripte, welche automatisch
gestartet werden bevor oder nachdem ein Paket installiert wird.
Zusammen mit einer Datei namens <tt>control</tt>  sind all diese Dateien
Teil des "control" Abschnitts einer Debian Archivdatei.

<p>Die einzelnen Dateien sind:
<taglist>
<tag/preinst/
  <item>Dieses Skript wird ausgeführt, bevor das Paket aus der Debian
  Archivdatei (<tt/.deb/) ausgepackt wird. Viele "preinst" Skripte beenden
  Dienste von Paketen, welche aktualisiert werden, bis deren Installation
  oder Upgrade vollzogen ist (d.h. nach der erfolgreichen Ausführung des
  "postinst" Skriptes).

<tag/postinst/
  <item>Dieses Skript schließt typischerweise jede nötige Konfiguration
  eines Paketes ab, nachdem es aus der Debian Archivdatei (<tt/.deb/)
  ausgepackt wurde. Oft fragen "postinst" Skripte die Nutzer nach Daten,
  und/oder weisen sie darauf hin, dass, wenn sie die Standardwerte
  akzeptieren, sie später die Möglichkeit haben zurückzugehen und das Paket
  zu rekonfigurieren, sollte dies nötig sein.
  Viele "postinst" Skripte führen Kommandos aus, welche nötig sind, um
  Dienste zu starten oder nach der Installation oder dem Upgrade neu zu
  starten.

<tag/prerm/
  <item>Dieses Skript beendet typischerweise Daemonen, welche dem Paket
  zugeordnet sind. Es wird ausgeführt, bevor die zum Paket gehörenden
  Dateien gelöscht werden.

<tag/postrm/
  <item>Dieses Skript modifiziert typischerweise Links oder andere Dateien,
  welche dem Paket zugeordnet sind und/oder entfernen Dateien, welche von
  ihm erzeugt wurden. (Siehe auch <ref id="virtual">.)
</taglist>

<p>Zur Zeit können all diese Kontrolldateien im Verzeichnis
<file>/var/lib/dpkg/info</file> gefunden werden. Die auf das Paket
<tt>foo</tt> bezogenen Dateien beginnen mit "foo" und haben die
entsprechende Dateierweiterungen "preinst", "postinst", u.s.w. Die Datei
<tt>foo.list</tt> in diesem Verzeichnis enthält alle Dateien, welche mit dem
Paket <tt>foo</tt> installiert wurden.
(Es ist zu beachten, dass die Position dieser Dateien eine interne dpkg
Eigenschaft ist und sich in der Zukunft ändern kann.)

<sect1 id="priority">Paket Prioritäten
<!--
What is a Required/Important/Standard/Optional/Extra
package?
-->
<p>Jedem Debian Paket ist eine <strong>Priorität</strong> vom
Distributionsbetreuer zugeordnet worden, um die Arbeit des
Paketverwaltungssystems zu vereinfachen. Die Prioritäten sind:

<list>
  <item><strong>Erforderliche</strong> Pakete werden benötigt für die
    zuverlässige Funktionalität des Systems.
    <p>
    Dies schließt alle Tools, welche nötig sind, um das System zu
    reparieren, ein. Diese Pakete dürfen nicht entfernt werden,
    andernfalls kann das System komplett versagen und man ist nicht
    einmal in der Lage <prgn>dpkg</prgn> zum Wiederherstellen zu nutzen.
    Systeme die nur die erforderlichen Pakete enthalten, sind
    wahrscheinlich ungeeignet für die meisten Aufgaben, jedoch kann der
    Systemadministrator jederzeit neue Software installieren.
  <item><strong>Wichtige</strong> Pakete sollten auf jedem Unix-artigen
    System gefunden werden.
    <p>
    Andere Pakete ohne die das System nicht gut oder brauchbar arbeitet, 
    haben diese Priorität. Dies schließt <strong>nicht</strong> Emacs,
    X11, TeX oder andere große Anwendungen ein. Diese Pakete erzeugen
    nur die nötige Infrastruktur.
  <item><strong>Standard</strong>pakete sind auf jedem Linuxsystem üblich,
    inklusive einem kleinen aber nicht zu sehr beschränkten textbasierten
    System.
    <p>
    Dies ist der Standardinstallationsumfang, solange der Nutzer nichts
    anderes wählt. "Standard" enthält nicht viele große Anwendungen, aber
    es enthält Emacs (das ist mehr eine Infrastruktur als eine Anwendung)
    und eine geeignete Teilmenge von TeX und LaTeX (sofern dies ohne X
    möglich ist).
  <item><strong>Optionale</strong> Pakete enthalten all diese, welche man
    vernünftigerweise installieren möchte, auch wenn man damit nicht
    vertraut ist und keine speziellen Anforderungen daran hat.
    <p>
    Dies schließt X11, eine vollständige TeX Distribution und viele
    Anwendungen mit ein.
  <item><strong>Zusätzliche</strong> Pakete sind entweder nicht mit anderen
    Paketen mit höherer Priorität verträglich, sind wahrscheinlich nur
    nützlich, wenn man sie bereits näher kennt oder haben spezielle
    Anforderungen, die sie für "Optional" ungeeignet machen.
</list>

<sect1 id="virtual">Virtuelle Pakete

<p>Ein virtuelles Paket ist ein allgemeiner Name, welcher für eine Gruppe
von Paketen steht, die alle ähnliche Funktionalitäten bereitstellen. Die
Programme <tt>tin</tt> und <tt>trn</tt> sind beispielsweise beide
News-Reader und einer von beiden sollte deshalb die Abhängigkeiten eines
Programms, welches einen News-Reader im System benötigt um richtig
funktionieren zu können, erfüllen. Deshalb sagt man, dass beide das
"virtuelle Paket" <tt>news-reader</tt> bereitstellen.

<p>Analog stellen <tt>exim</tt> und <tt>sendmail</tt> die Funktionalität
eines Mail Transport Agent bereit. Deshalb wird das virtuelle Paket
"mail-transport-agent" von beiden angeboten.
Wenn eines dieser Programme installiert ist, dann wird jedes Programm, das
von der Installation von <tt>mail-transport-agent</tt> abhängt, mit der
Existenz dieses virtuellen Paketes zufrieden sein.

<p>Debian besitzt einen Mechanismus so dass, wenn mehr als ein Paket,
welches das selbe virtuelle Paket bereitstellt, auf dem System installiert
ist, der Systemadministrator ein Programm bevorzugt auswählen kann. Das
entsprechende Kommando ist <tt>update-alternatives</tt> und wird genauer in
<ref id="alternatives"> beschrieben.

<sect1 id="depends">Paketabhängigkeiten
<!--
What is meant by saying that a package
  Depends/Recommends/Suggests/Conflicts/Replaces/Provides another package?
-->
<p>Das Debian Paketsystem enthält "Paketabhängigkeiten", welche (in einem
einzelnen Eintrag) festhalten, wie ein Programm A unabhängig von der
Existenz eines Programms B auf einem System arbeiten kann.
<list>
  <item>Paket A <strong>hängt</strong> von Paket B <strong>ab</strong>,
    wenn B unbedingt installiert sein muss, um A starten zu können. In
    einigen Fällen hängt A nicht nur von B, sondern einer speziellen
    Version von B ab. In diesem Fall ist die Versionsabhängigkeit im
    Allgemeinen eine untere Schranke, d.h. A hängt von einer beliebigen
    Version von B ab, welche aktueller als eine angegebene Version ist.
  <item>Paket A <strong>empfiehlt</strong> Paket B, wenn der Paketbetreuer
    meint, dass die meisten Nutzer A nicht ohne die von B bereitgestellte
    Funktionalität haben wollen.
  <item>Paket A <strong>schlägt</strong> Paket B <strong>vor</strong>, wenn
    B Dateien enthält, welche sich auf die Funktionalität von A beziehen
    (und diese eventuell erweitern).
  <item>Paket A <strong>kollidiert</strong> mit Paket B, wenn A nicht
    funktioniert, sofern B auf dem System installiert ist. Sehr oft
    bestehen solche <strong>Konflikte</strong> darin, dass A Dateien
    enthält, die gegenüber denen in B verbessert wurden.
    Der "Konflikt" Status wird oft mit "ersetzt" kombiniert.
  <item>Paket A <strong>ersetzt</strong> Paket B, wenn Dateien, die von
    B installiert wurden, von A entfernt und (in einigen Fällen) durch
    Dateien in A überschrieben werden.
  <item>Paket A <strong>unterstützt</strong> Paket B, wenn alle Dateien
    und Funktionalitäten von B in A verfügbar sind. Dieser Mechanismus
    steht für Nutzer mit geringem Plattenplatz zur Verfügung, um nur den
    Teil von A zu installieren, welcher absolut nötig ist.
</list>

<p>Weitere detaillierte Informationen zur Verwendung dieser Terme können im
Packaging Manual und dem Policy Manual gefunden werden.

<p>Es ist zu beachten, dass <prgn>dselect</prgn> eine bessere Kontrolle
über Pakete, die mit <strong>empfiehlt</strong> und <strong>schlägt
vor</strong> spezifiziert werden, bietet als <file>apt-get</file>, was
einfach alle <strong>hängt ab</strong> Pakete wählt und
<strong>empfiehlt</strong> und <strong>schlägt vor</strong> ignoriert.
Beide Programme nutzen in aktuellen Versionen APT als Back-end.

<sect1 id="pre-depends">Die Bedeutung von "pre-depends"

<p>"Pre-depends" ist eine spezielle Abhängigkeit. Im Falle eines
gewöhnlichen Pakets entpackt <prgn>dpkg</prgn> die Archivdatei (d.h. dessen
<tt>.deb</tt> Datei) unabhängig davon, ob die Dateien, von denen es abhängt,
im System existieren oder nicht. Entpacken bedeutet im wesentlichen, dass
<prgn>dpkg</prgn> die Dateien aus der Archivdatei extrahiert und korrekt
im Dateisystem plaziert. <strong>Hängen</strong> diese Pakete von der 
Existenz anderer Pakete auf dem System <strong>ab</strong>, dann wird
sich <prgn>dpkg</prgn> weigern, die Installation zu beenden (durch Ausführen
des "konfigurieren" Schritts), bis die anderen Pakete installiert sind.

<p>Dennoch gibt es einige Pakete, bei denen sich <prgn>dpkg</prgn> sogar
weigert, sie zu entpacken, bis gewisse Abhängigkeiten aufgelöst sind. Solche
Pakete hängen vom Vorhandensein anderer Pakete im Sinne von "pre-depend"
ab. Das Debian Projekt führte diesen Mechanismus ein, um das System sicher
vom <tt>a.out</tt> auf das ELF Format zu aktualisieren, wobei die 
<strong>Reihenfolge</strong> in welcher die Pakete entpackt werden,
bedeutend ist. Es gibt weitere große Update Situationen, wo diese Methode
nützlich ist, z.B. für Pakete mit der "erforderlich" Priorität und deren
libc Abhängigkeit.

<p>Erneut wird für detailliertere Informationen über dies auf das Packaging
Manual verwiesen.

<sect1 id="pkgstatus">Paket Status
<!--
What is meant by unknown/install/remove/purge/hold in
  the package status?
-->
<p>Der Paket Status kann "unbekannt", "installieren", "entfernen",
"säubern" oder "halten" sein.
Diese "gewünschten" Werte kennzeichnen, was der Nutzer mit einem Paket
beabsichtigte (entweder durch Anwahl des "[A]uswählen" Punktes in
<prgn>dselect</prgn> oder durch direkten Aufruf von <prgn>dpkg</prgn>).

<p>Deren Bedeutung ist:
<list compact>
  <item><strong>unbekannt</strong>    - der Nutzer hat niemals angegeben, ob
                er das Paket will.
  <item><strong>installieren</strong> - der Nutzer will das Paket installiert
                oder aktualisiert haben.
  <item><strong>entfernen</strong>    - der Nutzer will das Paket entfernen
                lassen, ohne das existierende Konfigurationsdateien gelöscht
                werden.
  <item><strong>säubern</strong>      - der Nutzer will das Paket komplett
                entfernt haben, inklusive der Konfigurationsdateien.
  <item><strong>halten</strong>       - der Nutzer will das Paket nicht
                verarbeiten lassen, d.h. er möchte die aktuelle Version im
                aktuellen Status belassen, unabhängig vom Wert.
</list>

<sect1 id="puttingonhold">Zurückhalten von Paketen von einem Upgrade
<!--
How do I put a package on hold?
Made major rewrite to accommodate new /etc/apt/preferences in progress
-->
<p>Es gibt zwei Mechanismen zum Zurückhalten von Paketen von einem Upgrade, 
durch <prgn>dpkg</prgn> oder in Woody durch APT.

<p>Mit <prgn>dpkg</prgn> ist zuerst die Paketauswahlliste zu exportieren:
<example>
dpkg --get-selections \* &gt; <var>Paketauswahl.txt</var>
</example>
Dann muss die erzeugte Datei <file><var>Paketauswahl.txt</var></file>
editiert werden, indem die Zeile, welche das zu haltende Paket, z.B. 
<package/libc6/, enthält, von:
<example>
libc6                       install
</example>
auf:
<example>
libc6                       hold
</example>
geändert wird.
Nach dem Speichern ist die Datei in die <prgn>dpkg</prgn> Datenbank
zurückzuladen mit:
<example>
dpkg --set-selections &lt; <var>Paketauswahl.txt</var>
</example>
Kennt man den Paketnamen des zu haltenden Pakets, kann man auch einfach
<example>
echo libc6 hold | dpkg --set-selections
</example>
starten. Wann immer der Installations Prozess dieses Paket bearbeitet (zu
upgraden versucht), hält er es zurück.
<!-- FIXME
  This procedure holds packages at the install process of each package file.
-->

<p>Der selbe Effekt kann mit <prgn>dselect</prgn> erreicht werden. Dazu ist
einfach der Punkt [A]uswählen und dann das Paket zu wählen, dessen Status
beibehalten werden soll sowie schließlich `=' (oder `H') zu drücken. Die
Änderungen werden sofort aktiv, nachdem das [A]uswählen Menü beendet wird.

<p>Das APT System in der Woody Distribution hat einen neuen "Alternativen"
Mechanismus zum Halten von Paketen während des Archivabfrageprozesses unter
Verwendung von <tt>Pin-Priority</tt>. Vergleiche die Manual-Page
<manref name="apt_preferences" section="5"> sowie <url id="&apt-howto;">
oder das <package>&p-apt-howto;</package> Paket.

<sect1 id="sourcepkgs">Quellpakete

<p>
Quellpakete befinden sich in einem Verzeichnis namens <tt>source</tt> und
können entweder manuell heruntergeladen werden oder durch
<example>
apt-get source <var>foo</var>
</example>
(vergleiche die <manref name="apt-get" section="8"> Manual-Page wie man APT
dazu bringt, dies zu tun).


<sect1 id="sourcebuild">Erzeugen von Binär- aus Quellcodepaketen

<p>Für ein Paket <tt><var>foo</var></tt> benötigt man alle
<file><var>foo_*</var>.dsc</file>, <file><var>foo_*</var>.tar.gz</file> und
<file><var>foo_*.diff</var>.gz</file> Dateien, um die Quellen zu übersetzen
(Bemerkung: es gibt keine <tt>.diff.gz</tt> Datei für ein natives Debian
Paket).

<p>Sind diese Dateien vorhanden und ist das <package/dpkg-dev/ Paket
installiert, so extrahiert das Kommando
<example>
$ dpkg-source -x <var>foo_version-revision</var>.dsc
</example>
das Paket in ein Verzeichnis namens <tt><var>foo-version</var></tt>.

<p>Zum Erzeugen des Binärpakets ist folgendes auszuführen:
<example>
$ cd foo-version
$ su -c "apt-get update; apt-get install fakeroot"
$ dpkg-buildpackage -rfakeroot -us -uc
</example>
Und danach
<example>
# su -c "dpkg -i ../<var>foo_version-revision_arch</var>.deb"
</example>
zum Installieren des neu gebildeten Pakets. Vergleiche <ref id="port">.

<!-- woody has simpler commands and build-depends -->

<sect1 id="creatingdebs">Erzeugen neuer Debian Pakete

<p>Für detaillierte Informationen zum Erzeugen neuer Pakete sollte der New
Maintainers' Guide gelesen werden, verfügbar im <package/maint-guide/ Paket,
oder unter <url id="&maint-guide;" name="&urlname;">.
<!--
<url id="ftp://ftp.debian.org/debian/doc/package-developer/maint-guide.html.tar.gz">.
-->
<!--
<sect id="pkgtools">Package Management Tools
Once many were moved up here but now moved down
-->

<!-- 
Rarely use command for woody, exclude but mention its manual page above.
<sect2 id="dpkg-deb">dpkg-deb
Removed below
-->

<!--
move up contents as a part of APT
<sect2 id="apt-get">apt-get
-->

<!--
Rarely use command for woody, exclude but mention its manual page above.
<sect2 id="dpkg-split">dpkg-split
removed
-->

<!--
Moved down
<sect1 id="updaterunning">Upgrade running system
Debian claims to be able to update a running program;
  how is this accomplished?
-->

<!--
<sect1 id="whatpackages">How can I tell what packages are already installed
  on a Debian system?
removed dpkg list and status things here
-->

<!-- these information are in debian.sgml and above
<sect1 id="filesearch">How can I find out what package produced a particular
  file?
removed dpkg list and status things here
-->

<sect id="uptodate">Aktualisierung eines Debian Systems

<p>Einer von Debian's Vorzügen ist die Unterstützung eines konsistenten 
Upgrade Wegs sowie ein sicherer Upgrade Prozess und es wird stets versucht,
eine ältere Ausgabe problemlos zu aktualisieren. Pakete warnen den Nutzer,
sollten bedeutende Bemerkungen während des Upgrade Prozesses auftreten und
bieten oft eine Lösung zu einem möglichen Problem.

<p>Man sollte auch die Release Notes lesen, das Dokument, das die Details zu
spezifischen Upgrades enthält. Es wird mit allen Debian CDs ausgeliefert und
ist im WWW unter <url id="&stable-release;"> oder
<url id="&testing-release;"> verfügbar.

<p>
Eine praktische Anleitung zum Aktualisieren wird in <ref id="package">
bereitgestellt. Dieser Abschnitt beschreibt die grundlegenden Einzelheiten.

<!-- Obsolete, removed
<sect1 id="libc5to6upgrade">How can I upgrade my Debian 1.3.1 (or earlier)
  distribution, based on libc5, to 2.0 (or later), based on libc6?
...
This paragraph is obsolete.
-->

<sect1 id="howtocurrent">Methoden zum Aktualisieren eines Debian Systems

<p>Man kann immer einfach einen anonymen FTP oder <prgn>wget</prgn> Aufruf
zu einem Debian Archiv starten, die Verzeichnisse durchsehen, bis man die
gewünschte Datei gefunden hat, diese herunterladen und schließlich mittels
<prgn>dpkg</prgn> installieren. (Es ist zu beachten, dass <prgn>dpkg</prgn>
die aktualisierten Dateien immer in das korrekte Verzeichnis installiert,
auch in einem laufenden System.) Manchmal kommt es dennoch vor, dass ein
überarbeitetes Paket die Installation einer neuen Version eines anderen
Paketes erfordert. In diesem Fall schlägt die Installation fehl, wenn das
andere Programm nicht installiert ist.

<p>Viele Personen finden dieses manuelle Vorgehen zu Zeit aufwendig, da
Debian sich so schnell entwickelt &ndash; typischerweise werden ein Dutzend
oder mehr Pakete jede Woche hochgeladen. Diese Zahl ist kurz vor einer neuen
Veröffentlichung noch größer. Um dies besser handhaben zu können, bevorzugen
viele Personen ein automatisches Programm zum Upgraden. Einige
spezialisierte Paketmanagement Tools sind für diesen Zweck verwendbar.

<sect1 id="pkgtools">Überblick über Paketverwaltungstools

<!-- reorganize this and following section in a compact section -->
<!--
<sect1 id="pkgprogs">What programs does Debian provide for managing its
  packages?
  Insert overview and
  bump sect2 to sect1
-->
<p>Das Debian Paketverwaltungssystem hat zwei Aufgaben: die Manipulation 
der Paketdatei und das Herunterladen von Paketdateien aus dem Debian Archiv.
<prgn>dpkg</prgn> erfüllt die erste Aufgabe, APT und <prgn>dselect</prgn>
die letztere.

<sect1 id="dpkg"><prgn>dpkg</prgn>

<p>Dies ist das wichtigste Programm zum Manipulieren von Paketdateien. Für
eine ausführliche Beschreibung ist <manref name="dpkg" section="8"> zu
lesen.
<!-- "install dpkg" deleted because it's a required package -->

<p><prgn>dpkg</prgn> wird mit einigen wichtigen Programmen ausgeliefert.

<list>
<item>dpkg-deb: Manipuliert <tt>.deb</tt> Dateien. 
 <manref name="dpkg-deb" section="1">
<item>dpkg-ftp: Ein älteres Programm zum Herunterladen von Paketen.
 <manref name="dpkg-ftp" section="1">
<item>dpkg-mountable: Ein älteres Programm zum Herunterladen von Paketen. 
 <manref name="dpkg-mountable" section="1">
<item>dpkg-split: Teilt ein größeres Paket in kleinere Dateien auf. 
 <manref name="dpkg-split" section="1">
</list>

<prgn>dpkg-ftp</prgn> und <prgn>dpkg-mountable</prgn> wurden durch das
APT System ersetzt.

<!-- Insert APT and apt-get here: -->
<sect1 id="apt">APT

<p>APT, das zukunftsweisende Paket-Tool (Advanced Packaging Tool) ist eine
fortschrittliche Schnittstelle zu Debian's Paketsystem und besteht aus
verschiedenen Programmen, deren Namen oft mit "apt-" beginnen. 
<prgn>apt-get</prgn>, <prgn>apt-cache</prgn> und <prgn>apt-cdrom</prgn> 
sind die Kommandozeilen Tools zum Umgang mit Paketen. Diese werden auch von
anderen Programmen, wie <prgn/dselect/ und <prgn/aptitude/ genutzt.

<p>Für weitere Informationen ist das <package/apt/ Paket zu installieren
und
<manref name="apt-get" section="8">,
<manref name="apt-cache" section="8">,
<manref name="apt-cdrom" section="8">,
<manref name="apt.conf" section="5">,
<manref name="sources.list" section="5">, 
<manref name="apt_preferences" section="5"> (woody) sowie
<file>/usr/share/doc/apt/guide.html/index.html</file> zu lesen.

<p>Weitere Informationen finden sich im
<url id="&apt-howto;" name="APT HOWTO">. <!-- FIXME check de -->
Dazu kann in Sarge <package/apt-howto-de/ installiert werden und steht
dann unter
<file>&f-apt-howto;</file>
zur Verfügung (Woody enthält nur die englische Version <package/apt-howto/).

<p><tt>apt-get upgrade</tt> und <tt>apt-get dist-upgrade</tt> installieren
nur die Pakete, die unter "Depends:" ("hängt ab:") aufgeführt sind und
übersieht alle unter "Recommends:" ("empfiehlt:") und "Suggests:" ("schlägt
vor:") gelisteten Pakete. Um dies zu vermeiden, sollte <prgn>dselect</prgn>
verwendet werden.

<!-- removed boring APT info -->

<!-- bump from sect2 to sect1 -->
<sect1 id="dselect-basics"><prgn>dselect</prgn>

<p>Dieses Programm besitzt eine Menüoberfläche zu Debian's
Paketverwaltungssystem. Es ist besonders für die Erstinstallation und große
Upgrades nützlich. Vergleiche <ref id="dselect">.

<p>Für weitere Informationen sollte das <package/install-doc/ Paket
installiert und
<file>/usr/share/doc/install-doc/dselect-beginner.en.html</file> oder
<url id="&dselect-beginner;" name="dselect Documentation for Beginners">
gelesen werden.

<!-- removed boring dselect info -->

<!-- move this up and make this sect1
<sect2 id="apt">APT
-->
<!-- remove this and mention above in dpkg
<sect2 id="dpkg-ftp">dpkg-ftp
-->
<!-- remove this
<sect2 id="mirror">mirror
-->

<!-- remove this section and mention above in dpkg
<sect2 id="dpkg-mountable">dpkg-mountable
-->

<!--
<sect1 id="upgradesingle">Must I go into single user mode in order to
  upgrade a package?

<p>No.  Packages can be upgraded in place, even in running systems.
Debian has a <tt>start-stop-daemon</tt> program that is invoked to stop,
then restart running process if necessary during a package upgrade.
-->

<sect1 id="updaterunning">Aktualisieren eines laufenden Systems

<p>Der Kernel (das Dateisystem) in &debian; Systemen unterstützt das Ersetzen
von Dateien auch während sie benutzt werden.

<p>Es wird auch ein Programm namens <prgn/start-stop-daemon/ bereitgestellt,
das verwendet wird, um Dämonen während des Bootens zu starten oder zum
Stoppen von Dämonen, wenn der Kernel-Runlevel geändert wird (z.B. von 
Mehrbenutzer- zu Einzelbenutzermodus oder zu "halt"). Das gleiche Programm
wird von Installationsskripten genutzt, wenn ein Paket, das einen Dämon
enthält, installiert wird, um laufende Dämonen zu stoppen und bei Bedarf
neuzustarten.

<p>Es wird darauf hingewiesen, dass das Debian System den Einzelnutzermodus
nicht erfordert, um ein laufendes System zu aktualisieren.


<sect1 id="savedebs">Heruntergeladene und zwischengespeicherte <tt>.deb</tt>
                     Archiv Dateien

<p>Hat man Paketdateien manuell auf die Festplatte heruntergeladen (was
nicht unbedingt notwendig ist, vergleiche die obige Beschreibung von
<prgn>dpkg-ftp</prgn> oder APT), dann kann man die <tt>.deb</tt> Dateien
nach der Installation der Pakete aus dem System entfernen.

<p>Wenn APT verwendet wird, so werden diese Dateien im
<file>/var/cache/apt/archives/</file> Verzeichnis zwischengespeichert. Sie
können nach der Installation gelöscht werden (<tt>apt-get clean</tt>) oder
auf einen anderen Rechner ins <file>/var/cache/apt/archives/</file>
Verzeichnis kopiert werden, um das Herunterladen während mehrerer
Installationen zu vermeiden.

<sect1 id="keepingalog">Aufbewahren des Datensatzes für Upgrades

<p><prgn/dpkg/ bewahrt einen Datensatz aller Pakete, die ausgepackt,
konfiguriert, entfernt und/oder gesäubert wurden, auf. Jedoch wird (zur
Zeit) kein Protokoll der Terminaleingaben, während der Paketmanipulation,
erzeugt.

<p>Der einfachste Weg, dieses Problem zu umgehen, ist Sitzungen von
<prgn>dpkg</prgn>, <prgn>dselect</prgn>, <prgn>apt-get</prgn>, etc.
innerhalb des <manref name="script" section="1"> Programms ablaufen zu
lassen.

<sect id="boot">Der Debian Bootvorgang

<sect1 id="init">Das <tt>init</tt> Programm

<p>Wie alle Unices, wird Debian durch das Programm <tt>init</tt> gestartet.
Die Konfigurationsdatei für <tt>init</tt> (dies ist <tt>/etc/inittab</tt>)
gibt an, dass das erste zu startende Skript <tt>/etc/init.d/rcS</tt> ist.
Dieses Skript startet alle anderen Skripte in <tt>/etc/rcS.d/</tt>, entweder
indem diese eingebunden oder explizit als Unterprozess aufgerufen werden,
je nach Dateierweiterung. Diese Skripte initialisieren das System indem sie
z.B. Dateisysteme überprüfen und einbinden, Module laden, Netzwerk Dienste
starten und die Uhrzeit setzen. Danach werden zwecks Kompatibilität die
Dateien (mit Ausnahme der mit einem `.' im Dateinamen) in
<tt>/etc/rc.boot/</tt> ausgeführt. Jedes Skript in diesem Verzeichnis ist
normalerweise dem Systemadministrator vorbehalten, die Verwendung dieser in
Paketen wird missbilligt. Vergleiche <ref id="init-hints"> für weitere
Informationen.

<sect1 id="runlevels">Runlevel

<p>Nach dem Bootprozess führt <tt>init</tt> alle Startskripte in einem
durch den Standard-Runlevel festgelegten Verzeichnis aus. (Dieses Runlevel
wird durch den Eintrag <tt>id</tt> in <tt>/etc/inittab</tt> festgelegt).
Wie viele <!-- all? SGK --> System V kompatible Unices hat Linux 7 Runlevel:
<list compact>
  <item>0 (Anhalten des Systems),
  <item>1 (Einzelnutzer Modus),
  <item>2 bis 5 (verschiedene Mehrbenutzer Modi) und
  <item>6 (Neustart des Systems).
</list>
<p>
Für Debian Systeme gilt <tt>id=2</tt>, was bedeutet, dass der
Standard-Runlevel 2 sein wird, wenn der Mehrbenutzer Modus aktiv ist und die
Skripte in <tt>/etc/rc2.d/</tt> werden ausgeführt.

<p>In Wirklichkeit sind die Skripte in den Verzeichnissen
<file>/etc/rc<var>N</var>.d/</file> nur symbolische Links zu Skripten in
<file>/etc/init.d/</file>. Dennoch werden die <strong>Namen</strong> der
Dateien in jedem der <file>/etc/rc<var>N</var>.d/</file> Verzeichnisse
individuell gewählt, um anzugeben <strong>wie</strong> die Skripte in
<file>/etc/init.d/</file> gestartet werden. Speziell werden bevor ein
Runlevel aktiv wird, alle Skripte die mit `K' beginnen ausgeführt; diese
Skripte beenden Dienste. Danach werden alle Skripte die mit `S' beginnen
gestartet; diese Skripte starten Dienste. Die zweistellige dem `K' oder `S'
folgende Nummer bestimmt die Reihenfolge der Ausführung. Skripte mit kleinerer
Nummer werden zuerst ausgeführt.

<p>Dieses Vorgehen funktioniert, da die Skripte in <tt>/etc/init.d/</tt> alle
ein Argument akzeptieren, das entweder "start", "stop", "reload", "restart"
oder "force-reload" sein kann und eine dem Argument entsprechende Aktion
ausführen (starten, stoppen, neuladen, neustarten, erzwinge Neustart).
Diese Skripte können auch ausgeführt werden, nachdem das System gebootet
wurde, um verschiedene Prozesse zu kontrollieren.

<p>Zum Beispiel führt das Argument "reload" im Kommando
<example>
# /etc/init.d/sendmail reload
</example>
dazu, dass der sendmail Dämon ein Signal zum erneuten Einlesen der
Konfigurationsdatei erhält.

<sect1 id="custombootscripts">Anpassen des Bootvorgangs
<p>
Debian verwendet kein BSD typisches <tt>rc.local</tt> Verzeichnis, um den
Bootvorgang anzupassen; stattdessen wird folgender Mechanismus angeboten.

<p>Angenommen <tt>foo</tt> sei ein Skript, das während des Startvorgangs
oder beim Übergang in ein bestimmtes (System V) Runlevel aufgerufen werden
soll. Dann sollte der Systemadministrator:
<enumlist>
  <item>Das Skript <tt>foo</tt> in das Verzeichnis <file>/etc/init.d/</file>
        verschieben.
  <item>Das Debian Kommando <prgn>update-rc.d</prgn> mit entsprechenden
        Argumenten starten, um Links zwischen den (Kommandozeilen
        spezifischen) Verzeichnissen <tt>rc<var>?</var>.d</tt> und
        <file>/etc/init.d/foo</file> anzulegen.
        Dabei bezeichnet <var>?</var> eine Nummer von 0 bis 6, die einem der
        System V Runlevel entspricht.
  <item>Das System neu booten.
</enumlist>

<p>Das Kommando <tt>update-rc.d</tt> setzt Links zwischen Dateien im
Verzeichnis <tt>rc<var>?</var>.d</tt> und dem Skript in
<file>/etc/init.d/</file>. Jeder Link beginnt mit einem `S' oder `K',
gefolgt von einer Nummer, gefolgt vom Namen des Skripts. Skripte in
<file>/etc/rc<var>N</var>.d/</file> die mit `S' beginnen, werden ausgeführt,
wenn in das Runlevel <var>N</var> gewechselt wird. Skripte die mit `K'
beginnen, werden beim Verlassen des Runlevel <var>N</var> gestartet.

<p>Man kann z.B. das Skript <tt>foo</tt> beim Booten ausführen lassen, indem
man es nach <file>/etc/init.d/</file> verschiebt und die Links mit
<tt>update-rc.d foo defaults 19</tt> erstellt. Das Argument <tt>defaults</tt>
bezieht sich auf den Standard-Runlevel, welcher zwischen 2 und 5 liegt. Das
Argument <tt>19</tt> sichert, dass <tt>foo</tt> vor allen Skripten, welche
die Nummern 20 oder größer enthalten, gestartet wird.

<sect id="diverse">Unterstützung von Vielfalten
<p>
Debian unterstützt verschiedene Möglichkeiten zum Anpassen des Systems, ohne
das System zu beeinträchtigen. 
<list>
<item><prgn>dpkg-divert</prgn>, vergleiche <ref id="dpkg-divert">.
<item><prgn>equivs</prgn>, vergleiche <ref id="equivs">.
<item><prgn>update-alternative</prgn>, vergleiche <ref id="alternatives">.
<item><prgn>make-kpkg</prgn> kann viele Boot-Loader anpassen. 
      Vergleiche <manref name="make-kpkg" section="1"> und
      <ref id="kernel-debian">.
</list>
Alle Dateien unter <file>/usr/local/</file> gehören dem Systemadministrator 
und &debian; wird sie nicht verändern. Viele (oder alle) Dateien unter
<file>/etc</file> sind Konfigurationsdateien und &debian; wird
sie nicht während eines Upgrades überschreiben, es sei denn der
Systemadministrator erlaubt dies ausdrücklich.

<sect id="i18n">Internationalisierung
<p>
Das &debian; System ist internationalisiert und bietet Unterstützung zur
Ein- und Ausgabe von Zeichen in vielen Sprachen, beides in der Konsole und
unter X. Viele Texte, Manual-Pages und Systemausgaben wurden in eine ständig
wachsende Anzahl von Sprachen übersetzt. Während der Installation fordert
Debian den Nutzer zum Wahl der Installationssprache (und manchmal eines
lokalen Dialekts) auf.
<p>
Sollte das installierte System nicht alle benötigten Eigenschaften der
Sprache unterstützen, soll eine andere Sprache gewählt werden oder wurde
eine neue Tastatur angeschlossen, um die Sprache zu unterstützen, vergleiche
<ref id="l10n">.

<sect id="kernel-details">Debian und der Kernel
<p>
Vergleiche <ref id="kernel">.

<sect1 id="non-debian-kernel">Kompilierung eines Kernel aus Debian fremden
  Quellen

<p><!--Yes.  But you have-->
Man sollte die Debian Politik bezüglich der Header verstanden haben, bevor
man startet.

<p>Die Debian C Bibliotheken wurden mit der aktuellsten
<strong>stabilen</strong> Version der <strong>Kernelheader</strong>
erstellt.

<p>Zum Beispiel nutzte die Debian 1.2 Ausgabe Version 5.4.13 der Header.
Dieses Vorgehen unterscheidet sich von den Linux Kernelquellpaketen, die
auf allen Linux FTP Archiv Seiten verbreitet werden, welche aktuellere
Versionen der Header verwenden. Die Kernelheader aus den Kernelquellen
befinden sich in <file>/usr/include/linux/include/</file>.

<p>Wenn es nötig ist, ein Programm mit aktuelleren Kernelheadern als in
<package/libc6-dev/ zu übersetzen, so muss
<tt>-I/usr/src/linux/include/</tt> zur Kommandozeile beim Kompilieren
hinzugefügt werden. Dies ist z.B. für das Packen des automounter Dämon
(<package/amd/) von Bedeutung. Als neue Kernel einige NFS bezogene Internals
änderten, musste dies <prgn>amd</prgn> mitgeteilt werden. Dies erforderte
die Einbindung der aktuellsten Kernelheader.

<sect1 id="customkernel">Tools zum Erzeugen angepasster Kernel

<p>Nutzern die einen angepassten Kernel erzeugen wollen (oder müssen), wird
empfohlen, das Paket <package/kernel-package/ herunterzuladen. Dieses Paket
enthält das Skript zur Kernelerstellung und bietet die Möglichkeit, ein
Debian kernel-image Paket einfach durch Aufruf von
<example>
# make-kpkg kernel_image
</example>
im Kernelquellverzeichnis zu starten. Hilfe ist durch Ausführung von
<example>
# make-kpkg --help
</example>
verfügbar und durch die Manual-Page <manref name="make-kpkg" section="8">
sowie <ref id="kernel">.

<p>Nutzer müssen den Quellcode für den aktuellsten Kernel (oder den Kernel
ihrer Wahl) separat vom bevorzugten Linux Archiv herunterladen, wenn kein
<package/kernel-source-<var>version</var>/ Paket (dabei steht
<var>version</var> für die Kernel Version) vorhanden ist. Das Debian
<file>initrd</file> Bootskript erfordert einen speziellen Kernel Patch namens
<prgn>initrd</prgn>; vergleiche <url id="&bug-initrd;">.

<p>Detaillierte Anweisungen zur Benutzung des <package/kernel-package/ Pakets
sind in der Datei <tt>/usr/doc/kernel-package/README</tt> zu finden.

<!-- TODO: check out a new source of details, this README isn't too useful,
  I'm told (joy) -->

<sect1 id="alt-boot">Alternative Boot Loader
<p>
Zur Verwendung von alternativen Boot Loader wie <package/grub/ oder
<package/loadlin/ ist der kompilierte Linux Kernel <file>bzimage</file> in
ein anderes Verzeichnis (wie <file>/boot/grub</file> oder auf eine MS-DOS
Partition) zu kopieren.
</sect1>

<sect1 id="custombootdisk">Erzeugen von Boot Disketten

<p>Die Erstellung einer angepassten Boot Diskette wird durch das Debian
Paket <package/boot-floppies/ unterstützt, das normalerweise im
<tt>admin</tt> Abschnitt des Debian FTP Archivs gefunden wird. Shellskripte
in diesem Paket erzeugen Boot Disketten im <prgn>syslinux</prgn> Format. Dies
sind MS-DOS formatierte Disketten, deren Master-Bootrecord so modifiziert
wurde, dass sie direkt Linux (oder irgend ein anderes Betriebssystem, das in
der <tt>syslinux.cfg</tt> Datei auf der Diskette definiert wurde) booten
können. Andere Skripte in diesem Paket erzeugen Notfall Disketten und können
auch die Basisdisketten neu erzeugen.

<p>Mehr Informationen darüber können in der
<file>/usr/doc/boot-floppies/README</file> Datei nach der Installation des
<package/boot-floppies/ Paketes gefunden werden.

<sect1 id="modules">Spezielle Regeln für den Umgang mit Modulen

<p>Debian's <package/modconf/ Paket enthält ein Shellskript
(<file>/usr/sbin/modconf</file>), dass zur Anpassung der Modulkonfiguration
genutzt werden kann. Dieses Skript besitzt eine Menü basierte Schnittstelle,
die den Nutzer nach Einzelheiten über ladbare Gerätetreiber im System fragt.
Die Antworten werden benutzt, um die Datei <file>/etc/modules.conf</file>
(welche Aliase enthält sowie andere Argumente, die in Verbindung mit
verschiedenen Modulen verwendet werden müssen) anzupassen, auf Grund von
Dateien in <file>/etc/modutils/</file> und <file>/etc/modules</file> (die
die Module auflistet, die zur Bootzeit geladen werden müssen).

<p>Wie die (neuen) Configure.help Dateien, die nun verfügbar sind, um
angepasste Kernel zu unterstützen, kommt das <package/modconf/ Paket
mit einer Reihe von Hilfe Dateien (in <file>/usr/lib/modules_help/</file>),
die detaillierte Informationen über passende Argumente für jedes Modul
enthalten. Vergleiche <ref id="kernel-modules"> für Beispiele.

<sect1 id="removeoldkernel">Deinstallation eines alten Kernel Pakets

<p>Das <tt>kernel-image-<var>NNN</var>.prerm</tt> Skript überprüft, ob der
aktuell laufende Kernel mit dem zu entfernenden Kernel übereinstimmt.
Deshalb können ungewünschte kernel-image Pakete sicher mittels
<example>
dpkg --purge --force-remove-essential kernel-image-<var>NNN</var>
</example>
entfernt werden. (<var>NNN</var> ist durch die entsprechende Kernelversion und
Revisionsnummer zu ersetzen.)
</sect>