Provided by: dpkg-dev_1.17.5ubuntu5.8_all 
NOM
deb-src-control - Format du fichier principal de contrôle dans les paquets Debian
SYNOPSIS
contrôle
DESCRIPTION
Chaque paquet source Debian contient un fichier « control » maître, qui contient au moins
2 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 multi-lignes sont aussi possibles, mais chaque ligne supplémentaire,
qui ne comporte pas de nom de champ, doit commencer par au moins un espace. Le contenu des
champs multi-lignes 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
multi-lignes, il est nécessaire de mettre un point après l'espace initial. Les lignes
commençant pas « # » 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.
Maintainer: nom complet et adresse électronique (requis)
Le format de ce champ sera « Jean Dupont <jdupont@foo.com> » ; et indique le
créateur du paquet, par opposition à l'auteur du programme mis en paquet.
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 une virgule.
Standards-Version: chaîne de version
Ce champ indique la version la plus récente des normes (constituées par la Charte
Debian et les textes indiqués dans le paquet debian-policy) auxquelles ce paquet se
conforme.
Homepage: URL
URL de la page d'accueil du projet amont.
Bugs: URL
Indique 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.
Vcs-*: 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
les programmes 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 Debian (« Debian Policy »). On peut en trouver une liste dans la
version la plus récente du paquet debian-policy.
Build-Depends: liste-de-paquets
Liste de paquets à installer et configurer pour pouvoir construire le paquet
source. 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-Depends-Arch et Build-Depends-Indep, en
ayant de plus l'effet d'être prise en compte pour les constructions de paquets
source uniquement (« source-only builds »).
Build-Depends-Arch:liste-de-paquets
Same as Build-Depends, but they are only needed when building the architecture
dependent packages. The Build-Depends are also installed in this case. This field
is supported since dpkg 1.16.4; in order to build with older dpkg versions,
Build-Depends should be used instead.
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 source
uniquement (« source-only builds »).
Build-Conflicts-Arch: liste de paquets
Same as Build-Conflicts, but only when building the architecture dependent
packages. This field is supported since dpkg 1.16.4; in order to build with older
dpkg versions, Build-Conflicts should be used instead.
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. Commas are to
be read as "AND", and pipes as "OR", with pipes binding more tightly. Each package name is
optionally followed by a version number specification in parentheses, an architecture
specification in square brackets, and a profile specification in angle brackets.
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".
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 profile specification in angle brackets.
Un 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 à.
An architecture specification consists of one or more architecture names, separated by
whitespace. Exclamation marks may be prepended to each of the names, meaning "NOT".
A profile specification consists of one or more profile names, prefixed with the
"profile." namespace, separated by whitespace. Exclamation marks may be prepended to each
of the names, meaning "NOT".
Veuillez noter que les dépendance 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.
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).
Package-Type: deb|udeb
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.
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.
Veuillez consulter /usr/share/doc/debian-installer/devel/modules.txt fourni avec le
paquet debian-installer pour plus de détails.
Essential: yes|no
Multi-Arch: same|foreign|allowed
Tag: liste-d'étiquettes
Description: description courte (requis)
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 indiquent les relations entre les paquets. Ils sont détaillés dans la
page de manuel deb-control(5) et dans le paquet debian-policy.
LES CHAMPS UTILISATEUR
Il est possible d'ajouter des champs définis par l'utilisateur au fichier « control ». Les
outils les ignoreront. Si ces champs doivent être copiés vers les fichiers créés, par
exemple les paquets binaires, il est indispensable d'utiliser un schéma de nommage
personnalisé : les champs doivent commencer par la lettre X suivie de l'une des lettres B,
C ou S et d'un tiret. Si la lettre B est utilisée, le champ sera copié dans le fichier
« control » du paquet binaire, voir deb-control(5). Avec la lettre S, le champ sera copié
dans le fichier « control » du paquet source créé par dpkg-source(1). Enfin, la lettre C
provoquera la recopie du champ dans le fichier de contrôle de l'envoi (« .changes »). Les
préfixes X[BCS]- sont supprimés lors de ces recopies. Ainsi, un champ XC-Approved-By
apparaîtra sous le nom Approved-By dans le fichier « changes » mais pas dans le fichier
« control » du paquet binaire ni dans celui du paquet source.
Il est conseillé de tenir compte que ces champs définis par l'utilisateur se serviront de
l'espace de nommage global et peuvent ainsi, dans le futur, entrer en collision avec des
champs gérés globalement. Pour éviter de telles situations, il est conseillé de les
préfixer avec Private- (exemple : XB-Private-New-Field) ce qui aura pour effet de bord de
ne pas provoquer d'avertissement de la part de dpkg-deb.
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: http://git.debian.org/?p=dpkg/dpkg.git
Vcs-Git: git://git.debian.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(5), 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>.