[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ weiter ]

Debian-Referenz
Kapitel 2 - Debian-Grundlagen

Dieses Kapitel liefert grundlegende Informationen über das Debian-System für Nicht-Programmierer. Für die ultimativen Informationen vergleiche:

aufgeführt unter Referenzen, Abschnitt 15.1.

Wenn Sie nach nicht allzu ausführlichen "wie geht" Erklärungen suchen, wechseln Sie direkt nach Debian-Paketverwaltung, Kapitel 6 oder in andere relevante Kapitel.

Dieses Kapitel basiert auf Dokumenten aus der "Debian-FAQ", größtenteils umgeschrieben, um dem gewöhnlichen Debian-Systemadministrator den Einstieg zu erleichtern.

2.1 Die Debian-Archive

2.1.1 Verzeichnisstrukturen

Die Software, welche für Debian paketiert wurde, ist in einem der vielen Verzeichnisbäume auf jedem Debian-Mirror durch FTP oder HTTP verfügbar.

Die folgenden Verzeichnisse können auf jedem Debian-Mirror unter dem debian Verzeichnis gefunden werden:

dists/:

Dieses Verzeichnis enthält die "Distributionen" und ist für den Zugriff auf die aktuell verfügbaren Pakete in Debian ausgelegt. Einige alte Pakete, die Contents-*.gz-Dateien und die Packages.gz-Dateien sind immer noch hier zu finden.

pool/:

Die neue Position aller Debian-Pakete.

tools/:

DOS-Hilfsmittel zum Erzeugen von Bootdisketten, Partitionieren der Festplatte, Komprimieren/Dekomprimieren von Dateien und zum Booten von Linux.

doc/:

Die grundlegenden Debian-Dokumentationen wie die FAQ's, Erläuterungen zum Fehler-Melde-System, usw.

indices/:

Enthält die Maintainers-Datei (Liste aller Paketbetreuer) und die override.*-Dateien.

project/:

Hauptsächlich Material, welches nur für Entwickler von Interesse ist, wie z.B.:

project/experimental/:

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.

project/orphaned/:

Pakete, welche von ihrem alten Betreuer aufgegeben wurden und aus der Distribution zurückgezogene Software.

2.1.2 Debian-Distributionen

Normalerweise befinden sich drei Debian-Distributionen im dists-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 dists-Verzeichnis.

2.1.3 Die stable-Distribution

Pakete der stable-Distribution, Debian Sarge (3.1r0), befinden sich im stable- (symbolischer Link zu sarge/) Verzeichnis:

Gegenwärtig befinden sich neue Pakete in Ergänzung zu obigen Verzeichnissen unterhalb des pool-Verzeichnisses (Das pool-Verzeichnis, Abschnitt 2.1.10).

Der aktuelle Status von Fehlern der stable-Distribution ist unter der Stable Problems-Webseite aufgeführt.

2.1.4 Die testing-Distribution

Pakete der testing-Distribution, Debian Etch, befinden sich im testing- (symbolischer Link zu etch/) Verzeichnis, nachdem sie einige Zeit in unstable getestet wurden. Gegenwärtig befinden sich neue Pakete, im Gegensatz zu den obigen Positionen, unterhalb des pool-Verzeichnisses (Das pool-Verzeichnis, Abschnitt 2.1.10). Auch in testing/ gibt es die main-, contrib- und non-free-Unterverzeichnisse, diese entsprechen den Verzeichnissen in stable/.

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 veröffentlichungskritische Fehler haben, als die Versionen in unstable. Auf diese Art hoffen wir, dass testing fast immer zur Veröffentlichung bereit ist. Mehr Details zu den Test-Mechanismen sind unter http://www.debian.org/devel/testing verfügbar.

Der aktuellste Status der testing-Distribution ist unter folgenden Seiten aufgeführt:

2.1.5 Die unstable-Distribution

Pakete, welche zur unstable-Distribution mit dem Kodenamen "Sid" gehören, werden im unstable- (symbolischer Link zu sid/) Verzeichnis aufbewahrt, nachdem sie in das Debian-Archiv geladen wurden und verbleiben hier solange, bis sie nach testing/ verschoben werden. Neue Pakete befinden sich unterhalb des pool-Verzeichnis (Das pool-Verzeichnis, Abschnitt 2.1.10). Es gibt auch main-, contrib- und non-free-Unterverzeichnisse in unstable/, welche dem selben Zweck dienen wie in stable/.

Die unstable-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 unstable-Distribution ist, dass man immer auf dem Laufenden mit der aktuellsten Debian-Software ist – geht jedoch etwas schief, so muss man auch damit umgehen können. :-)

Der aktuelle Status der Fehler in der unstable-Distribution wird auf der Unstable Problems-Webseite aufgeführt.

2.1.6 Die frozen-Distribution

Wenn die testing-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 dists-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.

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

2.1.7 Debian-Distributions-Kodenamen

Verzeichnisnamen im dists-Verzeichnis, wie sarge/ und etch/ 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 unstable plötzlich zu stable/ umbenannt wird, so müsste vieles erneut heruntergeladen werden).

Zurzeit ist stable/ ein symbolischer Link zu sarge/ und testing/ ist ein symbolischer Link zu etch/. Das bedeutet, dass Sarge die aktuelle stable-Distribution und Etch die aktuelle testing-Distribution ist.

unstable/ ist ein permanenter symbolischer Link zu sid/, so wie Sid ständig für die unstable-Distribution steht.

2.1.8 In der Vergangenheit verwendete Kodenamen

Andere bereits verwendete Kodenamen sind: "Buzz" für Ausgabe 1.1, "Rex" für Ausgabe 1.2, "Bo" für die Ausgaben 1.3.x, "Hamm" für Ausgabe 2.0, "Slink" für Ausgabe 2.1, "Potato" für Ausgabe 2.2, "Woody" für Ausgabe 3.0 und "Sarge" für Ausgabe 3.1.

2.1.9 Die Herkunft der Kodenamen

Bisher wurden Personen aus dem Film Toy Story von Pixar verwendet.

2.1.10 Das pool-Verzeichnis

Früher wurden Pakete in dem Unterverzeichnis von dists 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.

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 (main, contrib und non-free) 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.

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

Die dists-Verzeichnisse werden nach wie vor für die Index-Dateien, welche von Programmen wie apt 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 potato oder woody im "Directory"-Feld enthalten.

Normalerweise muss man sich um dies nicht kümmern, da neue apt und wahrscheinlich ältere dpkg-ftp Programme (vergleiche Methoden zum Aktualisieren eines Debian-Systems, Abschnitt 2.3.1) dies problemlos handhaben. Sind Sie an weiteren Informationen interessiert, so sei auf die RFC: Implementation von Paketpools verwiesen.

2.1.11 Historische Bemerkungen über Sid

Als das heutige Sid noch nicht existierte, gab es im Debian-Archiv nur einen Zweig für nicht ausgereifte Pakete: es gab die Annahme, dass, wenn eine Architektur im aktuellen unstable/ hinzukam, sie veröffentlicht wurde, wenn diese Distribution zum neuen stable-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.

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

Mit Beginn der Paket-Pools (vergleiche Das pool-Verzeichnis, Abschnitt 2.1.10) während der Entwicklung der Woody-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).

2.1.12 Heraufgeladene Pakete in incoming/

Heraufgeladene Pakete befinden sich zunächst unter http://incoming.debian.org/ nachdem sie überprüft wurden, um sicherzustellen, dass sie wirklich von einem Debian-Entwickler stammen, (und sie werden in das DELAYED-Unterverzeichnis verschoben, wenn das Paket nicht von einem Entwickler stammt, d.h. ein Non-Maintainer Upload (NMU) ist). Einmal pro Tag werden sie von incoming/ nach unstable/ verschoben.

Im Notfall kann man Pakete aus incoming/ installieren, bevor sie nach unstable/ kommen.

2.1.13 Wiederauffinden eines älteren Paketes

Während die aktuellsten Debian-Distributionen unter dem debian-Verzeichnis auf jedem Debian-Mirror zu finden sind, werden die Archive für ältere Debian-Distributionen wie Slink unter http://archive.debian.org/ oder unterhalb des debian-archive Verzeichnis auf jedem Debian-Mirror gehalten.

Ältere testing- und unstable-Pakete befinden sich auf http://snapshot.debian.net/.

2.1.14 Architekturabhängige Verzeichnisse

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

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

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 stable und testing gefunden werden.

2.1.15 Der Quellcode

Der Quellcode für alles im Debian-System ist mit darin enthalten. Außerdem fordern 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.

Normalerweise befindet sich der Quellcode in den source-Verzeichnissen, welche parallel zu allen architekturspezifischen Binärverzeichnissen sind oder aktueller im pool-Verzeichnis (vergleiche Das pool-Verzeichnis, Abschnitt 2.1.10). Um den Quellcode zu erhalten, ohne sich mit der Verzeichnisstruktur des Debian-Archivs auseinandersetzen zu müssen, kann ein Befehl wie apt-get source Meinpaketname genutzt werden.

Einige Pakete wie z.B. pine, sind wegen deren Lizenzbedingungen nur im Quellcode erhältlich. (Kürzlich wurde das pine-tracker-Paket bereitgestellt, um die Pine-Installation zu vereinfachen.) Die Anweisungen beschrieben in Portierung eines Pakets auf die stable-Distribution, Abschnitt 6.4.10 und Paketerzeugung, Abschnitt 13.10 bieten einige Möglichkeiten, um ein Paket manuell zu paketieren.

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

2.2 Das Debian-Paketverwaltungssystem

2.2.1 Überblick über Debian-Pakete

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:

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

Debian's Paketverwaltungstools können benutzt werden um:

2.2.2 Debian-Paketformat

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 .deb endet. [1]

Die internen Einzelheiten dieses Debian-Binärpaketformats werden in der deb(5) Handbuchseite beschrieben. Da dieses interne Format in Zukunft geändert werden kann (zwischen verschiedenen Ausgaben von Debian), sollte stets dpkg-deb(1) für Änderungen der .deb-Dateien verwendet werden.

Zumindest in der Sarge-Distribution kann auf alle Debian-Archivdateien mit den Standard-Unix-Kommandos ar und tar zugegriffen werden, auch wenn das dpkg-Kommando nicht verfügbar ist.

2.2.3 Namenskonventionen für Debians Paketdateinamen

Die Debian-Paketdateinamen folgen den Konventionen: 

     foo_Versionsnummer-DebianRevisionsnummer.deb

wobei foo für den Paketnamen steht. Zur Kontrolle kann man den Paketnamen, welcher einer bestimmten Debian-Archivdatei (.deb-Datei) zugeordnet ist, durch eine der folgenden Möglichkeiten bestimmen:

Der VVV-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.

Der RRR-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; ein neues Revisionslevel kennzeichnet in der Regel Änderungen in Debians Makefile (debian/rules), in Debians Kontrolldatei (debian/control), in Installations- oder Deinstallationsskripten (debian/p*) oder in den Konfigurationsdateien, die mit dem Paket genutzt werden.

2.2.4 Bewahren der lokalen Konfiguration

Die durch den Nutzer konfigurierbaren Dateien werden durch Debians "conffiles"-Mechanismus bewahrt. Konfigurationsdateien (diese befinden sich im Allgemeinen in /etc/) werden in den conffiles innerhalb von Debians Paketsystem angegeben. Das Paketverwaltungssystem garantiert, dass diese Dateien bei einer Paketaktualisierung (einem Upgrade) nicht überschrieben werden.

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.

Um zu bestimmen, welche Dateien während eines Upgrades bewahrt werden, kann man 

     dpkg --status Paket

ausführen und nach "Conffiles:" schauen.

Einzelheiten zum Inhalt einer Debian-conffiles-Datei sind im Debian Policy Manual, Abschnitt 11.7 (vergleiche Referenzen, Abschnitt 15.1) zu finden.

2.2.5 Debian-Wartungsskripte

Debian-Wartungsskripte sind ausführbare Skripte, welche automatisch gestartet werden bevor oder nachdem ein Paket installiert wird. Zusammen mit einer Datei namens control sind all diese Dateien Teil des "control"-Abschnitts einer Debian-Archivdatei.

Die einzelnen Dateien sind:

preinst

Dieses Skript wird ausgeführt, bevor das Paket aus der Debian-Archivdatei (.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).

postinst

Dieses Skript schließt typischerweise jede nötige Konfiguration eines Paketes ab, nachdem es aus der Debian-Archivdatei (.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.

prerm

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

postrm

Dieses Skript modifiziert typischerweise Links oder andere Dateien, welche dem Paket zugeordnet sind und/oder entfernen Dateien, welche von ihm erzeugt wurden. (Siehe auch Virtuelle Pakete, Abschnitt 2.2.7.)

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

2.2.6 Paket-Prioritäten

Jedem Debian-Paket ist eine Priorität vom Distributionsbetreuer zugeordnet worden, um die Arbeit des Paketverwaltungssystems zu vereinfachen. Die Prioritäten sind:

Beachten Sie die Unterschiede zwischen "Priority: required", "Section: base" und "Essential: yes" in der Paketbeschreibung. "Section: base" bedeutet, dass dieses Paket vor allen anderen in einem neuen System installiert wird. Die meisten der Pakete mit "Section: base" enthalten "Priority: required" oder zumindest "Priority: important" und viele von diesen sind mit "Essential: yes" versehen. "Essential: yes" bedeutet, dass das Paket die Angabe einer bestimmten Option an das Paketmanagementsystem wie dpkg erfordert, wenn es aus dem System entfernt werden soll. Beispielsweise sind libc6, mawk und makedev Pakete mit "Priority: required" und "Section: base" aber enthalten nicht "Essential: yes".

2.2.7 Virtuelle Pakete

Ein virtuelles Paket ist ein allgemeiner Name, welcher für eine Gruppe von Paketen steht, die alle ähnliche Funktionalitäten bereitstellen. Die Programme tin und trn 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" news-reader bereitstellen.

Analog stellen exim und sendmail 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 eines Mail-Transport-Agent abhängt, mit der Existenz dieses virtuellen Paketes zufrieden sein.

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 update-alternatives und wird genauer in Alternative Befehle, Abschnitt 6.5.3 beschrieben.

2.2.8 Paketabhängigkeiten

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.

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

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

2.2.9 Die Bedeutung von "pre-depends"

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

Dennoch gibt es einige Pakete, bei denen sich dpkg 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 a.out- auf das ELF-Format zu aktualisieren, wobei die Reihenfolge 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.

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

2.2.10 Paket-Status

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 dselect oder durch direkten Aufruf von dpkg).

Deren Bedeutung ist:

2.2.11 Zurückhalten von Paketen von einem Upgrade

Es gibt zwei Mechanismen zum Zurückhalten von Paketen von einem Upgrade, durch dpkg oder beginnend mit Woody durch APT.

Mit dpkg ist zuerst die Paketauswahlliste zu exportieren: 

     dpkg --get-selections \* > Paketauswahl.txt

Dann muss die erzeugte Datei Paketauswahl.txt editiert werden, indem die Zeile, welche das zu haltende Paket, z.B. libc6, enthält, von: 

     libc6                       install

auf: 

     libc6                       hold

geändert wird. Nach dem Speichern ist die Datei in die dpkg-Datenbank zurückzuladen mit: 

     dpkg --set-selections < Paketauswahl.txt

Kennt man den Paketnamen des zu haltenden Pakets, kann man auch einfach 

     echo libc6 hold | dpkg --set-selections

starten. Wann immer der Installations-Prozess dieses Paket bearbeitet (zu upgraden versucht), hält er es zurück.

Der selbe Effekt kann mit dselect 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.

Das APT-System in der Woody-Distribution hat einen neuen "Alternativen" Mechanismus zum Halten von Paketen während des Archivabfrageprozesses unter Verwendung von Pin-Priority. Vergleiche die Handbuchseite apt_preferences(5) sowie http://www.debian.org/doc/manuals/apt-howto/ oder das apt-howto-Paket; Überblick über /etc/apt/preferences, Abschnitt 6.2.8 enthält auch eine kurze Erläuterung.

2.2.12 Quellpakete

Quellpakete befinden sich in einem Verzeichnis namens source und können entweder manuell heruntergeladen werden oder durch 

     apt-get source foo

(vergleiche die apt-get(8) Handbuchseite wie man APT dazu bringt, dies zu tun).

2.2.13 Erzeugen von Binär- aus Quellcodepaketen

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

Sind diese Dateien vorhanden und ist das dpkg-dev-Paket installiert, so extrahiert das Kommando 

     $ dpkg-source -x foo_version-revision.dsc

das Paket in ein Verzeichnis namens foo-version.

Zum Erzeugen des Binärpakets ist Folgendes auszuführen: 

     $ cd foo-version
     $ su -c "apt-get update; apt-get install fakeroot"
     $ dpkg-buildpackage -rfakeroot -us -uc

Und danach 

     # su -c "dpkg -i ../foo_version-revision_arch.deb"

zum Installieren des neu gebildeten Pakets. Vergleiche Portierung eines Pakets auf die stable-Distribution, Abschnitt 6.4.10.

2.2.14 Erzeugen neuer Debian-Pakete

Für detaillierte Informationen zum Erzeugen neuer Pakete sollte der New Maintainers' Guide gelesen werden, verfügbar im maint-guide Paket, oder unter http://www.debian.org/doc/manuals/maint-guide/.

2.3 Aktualisierung eines Debian-Systems

Einer von Debians 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.

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 http://www.debian.org/releases/stable/releasenotes oder http://www.debian.org/releases/testing/releasenotes verfügbar.

Eine praktische Anleitung zum Aktualisieren wird in Debian-Paketverwaltung, Kapitel 6 bereitgestellt. Dieser Abschnitt beschreibt die grundlegenden Einzelheiten.

2.3.1 Methoden zum Aktualisieren eines Debian-Systems

Man kann immer einfach einen anonymen FTP- oder wget-Aufruf zu einem Debian-Archiv starten, die Verzeichnisse durchsehen, bis man die gewünschte Datei gefunden hat, diese herunterladen und schließlich mittels dpkg installieren. (Es ist zu beachten, dass dpkg 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.

Viele Personen finden dieses manuelle Vorgehen zu Zeit aufwendig, da Debian sich so schnell entwickelt – 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.

2.3.2 Überblick über Paketverwaltungstools

Das Debian-Paketverwaltungssystem hat zwei Aufgaben: die Manipulation der Paketdatei und das Herunterladen von Paketdateien aus dem Debian-Archiv. dpkg erfüllt die erste Aufgabe, APT und dselect die letztere.

2.3.3 dpkg

Dies ist das wichtigste Programm zum Manipulieren von Paketdateien. Für eine ausführliche Beschreibung ist dpkg(8) zu lesen.

dpkg wird mit einigen wichtigen Programmen ausgeliefert.

dpkg-ftp und dpkg-mountable wurden durch das APT-System ersetzt.

2.3.4 APT

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

Für weitere Informationen ist das apt-Paket zu installieren und apt-get(8), apt-cache(8), apt-cdrom(8), apt.conf(5), sources.list(5), apt_preferences(5) (Woody) sowie /usr/share/doc/apt/guide.html/index.html zu lesen.

Weitere Informationen finden sich im APT HOWTO. Dazu kann in Sarge apt-howto-de installiert werden und steht dann unter /usr/share/doc/Debian/apt-howto/ zur Verfügung (Woody enthält nur die englische Version apt-howto).

apt-get upgrade und apt-get dist-upgrade 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 dselect verwendet werden.

2.3.5 dselect

Dieses Programm besitzt eine Menüoberfläche zu Debians Paketverwaltungssystem. Es ist besonders für die Erstinstallation und große Upgrades nützlich. Vergleiche dselect, Abschnitt 6.2.3.

Für weitere Informationen sollte das install-doc-Paket installiert und /usr/share/doc/install-doc/dselect-beginner.en.html oder dselect Documentation for Beginners gelesen werden.

2.3.6 Aktualisieren eines laufenden Systems

Der Kernel (das Dateisystem) in Debian-Systemen unterstützt das Ersetzen von Dateien auch während sie benutzt werden.

Es wird auch ein Programm namens start-stop-daemon bereitgestellt, das verwendet wird, um Daemonen während des Bootens zu starten oder zum Stoppen von Daemonen, wenn das 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 Daemon enthält, installiert wird, um laufende Daemonen zu stoppen und bei Bedarf neuzustarten.

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

2.3.7 Heruntergeladene und zwischengespeicherte .deb-Archiv-Dateien

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

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

2.3.8 Aufbewahren des Datensatzes für Upgrades

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

Der einfachste Weg, dieses Problem zu umgehen, ist Sitzungen von dpkg, dselect, apt-get, etc. innerhalb des script(1) Programms ablaufen zu lassen.

2.4 Der Debian-Bootvorgang

2.4.1 Das init-Programm

Wie alle Unices, wird Debian durch das Programm init gestartet. Die Konfigurationsdatei für init (dies ist /etc/inittab) gibt an, dass das erste zu startende Skript /etc/init.d/rcS ist. Dieses Skript startet alle anderen Skripte in /etc/rcS.d/, 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, die Uhrzeit setzen, u.a. Danach werden zwecks Kompatibilität die Dateien (mit Ausnahme der mit einem `.' im Dateinamen) in /etc/rc.boot/ ausgeführt. Jedes Skript in diesem Verzeichnis ist normalerweise dem Systemadministrator vorbehalten, die Verwendung dieser in Paketen wird missbilligt. Vergleichen Sie Hinweise zur System-Inititalisierung, Abschnitt 9.1 und System run levels and init.d scripts in den Debian-Richtlinien für weitere Informationen.

2.4.2 Runlevel

Nach dem Bootprozess führt init alle Startskripte in einem durch das Standard-Runlevel festgelegten Verzeichnis aus. (Dieses Runlevel wird durch den Eintrag id in /etc/inittab festgelegt). Wie viele System-V-kompatible Unices hat Linux 7 Runlevel:

Für Debian-Systeme gilt id=2, was bedeutet, dass das Standard-Runlevel 2 sein wird, wenn der Mehrbenutzer-Modus aktiv ist und die Skripte in /etc/rc2.d/ werden ausgeführt.

In Wirklichkeit sind die Skripte in den Verzeichnissen /etc/rcN.d/ nur symbolische Links zu Skripten in /etc/init.d/. Dennoch werden die Namen der Dateien in jedem der /etc/rcN.d/-Verzeichnisse individuell gewählt, um anzugeben wie die Skripte in /etc/init.d/ 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.

Dieses Vorgehen funktioniert, da die Skripte in /etc/init.d/ 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 Neuladen). Diese Skripte können auch ausgeführt werden, nachdem das System gebootet wurde, um verschiedene Prozesse zu kontrollieren.

Zum Beispiel führt das Argument "reload" im Kommando 

     # /etc/init.d/exim4 reload

dazu, dass der exim4-Daemon ein Signal zum erneuten Einlesen der Konfigurationsdatei erhält.

2.4.3 Anpassen des Bootvorgangs

Debian verwendet kein BSD typisches rc.local Verzeichnis, um den Bootvorgang anzupassen; stattdessen wird folgender Mechanismus angeboten.

Angenommen foo sei ein Skript, das während des Startvorgangs oder beim Übergang in ein bestimmtes (System V) Runlevel aufgerufen werden soll. Dann sollte der Systemadministrator:

  1. Das Skript foo in das Verzeichnis /etc/init.d/ verschieben.

  1. Das Debian-Kommando update-rc.d mit entsprechenden Argumenten starten, um Links zwischen den (Kommandozeilen spezifischen) Verzeichnissen rc?.d und /etc/init.d/foo anzulegen. Dabei bezeichnet ? eine Nummer von 0 bis 6, die einem der System V Runlevel entspricht.

  1. Das System neu booten.

Das Kommando update-rc.d setzt Links zwischen Dateien im Verzeichnis rc?.d und dem Skript in /etc/init.d/. Jeder Link beginnt mit einem `S' oder `K', gefolgt von einer Nummer, gefolgt vom Namen des Skripts. Beim Wechsel in das Runlevel N, werden Skripte in /etc/rcN.d/ die mit `K' beginnen mit stop als Argument ausgeführt, gefolgt von den mit `S' beginnenden Skripten in /etc/rcN.d/ mit start als Argument.

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

2.5 Unterstützung von Vielfalten

Debian unterstützt verschiedene Möglichkeiten zum Anpassen des Systems, ohne das System zu beeinträchtigen.

Alle Dateien unter /usr/local/ gehören dem Systemadministrator und Debian wird sie nicht verändern. Viele (oder alle) Dateien unter /etc sind Konfigurationsdateien und Debian wird sie nicht während eines Upgrades überschreiben, es sei denn der Systemadministrator erlaubt dies ausdrücklich.

2.6 Internationalisierung

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, Handbuchseiten und Systemausgaben wurden in eine ständig wachsende Anzahl von Sprachen übersetzt. Während der Installation fordert Debian den Nutzer zur Wahl der Installationssprache (und manchmal eines lokalen Dialekts) auf.

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 Lokalisation und Sprachen, Abschnitt 9.7.

2.7 Debian und der Kernel

Vergleiche Der Linux-Kernel unter Debian, Kapitel 7.

2.7.1 Kompilierung eines Kernel aus Debian-fremden Quellen

Man sollte die Debian-Politik bezüglich der Header verstanden haben, bevor man startet.

Die Debian-C-Bibliotheken wurden mit der aktuellsten stabilen Version der Kernelheader erstellt.

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 /usr/include/linux/include/.

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

2.7.2 Tools zum Erzeugen angepasster Kernel

Nutzern die einen angepassten Kernel erzeugen wollen (oder müssen), wird empfohlen, das Paket 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 

     # make-kpkg kernel_image

im Kernelquellverzeichnis zu starten. Hilfe ist durch Ausführung von 

     # make-kpkg --help

verfügbar und durch die Handbuchseite make-kpkg(1) sowie Der Linux-Kernel unter Debian, Kapitel 7.

Nutzer müssen den Quellcode für den aktuellsten Kernel (oder den Kernel ihrer Wahl) separat vom bevorzugten Linux-Archiv herunterladen, wenn kein kernel-source-version-Paket (dabei steht version für die Kernel-Version) vorhanden ist. Das Debian initrd-Bootskript erfordert einen speziellen Kernel-Patch namens initrd; vergleiche http://bugs.debian.org/149236.

Detaillierte Anweisungen zur Benutzung des kernel-package-Pakets sind in der Datei /usr/share/doc/kernel-package/README.gz zu finden.

2.7.3 Spezielle Regeln für den Umgang mit Modulen

Debians modconf Paket enthält ein Shellskript (/usr/sbin/modconf), 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 /etc/modules.conf (welche Aliase enthält sowie andere Argumente, die in Verbindung mit verschiedenen Modulen verwendet werden müssen) anzupassen, auf Grund von Dateien in /etc/modutils/ und /etc/modules (die die Module auflistet, die zur Bootzeit geladen werden müssen).

Wie die (neuen) Configure.help-Dateien, die nun verfügbar sind, um angepasste Kernel zu unterstützen, kommt das modconf-Paket mit einer Reihe von Hilfe-Dateien (in /usr/share/modconf/), die detaillierte Informationen über passende Argumente für jedes Modul enthalten. Vergleiche Der modularisierte Kernel 2.4, Abschnitt 7.2 für Beispiele.

2.7.4 Deinstallation eines alten Kernel-Pakets

Das kernel-image-NNN.prerm-Skript überprüft, ob der aktuell laufende Kernel mit dem zu entfernenden Kernel übereinstimmt. Deshalb können ungewünschte kernel-image Pakete sicher mittels 

     # dpkg --purge --force-remove-essential kernel-image-NNN

entfernt werden. (NNN ist durch die entsprechende Kernelversion und Revisionsnummer zu ersetzen.)

[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ weiter ]

Debian-Referenz

CVS, Don 18. Jan 2007, 11:52:59 UTC

Osamu Aoki osamu#at#debian.org
Übersetzer: Jens Seidel tux-master#at#web.de
Autoren, Abschnitt A.1