Product SiteDocumentation Site

5.2. Paket-Meta-Information

The Debian package is not only an archive of files intended for installation. It is part of a larger whole and describes its relationship with other Debian packages (requisites, dependencies, conflicts, suggestions). It also provides scripts that enable the execution of commands at different stages in the package's lifecycle (installation, upgrade, removal). These data are used by the package management tools, but are not part of the packaged software; they are, within the package, what is called its “meta-information” - information about other information.

5.2.1. Beschreibung: Die control-Datei

Diese Datei verwendet eine ähnliche Struktur wie E-Mail-Header (wie in RFC 2822 definiert) und ist in der Debian-Richtlinie und den Handbuchseiten deb-control(5) vollständig beschrieben und deb822(5).
So sieht zum Beispiel für apt die control-Datei folgendermaßen aus:
$ apt-cache show apt
Package: apt
Version: 2.2.4
Installed-Size: 4337
Maintainer: APT Development Team <[email protected]>
Architecture: amd64
Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~)
Provides: apt-transport-https (= 2.2.4)
Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.2.4), debian-archive-keyring, libc6 (>= 2.15), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.0), libseccomp2 (>= 2.4.2), libstdc++6 (>= 9), libsystemd0
Recommends: ca-certificates
Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), gnupg | gnupg2 | gnupg1, powermgmt-base
Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude (<< 0.8.10)
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, devel::lang:ruby, hardware::storage,
 hardware::storage:cd, implemented-in::c++, implemented-in::perl,
 implemented-in::ruby, interface::commandline, network::client,
 protocol::ftp, protocol::http, protocol::ipv6, role::program,
 scope::application, scope::utility, suite::debian, use::downloading,
 use::organizing, use::playing, use::searching, works-with-format::html,
 works-with::audio, works-with::software:package, works-with::text
Section: admin
Priority: required
Filename: pool/main/a/apt/apt_2.2.4_amd64.deb
Size: 1491328
MD5sum: 24d53e8dd75095640a167f40476c0442
SHA256: 75f07c4965ff0813f26623a1164e162538f5e94defba6961347527ed71bc4f3d
Let us have a closer look at the purpose of some of the fields listed by the previous command.

5.2.1.1. Abhängigkeiten: dieDepends-Zeile

The dependencies are defined in the Depends field in the package header. It is a list of conditions to be met for the package to work correctly. This information is used by tools such as apt in order to install the required libraries, tools, drivers, etc., in appropriate versions fulfilling the dependencies of the package to be installed. For each dependency it is possible to restrict the range of versions that meet that condition. In other words, it is possible to express the fact that we need the package libc6 in a version equal to or greater than “2.15” (written “libc6 (>= 2.15)”). Version comparison operators are as follows:
  • <<: 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 a list of conditions to be met, the comma serves as a separator. It must be interpreted as a logical “and”. In conditions, the vertical bar (“|”) expresses a logical “or” (it is an inclusive “or”, not an exclusive “either/or”). Carrying greater priority than “and”, it can be used as many times as necessary. Thus, the dependency “(A or B) and C” is written A | B, C. In contrast, the expression “A or (B and C)” should be written as “(A or B) and (A or C)”, since the Depends field does not tolerate parentheses that change the order of priorities between the logical operators “or” and “and”. It would thus be written A | B, A | C.
The dependencies system is a good mechanism for guaranteeing the operation of a program, but it has another use with “meta-packages”. These are empty packages that only describe dependencies. They facilitate the installation of a consistent group of programs pre-selected by the meta-package maintainer; as such, apt install meta-package will automatically install all of these programs using the meta-package's dependencies. The gnome, kde-full and linux-image-amd64 packages are examples of meta-packages.

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 und Pfads 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 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 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 eines Pakets 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
The Provides field is also interesting when the content of a package is included in a larger package. For example, the libdigest-md5-perl Perl module was an optional module in Perl 5.6, and has been integrated as standard in Perl 5.8 (and later versions, such as 5.32.1 present in Bullseye). As such, the package perl has since version 5.8 declared Provides: libdigest-md5-perl so that the dependencies on this package are met if the user has Perl 5.8 (or newer). The libdigest-md5-perl package itself has eventually been deleted, since it no longer had any purpose when old Perl versions were removed.
Verwendung einer Provides-Zeile zur Vermeidung des Brechens von Abhängigkeiten

Abbildung 5.1. Verwendung einer Provides-Zeile zur Vermeidung des Brechens von Abhängigkeiten

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. Bisherige Einschränkungen
Virtual packages used to suffer from some limitations, the most significant of which was the absence of a version number. To return to the previous example, a dependency such as Depends: libdigest-md5-perl (>= 1.6), despite the presence of Perl 5.10, would have never been considered as satisfied by the packaging system — while in fact it most likely was satisfied. Unaware of this, the package system chose the least risky option, assuming that the versions do not match.
This limitation has been lifted in dpkg 1.17.11, and is no longer relevant. Packages, like perl 5.32.1, can assign a version to the virtual packages they provide, such as Provides: libdigest-md5-perl (= 2.55.01), and thus allow other packages to use versioned dependencies.

5.2.1.5. Dateien ersetzen: Die Replaces-Zeile

The Replaces field indicates that the package contains files that are also present in another package, but that the package is legitimately entitled to replace them. Without this specification, dpkg fails to install the package, stating that it cannot overwrite the files of another package (technically, it is possible to force it to do so with the --force-overwrite option, but that is not considered standard operation). This allows identification of potential problems and requires the maintainer to study the matter prior to choosing whether to add such a field.
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

In addition to the control file, the control.tar.gz archive for each Debian package may contain a number of scripts, called by dpkg at different stages in the processing of a package. The Debian Policy describes the possible cases in detail, specifying the scripts called and the arguments that they receive. These sequences may be complicated, since if one of the scripts fails, dpkg will try to return to a satisfactory state by canceling the installation or removal in progress (insofar as it is possible).
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

During the initial installation and for each upgrade of a package, dpkg calls the so called maintainer scripts such as the prerm or preinst scripts. These scripts can perform additional actions during the different stages of a package's life-cycle. Script names preceded by new- are the scripts from the new version of a package being installed or upgraded to. Script names preceded by old- are the scripts from the old version of a package that is being upgraded from.
During each invocation dpkg will pass certain arguments to each script such as upgrade new-version. The invoked script can then either handle the arguments and perform a particular action, or ignore the arguments and return with an exit code of 0, if nothing needs to be done during that step. In practice many packages will not need to perform an action during every step in the life cycle. Thus a typical configuration script will check for a particular argument and ignore all other ones, implicitly returning with exit code 0.
Here is what happens during an installation (or an update). The old-version, new-version and last-version-configured arguments are placeholders for the actual (old and new) version numbers of the package:
  1. For an update, dpkg calls the old-prerm script and passes upgrade new-version as arguments.
  2. Still for an update, dpkg then executes the new-preinst script with the arguments upgrade old-version; for the initial installation, it executes the new-preinst script and passes install as argument. It may add the old version in the last parameter, if the package has already been installed and removed since (but not purged, and thus configuration files have been retained).
  3. Die neuen Paketdateien werden dann entpackt. Falls eine Datei bereits vorhanden ist, wird sie ersetzt, wobei aber vorübergehend eine Sicherheitskopie erstellt wird.
  4. For an update, dpkg executes the old-postrm script and passes upgrade new-version as arguments.
  5. 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.
  6. dpkg aktualisiert dann die Konfigurationsdateien, wobei es den Nutzer auffordert, Entscheidungen zu treffen, falls es diese Aufgabe nicht selbsttätig erledigen kann. Die Einzelheiten dieses Vorgangs sind in Abschnitt 5.2.3, „Checksums, List of Configuration Files, et al.“ erläutert.
  7. Finally, dpkg configures the package by executing the new-postinst script with the arguments configure last-version-configured.

5.2.2.2. Paketentfernung

The steps to remove a package are analogous to the installation steps. The main difference is that the removal scripts of the package are called:
  1. dpkg calls the prerm script and passes the remove argument.
  2. dpkg removes all of the package's files, with the exception of the configuration files and maintainer scripts.
  3. dpkg executes the postrm script and passes remove as argument. Afterwards, all of the maintainer scripts, except the postrm script, are removed. If the user has not used the “purge” option, the process stops here.
  4. For a complete purge of the package (command issued with dpkg --purge or dpkg -P), the configuration files are also deleted, as well as a certain number of copies (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) and temporary files; dpkg then executes the postrm script and passes purge as argument.
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. Checksums, List of Configuration Files, et al.

In addition to the maintainer scripts and control data already mentioned in the previous sections, the control.tar.gz archive of a Debian package may contain other interesting files.
The first, md5sums, contains the MD5 checksums for all of the package's files. Its main advantage is that it allows dpkg --verify (which we will study in Abschnitt 14.3.4.1, „Pakete mit logcheck prüfen“) and debsums (from the package of the same name; see Abschnitt 14.3.4.2, „Pakete auditieren: debsums und seine Grenzen“) to check if these files have been modified since their installation. Note that when this file doesn't exist, which might be the case for some older packages, dpkg will generate it dynamically at installation time (and store it in the dpkg database just like other control files).
The file conffiles lists package files that must be handled as configuration files (see also deb-conffiles(5)). Configuration files can be modified by the administrator, and dpkg will try to preserve those changes during a package update.
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.
The control archive frequently contains other files as well, like triggers, shlibs, or symbols. These files are well described in deb-triggers(5), deb-shlibs(5), and deb-symbols(5).
Triggers were introduced to reduce the amount of duplicated events during package installation, such as file registration or catalog/database update tasks. Packages can define their own or activate defined triggers. A more comprehensive documentation can be found in /usr/share/doc/dpkg/triggers.txt.gz.
The shlibs system is an older and simpler alternative to the symbols system for declaring dependencies for shared libraries. It defines the package name and version in which to find a specific SONAME-version of a shared library. The newer symbols system allows to define the dependency by tracking the symbols and when they have been introduced or changed in the library instead.