deb-control

deb-control(5) dpkg suite deb-control(5)

NOM

   deb-control - Format du fichier principal de contrôle dans les paquets binaires Debian

SYNOPSIS

   DEBIAN/control

DESCRIPTION

   Chaque paquet de fichier binaire de Debian fournit un fichier control dans le membre control et leur format deb822(5) est un sous-ensemble du fichier
   principal debian/control dans les paquets source Debian, voir 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)
       C'est classiquement le numéro de version du paquet d'origine dans la forme choisie par l'auteur du programme. Il peut y avoir aussi un numéro de révision
       Debian (pour les paquets non natifs). Le format exact et l'algorithme de tri sont décrits dans 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- 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
       Ce champ définit une liste, séparée par des espaces, des raisons pour lesquelles ce paquet a été généré automatiquement. Les paquets binaires marqués
       avec ce champ n'apparaîtront pas dans le fichier principal de contrôle des sources debian/control. debug-symbols est la seule raison utilisée
       actuellement.

   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>.

1.21.22 2023-05-11 deb-control(5)