deb-src-control(5) | dpkg suite | deb-src-control(5) |
deb-src-control - Format du fichier principal de contrôle dans les paquets source Debian
debian/control
Chaque paquet source Debian contient le fichier « debian/control » principal au format deb822(5) dont le fichier control fourni dans les paquets binaires Debian est un sous-ensemble, voir deb-control(5).
Ce fichier 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 (la casse est significative à moins que cela ne soit spécifié autrement) 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 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).
Les champs Section et Priority possèdent un ensemble défini de valeurs acceptées, tiré de la Charte particulière de la distribution.
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'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.
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.
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.
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.
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).
# 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.
/usr/share/doc/dpkg/spec/rootless-builds.txt, deb822(5), deb-control(5), deb-version(7), dpkg-source(1)
Ariel VARDI <ariel.vardi@freesbee.fr>, 2002. Philippe Batailler, 2006. Nicolas François, 2006. Veuillez signaler toute erreur à <debian-l10n-french@lists.debian.org>.
2023-05-11 | 1.21.22 |