Provided by: dpkg-dev_1.22.6ubuntu6_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.

       Priority: priorité
           Définit l'importance du paquet à l'intérieur du système général. required, standard,
           optional, extra, etc., représentent des priorités habituelles.

       Les champs Section et Priority possèdent un ensemble défini de valeurs acceptées, tiré de
       la Charte particulière de la distribution.

       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 S<« 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 S<« grep »> ou S<« 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>.