http://www.debian.org/doc/debian-policy/
Debian Policy Manual
Chapter 7 - Dépendances entre paquets
http://www.debian.org/doc/debian-policy/ch-relationships.html
7.1 Syntaxe des champs de dépendance
- Ces champs ont une syntaxe uniforme : une liste de noms de paquets séparés par une virgule.
Field == PackageSpecList PackageSpecList == PackageSpecList ',' PackageSpec PackageSpecList == PackageSpec
Dans les champs Depends, 'Recommends', 'Suggests', 'Pre-Depends', 'Build-Depends' et 'Build-Depends-Indep' du fichier de contrôle (control) du paquet, déclarant les dépendances entre paquets, les noms de paquets listés peuvent également contenir des listes de noms de paquets alternatifs séparés par une barre verticale (pipe / symbole ||). Dans ce cas, si l'un d'entre eux est installé cette partie de la dépendance est considérée comme statisfaite.
PackageSpec == PackageSpecAlt PackageSpecAlt == PackageSpec '||' PackageSpec
- Tout les champs, à l'exception de 'Provides' peuvent restreindre leur portée (applicability) à une version particulière de chaque paquet nommé. Cela se fait entre parentheses après chaque nom de paquet; les parenthèses doivent contenir une relation de l'une des formes listées ci-dessous suivie par un numéro de version, selon le format décrit en (Version, section 5.6.11)
PackageVersion = '(' Relation ')' Relation = RelOp VersionNumber
Les relations/opérateur autorisés sont <<, <=, =, >= >>
pour 'strictement plus petit/tôt, plus petit/tôt ou identique, identique, plus grand/tard ou identique, ou strictement plus grand/tard.for strictly earlier, earlier or equal, exactly equal, later or equal and strictly later, respectively.
- Des espaces (blancs) peuvent apparaître en tout point d'une spécification de version soumise à la syntaxe des fichiers de contrôle, Section 5.1, et doivent apparaître aux endroits nécessaires pour lever une ambiguité; pour tout autre cas, cela n'est pas significatif.
- Pour la cohérence et par anticipiation de modifications éventuelle de 'dpkg', il est recommandé qu'une seule espace soit utilisée après une dépendance avec version et avant un numéro de version;
- Par convention, on place également une espace après chaque virgule, de part et d'autre d'une barre verticale, et avant chaque parenthèse ouvrante.
- Par exemple une liste de dépendances peut-être :
Package: mutt Version: 1.3.17-1 Depends: libc6 (>= 2.2.1), exim || mail-transport-agent
- Tout champs qui spécifie une dépendance de compilation (Build-Depends, Build-Depends-Indep, Build-Conflicts and Build-Conflicts-Indep) peut-être restreint à un sous-ensemble d'architectures.
- Cela est indiqué entre crochets après chaque nom de paquet et le numéro de version éventuel.
- Les crochets délimitent une liste de nom Debian d'architectures séparés par un/des espace(s) blanc(s)
Quelles sont les valeurs Debian d'architectures ?
- Un point d'exclamation peut-être ajouté à chaque noms (d'architecture?)
- Si l'architecture de la machine Debian considérée n'est pas dans cette liste et qu'il n'y a pas de point d'exclamation dans la liste, ou que l'architecture est présente dans la liste, précédée par un point d'exclamation, le paquet considéré et la spécification de version associée sont complètement ignorés dans la définition des dépendances
''__MG__'' Mon interprétation est que le signe '!' doit être compris comme la négation/annulation de la dépendance pour l'architecture ainsi marquée.
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]
NB les dépendances sur paquets binaires telles que Depends apparaissent dans l'une des sections du fichier contrôle du paquet binaire, alors que les dépendances de compilations telles que Build-Depends apparaissent dans la section 'source package' du fichier de contrôle (qui est la première section)