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 (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, suppression, mise à jour). 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 à un en-tête de courriel (défini par la RFC 2822), qui ressemble pour l'exemple d'apt à :
$ apt-cache show apt
Package: apt
Version: 1.0.9.8.1
Installed-Size: 3789
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: amd64
Replaces: manpages-it (<< 2.80-4~), manpages-pl (<< 20060617-3~), openjdk-6-jdk (<< 6b24-1.11-0ubuntu1~), sun-java5-jdk (>> 0), sun-java6-jdk (>> 0)
Depends: libapt-pkg4.12 (>= 1.0.9.8.1), libc6 (>= 2.15), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.9), debian-archive-keyring, gnupg
Suggests: aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), apt-doc, python-apt
Conflicts: python-apt (<< 0.7.93.2~)
Breaks: manpages-it (<< 2.80-4~), manpages-pl (<< 20060617-3~), openjdk-6-jdk (<< 6b24-1.11-0ubuntu1~), sun-java5-jdk (>> 0), sun-java6-jdk (>> 0)
Description-fr: gestionnaire de paquets en ligne de commande
Ce paquet fournit des outils en ligne de commande pour la recherche, la
gestion ainsi que la demande d'informations à propos de paquets, le tout
grâce à un accès bas niveau aux fonctionnalités de la bibliothèque libapt-pkg.
.
Ces outils sont :
* apt-get pour la récupération de paquets et d'informations à leur sujet
depuis des sources authentifiées et pour l'installation, la mise à
niveau et la suppression de paquets ainsi que leurs dépendances ;
* apt-cache pour consulter les informations disponibles sur les paquets
installés et installables ;
* apt-cdrom pour utiliser des médias amovibles en tant que source de
paquets ;
* apt-config qui sert d'interface pour les réglages de configuration ;
* apt-key qui sert d'interface pour gérer les clés d'authentification.
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,
role::shared-lib, scope::application, scope::utility, sound::player,
suite::debian, use::downloading, use::organizing, use::searching,
works-with::audio, works-with::software:package, works-with::text
Section: admin
Priority: important
Filename: pool/main/a/apt/apt_1.0.9.8.1_amd64.deb
Size: 1109900
MD5sum: 52acb9bf9006c1b7fb8679f859c93fb1
SHA1: f55b5aed9385945e9097de625d200c1c7b98f4ca
SHA256: 16b5132418cfa8ed638bda0366dfb6f82007a9964002e979c73ddbd48b755cb8
5.2.1.1. Dépendances : champ Depends
Les dépendances sont définies dans le champ Depends des en-têtes du paquet. Il s'agit d'une liste de conditions à remplir pour que le paquet fonctionne correctement, informations utilisées par des outils comme apt pour installer les versions des bibliothèques dont dépend le programme à installer. Pour chaque dépendance, il est possible de restreindre l'espace des versions qui satisfont la condition. Autrement dit, il est possible d'exprimer le fait que l'on a besoin du paquet libc6 dans une version supérieure ou égale à « 2.15 » (cela s'écrit « libc6 (>= 2.15) »). Les opérateurs de comparaison de versions sont les suivants :
<< : 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 à.
Dans une liste de conditions à remplir, la virgule sert de séparateur. Sur le plan logique, son sens est celui d'un « et ». Au sein d'une condition, la barre verticale (« | ») exprime un « ou » logique (il s'agit d'un « ou » inclusif, non d'un « ou bien »). Prioritaire sur le « et », elle est utilisable autant de fois que nécessaire. Ainsi, la dépendance « (A ou B) et C » s'écrit
A | B, C. En revanche, l'expression « A ou (B et C) » doit être développée en « (A ou B) et (A ou C) » puisque le champ
Depends ne tolère pas de parenthèses changeant les priorités entre les opérateurs logiques « ou » et « et ». Elle s'écrira donc
A | B, A | C.
Le système de dépendances est un bon mécanisme pour garantir le fonctionnement d'un logiciel, mais il trouve un autre usage avec les « métapaquets ». Il s'agit de paquets vides, décrivant uniquement des dépendances. Ils facilitent l'installation d'un ensemble cohérent de logiciels présélectionnés par le mainteneur du métapaquet ; en effet, apt install métapaquet installera automatiquement l'ensemble de ces logiciels grâce aux dépendances du métapaquet. Les paquets gnome, kde et linux-image-amd64 sont des exemples de métapaquets.
5.2.1.2. Conflits : champ Conflicts
Le champ Conflicts permet d'indiquer qu'un paquet ne peut être installé en même temps qu'un autre. Les raisons les plus courantes sont les suivantes : les deux paquets incluent un fichier portant le même nom, fournissent le même service sur le même port TCP, ou gênent mutuellement leur bon fonctionnement.
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
Le champ Provides s'avère aussi intéressant lorsque le contenu d'un paquet est intégré dans un paquet plus vaste. Ainsi, le module Perl libdigest-md5-perl était un module facultatif en Perl 5.6, qui a été intégré en standard dans Perl 5.8 (et les versions suivantes, comme la version 5.14 présente dans Jessie). Le paquet perl déclare donc depuis sa version 5.8 Provides: libdigest-md5-perl afin que les dépendances sur ce paquet soient satisfaites si l'utilisateur dispose de Perl 5.8 ou plus récent. Le paquet libdigest-md5-perl lui-même a ainsi pu être supprimé, n'ayant plus de raison d'être.
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
Les paquets virtuels souffraient de quelques limitations, dont la plus importante était l'absence de numéro de version. Pour reprendre l'exemple précédent, une dépendance Depends: libdigest-md5-perl (>= 1.6) n'était donc jamais satisfaite, pour le système de paquetage, par la présence de Perl 5.10 — bien qu'en réalité elle l'était probablement. Ne le sachant pas, le système de paquetage optait pour une politique du moindre risque en supposant que les versions ne correspondaient pas.
Cette limitation a été levée avec dpkg 1.17.11, et n'existe plus dans Jessie. Les paquets peuvent assigner une version aux paquets virtuels qu'ils fournissent avec une dépendance telle que Provides: libdigest-md5-perl (= 1.8).
5.2.1.5. Remplacements : champ Replaces
Le champ Replaces indique que le paquet contient des fichiers également présents dans un autre paquet, mais qu'il a légitimement le droit de les remplacer. En l'absence de cette précision, dpkg échoue en précisant qu'il ne peut pas écraser les fichiers d'un autre paquet (en fait, il est possible de lui forcer la main avec l'option --force-overwrite, mais ce n'est pas considéré comme une opération standard). Cela permet d'identifier les problèmes potentiels et contraint le mainteneur à étudier la question avant de choisir d'ajouter ou non ce champ.
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).
D'une manière générale, le script preinst est exécuté préalablement à l'installation du paquet alors que le postinst la suit. De même, prerm est invoqué avant la suppression du paquet et postrm après. Une mise à jour d'un paquet équivaut à en supprimer la version précédente puis à installer la nouvelle. Il n'est pas possible de détailler ici tous les scénarios d'actions réussies, mais évoquons quand même les deux plus courants : une installation/mise à jour et une suppression.
5.2.2.1. Installation et mise à jour
Voici les étapes d'une installation (ou mise à jour) :
En cas de mise à jour, dpkg appelle la commande ancien-prerm upgrade nouvelle-version.
Pour une mise à jour toujours, dpkg exécute alors nouveau-preinst upgrade ancienne-version ; pour une première installation, il exécute nouveau-preinst install. Il peut ajouter l'ancienne version en dernier paramètre si le paquet avait déjà été installé et supprimé entre-temps (mais non purgé, les fichiers de configuration ayant alors été conservés).
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.
En cas de mise à jour, dpkg exécute ancien-postrm upgrade nouvelle-version.
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.
Enfin, dpkg configure le paquet en exécutant nouveau-postinst configure dernière-version-configurée.
5.2.2.2. Suppression de paquets
Voici les étapes pour une suppression de paquet:
dpkg appelle prerm remove.
dpkg supprime tous les fichiers du paquet, à l'exception des fichiers de configuration et des scripts de configuration.
dpkg exécute postrm remove. Tous les scripts de configuration, sauf le postrm, sont effacés. Si l'utilisateur n'a pas demandé la « purge » du paquet, les opérations s'arrêtent là.
En cas de purge complète du paquet (demandée avec dpkg --purge ou dpkg -P), les fichiers de configuration sont supprimés, ainsi qu'un certain nombre de copies (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) et de fichiers temporaires ; dpkg exécute ensuite postrm purge.
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
En plus des données de contrôle et des scripts de configuration déjà cités dans les sections précédentes, l'archive
control.tar.gz d'un paquet Debian en contient d'autres. Le premier,
md5sums, contient la liste des empreintes numériques de tous les fichiers du paquet. Son principal avantage est de permettre à
dpkg --verify (que nous étudierons dans la
Section 14.3.3.1, « Audit des paquets avec dpkg --verify ») de vérifier que ces fichiers n'ont pas été modifiés depuis leur installation. Vous pouvez noter que lorsque ce fichier n'existe pas,
dpkg le génère dynamiquement au moment de l'installation (et l'enregistre dans la base de données dpkg comme les autres fichiers de contrôle).
conffiles liste les fichiers du paquet qu'il faudra gérer comme des fichiers de configuration. Un fichier de configuration a cela de particulier qu'il peut être modifié par l'administrateur et que ses changements seront normalement conservés lors d'une mise à jour du paquet.
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).
