Product SiteDocumentation Site

5.2. Pakiet Informacji Meta

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

5.2.1. Opis pliku control File

Plik ten wykorzystuje strukturę podobną do nagłówków e-mail (jak zdefiniowano w dokumencie RFC 2822). Na przykład dla apt , control wygląda następująco:
$ 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. Zależności DependsPola

The dependencies are defined in the Depends field in the package header. This 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, in their appropriate versions, that the package to be installed depends on. 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.3.4” (written “libc6 (>= 2.3.4)”). Version comparison operators are as follows:
  • <<: mniejsza od
  • <=: mniejsza od bądź równa do
  • =: równa się (note that “2.6.1”nie równa się “2.6.1-1”);
  • >=: większa bądz równa do
  • >>: większa od
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 preselected by the meta-package maintainer; as such, apt-get 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. Konflikt Konflikt Pola

The Conflicts field indicates when a package cannot be installed simultaneously with another. The most common reasons for this are that both packages include a file of the same name, or provide the same service on the same TCP port, or would hinder each other's operation.
dpkg will refuse to install a package if it triggers a conflict with an already installed package, except if the new package specifies that it will “replace” the installed package, in which case dpkg will choose to replace the old package with the new one. apt-get always follows your instructions: if you choose to install a new package, it will automatically offer to uninstall the package that poses a problem.

5.2.1.3. Incompatibilities: the Breaks Field

The Breaks field has an effect similar to that of the Conflicts field, but with a special meaning. It signals that the installation of a package will “break” another package (or particular versions of it). In general, this incompatibility between two packages is transitory, and the Breaks relationship specifically refers to the incompatible versions.
dpkg will refuse to install a package that breaks an already installed package, and apt-get will try to resolve the problem by updating the package that would be broken to a newer version (which is assumed to be fixed and, thus, compatible again).
This type of situation may occur in the case of updates without backwards compatibility: this is the case if the new version no longer functions with the older version, and causes a malfunction in another program without making special provisions. The Breaks field prevents the user from running into these problems.

5.2.1.4. Provided Items: the Provides Field

This field introduces the very interesting concept of a “virtual package”. It has many roles, but two are of particular importance. The first role consists in using a virtual package to associate a generic service with it (the package “provides” the service). The second indicates that a package completely replaces another, and that for this purpose it can also satisfy the dependencies that the other would satisfy. It is thus possible to create a substitution package without having to use the same package name.
5.2.1.4.1. Providing a “Service”
Let us discuss the first case in greater detail with an example: all mail servers, such as postfix or sendmail are said to “provide” the mail-transport-agent virtual package. Thus, any package that needs this service to be functional (e.g. a mailing list manager, such as smartlist or sympa) simply states in its dependencies that it requires a mail-transport-agent instead of specifying a large yet incomplete list of possible solutions (e.g. postfix | sendmail | exim4 | …). Furthermore, it is useless to install two mail servers on the same machine, which is why each of these packages declares a conflict with the mail-transport-agent virtual package. The conflict with itself is ignored by the system, but this technique will prohibit the installation of two mail servers side by side.
5.2.1.4.2. Interchangeability with Another Package
The Provides field is again 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.14 present in Wheezy). 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.
Use of a Provides field in order to not break dependencies

Rysunek 5.1. Use of a Provides field in order to not break dependencies

This feature is very useful, since it is never possible to anticipate the vagaries of development, and it is necessary to be able to adjust to renaming, and other automatic replacement, of obsolete software.
5.2.1.4.3. Current Limitations
Virtual packages suffer from some limitations, the most significant of which being 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, will never be considered as satisfied by the packaging system — while in fact it most likely is satisfied. Unaware of this, the package system chooses the least risky option, assuming that the versions do not match.

5.2.1.5. Replacing Files: The Replaces Field

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, stating that it can not overwrite the files of another package (in fact, it is possible to force it to do so with the --force-overwrite option). This allows identification of potential problems and requires the maintainer to study the matter prior to choosing whether to add such a field.
The use of this field is justified when package names change or when a package is included in another. This also happens when the maintainer decides to distribute files differently among various binary packages produced from the same source package: a replaced file no longer belongs to the old package, but only to the new one.
If all of the files in an installed package have been replaced, the package is considered to be removed. Finally, this field also encourages dpkg to remove the replaced package where there is a conflict.

5.2.2. Configuration Scripts

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).
In general, the preinst script is executed prior to installation of the package, while the postinst follows it. Likewise, prerm is invoked before removal of a package and postrm afterwards. An update of a package is equivalent to removal of the previous version and installation of the new one. It is not possible to describe in detail all the possible scenarios here, but we will discuss the most common two: an installation/update and a removal.

5.2.2.1. Installation and Upgrade

Here is what happens during an installation (or an update):
  1. For an update, dpkg calls the old-prerm upgrade new-version.
  2. Still for an update, dpkg then executes new-preinst upgrade old-version; for a first installation, it executes new-preinst install. It may add the old version in the last parameter, if the package has already been installed and removed since (but not purged, the configuration files having been retained).
  3. The new package files are then unpacked. If a file already exists, it is replaced, but a backup copy is temporarily made.
  4. For an update, dpkg executes old-postrm upgrade new-version.
  5. dpkg updates all of the internal data (file list, configuration scripts, etc.) and removes the backups of the replaced files. This is the point of no return: dpkg no longer has access to all of the elements necessary to return to the previous state.
  6. dpkg will update the configuration files, asking the user to decide if it is unable to automatically manage this task. The details of this procedure are discussed in Sekcja 5.2.3, „Sumy kontrolne, lista plików konfiguracyjnych”.
  7. Finally, dpkg configures the package by executing new-postinst configure last-version-configured.

5.2.2.2. Usuwanie pakietów

O to co zachodzi podczas usuwania pakietów:
  1. dpkg wywołuje komendę prerm remove.
  2. dpkg usuwa wszystkie pliki pakietów, z wyjątkiem plików konfiguracyjnych i skryptów konfiguracyjnych.
  3. dpkg uruchamia komendę postrm remove. Wszystkie skrypty konfiguracyjne, poza postrm, zostały usunięte. Jeśli użytkownik nie użył opcji "purge", proces dobiega końca.
  4. Dla całkowitego skasowania pakietów (Wydanie polecenia dpkg --purge albo dpkg -P), w tym usunięciu również plików konfiguracyjnych, wraz z ustaloną liczbą ich kopii (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) i plików tymczasowych; dpkg następnie wykonaj postrm purge.
The four scripts detailed above are complemented by a config script, provided by packages using debconf to acquire information from the user for configuration. During installation, this script defines in detail the questions asked by debconf. The responses are recorded in the debconf database for future reference. The script is generally executed by apt prior to installing packages one by one in order to group all the questions and ask them all to the user at the beginning of the process. The pre- and post-installation scripts can then use this information to operate according to the user's wishes.

5.2.3. Sumy kontrolne, lista plików konfiguracyjnych

Oprócz zarządcy skryptów i kontroli danych wspomnianych już w poprzednich sekcjach, control.tar.gz archiwum pakietów Debiana może zawierać inne interesujące pliki. Pierwszy , md5sums, zawiera MD5 sumy kontrolne dla wszystkich plików pakietu. Główną zaletą jest to, że umożliwia to narzędziom takim jak debsums (które będziemy badać w Sekcja 14.3.3.1, „Auditing Packages: debsums and its Limits”) sprawdzenie czy te pliki były modyfikowane od czasu ich instalacji. Zauważ, że kiedy ten plik nie istnieje, dpkg dynamicznie go wygeneruje podczas instalacji (i zostanie zachowany w bazie danych dpkg tak jak inne pliki kontrolne).
conffiles zestawienia plików pakietowych, które muszą być obsługiwane jako pliki konfiguracyjne. Pliki konfiguracyjne mogą być modyfikowane przez administratora i dpkg spróbuje przechować zmiany podczas aktualizacji pakietów.
W istocie, w tej sytuacji dpkg zachowuje się na tyle inteligentnie na ile to jest możliwe; Jeśli standardowy plik konfiguracyjny nie został zmieniony pomiędzy dwoma wersjami, nie podejmuje żadnych działań. Jeśli jednak plik był modyfikowany spróbuje wtedy go uaktualnić. Są możliwe dwa przypadki: Albo administrator nie modyfikował tego pliku konfiguracyjnego, w takim razie dpkg automatycznie instaluje nową wersję; albo plik był zmieniany i w takim razie dpkg pyta administratora, którą wersję chciałby użyć (starą wersję ze zmianami albo nową dostarczoną wraz z pakietem). Dla ułatwienia podjęcia tej decyzji dpkg oferuje wyświetlenie “diff” który pokazuje różnice pomiędzy dwiema wersjami. Jeśli użytkownik postanowi zachować starą wersję, nowa wersja będzie przechowywana w tej samej lokalizacji, w pliku z rozszerzeniem .dpkg-dist. Jeśli użytkownik wybierze nową wersję, stara wersja będzie przechowywana w pliku o rozszerzeniu .dpkg-old. Inna dostępna akcja polega na chwilowym przerwaniu dpkg w celu edycji pliku i próby przeinstalowania odpowiednich modyfikacji (poprzednio zidentyfikowanych z pomocą diff).