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.
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/:Contents-*.gz Dateien, und die Packages.gz
Dateien sind immer noch hier zu finden.
pool/:tools/:doc/:indices/:Maintainers-Datei (Liste aller Paketbetreuer) und die
override.*-Dateien.
project/:project/experimental/:project/orphaned/:
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.
Pakete der stable-Distribution, Debian Woody (3.0r0), befinden
sich im stable- (symbolischer Link zu woody/)
Verzeichnis:
stable/main/: Dieses Verzeichnis enthält die Pakete, welche formal
die aktuellste Ausgabe des Debian-Systems bilden.
Diese Pakete entsprechen alle den Debian Free Software
Leitlinien (DFSG) (auch verfügbar unter
/usr/share/doc/debian/social-contract.txt installiert durch
debian-doc) und sind alle frei verfügbar und verteilbar.
stable/non-free/: Dieses Verzeichnis enthält Pakete, deren
Weitergabe in gewisser Weise beschränkt ist. Genauere Informationen sind in
den jeweiligen Copyright-Hinweisen zu finden.
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.
stable/contrib/: Dieses Verzeichnis enthält Pakete, welche
DFSG-frei und frei verteilbar sind, aber irgendwie von einem
Paket abhängen, das nicht frei verteilbar und somit nur im
non-free Abschnitt zu finden ist.
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.
Pakete der testing-Distribution, Debian Sarge, befinden sich im
testing- (symbolischer Link zu sarge/) 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:
update
Ausflüchte
testing
Probleme
veröffentlichungskritische
Fehler
Basissystem
Fehler
Fehler in
Standard und Task Paketen
andere Fehler und Bemerkungen zu
Fehlerausmerzungs-Partys
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.
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. (Der aktuelle Woody-Ausgabeprozess erzeugte keinen
symbolischen Link frozen/, deshalb war frozen keine
Distribution sondern nur ein Entwicklungsschritt der
testing-Distribution.)
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).
Verzeichnisnamen im dists-Verzeichnis, wie woody/ und
sarge/ 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).
Zur Zeit ist stable/ ein symbolischer Link zu woody/
und testing/ ist ein symbolischer Link zu sarge/.
Das bedeutet, dass Woody die aktuelle
stable-Distribution und Sarge die aktuelle
testing-Distribution ist.
unstable/ ist ein permanenter symbolischer Link zu
sid/, so wie Sid ständig für die
unstable-Distribution steht.
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.
Bisher wurden Personen aus dem Film Toy Story von Pixar verwendet.
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.
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).
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.
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/.
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.
binary-all/ für Pakete, welche architekturunabhängig sind. Dies
umschließt z.B. Perl-Skripte oder Dokumentationen.
binary-Plattform/ für Pakete, welche sich auf einer
einzelnen Binärplattform starten lassen.
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.
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.
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:
dpkg-Programm ausgepackt werden; Details sind in der Handbuchseite
beschrieben.
dpkg-source packt und
entpackt Debian-Quellpakete; Details sind in der Handbuchseite enthalten.
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:
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(8) 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.
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.
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.
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:
Zur Zeit 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.)
Jedem Debian-Paket ist eine Priorität vom Distributionsbetreuer zugeordnet worden, um die Arbeit des Paketverwaltungssystems zu vereinfachen. Die Prioritäten sind:
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 dpkg 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.
Andere Pakete ohne die das System nicht gut oder brauchbar arbeitet, haben diese Priorität. Dies schließt nicht Emacs, X11, TeX oder andere große Anwendungen ein. Diese Pakete erzeugen nur die nötige Infrastruktur.
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).
Dies schließt X11, eine vollständige TeX-Distribution und viele Anwendungen mit ein.
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".
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.
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.
"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.
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:
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.
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).
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.
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/.
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.
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.
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.
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-deb: Manipuliert .deb Dateien.
dpkg-deb(1)
dpkg-ftp: Ein älteres Programm zum Herunterladen von Paketen.
dpkg-ftp(1)
dpkg-mountable: Ein älteres Programm zum Herunterladen von
Paketen. dpkg-mountable(1)
dpkg-split: Teilt ein größeres Paket in kleinere Dateien auf.
dpkg-split(1)
dpkg-ftp und dpkg-mountable wurden durch das
APT-System ersetzt.
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.
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.
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.
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.
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.
Der einfachste Weg, dieses Problem zu umgehen, ist Sitzungen von
dpkg, dselect, apt-get, etc. innerhalb
des script(1) Programms ablaufen zu lassen.
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.
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.
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:
/etc/init.d/
verschieben.
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.
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.
Debian unterstützt verschiedene Möglichkeiten zum Anpassen des Systems, ohne das System zu beeinträchtigen.
dpkg-divert, vergleiche Der dpkg-divert-Befehl,
Abschnitt 6.5.1.
equivs, vergleiche Das
equivs-Paket, Abschnitt 6.5.2.
update-alternative, vergleiche Alternative Befehle, Abschnitt
6.5.3.
make-kpkg kann viele Boot-Loader anpassen. Vergleiche
make-kpkg(1) und Die
Debian-Standardmethode, Abschnitt 7.1.1.
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.
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.
Vergleiche Der Linux-Kernel unter Debian, Kapitel 7.
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.
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(8) 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.
Zur Verwendung von alternativen Boot-Loader wie grub oder
loadlin ist der kompilierte Linux-Kernel bzimage in
ein anderes Verzeichnis (wie /boot/grub oder auf eine MS-DOS
Partition) zu kopieren.
Die Erstellung einer angepassten Boot-Diskette wird durch das Debian-Paket
boot-floppies unterstützt, das normalerweise im
admin-Abschnitt des Debian-FTP-Archivs gefunden wird.
Shellskripte in diesem Paket erzeugen Boot-Disketten im
syslinux-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 syslinux.cfg-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.
Mehr Informationen darüber können in der
/usr/doc/boot-floppies/README-Datei nach der Installation des
boot-floppies-Paketes gefunden werden.
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.
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.)
Debian-Referenz
CVS, Mon 3. Apr 2005, 22:57:58 UTCosamu@debian.orgtux-master@web.de