Provided by: dpkg-dev_1.22.18ubuntu3_all bug

NOM

       deb-control - Debian binary package control file format

SYNOPSIS

       DEBIAN/control

DESCRIPTION

       Each Debian binary package contains a control file in its control member, and its deb822(5) format is a
       subset of the debian/control template source control file in Debian source packages, see
       deb-src-control(5).

       Ce fichier contient un certain nombre de champs. Chaque champ commence par une étiquette, telle que
       Package ou Version (la casse n'importe pas), suivie d'un « : », et du contenu du champ (sensible à la
       casse à moins que cela ne soit spécifié autrement). Les champs sont séparés seulement par des étiquettes
       de champ. En d'autres termes, le contenu d'un champ peut s'étendre sur plusieurs lignes, mais les outils
       d'installation joindront en général les lignes pendant le traitement du contenu du champ (sauf pour le
       champ Description, voir ci-dessous).

LES CHAMPS

       Package: nom-du-paquet (requis)
           La  valeur  de  ce champ donne le nom du paquet, et la plupart des outils d'installation s'en servent
           pour produire les noms des paquets.

       Package-Type: deb|udeb|type
           Ce champ indique le type de paquet. La valeur udeb est à utiliser pour les paquets à taille contrôlée
           utilisés par l'installateur Debian. La valeur deb est la valeur par défaut qui  est  utilisée  si  le
           champ n'est pas présent. De nouveaux types pourraient être ajoutés au fil du temps.

       Version: chaîne-de-la-version (requis)
           Typically,  this is the original package's version number in whatever form the program's author uses.
           It may also include a Debian revision number (for non-native packages). The exact format and  sorting
           algorithm are described in deb-version(7).

       Maintainer: nom-complet-et-adresse-électronique (recommandé)
           Le  format  de  ce  champ  sera  « Jean Dupont <jdupont@foo.com> » ; et c'est bien sûr le créateur du
           paquet, par opposition à l'auteur du programme mis en paquet.

       Description: description-courte (recommandé)
        description-longue
           Le format de la description du paquet est un résumé bref  sur  la  première  ligne  (après  le  champ
           Description).  Les  lignes  suivantes peuvent servir à une description plus longue et plus détaillée.
           Chaque ligne de cette description longue doit être précédée d'une espace  ;  quand  c'est  une  ligne
           blanche, elle doit contenir un seul « . » après cette espace.

       Section: section
           Champ  général qui indique la catégorie d'un paquet ; cette catégorie est fondée sur le programme que
           ce paquet installe. utils, net, mail, text, x11, etc., représentent quelques catégories habituelles.

           The accepted values are based on the specific distribution policy.

       Priority: priorité
           Sets the importance of this package in relation to the system as a whole. The  known  priorities  are
           required, important, standard, optional, extra, and unknown, but other values can be used as well.

           How to apply these values depends on the specific distribution policy.

       Installed-Size: taille
           La taille approximative totale des fichiers installés du paquet, en Kio. L'algorithme de calcul de la
           taille est décrit dans deb-substvars(5).

       Protected: yes|no
           On  se  sert habituellement de ce champ uniquement si la réponse est yes. Cela signifie que ce paquet
           est exigé principalement pour un démarrage correct  du  système  ou  utilisé  pour  des  méta-paquets
           personnalisés  du  système  local.  dpkg(1)  et  les  autres  outils  d'installation  interdisent  la
           suppression d'un paquet Protected (du moins tant qu'une des options de forçage n'est pas utilisée).

           Pris en charge depuis dpkg 1.20.1.

       Essential: yes|no
           On se sert habituellement de ce champ uniquement si la réponse est yes. Cela signifie que  ce  paquet
           est  exigé  pour  le  système  d'empaquetage, pour un fonctionnement correct du système en général ou
           durant le démarrage (même si dans ce dernier cas, il  devrait  être  converti  en  champ  Protected).
           dpkg(1)  et  les  autres  outils  d'installation interdisent la suppression d'un paquet Essential (du
           moins tant qu'une des options de forçage n'est pas utilisée).

       Build-Essential: yes|no
           Ce champ est habituellement nécessaire seulement si la  réponse  est  yes,  et  il  est  généralement
           injecté  par  le  logiciel  d'archive.  Il  désigne  un paquet qui est requis lors de la construction
           d'autres paquets.

       Architecture: arch|all (requis)
           L'architecture précise  pour  quel  type  de  matériel  le  paquet  a  été  compilé.  Voici  quelques
           architectures habituelles : amd64, armel, i386, powerpc, etc. Remarquez que l'option all signifie que
           le   paquet  est  indépendant  de  toute  architecture.  C'est  le  cas,  par  exemple,  des  scripts
           d'interpréteur de commandes (shell) ou Perl, ainsi que de la documentation.

       Origin: nom
           Nom de la distribution dont ce paquet provient.

       Bugs: URL
           L'URL du système de suivi de bogues (BTS) de ce paquet. Le format utilisé est  type_de_bts://adresse-
           du-bts, par exemple debbugs://bugs.debian.org.

       Homepage: URL
           URL de la page d'accueil du projet amont.

       Tag: liste-d'étiquettes
           Liste  d'étiquettes  décrivant  les  qualités  du  paquet.  La description et la liste des étiquettes
           (« tags ») prises en charge peuvent être trouvées dans le paquet debtags.

       Multi-Arch: no|same|foreign|allowed
           Ce champ est utilisé pour indiquer comment ce paquet  se  comportera  sur  les  installations  multi-
           architectures.

           no  C'est  la  valeur  par  défaut  quand  le champ est omis ; dans ce cas, ajouter le champ avec une
               valeur no explicite est généralement inutile.

           same
               Ce paquet est co-installable avec lui-même, mais il ne doit pas être utilisé pour  satisfaire  la
               dépendance d'un paquet d'une autre architecture que la sienne.

           foreign
               Ce  paquet n'est pas co-installable avec lui-même, mais il pourra être autorisé pour permettre de
               satisfaire les dépendances sans  qualification  d'architecture  d'un  paquet  d'une  architecture
               différente de la sienne (si une dépendance a une qualification d'architecture explicite, alors la
               valeur foreign est ignorée).

           allowed
               Cela  permet  aux  dépendances  inverses d'indiquer dans leur champ Depends qu'elles acceptent ce
               paquet d'une autre architecture en qualifiant le nom du paquet avec :any, mais n'a  pas  d'autres
               effets.

       Source: nom-du-paquet-source [(version-source)]
           Le  nom  du  paquet  source  d'où  est  issu  ce  paquet binaire, s'il est différent du nom du paquet
           lui-même. Si la version des sources diffère de la version du binaire, alors  le  nom-du-paquet-source
           sera  suivi  par  la  version-source  entre  parenthèses.  Cela peut arriver par exemple sur un envoi
           seulement binaire NMU (« non-maintainer upload »), ou lorsqu'une version différente  de  binaire  est
           fixée avec « dpkg-gencontrol -v ».

       Subarchitecture: valeur
       Kernel-Version: valeur
       Installer-Menu-Item: valeur
           Ces  champs  sont  utilisés  par  l'installateur  et ne sont en général pas nécessaires. Pour plus de
           détails,                                                                                    consultez
           <https://salsa.debian.org/installer-team/debian-installer/-/raw/master/doc/devel/modules.txt>.

       Depends: liste-de-paquets
           C'est  la liste des paquets exigés pour que ce paquet procure un nombre important de fonctionnalités.
           Le programme de maintenance des  paquets  interdit  l'installation  d'un  paquet  quand  les  paquets
           répertoriés dans le champ Depends ne sont pas installés (du moins tant qu'une option de forçage n'est
           pas  utilisée).  Lors  d'une  installation, il lance les scripts « postinst » des paquets répertoriés
           dans les champs Depends avant les scripts « postinst » des paquets qui dépendent d'eux. À  l'inverse,
           lors  d'une suppression, le script « prerm » d'un paquet est lancé avant ceux des paquets listés dans
           son champ Depends.

       Pre-Depends: liste-de-paquets
           C'est la liste des paquets qui doivent être installés et configurés avant que ce paquet  puisse  être
           installé.  Habituellement, on utilise ce champ quand un paquet a besoin d'un autre paquet pour lancer
           son script « preinst ».

       Recommends: liste-de-paquets
           C'est la liste des paquets qu'on trouverait avec ce  paquet  dans  toute  installation  standard.  Le
           programme de maintenance des paquets avertit l'utilisateur quand il installe un paquet sans installer
           les paquets répertoriés dans le champ Recommends.

       Suggests: liste-de-paquets
           C'est  la  liste des paquets qui, associés avec ce paquet, peuvent améliorer son utilité ; néanmoins,
           une installation sans ces paquets est parfaitement raisonnable.

       La syntaxe des champs Depends, Pre-Depends, Recommends et Suggests est une liste d'ensembles  de  paquets
       alternatifs.  Chaque  ensemble  est une liste de paquets séparés par des barres verticales (le symbole du
       tube) « | ». Les ensembles sont séparés par des virgules. Une virgule représente un « ET » logique et une
       barre verticale représente un « OU » logique ; le tube a la précédence dans l'évaluation de l'expression.
       Chaque nom de paquet est suivi éventuellement par un type d'architecture après deux-points « : », et  par
       une contrainte sur le numéro de version mise entre parenthèses.

       Un  nom  de  type d'architecture peut être un nom d'architecture réelle de Debian (depuis dpkg 1.16.5) ou
       any (depuis dpkg 1.16.2). S'il est omis, la valeur  par  défaut  est  l'architecture  du  paquet  binaire
       actuel.  Un  nom  d'architecture réelle de Debian correspondra exactement à l'architecture pour ce nom de
       paquet, any correspondra à toute architecture pour ce nom de paquet si le paquet a été marqué Multi-Arch:
       allowed.

       Une contrainte sur le numéro de version  peut  commencer  par  « >> »,  et  dans  ce  cas  toute  version
       supérieure  correspondra,  et  il peut indiquer (ou pas) le numéro de révision pour le paquet Debian (les
       deux numéros étant séparés par un trait d'union). Voici  les  relations  acceptées  pour  les  versions :
       « >> » pour supérieur à, « << » pour inférieur à, « >= » pour supérieur ou égal, « <= » pour inférieur ou
       égal, et « = » pour égal à.

       Breaks: liste-de-paquets
           C'est  une  liste  de  paquets  que ce paquet « casse », par exemple en révélant des bogues quand les
           paquets concernés dépendent de  celui-ci.  Le  programme  de  maintenance  des  paquets  interdit  la
           configuration  de paquets cassés ; une méthode usuelle de résolution est la mise à niveau des paquets
           mentionnés dans le champ Breaks.

       Conflicts: liste-de-paquets
           C'est une liste de paquets qui sont en conflit avec ce paquet  ;  ils  contiennent  par  exemple  des
           fichiers  qui  ont  le  même  nom.  Le  programme  de maintenance des paquets interdit l'installation
           simultanée de paquets en conflit. Deux paquets en conflit renseigneront une ligne Conflicts  avec  le
           nom de l'autre paquet.

       Replaces: liste-de-paquets
           C'est une liste de paquets que ce paquet remplace. Il peut ainsi remplacer les fichiers de ces autres
           paquets  ;  on se sert pour cela du champ Conflicts pour forcer la suppression des autres paquets, si
           celui-là possède aussi les mêmes fichiers que le paquet en conflit.

       La syntaxe des champs Breaks, Conflicts et Replaces est une liste de noms de  paquets,  séparés  par  des
       virgules (et des espaces facultatives). Dans les champs Breaks et Conflicts, la virgule sera lue comme un
       « OU ». Un type d'architecture optionnel peut être aussi ajouté au nom de paquet avec la même syntaxe que
       ci-dessus,  mais par défaut la valeur est any plutôt que l'architecture du paquet binaire. On peut donner
       une version optionnelle de la même façon que ci-dessus dans les champs Breaks, Conflicts et Replaces.

       Enhances: liste-de-paquets
           C'est une liste de paquets que ce paquet améliore. C'est similaire à Suggests mais en sens inverse.

       Provides: liste-de-paquets
           C'est une liste de paquets virtuels que ce paquet procure.  On  s'en  sert  habituellement  pour  des
           paquets  qui offrent le même service. Par exemple, sendmail et exim sont des serveurs de courrier, et
           donc ils procurent chacun un paquet commun (« mail-transport-agent ») duquel d'autres paquets peuvent
           dépendre. Sendmail et exim peuvent ainsi servir d'option valable pour satisfaire la dépendance.  Cela
           permet  aux  paquets  qui  dépendent d'un serveur de courrier de ne pas avoir à connaître les noms de
           paquet de tous les serveurs de courrier, en utilisant « | » comme séparateur de liste.

       La syntaxe du champ Provides est une liste de noms de paquets, séparés par des virgules (et  des  espaces
       facultatives).  Un  type d'architecture facultatif peut également être ajouté au nom de paquet de la même
       façon que ci-dessus. S'il est omis l'architecture par défaut est  celle  du  paquet  binaire  actuel.  Un
       numéro  de  version  précis  (égal  à)  optionnel peut être donné de la même façon que ci-dessus (pris en
       compte depuis dpkg 1.17.11).

       Built-Using: liste-de-paquets
           Ce champ de dépendance affiche les paquets source supplémentaires utilisés lors de la construction du
           paquet binaire, pour des raisons de conformité avec la licence. Il permet d'indiquer au  logiciel  de
           gestion de l'archive que des paquets source supplémentaires doivent être conservés tant que le paquet
           binaire  est  maintenu. Ce champ doit être une liste de paquets source, séparés par des virgules avec
           des références strictes de version « = » et mise entre parenthèses. Veuillez noter que le logiciel de
           gestion de l'archive risque de ne pas accepter un envoi qui déclare une relation Built-Using  qui  ne
           peut pas être satisfaite dans l'archive.

       Static-Built-Using: liste-de-paquets
           Ce champ de dépendance affiche les paquets source supplémentaires utilisés lors de la construction du
           paquet  binaire,  aux  fins  de  construction  statiques  (par  exemple,  pour  la  liaison  avec des
           bibliothèques statiques, les constructions pour des langages centrés sur le source  tels  que  Go  ou
           Rust, l'utilisation de bibliothèques C/C++ avec seulement des en-têtes, l'injection d'objets binaires
           (blob)  de  données  dans  le  code, etc.).  C'est  utile  pour  vérifier  si  ce paquet devrait être
           reconstruit lorsque les paquets source listés ont été mis à jour, par exemple à cause  d'annonces  de
           sécurité.  Ce  champ doit être une liste de noms de paquets source, séparés par des virgules avec des
           références strictes de version « = », mise entre parenthèses.

           Pris en charge depuis dpkg 1.21.3.

       Built-For-Profiles: liste-de-profils (obsolète)
           Ce champ sert à spécifier une liste, séparée  par  des  espaces,  de  profils  de  construction  avec
           lesquels  ce  paquet  binaire a été construit (depuis dpkg 1.17.2 et jusqu'à la version 1.18.18). Les
           informations précédemment trouvées dans ce champ sont maintenant dans le  champ  .buildinfo  qui  l'a
           remplacé.

       Auto-Built-Package: liste-de-raisons
           This  field  specifies  a  whitespace  separated list of reasons why this package was auto-generated.
           Binary packages marked with this field will not appear in the debian/control template source  control
           file. The only currently used reason is debug-symbols.

       Build-Ids: liste-identifiants-de-construction-elf
           Ce  champ définit une liste, séparée par des espaces, des identifiants de construction ELF. Il s'agit
           des identifiants uniques d'objets ELF sémantiquement identiques, pour chacun de ces  objets  présents
           dans le paquet.

           Le format ou la manière de calculer chaque identifiant de construction n'est pas défini par nature.

EXEMPLE

        Package: grep
        Essential: yes
        Priority: required
        Section: base
        Maintainer: Wichert Akkerman <wakkerma@debian.org>
        Architecture: sparc
        Version: 2.4-1
        Pre-Depends: libc6 (>= 2.0.105)
        Provides: rgrep
        Conflicts: rgrep
        Description: GNU grep, egrep and fgrep.
         Il se peut que le grep de la famille GNU des utilitaires grep soit
         le plus rapide de l'ouest ! Le grep de GNU est fondé sur un mécanisme
         rapide de mise en correspondance déterministe d'états simples (environ
         deux fois plus rapide que le « egrep » standard d'Unix), modifié par une
         recherche de type Boyer-Moore-Gosper qui cherche une chaîne donnée en
         empêchant que les textes impossibles soient analysés par le mécanisme de
         mise en correspondance d'expressions rationnelles et sans avoir
         nécessairement besoin de voir chaque caractère. C'est beaucoup plus
         rapide que les « grep » ou « egrep » d'Unix.
         (Des expressions rationnelles contenant des références circulaires
         ralentissent cependant le programme.)

BOGUES

       Le champ Build-Ids utilise un nom plutôt générique à partir de son contexte original dans l'objet ELF qui
       sert un objectif très spécifique et a un format exécutable.

VOIR AUSSI

       deb822(5), deb-src-control(5), deb(5), deb-version(7), debtags(1), dpkg(1), dpkg-deb(1).

TRADUCTION

       Ariel  VARDI  <ariel.vardi@freesbee.fr>, 2002. Philippe Batailler, 2006. Nicolas François, 2006. Veuillez
       signaler toute erreur à <debian-l10n-french@lists.debian.org>.

1.22.18                                            2025-04-28                                     deb-control(5)