[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ suivant ]


La Charte Debian
Chapitre 5 - Les fichiers de contrôle et leurs champs

Le système de gestion des paquets manipule les données de la même façon : des données de contrôle sont stockées dans des fichiers de contrôle. Les paquets source et binaire possèdent des fichiers de contrôle ; et les fichiers .changes qui contrôlent l'installation des fichiers sur le serveur (upload) sont aussi des fichiers de contrôle [28].


5.1 La syntaxe des fichiers de contrôle

Un fichier consiste en un ou plusieurs paragraphes comportant des champs [29]. Ces paragraphes sont séparés par des lignes blanches. Certains fichiers de contrôle n'autorisent qu'un seul paragraphe ; d'autres en autorisent plusieurs, et dans ce cas, chaque paragraphe fait souvent référence à un paquet différent. Dans les paquets sources, par exemple, le premier paragraphe se réfère au paquet source et les paragraphes suivants aux paquets binaires créés à partir de ce source.

Chaque paragraphe est une série de champs contenant des données ; chaque champ est constitué d'un nom, suivi par deux-points et la valeur associée. Il se termine à la fin de la ligne (logique). Les espaces horizontaux (espaces et tabulations) peuvent apparaître immédiatement avant la valeur et après, mais là, ils sont ignorés ; par convention, il y a une espace après les deux-points. Voici un exemple de champ :

     Package: libc6

Le nom du champ est Package et la valeur est libc6.

Un grand nombre de valeurs de champ peuvent déborder sur plusieurs lignes ; dans ce cas chaque nouvelle ligne doit commencer par une espace ou une tabulation. Toutes les espaces ou tabulations restantes en fin de ligne sont ignorées.

Dans les champs où il est spécifié que les lignes ne peuvent pas déborder, une seule ligne de données est autorisée et les espaces ne sont pas significatives dans le corps du champ. Les espaces ne doivent jamais apparaître dans les noms (de paquets, d'architectures, de fichiers, etc), dans les numéros de version ou entre les éléments de relations de version à plusieurs caractères.

Les noms de champs sont indépendants de la casse ; en général, ceux-ci sont écrits en commençant par une majuscule puis en mélangeant majuscules et minuscules comme dans les exemples plus bas.

Les lignes vides ou les lignes contenant seulement des espaces ou des tabulations ne sont pas autorisées à l'intérieur des valeurs de champ ou entre les champs - ce qui signifierait un nouveau paragraphe.


5.2 Le fichier de contrôle d'un paquet source : debian/control

Le fichier debian/control contient les informations les plus importantes sur le paquet source et sur les paquets binaires qui sont créés. Elles sont indépendantes des versions.

Le premier paragraphe contient en général les informations sur le paquet source ; chaque ensemble suivant décrit un paquet binaire que l'arbre source construit.

Les champs du paragraphe général (le premier, concernant le paquet source) sont :

Les champs des paragraphes pour les paquets binaires sont :

La syntaxe et la sémantique des champs sont décrites ci-dessous.

Ces champs sont utilisés par dpkg-gencontrol pour créer les fichiers de contrôle pour les paquets binaires (voir ci-dessus), par dpkg-genchanges pour créer le fichier .changes qui accompagne l'installation sur le serveur et par dpkg-source quand il crée le fichier de contrôle source .dsc comme une partie de l'archive source. Il est permis pour un grand nombre de champs de s'étendre sur plusieurs lignes dans debian/control, mais pas dans tout autre fichier de contrôle. Ces outils sont responsables pour supprimer les sauts de ligne de tels champs quand des champs de debian/control sont utilisés pour générer d'autres fichiers de contrôle.

Les champs peuvent contenir des références à des variables, leurs valeurs seront substituées par dpkg-gencontrol, dpkg-genchanges ou dpkg-source quand ils créeront les fichiers de sortie. Voir debian/substvars et le remplacement de variables, Section 4.10 pour des précisions.


5.3 Les fichiers de contrôles des paquets binaires : DEBIAN/control

Le fichier DEBIAN/control contient les informations les plus importantes sur le paquet binaire. Elles sont indépendantes des versions.

Les champs de ce fichier sont :


5.4 Les fichiers de contrôle des sources Debian -- .dsc

Ce fichier contient une série de champs, identifiés et séparés comme les champs dans le fichier de contrôle d'un paquet binaire. Les champs sont listés ci-dessous ; leur syntaxe est décrite ci-dessus dans Les fichiers de contrôle et leurs champs (annexe tirée de l'ancien Packaging Manual), Annexe D.

Le fichier de contrôle du paquet source est créé par dpkg-source quand il crée l'archive source, à partir des autres fichiers dans le paquet source, décrit ci-dessus. Quand on le déballe, il est vérifié par rapport aux autres fichiers et répertoires dans les autres parties du paquet source, comme décrit ci-dessous.


5.5 Les fichiers Debian changes : .changes

Les fichiers .changes sont utilisés par les logiciels de gestion de l'archive Debian pour gérer les mises à jour des paquets. Ils contiennent un paragraphe d'informations provenant du fichier debian/control ainsi que d'autres données concernant le paquet source provenant des fichiers debian/changelog et debian/rules.

Les champs de ce fichier sont les suivants :


5.6 La liste des champs


5.6.1 Source

Ce champ identifie le nom du paquet source.

Dans un fichier principal de contrôle de source ou dans un fichier .changes ou dans un fichier .dsc, ce champ peut ne contenir que le nom du paquet source.

Dans un fichier de contrôle d'un paquet binaire (ou dans un fichier Packages), il peut être suivi par un numéro de version entre parenthèses[30]. Ce numéro de version peut être omis (et il l'est par dpkg-gencontrol) s'il a la même valeur que le champ Version du paquet binaire en question. Le champ lui-même peut être omis d'un fichier de contrôle d'un paquet binaire quand le paquet source possède le même nom et la même version que le paquet binaire.


5.6.2 Maintainer

Ce champ contient le nom du responsable et son adresse électronique. Le nom vient d'abord, suivi par l'adresse électronique entre les signes inférieur et supérieur <> (au format RFC 822).

Si le nom du responsable contient un point alors le champ entier ne fonctionnera pas directement comme une adresse électronique à cause d'un problème dans la syntaxe spécifiée dans la RFC 822 ; un programme utilisant ce champ comme une adresse doit vérifier cela et corriger le problème si nécessaire (par exemple en mettant entre parenthèses le nom et en le déplaçant à la fin, et en amenant l'adresse électronique devant).


5.6.3 Uploaders

Liste les noms et les adresses des co-responsables d'un paquet, s'il y en a. Quand un paquet possède d'autres responsables que celui nommé dans le champ « Maintainer », leurs noms et adresses seront indiqués dans ce champ. Le format est le même que celui du champ « Maintainer », plusieurs entrées seront séparées par des virgules. Actuellement, ce champ est limité à une seule ligne de données. C'est un champ facultatif.

Tout analyseur interprétant le champ Uploaders dans debian/control devrait l'autoriser à s'étendre sur plusieurs lignes[31]. Les sauts de ligne dans un champ Uploaders qui s'étendent sur plusieurs lignes ne sont pas significatifs et les sémantiques du champ sont les mêmes que si les sauts de ligne étaient absents.


5.6.4 Changed-By

Le nom et l'adresse électronique de celui qui a modifié ce paquet. C'est habituellement le nom du responsable du paquet. Toutes les règles qui s'appliquent au champ Maintainer s'appliquent aussi.


5.6.5 Section

Le champ Section représente un secteur d'applications dans laquelle le paquet a été classé (voir Les sections, Section 2.4).

Quand ce champ apparaît dans le fichier debian/control, il donne la valeur du sous-champ Section du champ Files du fichier .changes, et il donne la valeur par défaut de la section pour les paquets binaires.


5.6.6 Priority

Le champ Priority représente l'importance accordée à un paquet. Voyez Les priorités, Section 2.5.

Quand ce champ apparaît dans le fichier debian/control, il donne la valeur du sous-champ Priority du champ Files du fichier .changes, et il donne la valeur par défaut de la priorité pour les paquets binaires.


5.6.7 Package

Le nom du paquet binaire. Les noms de paquet sont constitués de lettres minuscules (a-z), de chiffres (0-9), et des caractères plus (+), moins (-), ainsi que du point (.). Il doit contenir au moins deux caractères et doit commencer par un caractère alphanumérique.


5.6.8 Architecture

Selon le contexte et le fichier de contrôle utilisé, le champ Architecture peut comporter les valeurs suivantes :

Dans le fichier principal debian/control du paquet source, ou dans le fichier de contrôle des paquets sources .dsc, on peut indiquer une liste des architectures (séparées par des espaces) ou bien les valeurs spéciales, any et all.

Utiliser la valeurany indique que le paquet source ne dépend pas d'une architecture particulière et qu'il se compile bien sur toute architecture. Le paquet binaire résultant sera spécifique à l'architecture qui a cours [32].

Utiliser une liste d'architectures indique que le paquet source produira un paquet dépendant de l'architecture et fonctionnera correctement sur toutes les architectures listées [33].

Dans un fichier .changes, le champ Architecture liste la ou les architectures des paquets qui sont installés sur le serveur. Ce sera une liste ; si le source du paquet est aussi installé, l'entrée spéciale source est aussi présente.

Voir debian/rules, le principal script de construction, Section 4.9 pour des informations sur la manière d'obtenir l'architecture pour le processus de construction.


5.6.9 Essential

C'est un champ booléen qui ne peut apparaître que dans un fichier de contrôle d'un paquet binaire ou dans un paragraphe concernant un paquet dans un fichier principal de contrôle de source.

S'il est positionné à yes, le système de gestion des paquets refusera d'enlever ce paquet (bien qu'il puisse être mis à niveau ou remplacé). L'autre valeur possible est no, ce qui est la même chose que de ne pas avoir de champ du tout.


5.6.10 Les champs concernant la relation entre les paquets : Depends, Pre-Depends, Recommends, Suggests, Conflicts, Provides, Replaces, Enhances

Ces champs décrivent les relations du paquet avec les autres paquets. Leurs syntaxe et sémantique sont décrites dans Comment déclarer des relations entre les paquets ?, Chapitre 7.


5.6.11 Standards-Version

Ce champ donne la plus récente version des normes (la charte Debian et les textes associés) à laquelle se conforme le paquet.

Le numéro de version est composé de quatre parties : un numéro de version majeur et un mineur, un niveau de patch majeur et un mineur. Quand les normes changent, exigeant des modifications dans tous les paquets, le numéro majeur est changé. Les changements significatifs, exigeant des évolutions dans de nombreux paquets, sont signalés par un changement du numéro mineur. Le niveau majeur de patch sera modifié pour tout changement limité de la signification des standards. Le niveau de patch mineur sera changé pour toute amélioration légère (typographique, ou autres...) qui ne modifie pas le sens de ce document, ou pour des changements qui n'affectent pas le contenu des paquets.

Seuls les trois premiers chiffres de la version sont significatifs pour le champ Standards-Version, et on peut choisir de donner soit les trois chiffres, soit la formule complète [34].


5.6.12 Version

Ce champ donne le numéro de version d'un paquet. Son format est le suivant : [epoch:]version_amont[-révision_debian]

Les trois composantes sont :

epoch

C'est simplement un entier non signé (souvent petit). Il peut être omis et dans ce cas il est égal à 0. S'il est omis, le champ version_originelle ne peut pas contenir un « : ».

Il sert à permettre les erreurs dans les numéros des vieilles versions d'un paquet, et aussi à abandonner les précédentes structures de numérotation concernant les versions d'un paquet.

version_amont

C'est la partie principale du champ. En général, on utilise le numéro de la version amont (« upstream ») du paquet à partir duquel le fichier .deb a été créé (s'il est utilisable). Le plus souvent, ce champ est dans le même format que celui spécifié par le ou les auteurs amont ; cependant, il peut devoir être reformaté pour s'adapter au format et aux méthodes de comparaison du système de gestion des paquets.

Les méthodes de comparaison du système de gestion des paquets en ce qui concerne la partie version_amont sont décrites ci-dessous. Cette partie est obligatoire.

La partie version_amont ne peut contenir que des caractères alphanumériques [35]et les caractères ., +, - et : (point, plus, trait d'union et deux-points) ; elle commencera par un chiffre. S'il n'y a pas de partie révision_debian alors le trait d'union « - » n'est pas autorisé. S'il n'y a pas de partie epoch alors les « : » ne sont pas autorisés.

révision_debian

Cette partie du champ indique le numéro de version du paquet Debian basé sur la version originelle. Il ne peut contenir que des caractères alphanumériques et les caractères + et . (plus et point) ; les méthodes de comparaison sont les mêmes que pour la partie version_amont.

Cette partie est facultative. Si elle manque, la partie version_amont ne peut contenir de trait d'union. On utilise cette partie quand un morceau de code a été écrit spécialement pour obtenir un paquet Debian. Il n'y a qu'une seule debianisation de ce paquet et aucune indication de révision n'est nécessaire.

Par convention, la partie révision_debian est remis à 1 à chaque fois que la partie version_amont est incrémentée.

Le système de gestion des paquets sépare les parties version_amont et révision_debian au dernier trait d'union de la chaîne. Dans une comparaison, l'absence de la partie révision_debian est détectée plus tôt que sa présence (néanmoins la partie révision_debian est la partie la moins significative du numéro de version).

Le système de gestion des paquets compare les parties version_amont et révision_debian en utilisant le même algorithme.

Les chaînes sont comparées de gauche à droite.

Pour chaque chaîne, une partie initiale composée uniquement de lettres est déterminée. Ces deux parties (l'une peut être vide) sont comparées lexicalement. Si une différence est trouvée, elle est retournée. La comparaison lexicale est une comparaison qui utilise des valeurs ASCII modifiées de manière à ce que toutes les lettres soient classées avant les chiffres et les caractères de ponctuation.

Ensuite, pour ce qui reste de cette chaîne, une partie initiale composée uniquement de chiffres est déterminée. Les valeurs numériques de ces deux parties sont comparées, la différence est retournée comme résultat de la comparaison. Dans ce but, une chaîne vide (qui peut seulement apparaître à la fin de l'une ou des deux chaînes que l'on compare) compte pour zéro.

Ces deux phases sont répétées (comparaison et suppression des caractères et des chiffres se trouvant au début des chaînes) jusqu'à ce qu'une différence soit trouvée ou que les deux chaînes soient terminées.

Le but de la partie epoch est de permettre des erreurs dans la numérotation de version et de s'arranger avec les situations où la numérotation de version change. Il ne sert pas à corriger les numéros de version contenant des chaînes de caractères que le système de gestion des paquets ne peut pas interpréter (tel que ALPHA ou pre-) ou une numérotation bâtarde (l'auteur de ce manuel a entendu parler d'un paquet dont les versions allaient ainsi : 1.1.1.2, 1.3, 1, 2.1, 2.2, 2 et ainsi de suite).


5.6.13 Description

Le champ Description dans le fichier de contrôle d'un paquet source ou binaire comprend deux parties, le résumé ou courte description et la description étendue. Le format de ce champ est le suivant :

            Description: <résumé sur une seule ligne>
             <description étendue sur plusieurs lignes>

Les lignes de la description étendue peuvent suivre ces formats :

N'utilisez pas le caractère de tabulation, son effet est imprévisible.

Voyez La description d'un paquet, Section 3.4 pour des informations supplémentaires.

Dans un fichier .changes, le champ Description contient les résumés des descriptions des paquets déposés sur le serveur.

La partie du champ située avant le premier retour à la ligne est vide ; chaque ligne comprend donc le nom du paquet binaire et sa ligne de résumé. Chaque ligne commence par une espace.


5.6.14 Distribution

Dans un fichier .changes ou affiché par l'analyse d'un changelog, ce champ contient les noms (séparés par des espaces) des distributions dans lesquelles cette version du paquet sera installée. Les noms de distribution sont déterminés par les responsables de l'archive [37].


5.6.15 Date

Ce champ donne la date de la construction de paquet ou de la dernière édition.

Sa valeur est tirée du fichier debian/changelog - voyez Changelog Debian : debian/changelog, Section 4.4.


5.6.16 Format

Ce champ indique une révision de format pour le fichier. Le format décrit ici est la version 1.5. La syntaxe de la valeur du format est la même que la numérotation de la version des paquets, sauf que epoch et la révision Debian ne sont pas autorisés - voir La version d'un paquet, Section 3.2.


5.6.17 Urgency

Ce champ décrit l'importance de la mise à jour de cette version par rapport aux autres versions. Il contient un simple mot-clé qui prend habituellement une de ces valeurs low, medium ou high (peu importe la casse) suivie par un commentaire optionnel (séparé par une espace) qui est généralement entre parenthèses. Par exemple :

     Urgency: low (HIGH pour les utilisateurs de diversions)

La valeur de ce champ est habituellement tirée du fichier debian/changelog - voyez Changelog Debian : debian/changelog, Section 4.4.


5.6.18 Changes

Ce champ contient les données lisibles des changements, décrivant les différences entre la dernière version et celle courante.

Il ne doit rien y avoir dans ce champ avant le première nouvelle ligne ; toutes les lignes suivantes doivent être indentées d'au moins une espace ; les lignes vides doivent être représentées par une ligne contenant seulement une espace et un point.

La valeur de ce champ est habituellement tirée du fichier debian/changelog – voyez Changelog Debian : debian/changelog, Section 4.4.

Chaque information de changement de version doit être précédée par une ligne de titre donnant au moins la version, la ou les distributions et l'urgence, d'une façon lisible.

Si les données de plusieurs versions sont retournées, l'entrée de la plus récente version doit être retournée d'abord, et les entrées doivent être séparées par une ligne vide (la ligne de titre peut aussi être suivie par une ligne vide).


5.6.19 Binary

Ce champ est une liste de paquets binaires.

Quand il apparaît dans un fichier .dsc, il représente la liste des paquets binaires qu'un paquet source peut produire. Il ne produit pas nécessairement tous ces paquets binaires pour chaque architecture. Le fichier de contrôle source ne contient pas les détails sur les architectures qui sont les plus appropriées pour les paquets binaires.

Quand il apparaît dans un fichier .changes, il liste les noms des paquets binaires actuellement installés sur le serveur.

La syntaxe est une liste de paquets binaires séparée par des virgules[38]. Actuellement, les paquets doivent être séparés en utilisant seulement des espaces dans le fichier .changes.


5.6.20 Installed-Size

Ce champ apparaît dans les fichiers de contrôle des paquets binaires, et dans les fichiers Packages. Il donne la capacité totale du disque nécessaire pour installer le paquet.

L'espace disque est représenté en Kilo-octets comme un nombre décimal simple.


5.6.21 Files

Ce champ contient la liste des fichiers avec des informations sur chacun d'eux. L'information exacte et la syntaxe exacte varient avec le contexte. Dans tous les cas, la partie du contenu du champ sur la même ligne que le nom du champ est vide. Le reste du champ est une ligne par fichier, chaque ligne est indentée par une espace et contient un nombre de sous-champs séparés par des espaces.

Dans le fichier .dsc (contrôle des sources Debian), chaque ligne contient la somme de contrôle MD5, la taille et le nom du fichier tar et (éventuellement) le fichier diff qui représente le reste du paquet source[39]. Les formes exactes des noms de fichier sont décrites dans Les paquets sources en tant qu'archive, Section C.3.

Dans le fichier .changes, il contient une ligne par fichier chargé. Chaque ligne contient la somme de contrôle, la taille, la section et la priorité et le nom du fichier. La section et la priorité sont les valeurs des champs correspondants dans le fichier principal de contrôle des sources. Si aucune section ou priorité n'est spécifiée alors - doit être utilisé, bien que les valeurs de section et de priorité doivent être spécifiées pour installer correctement les nouveaux paquets.

La valeur spéciale byhand pour la section dans un fichier .changes indique que le fichier en question n'est pas un fichier ordinaire de paquet et doit être installé à la main par les responsables de la distribution. Si la valeur de la section est byhand alors la valeur de la priorité devrait être -.

Si une nouvelle révision Debian d'un paquet est chargée et qu'aucune archive originale source n'est distribuée, le fichier .dsc doit toujours contenir l'entrée du champ Fields pour l'archive originale source package-upstream-version.orig.tar.gz mais le fichier .changes devrait l'omettre. Dans ce cas, l'archive originale source sur le site de distribution doit être exactement, octet par octet, l'archive originale source qui a été utilisée pour créer le fichier .dsc et le fichier diff qui a été installé sur le serveur.


5.6.22 Closes

Une liste de numéros de rapport de bogues séparés par des espaces qui sont fermés par le téléchargement défini par le fichier .changes.


5.7 Champs définis par l'utilisateur

Des champs utilisateurs supplémentaires peuvent être ajoutés au fichier de contrôle du paquet source. Ces champs seront ignorés, ne seront pas copiés dans les fichiers de contrôle des paquets sources ou binaires (par exemple) ou dans les fichiers de contrôle de l'installation sur le serveur.

Quand on souhaite ajouter des champs supplémentaires non reconnus par ces fichiers de sortie, on utilisera le mécanisme décrit ci-dessous.

Les champs du fichier principal de contrôle de source avec des noms commençant par X, suivis par une ou plusieurs lettres BCS et un trait d'union -, seront copiés vers les fichiers de sortie. Seule la partie du nom du champ qui se trouve après le trait d'union sera utilisée dans le fichier de sortie. Si la lettre B est utilisée, le champ apparaîtra dans les fichiers de contrôle des paquets binaires, si c'est la lettre S, dans les fichiers de contrôle de paquet source, et si c'est la lettre C, dans les fichiers de contrôle de l'installation sur le serveur (.changes).

Par exemple, le fichier principal de contrôle de source contient le champ suivant :

        XBS-Comment: I stand between the candle and the star.

alors les fichiers de contrôle des paquets sources et binaires contiendront le champ :

     Comment: I stand between the candle and the star.

[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ suivant ]


La Charte Debian

version 3.7.2.2

La liste de diffusion Debian-Policy