Provided by: dpkg-dev_1.19.7ubuntu3.2_all 
NOM
deb-src-control - Format du fichier principal de contrôle dans les paquets source Debian
SYNOPSIS
debian/control
DESCRIPTION
Chaque paquet source Debian contient un fichier « control » maître, qui contient au moins
deux paragraphes, séparés par une ligne vide. Le premier paragraphe donne toutes les
informations à propos du paquet source en général et chaque paragraphe qui suit décrit
exactement un paquet binaire. Chaque paragraphe contient au moins un champ. Un champ
commence par le nom du champ, par exemple Package ou Section (la casse n'est pas
significative), suivi d'un caractère « deux-points », du contenu du champ et d'un retour à
la ligne. Les champs à lignes multiples sont aussi possibles, mais chaque ligne
supplémentaire, qui ne comporte pas de nom de champ, doit commencer par au moins une
espace. Le contenu des champs à lignes multiples est en général réassemblé en une ligne
unique par les outils (sauf pour le champ Description, voir ci-dessous). Pour inclure des
lignes vides dans un champ à lignes multiples, il est nécessaire de mettre un point après
l'espace initiale. Les lignes commençant par « # » sont traitées comme des commentaires.
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 Les cibles binaires n'exigeront aucun (fake)root.
binary-targets
Les cibles binaires doivent toujours être exécutées avec les droits
(fake)root. C'est la valeur par défaut quand le champ est omis ; l'ajout du
champ avec un binary-targets explicite, alors qu'il n'est pas strictement
nécessaire, marque qu'il a été analysé pour cette exigence.
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
Ces champs sont décrits dans la page de manuel de dsc(5), car ils sont créés à
partir des informations déduites de debian/tests/control ou copiés littéralement
dans le fichier « control » du paquet source.
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 version.
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.
La syntaxe des champs Build-Depends, Build-Depends-Arch et Build-Depends-Indep est une
liste de groupes contenant des paquets alternatifs. Chaque groupe est une liste de paquets
séparés par des barres verticales (le symbole du tube) « | ». Les groupes sont séparés par
des virgules « , », et la liste peut finir par une virgule qui peut être éliminée lors de
la création des champs pour deb-control(5) (depuis dpkg 1.10.14). Une virgule représente
un « ET » logique et une barre verticale représente un « OU » logique ; le tube représente
un lien plus fort. Chaque nom de paquet est suivi de façon optionnelle par un type
d'architecture entre crochets après deux-points « : », éventuellement suivi par un numéro
de version entre parenthèses « ( » et « ) », une spécification d'architecture entre
crochets « [ » et « ] », et une formule de restriction constituée d'une ou plusieurs
listes de noms de profil entre chevrons « < » et « > ».
La syntaxe des champs Build-Conflicts, Build-Conflicts-Arch et Build-Conflicts-Indep est
une liste de paquets séparés par des virgules qui représentent le « ET » logique et peut
finir par une virgule qui peut être éliminée lors de la création des champs pour
deb-control(5) (depuis dpkg 1.10.14). L'indication de paquets alternatifs avec une barre
verticale (le symbole du tube) « | » n'est pas prise en charge. Chaque nom de paquet peut
être suivi de façon optionnelle par un numéro de version entre parenthèses, un type
d'architecture entre crochets et une formule de restriction constituée d'une ou plusieurs
listes de noms de profil entre chevrons.
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'architecturede construction actuelle si le paquet n'a é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)
Ce champ indique l'architecture matérielle sur laquelle le paquet peut être
utilisé. Les paquets qui peuvent être utilisés sur toute architecture doivent
utiliser le champ any. Les paquets indépendants de l'architecture, tels les scripts
shell ou Perl ou la documentation utilisent la valeur all. Pour restreindre un
paquet à certaines architectures, leurs noms doivent être indiqués séparés par des
espaces. Il est également possible d'utiliser des noms génériques d'architectures
dans cette liste (voir dpkg-architecture(1) pour plus d'informations sur ces
architectures génériques).
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.
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.
Essential: yes|no
Build-Essential: yes|no
Multi-Arch: same|foreign|allowed|no
Tag: liste-d'étiquettes
Description: description-courte (recommandé)
Ces champs sont décrits dans la page de manuel de deb-control(5), car ils sont
copiés littéralement dans le fichier « control » du paquet binaire.
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
Ces champs déclarent les relations entre les paquets. Ils sont discutés dans la
page de manuel de deb-control(5). Quand ces champs se trouvent dans debian/control,
ils peuvent aussi se terminer par une virgule (depuis dpkg 1.10.14) ; ils
comprennent des spécifications d'architecture et des formules de restriction qui
seront réduites lors de la génération des champs pour 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. Veuillez consulter /usr/share/doc/debian-installer/devel/modules.txt
fourni avec le paquet debian-installer pour plus de détails.
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 Ce champ apparaîtra dans le fichier de contrôle du paquet des sources, voir dsc(5).
B Le champ apparaîtra dans le fichier de contrôle du paquet binaire, voir
deb-control(5).
C Le champ apparaîtra dans le fichier de contrôle d'envoi (.changes), voir
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
# Commentaire
Source: dpkg
Section: admin
Priority: required
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
# ce champ est copié dans les paquets source et binaires
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: pkg-config, 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
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>.