[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ suivant ]
Ces champs ont tous la même syntaxe. Ce sont des listes de noms de paquets séparés par des virgules.
Dans les champs Depends, Recommends, Suggests, Pre-Depends, Build-Depends et Build-Depends-Indep (les champs qui déclarent les dépendances d'un paquet envers d'autres paquets), ces noms peuvent aussi être des listes de noms de paquets alternatifs, séparés par des symboles barre verticale « | » (symbole du tube de communication). Si c'est le cas, quand l'un des paquets alternatifs est installé, on considère que cette partie de la dépendance est satisfaite.
Tous les champs sauf le champ Provides peuvent restreindre leur application à des versions particulières de chaque paquet nommé. Ces versions sont indiquées entre parenthèses après chaque nom de paquet ; les parenthèses contiendront une des relations de la liste ci-dessous, suivie par un numéro de version, dans le format décrit dans Version, Section 5.6.12.
Les relations autorisées sont : <<, <=,
=, >= et >> pour strictement
avant, avant ou égal, égal, après ou égal, strictement après, respectivement.
Les formes déconseillées < et > ont été
utilisées pour signifier avant/après ou égal, plutôt que strictement
avant/après, ainsi elles ne doivent pas apparaître dans les nouveaux paquets
(bien que dpkg
les accepte encore).
Les espaces peuvent apparaître n'importe où dans la spécification de version
sujette aux règles énoncées dans La syntaxe des fichiers de
contrôle, Section 5.1, et doivent apparaître là où c'est nécessaire pour
supprimer toute ambiguïté ; autrement elles ne sont pas significatives. Pour
la cohérence et dans le cas de futures modifications de dpkg
, il
est recommandé de mettre une seule espace après une relation de version et
avant un numéro de version ; il est aussi convenu de mettre une espace après
chaque virgule, de chaque côté d'une barre verticale, et avant chaque
parenthèse ouvrante.
Par exemple, une liste de dépendances peut apparaître ainsi :
Package: mutt Version: 1.3.17-1 Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
On peut limiter à un ensemble d'architectures tous les champs qui précisent des relations pour la compilation (Build-Depends, Build-Depends-Indep, Build-Conflicts et Build-Conflicts-Indep). On se sert de crochets après chaque nom de paquet et l'indication facultative de la version. Les crochets enferment une liste d'architectures acceptées par Debian, séparées par une espace. Un point d'exclamation peut être ajouté à chaque nom. On ne peut pas ajouter un point d'exclamation à certains noms et pas à d'autres. Quand l'architecture de la machine hôte n'est pas présente dans la liste et qu'il n'y a pas de point d'exclamation, ou bien quand elle est dans la liste et qu'elle est préfixée par un point d'exclamation, le paquet et l'indication de la version associée sont complètement ignorés pour ce qui concerne la définition du système de relation.
Par exemple :
Source: glibc Build-Depends-Indep: texinfo Build-Depends: kernel-headers-2.2.10 [!hurd-i386], hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
Il faut remarquer que les champs concernant les relations entre paquets binaires tel que Depends apparaissent dans l'une des sections du fichier de contrôle du paquet binaire, alors que les champs concernant les relations pour la construction tel que Build-Depends apparaissent dans la première section du fichier de contrôle du paquet source.
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 tel paquet, ou qu'ils dépendent de la présence de tel autre.
On se sert pour cela des champs du fichier control suivants : Depends, Pre-Depends, Recommends, Suggests, Enhances et Conflicts.
Ces six champs sont utilisés pour déclarer une relation de dépendance d'un paquet envers un autre paquet. Ils apparaissent dans le fichier control du paquet dépendant (binaire), sauf le champ Enhances qui apparaît dans le fichier de contrôle du paquet recommandé.
Un champ Depends prend effet seulement lors de la
configuration du paquet. Il n'empêche pas qu'un paquet soit sur le système
dans un état « non configuré » et ses dépendances non
satisfaites ; il est aussi possible de remplacer un paquet correctement
installé et dont les dépendances sont satisfaites 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 est laissé « non configuré »
(étant donné que les tentatives pour le configurer donnent des erreurs) et il
ne fonctionne pas correctement. On peut utiliser si nécessaire un champ
Pre-Depends qui a un effet limité même si le paquet est dans la
phase de dépaquetage, comme c'est expliqué plus bas. (Les trois autres champs,
Recommends, Suggests et Enhances, ne
sont utilisés que par les différentes interfaces de dpkg
, telle
que dselect
.)
Pour cette raison, lors d'une installation, les paquets sont généralement tous installés d'abord et tous configurés ensuite ; cela permet que les dernières versions des paquets ayant des dépendances sur les dernières versions d'autres paquets voient leurs dépendances satisfaites.
Dans le cas de dépendances circulaires, comme l'ordre d'installation ou de suppression pour honorer l'ordre des dépendances ne peut être établi, les boucles de dépendances sont cassées à un certain point (basé sur les règles ci-dessous) et certains paquets peuvent ne pas pouvoir être certain que leurs dépendances soient présentes lors de l'installation ou de la suppression selon de quel côté de la cassure de la boucle de dépendance circulaire ils sont placés. Si l'un des paquets dans la boucle n'a pas de script postinst, alors le cycle peut être cassé sur ce paquet pour garantir que tous les scripts postinst sont exécutés avec leurs dépendances correctement configurés si cela est possible. Sinon, le point de cassure est arbitraire.
Ainsi le champ Depends autorise les responsables de paquet à imposer un ordre sur la manière de configurer les paquets.
Voici la signification des cinq champs de dépendance :
Ce champ déclare une dépendance absolue. Il n'est pas possible de configurer un paquet tant que tous les paquets listés dans ce champ n'ont pas été correctement configurés.
Le champ Depends sera utilisé quand le paquet dépendant a besoin, pour fonctionner d'une manière intéressante, de tel paquet.
Le champ Depends sera aussi utilisé quand les scripts
postinst
, prerm
ou postrm
demandent que
tel paquet soit présent pour qu'ils puissent fonctionner. Cependant, il faut
noter que le script postrm
ne peut pas compter sur la présence de
paquets « non-essential » pendant la phase de purge.
Ce champ déclare une dépendance forte, mais pas absolue. Le champ Recommends listera les paquets qu'on trouve habituellement avec ce paquet dans toute installation standard.
On se sert de ce champ pour déclarer qu'un paquet serait plus utile avec un ou plusieurs autres paquets. On indique au système de gestion de paquet et à l'utilisateur que les paquets listés sont liés au paquet et qu'ils peuvent peut-être augmenter son utilité, mais qu'une installation sans ces paquets est parfaitement concevable.
Ce champ ressemble au champ Suggests mais il marche en sens inverse. On s'en sert pour déclarer qu'un paquet améliore l'efficacité de tel autre paquet.
Ce champ ressemble au champ Depends, sauf qu'il force aussi
dpkg
à terminer l'installation des paquets qu'il liste avant même
de démarrer l'installation du paquet qui déclare ces pré-dépendances.
Quand un paquet déclarant une relation de pré-dépendance est sur le point d'être dépaqueté, cette relation peut être satisfaite si le paquet exigé par la pré-dépendance est, soit pleinement configuré, soit même s'il est seulement dépaqueté ou « à demi configuré », pourvu qu'il ait été déjà correctement configuré au moins une fois (et pas effacé ou partiellement effacé depuis). Dans ce cas, les deux versions, celle précédemment configurée et celle actuellement dépaquetée ou dans un état « à moitié configuré », doivent satisfaire à toute clause de version contenue dans le champ Pre-Depends.
Quand le paquet déclarant une relation de Pre-Dépendance est configuré, cette relation sera considérée comme une relation Depends normale ; c'est-à-dire, elle sera considérée comme satisfaite seulement si le paquet dépendant a bien été configuré.
Le champ Pre-Depends sera utilisé parcimonieusement et de préférence seulement pour les paquets dont une mise à jour ou une installation prématurée entraverait la capacité du système à continuer les mises à jour en cours.
Des relations Pre-Depends sont aussi exigées quand un script
preinst
dépend d'un paquet cité. Il vaut mieux éviter cette
situation.
Pour choisir un niveau de dépendance, on mesurera l'importance du paquet demandé pour les fonctionnalités du paquet qui déclare la dépendance. Certains paquets sont composés d'éléments plus ou moins importants. Un tel paquet listera dans le champ Depends le ou les paquets qui sont nécessaires aux éléments les plus importants. Les autres éléments peuvent être mentionnés comme des Suggestions ou des Recommandations, selon l'importance relative de ces éléments.
Quand un paquet déclare un conflit avec un autre, en utilisant le champ
Conflicts, dpkg
refuse de les installer en même temps
sur le système.
Si l'on veut installer l'un de ces paquets, l'autre doit d'abord être supprimé
— si le paquet en cours d'installation est marqué comme remplaçant (voir
le champ Replaces -- regénérer les fichiers
et remplacer les paquets, Section 7.5) le paquet sur le système, ou si
celui-ci est marqué comme « désélectionné », ou bien si les deux
paquets sont marqués Essential, alors dpkg
enlève
automatiquement le paquet qui crée le conflit, ou bien arrête l'installation du
nouveau paquet par une erreur. Ce mécanisme est spécifiquement conçu pour
provoquer une erreur quand le paquet installé est marqué Essential
et que le nouveau paquet ne l'est pas.
Un paquet ne provoque pas de conflit simplement parce que ses fichiers de configuration sont toujours installés ; il doit être au moins dans l'état « à moitié installé ».
Une exception spéciale est faite pour les paquets qui déclarent un conflit avec leur propre nom de paquet, ou avec le paquet virtuel qu'ils fournissent (voir ci-dessous) : cela n'empêche pas leur installation, et cela autorise un paquet à déclarer un conflit avec les paquets qui peuvent le remplacer. On utilise ce dispositif quand on veut que le paquet en question soit le seul paquet à fournir une fonctionnalité particulière.
Une entrée Conflicts ne devrait presque jamais avoir une clause de
version indiquant une relation « avant ». Cela empêcherait
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 ait
été terminé.
Aussi bien que des noms de paquets réels (concrets), les champs de relation Depends, Recommends, Suggests, Enhances, Pre-Depends, Conflicts, Build-Depends, Build-Depends-Indep, Build-Conflicts et Build-Conflicts-Indep peuvent mentionner des noms de « paquets virtuels ».
Un paquet « virtuel » est un paquet qui apparaît dans le champ Provides du fichier « control » d'un autre paquet. L'effet est le même que si le ou les paquets qui fournissent un paquet virtuel particulier avaient été listés par leur nom partout où le nom du paquet virtuel apparaît. Voir aussi Les paquets virtuels, Section 3.6.
Quand un paquet concret et un paquet virtuel ont le même nom, la dépendance peut être satisfaite (ou le conflit provoqué) soit par le paquet concret du même nom soit par tout autre paquet concret fournissant le paquet virtuel du même nom. Par exemple, en supposant que nous ayons :
Package: foo Depends: bar
et que quelqu'un d'autre sorte un paquet bar amélioré, il peut dire :
Package: bar-plus Provides: bar
et le paquet bar-plus satisfera aussi la dépendance pour le paquet foo.
Quand un numéro de version est attaché à une dépendance ou à un conflit, seuls les paquets réels seront examinés pour savoir si la relation est satisfaite (ou, pour un conflit, l'interdiction violée) - on supposera qu'un paquet réel qui fournit un paquet virtuel n'a pas la « bonne » version. Ainsi, un champ Provides ne peut pas contenir de numéros de version, et le numéro de version du paquet concret qui fournit un paquet virtuel particulier n'est pas examiné quand on considère une dépendance envers ou un conflit avec le nom du paquet virtuel.
Il est probable que la possibilité d'indiquer un numéro de version pour chaque
paquet virtuel sera ajoutée dans une version prochaine de dpkg
.
Cette caractéristique n'est pas encore présente et il est probable qu'elle sera
très peu utilisée.
Quand on veut spécifier quel paquet d'un ensemble de paquets réels sera celui qui satisfait par défaut une dépendance particulière envers un paquet virtuel, on listera le paquet réel alternatif avant le paquet virtuel.
Un paquet peut déclarer dans son fichier control qu'il modifiera des fichiers appartenant à un autre paquet ou qu'il remplacera complètement un autre paquet. Le champ Replaces du fichier control remplit ces deux fonctions.
Tout d'abord, comme mentionné auparavant, qu'un paquet possède des fichiers qui sont sur le système mais dans un autre paquet est généralement une erreur.
Cependant, si le paquet, qui veut faire un remplacement, déclare, dans le champ
Replaces, qu'il remplace le paquet qui contient le fichier à
remplacer, dpkg
procède au remplacement du fichier de l'ancien
paquet par le nouveau. Ce fichier ne sera plus listé comme faisant partie de
l'ancien paquet.
Quand un paquet est ainsi complètement remplacé, de sorte que dpkg
ne sait pas quels fichiers il contient encore, on considère qu'il a
« disparu ». Sur le système, il est marqué comme « non
sélectionné » (sélectionné pour l'effacement) et « non
installé ». Tous les renseignements contenus dans les
conffiles sont ignorés, vu que le paquet remplaçant les aura
repris. Le script postrm
du paquet est exécuté avec un argument
particulier pour permettre au paquet de faire le nettoyage final nécessaire.
Voir Résumé des façons
d'appeler les scripts du responsable, Section 6.5 [43].
Avec cette utilisation du champ Replaces, et quand on l'examine, on ne prend pas en compte les paquets virtuels (voyez Les paquets virtuels -- le champ Provides, Section 7.4) -- les paquets déclarant qu'ils sont remplacés doivent être mentionnés par leurs noms réels.
De plus, cet usage de Replaces prend seulement effet quand deux paquets sont -- au moins partiellement -- en même temps sur le système, et cela peut seulement se produire s'ils ne sont pas en conflit, ou si le conflit a été annulé.
Et deuxièmement, le champ Replaces permet au système de gestion des paquets de savoir quel paquet enlever quand il y a un conflit - voir Mettre en conflit des paquets binaires -- le champ Conflicts, Section 7.3. Cet usage prend seulement effet quand deux paquets sont réellement en conflit, afin que les deux usages de ce champ n'interfèrent pas l'un avec l'autre.
Dans ce cas, le paquet déclaré comme étant remplacé peut être un paquet virtuel ; c'est ainsi que les agents de transport du courrier (MTA) pourront avoir les champs suivants dans leur fichier de contrôle :
Provides: mail-transport-agent Conflicts: mail-transport-agent Replaces: mail-transport-agent
On s'assure ainsi qu'un seul MTA peut être installé à la fois.
Les paquets sources peuvent déclarer des relations avec des paquets binaires si, par exemple, ils ont besoin que tel paquet binaire soit présent ou absent au moment de leur construction.
On se sert des champs Build-Depends, Build-Depends-Indep, Build-Conflicts et Build-Conflicts-Indep du fichier control.
Les dépendances de construction sur les paquets binaires appartenant à « build-essential » peuvent être omises. Voyez Les relations entre paquets, Section 4.2 pour davantage d'informations.
Les dépendances ou les conflits qu'ils définissent doivent être résolus (comme cela a été défini plus haut pour les paquets binaires) pour pouvoir appeler les cibles de debian/rules[44] comme suit :
Les champs Build-Depends et Build-Conflicts doivent être satisfaits quand l'une des cibles suivantes est appelée : build, clean, binary, binary-arch, build-arch, build-indep et binary-indep.
Les champs Build-Depends-Indep et Build-Conflicts-Indep doivent être satisfaits quand l'une des cibles suivantes est appelée : build, build-indep, binary et binary-indep.
[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ suivant ]
La Charte Debian
version 3.7.2.2