Le paquet Debian n'est pas qu'une archive de fichiers destinés à l'installation. Il s'inscrit dans un ensemble plus vaste en décrivant des relations avec les autres paquets Debian (prérequis, dépendances, conflits, suggestions). Il fournit également des scripts permettant d'exécuter des commandes lors des différentes étapes du parcours du paquet (installation, mise à jour, suppression). Ces données sont utilisées par les outils de gestion des paquets mais ne font pas partie du logiciel empaqueté ; elles constituent, au sein du paquet, ce que l'on appelle ses « méta-informations » – informations portant sur les informations.
5.2.1. Description : fichier control
Ce fichier utilise une structure similaire à celle des en-têtes de courrier électronique (telle que définie par
RFC 2822) et est entièrement décrit dans la charte Debian et les pages de manuel
deb-control(5) et
deb822(5).
For example, for apt, the control file looks like the following:
$ apt-cache show apt
Package: apt
Architecture: amd64
Version: 2.6.1
Priority: required
Section: admin
Maintainer: APT Development Team <deity@lists.debian.org>
Installed-Size: 4232
Provides: apt-transport-https (= 2.6.1)
Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.6.1), debian-archive-keyring, libc6 (>= 2.34), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.5), libseccomp2 (>= 2.4.2), libstdc++6 (>= 11), 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)
Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~)
Filename: pool/main/a/apt/apt_2.6.1_amd64.deb
Size: 1372852
MD5sum: 2a077296b9b9f4f8b027f86d9500192b
SHA256: 6ea03cbbc7a7bfcee601c9fb08d4e026fd522ede5350561f06867ad9c0a0fa6b
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
Examinons de plus près l'utilité de certains des champs listés par la commande précédente.
5.2.1.1. Dépendances : champ Depends
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:
<< : strictement inférieur à ;
<= : inférieur ou égal à ;
= : égal à (attention, « 2.6.1 » n'est pas égal à « 2.6.1-1 ») ;
>= : supérieur ou égal à ;
>> : strictement supérieur à.
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. Conflits : champ Conflicts
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 and path, or provide the same service on the same TCP port, or would hinder each other's operation.
dpkg refusera d'installer un paquet s'il déclenche un conflit avec un autre paquet déjà présent, sauf si le nouveau paquet précise qu'il « remplace » le paquet installé — auquel cas dpkg choisira de remplacer l'ancien par le nouveau. apt suit toujours vos instructions : si vous choisissez d'installer le nouveau paquet, il proposera automatiquement de désinstaller celui qui pose problème.
5.2.1.3. Incompatibilités : champ Breaks
Le champ Breaks a un effet similaire à celui de Conflicts, mais une signification particulière. Il signale en effet que l'installation du paquet « casse » un autre paquet (ou certaines versions particulières de ce dernier). En général, cette incompatibilité entre les deux paquets est transitoire et la relation Breaks désigne spécifiquement les versions incompatibles entre elles.
dpkg refusera d'installer un paquet qui casse un paquet déjà installé et apt essaiera de résoudre le problème en mettant à jour le paquet qui serait cassé par une version plus récente (que l'on suppose corrigée pour être à nouveau compatible).
Ce genre de situation peut se rencontrer dans le cas de mises à jour sans compatibilité ascendante : c'est le cas si la nouvelle version ne fonctionne plus comme l'ancienne et entraîne un dysfonctionnement d'un autre logiciel en l'absence de dispositions particulières. Le champ Breaks évite que l'utilisateur soit confronté à ces problèmes.
5.2.1.4. Éléments fournis : champ Provides
Ce champ introduit le concept très intéressant de « paquet virtuel ». Il a de nombreux rôles, mais on en distingue deux principaux. Le premier consiste à utiliser un paquet virtuel pour lui associer un service générique (le paquet « fournit » le service). Le second indique qu'un paquet en remplace complètement un autre et qu'à ce titre il peut également satisfaire les dépendances déclarées sur celui-ci. Il est ainsi possible de créer un paquet de substitution sans avoir de contrainte sur son nom.
5.2.1.4.1. La fourniture d'un « service »
Détaillons le premier cas par un exemple : tous les serveurs de courrier électronique tels que postfix ou sendmail déclarent « fournir » le paquet virtuel mail-transport-agent. Ainsi, tout paquet qui a besoin de ce service pour fonctionner (ce peut être un gestionnaire de listes de diffusion, comme smartlist ou sympa) se contentera de déclarer dans ses dépendances mail-transport-agent au lieu d'y préciser une grande liste de choix toujours incomplète (postfix | sendmail | exim4 | ...). Par ailleurs, il ne sert à rien d'installer deux serveurs de courrier électronique ; c'est pourquoi chacun de ces paquets déclare un conflit avec le paquet virtuel mail-transport-agent. Un conflit d'un paquet avec lui-même est ignoré par le système, mais cette technique interdira d'installer de concert deux serveurs de courrier électronique.
5.2.1.4.2. L'interchangeabilité avec un autre paquet
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.36.0 present in Bookworm). 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.
Cette fonctionnalité est très utile puisqu'il n'est jamais possible d'anticiper les aléas du développement et qu'il faut être capable de s'ajuster aux renommages et autres remplacements automatiques de logiciels obsolètes.
5.2.1.4.3. Anciennes limitations
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.36.0, can assign a version to the virtual packages they provide, such as Provides: libdigest-md5-perl (= 2.58), and thus allow other packages to use versioned dependencies.
5.2.1.5. Remplacements : champ Replaces
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.
L'emploi de ce champ se justifie dans le cas de changements de noms de paquets ou lorsqu'un paquet est intégré dans un autre. Cela se produit également quand le mainteneur a décidé de répartir différemment les fichiers entre divers paquets binaires produits depuis le même paquet source : un fichier remplacé n'appartient plus à l'ancien paquet, mais uniquement au nouveau.
Si tous les fichiers d'un paquet installé ont été remplacés, il est considéré comme supprimé. Enfin, ce champ incite aussi dpkg à supprimer le paquet remplacé en cas de conflit.
5.2.2. Scripts de configuration
En plus du fichier
control, l'archive
control.tar.gz de chaque paquet Debian peut contenir un certain nombre de scripts, appelés par
dpkg à différentes étapes du traitement d'un paquet. La charte Debian détaille longuement les cas possibles en précisant les scripts appelés et les arguments qu'ils reçoivent. Ces séquences peuvent être compliquées puisque si l'un des scripts échoue,
dpkg essaiera de revenir dans un état satisfaisant en annulant l'installation ou la suppression en cours (tant que cela est possible).
In general, the preinst script is executed prior to installation of the package, while 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 et mise à jour
Lors de l'installation initiale et pour chaque mise à niveau d'un paquet, dpkg appelle les scripts dits scripts du responsable (mainteneur) tels que les scripts prerm ou preinst. Ces scripts peuvent effectuer des actions supplémentaires pendant les différentes étapes du cycle de vie d'un paquet. Les noms de script précédés de new- sont les scripts de la nouvelle version d'un paquet étant installé ou mis à jour. Les noms de script précédés de old- sont les scripts de l'ancienne version d'un paquet qui est mis à niveau.
Lors de chaque invocation dpkg passera certains arguments à chaque script comme upgrade new-version. Le script invoqué peut alors gérer les arguments et effectuer une action particulière, ou ignorer les arguments et renvoyer avec un code de sortie de 0, si rien n'a besoin d'être fait pendant cette étape. Dans la pratique, de nombreux paquets n'auront pas besoin de faire quelque chose à chaque étape du cycle de vie. Ainsi, un script de configuration typique vérifiera un argument particulier et ignorera tous les autres, renvoyant implicitement avec code de sortie 0.
Voici ce qui se passe lors d'une installation (ou d'une mise à jour). Les arguments old-version, new-version et last-configured sont des substituts pour les numéros de version réels (ancien et nouveau) du paquet :
For an update, dpkg calls the old-prerm script and passes upgrade new-version as arguments.
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).
Les fichiers du nouveau paquet sont décompactés. Si un fichier existait au préalable, il est remplacé mais une copie de sauvegarde est temporairement réalisée.
For an update, dpkg executes the old-postrm script and passes upgrade new-version as arguments.
dpkg met à jour toutes ses données internes (liste de fichiers, scripts de configuration) et supprime les copies de sauvegarde des fichiers remplacés. C'est un point de non-retour : dpkg ne dispose plus désormais de tous les éléments nécessaires pour revenir à l'état antérieur.
Finally, dpkg configures the package by executing the new-postinst script with the arguments configure last-version-configured.
5.2.2.2. Suppression de paquets
Les étapes pour supprimer un paquet sont analogues aux étapes d'installation. La principale différence est que les scripts de suppression du paquet sont appelés :
dpkg calls the prerm script and passes the remove argument.
dpkg removes all of the package's files, with the exception of the configuration files and maintainer scripts.
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.
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.
Les quatre scripts évoqués précédemment sont complétés par un script config, fourni par les paquets utilisant debconf pour obtenir de l'utilisateur des informations de configuration. Lors de l'installation, ce script définit en détail les questions posées par debconf. Les réponses sont enregistrées dans la base de données de debconf pour référence ultérieure. Le script est généralement exécuté par apt avant d'installer un à un tous les paquets afin de regrouper en début de processus toutes les questions posées à l'utilisateur. Les scripts de pré- et post-installation pourront ensuite exploiter ces informations pour effectuer un traitement conforme aux vœux de l'utilisateur.
5.2.3. Sommes de contrôle, liste des fichiers de configuration, et al.
En plus des scripts du mainteneur et des données de contrôle déjà mentionnées dans les sections précédentes, l'archive control.tar.gz d'un paquet Debian peut contenir d'autres fichiers intéressants.
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.
En effet, dans une telle situation, dpkg se comporte aussi intelligemment que possible : si le fichier de configuration standard n'a pas évolué entre les deux versions, il ne fait rien. Sinon, il va essayer de le mettre à jour. Deux cas sont possibles : soit l'administrateur n'a pas touché à ce fichier de configuration, auquel cas dpkg installe automatiquement la nouvelle version disponible, soit le fichier a été modifié, auquel cas dpkg demande à l'administrateur quelle version il souhaite utiliser (l'ancienne avec les modifications, ou la nouvelle fournie par le paquet). Pour l'aider à prendre sa décision, dpkg lui propose de consulter un « diff » présentant les différences entre les deux versions. S'il choisit de conserver l'ancienne version, la nouvelle sera stockée au même emplacement dans un fichier suffixé de .dpkg-dist. S'il choisit la nouvelle version, l'ancienne sera conservée dans un fichier .dpkg-old. La dernière possibilité offerte consiste à interrompre momentanément dpkg pour éditer le fichier et tenter d'y reprendre les modifications pertinentes (préalablement identifiées grâce au diff).
L'archive de contrôle contient souvent d'autres fichiers, comme triggers, shlibs ou symbols. Ces fichiers sont bien décrits dans deb-triggers(5), deb-shlibs(5) et 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.
Le système shlibs est une alternative plus ancienne et plus simple au système symbols pour déclarer les dépendances pour les bibliothèques partagées. Il définit le nom de paquet et la version dans laquelle trouver une version SONAME spécifique d'une bibliothèque partagée. Le nouveau système symbols permet de définir la dépendance par le suivi des symboles et du moment de leur modification ou introduction dans la bibliothèque.
