Les paquets peuvent déclarer dans leur fichier de contrôle qu'ils ont certaines relations avec d'autres paquets - par exemple, qu'ils ne peuvent pas être installés en même temps que certains autres paquets, et/ou qu'ils dépendent de la présence d'autres, ou qu'ils doivent écraser les fichiers dans certains autres paquets s'ils sont présents.
Ceci est effectué en utilisant les champs du fichier de contrôle Depends, Recommends, Sugggests, Conflicts, Provides et Replaces.
Ces champs ont tous la même syntaxe uniforme. Ce sont des listes de noms de paquets séparées par des virgules.
Dans Depends, Recommends, Suggests et Pre-Depends (les champs qui déclarent les dépendances du paquets dans lesquelles elles apparaissent dans d'autres paquets), ces noms de paquet peuvent aussi être des listes de noms de paquets alternatifs, séparés par des symboles barre verticale | (symbole du tube de communication).
Tous les champs sauf Provides peuvent restreindre leur application à des versions particulières de chaque paquet nommé. C'est indiqué entre parenthèses après chaque nom individuel de paquet; les parenthèses devraient contenir une relation de la liste ci-dessous suivie par un numéro de version, dans le format décrit dans Numérotation des versions, Chapter 5.
Les relations autorisées sont <<, <=, = >= et >> pour strictement avant, avant ou égal, égal, après ou égal, strictement après, respectivement. Les formes < et > ont été utilisées pour signifier avant/après ou égal, plutôt que strictement avant/après, ainsi ils ne doivent pas apparaître dans les nouveaux paquets (bien que dpkg les supporte toujours).
Les espaces peuvent apparaître n'importe où dans la spécification de version, et doivent apparaître où cela est nécessaire pour désambiguïser; autrement ils ne sont pas significatifs. Pour l'uniformité et dans le cas de futurs changements à dpkg, il est recommandé qu'un seule espace soit utilisé après une relation de version et avant un numéro de version; il est aussi convenu de mettre un espace après chaque virgule, de chaque côté d'une barre verticale, et avant chaque parenthèse ouvrante.
Par exemple:
Package: metamail Version: 2.7-3 Depends: libc5 (>= 5.2.18-4), mime-support, csh | tcsh
Ces quatre champs sont utilisés pour déclarer une dépendance d'un paquet sur un autre. Ils apparaissent dans le fichier de contrôle dépendant du paquet.
Tous, sauf Pre-Depends (voir ci-dessous) prennent effet seulement quand un paquet est configuré. Ils n'empêchent pas un paquet d'être sur le système dans un état non configuré alors que ses dépendances sont non satisfaites, et il est possible de remplacer un paquet dont les dépendances sont satisfaites et qui est proprement installé par une version différente dont les dépendances ne sont pas et ne peuvent pas être satisfaites; quand c'est le cas, le paquet dépendant sera laissé non configuré (étant donnée que les tentatives pour le configurer, donneront des erreurs) et ne fonctionnera pas correctement.
Pour cette raison, les paquets dans une installation sont généralement tous installés d'abord et tous configurés ensuite; ceci donne les dernières versions des paquets avec les dépendances sur les dernières versions des autres paquets, l'opportunité d'avoir leurs dépendances satisfaites.
Ainsi Depends autorise les mainteneurs de paquets d'imposer un ordre sur la configuration des paquets.
dpkg
ne configurera pas les paquets dont les dépendances ne sont
pas satisfaites. S'il est demandé de faire une installation qui ne satisfait
pas les dépendances d'un paquet installé, il produira une erreur[22], à moins que
--auto-deconfigure ne soit spécifié, dans quel cas, ces paquets
seront déconfigurés avant la procédure d'installation.
dselect rend difficile pour l'utilisateur la sélection des paquets pour l'installation, l'effacement ou la mise à jour de façon à ce que les champs Depends des paquets soient insatisfaits. L'utilisateur peut écraser cela s'il veut, par exemple s'ils savent que dselect a une vue périmée des relations réelles des paquets.
Le champ Depends devrait être utilisé si le paquet d'appui est nécessaire pour le paquet dépendant pour fournir une quantité significative de fonctionnalités.
Recommends est ignoré par dpkg, afin que les utilisateurs utilisant la ligne de commande (en supposant savoir ce qu'ils font) ne soient pas gênés.
Il est traité par dselect exactement comme Depends; ce qui rend difficile pour l'utilisateur de sélectionner les choses de façon à laisser les champs Recommends non satisfaits, mais ils sont capable de le faire en étant persistent.
Le champ Recommends devrait lister les paquets qui devraient être liés entre eux à celui-ci pour tout sauf les installations inhabituelles.
dselect offrira les paquets suggérés à l'administrateur du système quand ils sélectionnent les paquets suggérés, mais par défaut, il n'installe pas les paquets suggérés.
dselect vérifie les pré-dépendances quand il fait une installation, et essayer de trouver les paquets qui sont nécessairement installés avant et le fait dans le bon ordre.
Cependant, ce processus est lent (car il nécessite des appels répétés à dpkg) et pénible (car il nécessite de deviner où se trouvent les fichiers appropriés).
Pour ces raisons, et car ce champ impose des restrictions sur l'ordre dans lequel les paquets doivent être installés (ce qui peut-être difficile pour des installation à partir de média différent, par exemple). Pre-Depends devrait être utilisé avec modération, de préférence seulement pour les paquets dont la mise à jour prématuré ou l'installation pourrait entraver la capacité du système de continuer les mises à jour en cours.
Quand le paquet déclarant qu'il a été configuré, une Pre- Dependency sera considérée satisfaite seulement si le paquet dépendant a bien été configuré, juste comme ci une Depends ordinaire avait été utilisé.
Cependant, quand un paquet déclarant un pré-dépendance est installé, la pré-dépendance peut être satisfaite même si le ou les paquets d'appui sont seulement installés ou à moitié configurés, indiquant qu'ils ont été correctement installés à un moment dans la passé (et pas effacés ou partiellement effacés depuis). Dans ce cas, les deux versions précédemment configurées et en cours d'installation ou à moitié configurées doivent satisfaire n'importe quelle clause de version du champ Pre-Depends.
Quand on sélectionne le niveau de dépendance à utiliser, tu dois considéré l'impact des fonctionnalité du paquet d'appui sur le paquet déclarant la dépendance. Certains paquets sont constitués de composants de différents niveaux d'importance. De tel paquet devrait lister en utilisant Depends, le ou les paquets qui sont nécessaires par les composants les plus importants. Les autres composants exigés peuvent être mentionnés comme Suggestions ou Recommendations, en fonction de l'importance du composant.
Les champs de dépendance listés ci-dessus sont utilisés par les paquets qui ont besoin de librairies partagées pour déclarer les dépendances sur les paquets appropriés.
Ces dépendances sont généralement déterminées automatiquement en utilisant dpkg-shlibdeps et insérées dans le fichier de contrôle du paquet en utilisant le mécanisme de substitutions de variables du fichier de contrôle; voir debian/substvars et substitutions de variables, Section 3.2.3 et Les outils pour manipuler les paquets sources, Section 3.1.
Si dpkg veux effacer un paquet à cause d'un conflit, comme décrit ci-dessus, mais en violation avec une dépendance de certains autres paquets sur le système, dpkg n'effacera généralement pas le paquet en conflit et s'arrêtera sur une erreur.
Cependant, si l'option --auto-deconfigure (-B) est utilisée, dpkg déconfigurera automatiquement le paquet avec la dépendance problématique, afin que le paquet en conflit puisse être enlevé et le paquet à installer puisse être installé. Si dpkg est appelé pour installer des paquets (plutôt que juste les dépaqueter), il essayera de reconfigurer le paquet quand il aura dépaqueté tous ces arguments, dans l'espoir qu'un des autres paquets qu'il installe, satisfera la dépendance problématique.
dselect fournit ces arguments à dpkg quand il l'appelle, afin de procéder aux installations facilement.
Quand un paquet déclare un conflit avec un autre, dpkg refusera de les installer sur le système en même temps.
Si un paquet est installé, les autres doivent être enlevé d'abord - si le paquet en cours d'installation est marqué comme remplacement (voir Replaces - écraser les fichiers et remplacer les paquets, Section 8.5) du paquet sur le système, ou si celui du système est marqué comme désélectionner, ou les deux paquets sont marqués Essential, alors dpkg enlèvera automatiquement le paquet qui provoque le conflit, autrement il arrête l'installation des nouveaux paquets par une erreur.
dselect rend difficile la sélection des paquets en conflit, bien que l'utilisateur puisse l'annuler s'il le veut. S'ils ne sont pas annulés alors dselect sélectionnera un des paquets pour l'effacer, et l'utilisateur doit être sûr que c'est le bon. Dans le futur, dselect vérifiera la présence d'un champ Replaces pour décider quel paquet doit être installé et lequel enlevé.
Un paquet ne provoquera pas de conflit, simplement car ses fichiers de configuration sont toujours installés; il doit être au moins à moitié installé.
Une exception spéciale est faite pour les paquets qui déclare un conflit avec leur propre nom de paquet, ou avec un paquet virtuel qu'ils fournissent (voir ci-dessous); cela n'empêche pas leurs installations, et autorise un paquet d'être en conflit avec d'autres fournissant un remplacement pour lui. Tu peux utiliser ce dispositif quand tu veux que le paquet en question soit le seul paquet fournissant quelque chose.
Une entrée Conflicts ne devrait presque jamais avoir une clause de version 'avant'. Ceci devait empêcher dpkg de mettre à jour ou d'installer le paquet qui déclare un tel conflit jusqu'à ce que la mise à jour ou l'effacement du paquet en conflit soient résolus. Cet aspect de l'ordre d'installation n'est pas géré par dselect, afin que l'utilisation de Conflicts provoque des problèmes pour les mises à jour et les installations.
Aussi bien que les noms de paquets concrets (réels), les champs de relations de paquet Depends, Recommends, Suggests et Conflicts peuvent mentionner des paquets virtuels.
Un paquet virtuel est un paquet qui apparaît dans le champ Provides du fichier de contrôle d'un autre paquet. L'effet est comme ci le ou les paquets qui fournissent un nom particulier de paquet virtuel avaient été listés par nom partout le nom du paquet virtuel apparaît.
Si il y a deux paquets, un réel et un virtuel du même nom alors la dépendance peut être satisfaite (or le conflit provoqué par) soit par le paquet réel ou n'importe quels paquets virtuels que la fournit. Par exemple, nous avons:
Package: vm Depends: emacs
Et quelqu'un d'autre met à jour un paquet xemacs, ils peuvent dire:
Package: xemacs Provides: emacs
Et tout fonctionnera entre temps (jusqu'à ce qu'un nom de paquet purement virtuel est décidé et les paquets emacs et vm soient modifiés pour l'utiliser).
Si une dépendance ou un conflit a un numéro de version attaché alors seuls les paquets réels seront considérés pour voir si la relation est satisfaite (ou la prohibition violée, pour un conflit) - on supposera qu'un paquet réel qui fournit un paquet virtuel n'est pas la bonne version. Ainsi, un champ Provides ne doit pas contenir de numéros de version, et le numéro de version d'un paquet concret qui fournit un paquet virtuel particulier ne le regardera pas quand on considère une dépendance ou un conflit avec le nom du paquet virtuel.
Si tu veux spécifier quel paquet d'un ensemble de paquets réels devrait être celui satisfait par défaut une dépendance particulière sur un paquet virtuel, tu devrais lister le paquet réel comme alternatif avant le paquet virtuel.
Le champ Replaces du fichier de contrôle a deux buts qui entre en jeu dans des situations différentes.
Les paquets virtuels (voir Les paquets virtuels - Provides, Section 8.4) ne sont pas considérés quand on regarde le champ Replaces - les paquets déclarés comme étant remplacés doivent être mentionnés par leurs noms réels.
Tout d'abord, comme mentionné avant, c'est généralement une erreur pour un paquet de contenir des fichiers qui sont sur le système dans un autre paquet, bien que couramment l'option --force-overwrite soit mise par défaut, déclassant l'erreur en avertissement.
Si le paquet qui écrase déclare qu'il remplace l'ancien contenant le fichier qui doit être écrasé alors dpkg le traitera, et remplacera le fichier de l'ancien paquet par le nouveau. Le fichier ne sera plus listé comme faisant partie de l'ancien paquet.
Si un paquet est complètement remplacé de cette façon, afin que dpkg ne sait pas quels fichiers il contient, il est considéré comme ayant disparu. Il sera marqué comme non sélectionné sur le système (sélectionné pour l'effacement) et non installé. tous les détails des conffiles notés dans le paquet seront ignorés, comme ils seront pris par le paquet qui le remplace. Le script postrm du paquet sera exécuté pour permettre au paquet de faire le nettoyage final nécessaire. Voir Résumé des façons dont les scripts de maintenance sont appelés, Section 6.2.
Dans le futur, dpkg écartera les fichiers qui écrasent ceux d'un autre paquet qui déclare qu'il remplace celui qui est en cours d'installation (afin de pouvoir installer une version plus ancienne d'un paquet sans problèmes).
L'usage de Replaces prend seulement effet quand deux paquets sont au moins partiellement sur le système à la fois, cela peut seulement se produire s'ils ne sont pas en conflits, ou si le conflit a été annulé.
Deuxièmement, Replaces permet à dpkg et dselect de résoudre quel paquet doit être enlevé quand il y a un conflit - voir Les paquets alternatifs - Conflicts et Replaces, Section 8.3. Cet usage prend seulement effet quand deux paquets sont en conflit, afin que les deux effets n'interfèrent pas l'un avec l'autre.
Le tri est significatif dans les champs de dépendance.
Généralement, dselect suggérera à l'utilisateur qu'ils sélectionnent le paquet avec la classe la plus 'fondamental' (il préférera les paquets de Base plutôt que les paquets optionnels), ou le paquet qu'ils veulent le plus sélectionner, dans un certain sens.
En l'absence d'autres informations, dselect offrira une sélection par défaut des premiers paquets nommés de la liste des alternatives.
Cependant, il n'y a aucun moyen de spécifier l'ordre de plusieurs paquets qui fournissent tous la même chose quand cette chose est listée comme dépendance.
Donc, une dépendance sur un paquet virtuel devrait contenir un nom de paquet concret comme première alternative par défaut.
Par exemple, considérons l'ensemble de paquets suivant:
Package: glibcdoc Recommends: info-browser Package: info Provides: info-browser Package emacs Provides: info-browser
Si emacs et info ont tous les deux la même priorité alors le choix dselect est essentiellement aléatoire. Le mieux serait:
Package: glibcdoc Recommends: info | info-browser
afin que dselect sélectionne l'info-browser.
Le manuel de programmation de dpkg
15 avril 2002cure@cnam.fr
jacolot@ubolib.univ-brest.fr