Provided by: dpkg-dev_1.22.6ubuntu6_all bug

NOM

       deb-src-control - Debian source package template control file format

SYNOPSIS

       debian/control

DESCRIPTION

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

       This file contains at least 2 stanzas, separated by a blank line. The first stanza is
       called the source package stanza and lists all information about the source package in
       general, while each following stanzas are called the binary package stanzas and describe
       exactly one binary package per stanza. Each stanza consists of at least one field. A field
       starts with a field name, such as Package or Section (case insensitive), followed by a
       colon, the body of the field (case sensitive unless stated otherwise) and a newline.
       Multi-line fields are also allowed, but each supplementary line, without a field name,
       should start with at least one space. The content of the multi-line fields is generally
       joined to a single line by the tools (except in the case of the Description field, see
       below). To insert empty lines into a multi-line field, insert a dot after the space. Lines
       starting with a ‘#’ are treated as comments.

LES CHAMPS SOURCE

       Source: nom-du-paquet-source (requis)
           La valeur de ce champ est le nom du paquet source et doit correspondre au nom du
           paquet source dans le fichier debian/changelog. Un nom de paquet doit être constitué
           uniquement de lettres minuscules (a-z), de chiffres (0-9), des caractères plus (+) et
           moins (-) et de points (.). Les noms de paquets doivent comporter au moins deux
           caractères et doivent commencer par un caractère alphanumérique (a-z0-9) en minuscule.

       Maintainer: nom-complet-et-adresse-électronique (recommandé)
           Le format de ce champ sera « Jean Dupont <jdupont@foo.com> » ; il indique le
           responsable actuel du paquet, par opposition à l'auteur du logiciel ou au responsable
           originel.

       Uploaders: nom-complet-et-adresse-électronique
           Affiche les noms et les adresses électroniques des co-responsables du paquet, au même
           format que le champ Maintainer. Des co-responsables multiples peuvent être séparés par
           des virgules.

       Standards-Version: chaîne-de-la-version
           Ce champ indique la version la plus récente des normes de la charte de la distribution
           auxquelles ce paquet se conforme.

       Description description-courte
        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.

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

       Bugs: URL
           L'URL du système de suivi de bogues (BTS) de ce paquet. Le format utilisé est
           type_de_bts://adresse_du_btsE, par exemple debbugs://bugs.debian.org. Ce champ est en
           général inutile.

       Rules-Requires-Root: no|binary-targets|mots-clés-implémentation
           Ce champ est utilisé pour indiquer si le fichier debian/rules exige des droits
           (fake)root pour exécuter certaines de ses cibles et quand, si c'est le cas.

           no  The binary targets will not require (fake)root at all. This is the default in
               dpkg-build-api level >= 1.

           binary-targets
               The binary targets must always be run under (fake)root. This value is the default
               in dpkg-build-api level 0, when the field is omitted; adding the field with an
               explicit binary-targets, while not strictly needed, marks it as having been
               analyzed for this requirement.

           mots-clés-implémentation
               Il s'agit d'une liste, séparée par des espaces, de mots-clés qui définissent quand
               (fake)root est exigé.

               Les mots-clés sont composés de espace-de-nommage/cas. La partie espace-de-nommage
               ne peut pas inclure de « / » ou d'espace. La partie cas ne peut pas inclure
               d'espace. Par ailleurs, les deux parties doivent être entièrement composées de
               caractères ASCII imprimables.

               Chaque outil ou paquet définira un espace de nommage nommé d'après lui-même et
               fournira le nombre des cas où (fake)root est exigé. (Voir « Mots-clés fournis par
               l'implémentation » dans rootless-builds.txt).

               Quand le champ est défini pour un des mots-clés-implémentation, le constructeur
               exposera une interface qui est utilisée pour exécuter une commande avec les droits
               (fake)root. (Voir « API pour obtenir les droits root » dans rootless-builds.txt).

       Testsuite: liste-de-noms
       Testsuite-Triggers: liste-de-paquets
           These fields are described in the dsc(5) manual page, as they are generated from
           information inferred from debian/tests/control or copied literally to the source
           control file.

       Vcs-Arch: URL
       Vcs-Bzr: URL
       Vcs-Cvs: URL
       Vcs-Darcs: URL
       Vcs-Git: URL
       Vcs-Hg: URL
       Vcs-Mtn: URL
       Vcs-Svn: URL
           Ce champ indique l'URL du système de gestion de version utilisé pour la gestion du
           paquet. Les systèmes gérés sont Arch, Bzr (Bazaar), Cvs, Darcs, Git, Hg (Mercurial),
           Mtn (Monotone) et Svn (Subversion). En général, ce champ fait référence à la dernière
           version du paquet, c'est-à-dire la branche principale ou le « trunk ».

       Vcs-Browser: URL
           Indique l'URL de l'interface web permettant de parcourir le dépôt du système de
           gestion de versions.

       Origin: nom
           Indique le nom de la distribution dont le paquet provient. Ce champ n'est souvent pas
           nécessaire.

       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.

       Build-Depends: liste-de-paquets
           Liste de paquets à installer et configurer pour pouvoir construire à partir du paquet
           source. Ces dépendances doivent être satisfaites lors de la construction des paquets
           binaires dépendant ou non de l'architecture, et des paquets source. Ajouter une
           dépendance à ce champ n'aura pas exactement le même effet que de l'inclure à la fois
           dans Build-Depends-Arch et Build-Depends-Indep, parce que la dépendance a aussi besoin
           d'être prise en compte lors de la construction du paquet source.

       Build-Depends-Arch:liste-de-paquets
           Liste analogue à Build-Depends, mais restreinte aux paquets nécessaires pour
           construire les paquets dépendants de l'architecture. Les paquets indiqués dans Build-
           Depends sont alors également installés. Ce champ est géré depuis la version 1.16.4 de
           dpkg ; pour pouvoir construire des paquets avec des versions plus anciennes de dpkg,
           il est préférable d'utiliser Build-Depends.

       Build-Depends-Indep: liste-de-paquets
           Liste analogue à Build-Depends, mais restreinte aux paquets nécessaires pour
           construire les paquets indépendants de l'architecture. Les paquets indiqués dans
           Build-Depends sont alors aussi installés.

       Build-Conflicts: liste de paquets
           Liste de paquets qui ne doivent pas être installés lors de la construction du paquet,
           par exemple s'ils interfèrent avec le système de construction utilisé. Si une
           dépendance est ajoutée à cette liste, l'effet sera le même que si elle était ajoutée à
           la fois dans Build-Conflicts-Arch et Build-Conflicts-Indep, en ayant de plus l'effet
           d'être prise en compte pour les constructions de paquets uniquement source (« source-
           only builds »).

       Build-Conflicts-Arch: liste-de-paquets
           Identique à Build-Conflicts, mais n'est prise en compte que pour les paquets
           dépendants de l'architecture. Ce champ est géré depuis la version 1.16.4 de dpkg ;
           pour pouvoir construire des paquets avec des versions plus anciennes de dpkg, il est
           préférable d'utiliser Build-Conflicts.

       Build-Conflicts-Indep: liste-de-paquets
           liste analogue à Build-Conflicts mais restreinte à la construction des paquets
           indépendants de l'architecture.

       The syntax of the Build-Depends, Build-Depends-Arch and Build-Depends-Indep fields is a
       list of groups of alternative packages. Each group is a list of packages separated by
       vertical bar (or “pipe”) symbols, ‘|’. The groups are separated by commas ‘,’, and can end
       with a trailing comma that will be eliminated when generating the fields for
       deb-control(5) (since dpkg 1.10.14). Commas are to be read as “AND”, and pipes as “OR”,
       with pipes binding more tightly. Each package name is optionally followed by an
       architecture qualifier appended after a colon ‘:’, optionally followed by a version number
       specification in parentheses ‘(’ and ‘)’, an architecture specification in square brackets
       ‘[’ and ‘]’, and a restriction formula consisting of one or more lists of profile names in
       angle brackets ‘<’ and ‘>’.

       The syntax of the Build-Conflicts, Build-Conflicts-Arch and Build-Conflicts-Indep fields
       is a list of comma-separated package names, where the comma is read as an “AND”, and where
       the list can end with a trailing comma that will be eliminated when generating the fields
       for deb-control(5) (since dpkg 1.10.14). Specifying alternative packages using a “pipe” is
       not supported. Each package name is optionally followed by a version number specification
       in parentheses, an architecture specification in square brackets, and a restriction
       formula consisting of one or more lists of profile names in angle brackets.

       Un nom de type d'architecture peut être un nom d'architecture réelle de Debian (depuis
       dpkg 1.16.5), any (depuis dpkg 1.16.2) ou native (depuis dpkg 1.16.5). S'il est omis, la
       valeur par défaut des champs Build-Depends est l'architecture de l'hôte actuel, la valeur
       par défaut des champs Build-Conflicts est any. 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, et
       native correspondra à l'architecture de construction actuelle si le paquet n'a pas été
       marqué Multi-Arch: foreign.

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

       Une indication d'architecture consiste en un ou plusieurs noms d'architectures, séparés
       par des espaces. Un nom d'architecture peut être précédé d'un point d'exclamation qui
       correspond alors au « NON » logique.

       Une formule de restriction consiste en une ou plusieurs listes de restriction séparées par
       des espaces. Chaque liste de restriction est incluse entre chevrons. Les éléments des
       listes de restriction sont des noms de profils de construction séparés par des espaces et
       pouvant être préfixés d'un point d'exclamation représentant un « NON » logique. Une
       formule de restriction représente une forme normale disjonctive.

       Veuillez noter que les dépendances des paquets du jeu build-essential peuvent être omises
       et qu'il n'est pas possible de déclarer des conflits avec ces paquets. La liste des
       paquets concernés est fournie par le paquet build-essential.

CHAMPS BINAIRES

       Veuillez noter que les champs Priority, Section et Homepage peuvent être placés dans le
       paragraphe d'un paquet binaire et leur valeur remplace alors celle du paquet source.

       Package: nom-du-paquet-binaire (requis)
           Ce champ sert à indiquer le nom du paquet binaire. Les restrictions sont les mêmes que
           celles des paquets source.

       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.

       Architecture: arch|all|any (requis)
           The architecture specifies on which type of hardware this package runs. For packages
           that run on all architectures, use the any value. For packages that are architecture
           independent, such as shell and Perl scripts or documentation, use the all value. To
           restrict the packages to a certain set of architectures, specify the architecture
           names, separated by a space. It's also possible to put architecture wildcards in that
           list (see dpkg-architecture(1) for more information about them).

       Build-Profiles: formule-de-restriction
           Ce champ précise les conditions pour lesquelles ce paquet binaire est ou n'est pas
           construit. Cette condition est exprimée en utilisant la même syntaxe de formule de
           restriction qui provient du champ Build-Depends (y compris les chevrons).

           Si un paragraphe de paquet binaire ne contient pas ce champ, cela signifie de façon
           implicite que ce paquet se construit avec tous les profils de construction (y compris
           aucun profil).

           En d'autres termes, si un paragraphe de paquet binaire est annoté d'un champ Build-
           Profiles non vide, alors, ce paquet binaire est créé si et seulement si la condition
           exprimée par l'expression en forme normale conjonctive est évaluée à vrai.

       Protected: yes|no
       Essential: yes|no
       Build-Essential: yes|no
       Multi-Arch: same|foreign|allowed|no
       Tag: liste-d'étiquettes
       Description: description-courte (recommandé)
           These fields are described in the deb-control(5) manual page, as they are copied
           literally to the control file of the binary package.

       Depends: liste-de-paquets
       Pre-Depends: liste-de-paquets
       Recommends: liste-de-paquets
       Suggests: liste-de-paquets
       Breaks: liste-de-paquets
       Enhances: liste-de-paquets
       Replaces: liste-de-paquets
       Conflicts: liste-de-paquets
       Provides: liste-de-paquets
       Built-Using: liste-de-paquets
       Static-Built-Using: liste-de-paquets
           These fields declare relationships between packages. They are discussed in the
           deb-control(5) manual page. When these fields are found in debian/control they can
           also end with a trailing comma (since dpkg 1.10.14), have architecture specifications
           and restriction formulas which will all get reduced when generating the fields for
           deb-control(5).

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

LES CHAMPS UTILISATEUR

       Il est autorisé d'ajouter au fichier de contrôle des champs supplémentaires définis par
       l'utilisateur. L'outil ignorera ces champs. Si vous souhaitez que ces champs soient copiés
       dans ces fichiers de sortie, tels que les paquets binaires, vous devez utiliser un schéma
       de nommage personnalisé : les champs démarreront par un X, suivi de zéro ou plusieurs des
       lettres SBC et un trait d'union.

       S   The field will appear in the source package control file, see dsc(5).

       B   The field will appear in the control file in the binary package, see deb-control(5).

       C   The field will appear in the upload control (.changes) file, see deb-changes(5).

       Veuillez noter que les préfixes X[SBC]- sont retirés quand les champs sont copiés dans les
       fichiers de sortie. Un champ XC-Approved-By apparaîtra sous la forme Approved-By dans le
       fichier des modifications et n'apparaîtra pas dans les fichiers de contrôle des paquets
       binaires ou source.

       Il faut prendre en compte le fait que ces champs définis par l'utilisateur se serviront de
       l'espace de nommage global, lequel pourrait, dans le futur, entrer en conflit avec des
       champs officiellement reconnus. Pour éviter de telles situations, il est conseillé de les
       préfixer avec Private- (exemple : XB-Private-New-Field).

EXEMPLE

        # Comment
        Source: dpkg
        Section: admin
        Priority: required
        Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
        # this field is copied to the binary and source packages
        XBS-Upstream-Release-Status: stable
        Homepage: https://wiki.debian.org/Teams/Dpkg
        Vcs-Browser: https://git.dpkg.org/cgit/dpkg/dpkg.git
        Vcs-Git: https://git.dpkg.org/git/dpkg/dpkg.git
        Standards-Version: 3.7.3
        Build-Depends: pkgconf, debhelper (>= 4.1.81),
         libselinux1-dev (>= 1.28-4) [!linux-any]

       Package: dpkg-dev Section: utils Priority: optional Architecture: all # champ personnalisé
       dans le paquet binaire XB-Mentoring-Contact: Raphael Hertzog <hertzog@debian.org> Depends:
       dpkg (>= 1.14.6), perl5, perl-modules, cpio (>= 2.4.2-2),
        bzip2, lzma, patch (>= 2.2-1), make, binutils, libtimedate-perl Recommends: gcc |
       c-compiler, build-essential Suggests: gnupg, debian-keyring Conflicts: dpkg-cross (<<
       2.0.0), devscripts (<< 2.10.26) Replaces: manpages-pl (<= 20051117-1) Description: Debian
       package development tools
        This package provides the development tools (including dpkg-source)
        required to unpack, build and upload Debian source packages.
        .
        Most Debian source packages will require additional tools to build;
        for example, most packages need make and the C compiler gcc.

VOIR AUSSI

       /usr/share/doc/dpkg/spec/rootless-builds.txt, deb822(5), deb-control(5), deb-version(7),
       dpkg-source(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>.