Das Debian-Paket ist nicht nur ein für die Installation vorgesehenes Archiv von Dateien. Es ist Teil eines größeren Ganzen und beschreibt seine Beziehungen zu anderen Debian-Paketen (Abhängigkeiten, Konflikte, Vorschläge). Es stellt auch Skripte zur Verfügung, die die Ausführung von Befehlen in verschiedenen Lebensphasen des Paketes (Installation, Entfernung, Aktualisierung) ermöglichen. Diese vom Paket-Verwaltungsprogramm benutzten Daten sind nicht Teil des Softwarebündels, sondern sind innerhalb des Pakets sogenannte „Meta-Informationen“ (Information über andere Information).
5.2.1. Beschreibung: Die control-Datei
Diese Datei verwendet eine den E-Mail-Kopfzeilen ähnliche Struktur (wie sie in RFC 2822 definiert ist). So sieht zum Beispiel für aptdie control-Datei folgendermaßen aus:
$ apt-cache show apt
Package: apt
Version: 0.9.7.9
Installed-Size: 3271
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: amd64
Replaces: manpages-pl (<< 20060617-3~)
Depends: libapt-pkg4.12 (>= 0.9.7.9), libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.6), debian-archive-keyring, gnupg
Suggests: aptitude | synaptic | wajig, dpkg-dev, apt-doc, xz-utils, python-apt
Conflicts: python-apt (<< 0.7.93.2~)
Description-en: commandline package manager
This package provides commandline tools for searching and
managing as well as querying information about packages
as a low-level access to all features of the libapt-pkg library.
.
These include:
* apt-get for retrieval of packages and information about them
from authenticated sources and for installation, upgrade and
removal of packages together with their dependencies
* apt-cache for querying available information about installed
as well as installable packages
* apt-cdrom to use removable media as a source for packages
* apt-config as an interface to the configuration settings
* apt-key as an interface to manage authentication keys
Description-md5: 9fb97a88cb7383934ef963352b53b4a7
Tag: admin::package-management, hardware::storage, hardware::storage:cd,
implemented-in::c++, interface::commandline, network::client,
protocol::ftp, protocol::http, protocol::ipv6, role::program,
suite::debian, use::downloading, use::searching,
works-with::software:package
Section: admin
Priority: important
Filename: pool/main/a/apt/apt_0.9.7.9_amd64.deb
Size: 1253524
MD5sum: 00a128b2eb2b08f4ecee7fe0d7e3c1c4
SHA1: 6a271487ceee6f6d7bc4c47a8a16f49c26e4ca04
SHA256: 3bba3b15fb5ace96df052935d7069e0d21ff1f5b496510ec9d2dc939eefad104
5.2.1.1. Abhängigkeiten: dieDepends-Zeile
Die Abhängigkeiten sind in der Depends-Zeile des Paketkopfs definiert. Dies ist eine Liste von Bedingungen, die erfüllt sein müssen, damit das Paket korrekt funktioniert - diese Information wird von Programmen wie apt dazu verwendet, die erforderlichen Bibliotheken in der passenden Version zu installieren, auf die das zu installierende Programm angewiesen ist. Für jede Abhängigkeit kann der Bereich der Versionen, die diese Bedingung erfüllen, eingeschränkt werden. Anders ausgedrückt ist es möglich, die Tatsache zu bekunden, dass wir das Paket libc6 in einer Version größer oder gleich „2.3.4“ benötigen (geschrieben „libc6 (>= 2.3.4)“). Für den Versionsvergleich gibt es folgende Operatoren:
<<: kleiner als;
<=: kleiner als oder gleich;
=: gleich (man beachte, „2.6.1“ ist nicht gleich „2.6.1-1“);
>=: größer als oder gleich;
>>: größer als.
In einer Liste der zu erfüllenden Bedingungen dient das Komma als Trennzeichen. Logisch wird es als „UND“ interpretiert. In den Bedingungen drückt der vertikale Strich („|“) ein logisches „ODER“ aus (es ist ein nicht ausschließendes bzw. inklusives „ODER“, im Gegensatz zum exklusiven „ODER“, bei dem nur eine der Aussagen wahr ist). Es hat einen höheren Rang als „UND“ und kann so oft aneinandergereiht werden wie nötig. So wird die Abhängigkeit „(A ODER B) UND C“ geschrieben als
A | B, C. Dagegen sollte der Ausdruck „A ODER (B UND C)“ geschrieben werden als „(A ODER B) UND (A ODER C)“, da die
Depends-Zeilen keine Klammern zulassen, die die Rangordnung zwischen den logischen Operatoren „ODER“ und „UND“ verändern. Es würde daher als
A | B, A | C geschrieben.
Das Abhängigkeitensystem ist eine gute Vorrichtung um das Funktionieren eines Programms sicherzustellen, aber es hat mit den „Meta-Paketen“ noch eine weitere Funktion. Dies sind leere Pakete, die lediglich Abhängigkeiten beschreiben. Sie erleichtern die Installation einer zusammenhängenden Gruppe von Programmen, die vom Betreuer des Meta-Pakets ausgewählt wurden. So installiert apt-get install Meta-Paket automatisch alle Programme unter Verwendung der Abhängigkeiten des Meta-Pakets. Die Pakete gnome, kde-full und linux-image-amd64 sind Beispiele solcher Meta-Pakete.
5.2.1.2. Konflikte: die Conflicts-Zeilen
Die Conflicts-Zeilen zeigen an, dass ein Paket nicht gleichzeitig mit einem anderen installiert sein kann. Die häufigsten Gründe hierfür sind, dass beide Pakete eine Datei gleichen Namens enthalten, dass sie den gleichen Dienst am selben TCP-Port anbieten oder dass sie sich gegenseitig im Betrieb behindern würden.
dpkg wird sich weigern, ein Paket zu installieren, falls es einen Konflikt mit einem bereits installierten Paket auslöst, es sei denn das neue Paket gibt an, dass es die installierten Pakete „ersetzen“ wird. In diesem Fall wird sich dpkg dafür entscheiden, das alte Paket durch das neue zu ersetzen. apt-get folgt immer Ihren Anweisungen: wenn Sie es vorziehen ein neues Paket zu installieren, wird es automatisch anbieten das Paket, das ein Problem darstellt, zu deinstallieren.
5.2.1.3. Inkompatibilitäten: die Breaks-Zeilen
Die Breaks-Zeilen haben einen ähnlichen Effekt wie die Conflicts-Zeilen, jedoch mit einer besonderen Bedeutung. Sie deutet darauf hin, dass die Installation eines Paketes ein anderes Paket (oder bestimmte Versionen davon) „brechen“ wird. Normalerweise ist die Inkompatibilität zwischen zwei Paketen vorübergehend, und die Breaks-Beziehung bezieht sich auf die inkompatiblen Versionen.
dpkg wird sich weigern, ein Paket zu installieren das ein bereits installiertes Paket beschädigen würde, und apt-get wird versuchen das Problem dadurch zu lösen, dass es das Paket das beschädigt würde auf eine neuere Version zu aktualisieren (von der angenommen wird, dass sie korrigiert und damit wieder kompatibel ist).
Diese Situation kann bei Aktualisierungen ohne rückwärtige Kompatibilität auftreten: dies ist der Fall, wenn eine neue Version nicht mehr zusammen mit der älteren Version funktioniert und eine Fehlfunktion in einem anderen Programm verursacht ohne dass dafür besondere Vorkehrungen getroffen worden sind. Die Breaks-Zeilen verhindern, dass der Nutzer in diese Schwierigkeiten gerät.
5.2.1.4. Bereitgestellte Elemente: die Provides-Zeilen
Diese Zeile führt das sehr interessante Konzept eines „virtuellen Pakets“ ein. Sie hat viele Aufgaben, aber zwei sind von besonderer Bedeutung. Die erste Aufgabe besteht darin, ein virtuelles Paket dazu zu benutzen, ihm einen allgemeinen Dienst zuzuordnen (das Paket „stellt“ den Dienst „bereit“). Die zweite zeigt an, dass ein Paket ein anderes vollständig ersetzt, und dass es daher auch die Abhängigkeiten erfüllen kann, die das andere erfüllen würde. Auf diese Weise kann ein Ersatzpaket erstellt werden, ohne denselben Paketnamen verwenden zu müssen.
5.2.1.4.1. Einen „Dienst“ bereitstellen
Lassen Sie uns den ersten Fall anhand eines Beispiels ausführlicher erörtern: alle Mailserver, wie postfix oder sendmail, „stellen“ angeblich das virtuelle Paket mail-transport-agent „bereit“. Daher erklärt jedes Paket, das diesen Service benötigt, um funktionsfähig zu sein (z. B. Mailinglisten-Manager wie smartlist oder sympa), in seinen Abhängigkeiten einfach, dass es einen mail-transport-agent benötigt, anstatt eine lange, jedoch unvollständige Liste möglicher Lösungen aufzustellen (z. B. postfix | sendmail | exim4 | …). Außerdem wäre es sinnlos, zwei Mailserver auf demselben Rechner zu installieren, weshalb jedes dieser Pakete einen Konflikt mit dem virtuellen Paket mail-transport-agent angibt. Der Konflikt mit sich selbst wird vom System ignoriert, jedoch verhindert dieses Verfahren. dass zwei Mailserver nebeneinander installiert werden.
5.2.1.4.2. Austauschbarkeit mit einem anderen Paket
Die Provides-Zeile ist dagegen von Interesse, wenn der Inhalt eines Pakets in einem größeren Paket enthalten ist. So war zum Beispiel das Perl-Modul libdigest-md5-perl ein optionales Modul in Perl 5.6 und ist als Standard in Perl 5.8 (und späteren Versionen wie der aktuellen Version 5.14 in Wheezy) integriert worden. Daher gibt das Paket perl seit der Version 5.8 Provides: libdigest-md5-perl an, so dass die Abhängigkeiten dieses Pakets erfüllt sind, falls der Nutzer Perl 5.8 oder neuer hat. Das Paket libdigest-md5-perl selbst ist irgendwann gelöscht worden, da es keinen weiteren Nutzen mehr hatte, nachdem alte Perl-Versionen entfernt worden waren.
Dieses Merkmal ist sehr nützlich, da es nie möglich ist, die Wechselfälle der Entwicklung vorherzusehen, und es erforderlich ist, sich auf die Umbenennung oder einen anderen automatischen Ersatz einer veralteten Software einzustellen.
5.2.1.4.3. Gegenwärtige Einschränkungen
Virtuelle Pakete leiden an einigen Einschränkungen, von denen die wichtigste das Fehlen einer Versionsnummer ist. Um zum vorhergehenden Beispiel zurückzukehren: eine Abhängigkeit wie Depends: libdigest-md5-perl (>= 1.6) wird trotz der Anwesenheit von Perl 5.10 von der Paketverwaltung niemals als erfüllt angesehen werden - obwohl sie in Wirklichkeit höchstwahrscheinlich erfüllt ist. In Unkenntnis dieser Tatsache wählt die Paketverwaltung die risikoärmste Option und geht davon aus, dass die Versionen nicht übereinstimmen.
5.2.1.5. Dateien ersetzen: Die Replaces-Zeile
Die Replaces-Zeile zeigt an, dass das Paket Dateien enthält, die auch in einem anderen Paket vorhanden sind, dass aber das Paket offiziell berechtigt ist, sie zu ersetzen. Ohne diese Angabe würde dpkg scheitern und erklären, dass es die Dateien eines anderen Pakets nicht überschreiben kann (allerdings kann es durch die Option --force-overwrite dazu gezwungen werden). Hierdurch ist es möglich, eventuelle Probleme zu identifizieren, und der Betreuer muss die Angelegenheit untersuchen, bevor er entscheidet, ob er solch eine Zeile einfügt.
Die Verwendung dieser Zeile ist gerechtfertigt, wenn sich Paketnamen ändern oder wenn ein Paket in einem anderen enthalten ist. Dies kommt auch vor, wenn der Betreuer sich entschließt, Dateien in unterschiedlicher Weise auf mehrere Binärpakete zu verteilen, die vom selben Quellpaket erstellt werden: eine ersetzte Datei ist nicht mehr Teil des alten Pakets, sondern nur noch des neuen.
Sobald alle Dateien eines installierten Pakets ersetzt wurden, gilt das Paket als entfernt. Ausserdem veranlasst dieses Feld dpkg, das ersetzte Paket zu entfernen, wenn ein Konflikt auftritt.
5.2.2. Konfigurationsskripte
Zusätzlich zur control-Datei kann das control.tar.gz-Archiv jeden Debian-Pakets eine Anzahl von Skripten enthalten, die von dpkg in verschiedenen Phasen der Paketverarbeitung aufgerufen werden. Die Debian-Richtlinien beschreiben ausführlich die möglichen Fälle mit Benennung der aufgerufenen Skripte und der Parameter, die sie entgegennehmen. Diese Abläufe können kompliziert sein, da dpkg im Falle des Scheiterns eines Skripts versucht, zu einem zufriedenstellenden Zustand zurückzukehren, indem es die Installation oder die gerade stattfindende Entfernung (insofern möglich) abbricht.
Im Allgemeinen wird das Skript preinst vor der Installation eines Pakets ausgeführt, postinst danach. In gleicher Weise wird prerm vor dem Entfernen eines Pakets aufgerufen und postrm danach. Die Aktualisierung eines Pakets ist gleichbedeutend mit dem Entfernen der vorhergehenden Version und einer Installation der neuen. Alle möglichen Szenarien können hier nicht ausführlich beschrieben werden, aber wir werden die zwei häufigsten erörtern: eine Installation/Aktualisierung und ein Entfernen.
5.2.2.1. Installation und Aktualisierung
Folgendes geschieht während einer Installation (oder einer Aktualisierung):
Für eine Aktualisierung ruft dpkg das Skript old-prerm upgrade neue-version auf.
Ebenfalls für eine Aktualisierung führt dpkg dann new-preinst upgradealte-version aus; bei einer erstmaligen Installation führt es stattdessen new-preinst install aus. Möglicherweise fügt es im letzten Parameter die alte Version hinzu, falls das Paket früher schon einmal installiert war und seither entfernt wurde (aber nicht vollständig gelöscht, da die Konfigurationsdateien noch zurückbehalten wurden).
Die neuen Paketdateien werden dann entpackt. Falls eine Datei bereits vorhanden ist, wird sie ersetzt, wobei aber vorübergehend eine Sicherheitskopie erstellt wird.
Für eine Aktualisierung führt dpkg das Skript old-postrm upgrade neue-version aus.
dpkg aktualisiert alle internen Daten (Dateiliste, Konfigurationsskripte usw.) und entfernt die Sicherheitskopien der ersetzten Dateien. Dies ist der Punkt, an dem es kein Zurück mehr gibt: dpkg hat keinen Zugang zu all den Elementen mehr, die für eine Rückkehr zum vorherigen Zustand erforderlich wären.
Schließlich konfiguriert dpkg das Paket, indem es new-postinst configure vorherige-konfigurierte-version ausführt.
Folgendes geschieht, wenn ein Paket entfernt wird:
dpkg ruft prerm remove auf.
dpkg entfernt alle Dateien des Pakets bis auf die Konfigurationsdateien und die Konfigurationsskripte.
dpkg führt postrm remove aus. Hierdurch werden alle Konfigurationsskripte bis auf postrm entfernt. Falls der Nutzer nicht die Option „purge“ benutzt hat, wird der Ablauf hier beendet.
Bei einer vollständigen Entfernung des Paketes (durch den Befehl dpkg --purge oder dpkg -P) werden sowohl die Konfigurationsdateien entfernt, als auch eine Anzahl von Kopien (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) und temporären Dateien; dpkg führt dann abschließend postrm purge aus.
Die vier oben beschriebenen Skripte werden durch ein config-Skript ergänzt, das von Paketen bereitgestellt wird, die debconf verwenden, um vom Nutzer Informationen für die Konfigurierung zu bekommen. Während der Installation bestimmt dieses Skript im Einzelnen die Fragen, die von debconf gestellt werden. Die Antworten werden zur späteren Verwendung in der debconf-Datenbank aufgezeichnet. Das Skript wird von apt normalerweise ausgeführt, bevor es ein Paket nach dem anderen installiert, um so alle Fragen zu gliedern und sie dem Nutzer vollständig zu Beginn des Vorgangs zu stellen. Die Vor- und Nachinstallationsskripte können dann diese Information verwenden, um den Wünschen des Nutzers entsprechend zu agieren.
5.2.3. Checksummen, Liste der Konfigurationsdateien
Zusätzlich zu den in den vorherigen Kapiteln genannten Verwaltungsskripten und Kontrolldaten enthält das Archiv
control.tar.gz eines Debian-Pakets weitere interessante Dateien. Die erste,
md5sums, enthält die MD5-Prüfsumme aller Dateien des Pakets. Ihr Hauptvorteil besteht darin, dass sie es einem Programm wie
debsums (auf das wir in
Abschnitt 14.3.3.1, „Pakete auditieren: debsums und seine Grenzen“ noch näher eingehen werden) ermöglicht, zu überprüfen, ob diese Dateien seit ihrer Installation verändert worden sind. Man beachte, dass der Befehl
dpkg diese Datei dynamisch zur Installationszeit erzeugt, falls sie nicht vorhanden ist (und in der dpkg-Datenbank speichert wie die anderen Kontrolldateien).
conffiles führt Paketdateien auf, die als Konfigurationsdateien behandelt werden müssen. Konfigurationsdateien können durch den Administrator angepasst werden und dpkg wird versuchen, diese Anpassungen bei einer Paketaktualisierung zu erhalten.
Im Ergebnis verhält sich dpkg in dieser Situation möglichst intelligent: falls die Standard-Konfigurationsdatei zwischen zwei Versionen nicht verändert worden ist, tut es gar nichts. Falls die Datei jedoch verändert wurde, wird es versuchen, sie zu aktualisieren. Zwei Fälle sind möglich: entweder hat der Administrator diese Konfigurationsdatei nicht angerührt, dann installiert dpkg automatisch die neue Version; oder die Datei ist verändert worden, dann fragt dpkg den Administrator, welche Version er verwenden möchte (die alte mit den Veränderungen oder die neue, die mit dem Paket bereitgestellt wird). Um diese Entscheidung zu erleichtern, bietet dpkg an, ein „diff“ anzuzeigen, das die Unterschiede zwischen den beiden Versionen aufführt. Falls der Nutzer sich entscheidet, die alte Version zu behalten, wird die neue am selben Ort in einer Datei mit dem Zusatz .dpkg-dist abgespeichert. Wenn der Anwender die neue Version auswählt, wird die alte in einer Datei mit dem Suffix .dpkg-old suffix gespeichert. Eine weitere mögliche Maßnahme besteht darin, dpkg vorübergehend anzuhalten und dann die Datei zu editieren, und dabei zu versuchen, die relevanten Veränderungen (die zuvor durch diff identifiziert worden sind) wieder einzusetzen.
