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.
- DM-Upload-Allowed: yes|no
- Ce champ indique si un paquet peut être envoyé
par les responsables Debian qui sont indiqués dans le champ
Maintainer ou le champ Uploaders. La valeur par défaut est
« no ».
- 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
- 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 aussi installés. Ce champ a été ajouté dans
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
source uniquement (« 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
a été ajouté dans 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
successifs. Chaque groupe est une liste de paquets séparés par une
barre verticale (le symbole du tube) « | ». Les groupes
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 représente un lien plus
fort. Chaque élément est le nom d'un paquet suivi de façon
optionnelle par un numéro de version entre parenthèses et une
indication d'architecture entre accolades.
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.
L'indication de paquets alternatifs avec une barre verticale (le symbole du
tube) « | » n'est pas prise en charge. Chaque om de paquet
peut être suivi de façon optionnelle par un numéro de version
entre parenthèses et une indication d'architecture entre accolades.
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 à.
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.
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: http://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>.