Beaucoup d'outils de la suite dpkg manipulent les données dans un format commun, connu sous le nom de fichiers de contrôle. Les paquets source et binaire ont des données de contrôle comme les fichiers .changes qui contrôlent l'installation des fichiers sur le serveur, et les bases de données internes à dpkg sont dans un format similaire.
Un fichier consiste en un ou plusieurs paragraphes comportant des champs. 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.
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. Les espaces horizontaux (espaces et tabulations) peuvent apparaître immédiatement avant la valeur ou après, mais là, ils sont ignorés ; par convention, il y a un espace après les deux-points.
Certaines valeurs de champ peuvent déborder sur plusieurs lignes ; dans ce cas chaque nouvelle ligne doit commencer par un espace ou une tabulation. Tous les espaces ou tabulations restants en fin de ligne sont ignorés.
Sauf indications contraires, une seule ligne de données est autorisée et les espaces ne sont pas significatifs 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.
Il est important de noter que plusieurs champs sont facultatifs pour ce qui
concerne dpkg
et ses outils associés ; mais ils doivent apparaître
dans chaque paquet Debian, et leur omission peut entraîner des problèmes.
Quand on écrit des fichiers de contrôle pour les paquets Debian, on
doit lire la charte Debian en même temps que les détails ci-dessous et
la liste des champs pour un fichier particulier.
Le nom du paquet binaire. Les noms de paquet sont constitués de caractères alphanumériques et des caractères +, -, . (plus, moins, point)[77].
Ils doivent contenir au moins deux caractères et commencer par un caractère alphanumérique. Dans la version courante de dpkg, ils sont triés par ordre alphabétique en tenant compte des majuscules [78]; utilise des noms de paquets en minuscule à moins que le paquet que tu construis (ou est référencé dans d'autres champs) utilise déjà des majuscules.
Ce champ donne le numéro de version des paquets source ou binaire - voir La numérotation des versions, Chapter 4.
Ce champ est une chaîne de caractères correspondant à une architecture ; c'est un simple mot pour l'architecture Debian.
dpkg
comparera l'architecture déclarée d'un paquet binaire avec sa
propre valeur compilée avant de l'installer.
La valeur spéciale all indique que le paquet est indépendant de l'architecture.
Dans le fichier principal debian/control du paquet source, ou dans le fichier de contrôle des paquets sources .dsc, une liste des architectures (séparée par des espaces) est aussi autorisée, tout comme la valeur spéciale any. Une liste indique que le source construira un paquet dépendant de l'architecture, et fonctionnera correctement seulement sur les architectures listées. any indique que même si le paquet source n'est pas dépendant d'une architecture particulière et devrait bien se compiler sur n'importe laquelle, les paquets binaires produits ne sont pas indépendants des architectures mais sera par contre spécifique à l'architecture courante de construction.
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 script principal de construction, Section C.2.1 pour des informations sur la manière d'obtenir l'architecture pour le processus de construction.
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 RFC822).
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 RFC822 ; 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).
Le fichier .changes ou les données analysées de changelog contiennent le nom et l'adresse électronique de la personne responsable de cette version particulière - ce n'est pas forcément le responsable habituel du paquet.
Ce champ est habituellement facultatif tant qu'il concerne dpkg, mais son absence provoque généralement un avertissement lors de la construction de paquets.
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 ou dans les données analysées de changelog, ce champ peut seulement contenir 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[79]. Ce numéro de version peut être omis (et 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.
Ces champs décrivent les relations du paquet avec les autres paquets. Leurs syntaxes et sémantiques sont décrites dans Comment déclarer des relations entre les paquets ?, Chapter 7.
Dans un paquet binaire, dans le fichier Packages ou le fichier principal de contrôle du source, ce champ contient une description du paquet binaire, dans un format spécial. Voir La description des paquets - le champ Description, Section 5.7 pour des précisions.
Dans un fichier .changes, il contient un résumé de la description des paquets installés sur le serveur. La partie du champ avant la première nouvelle ligne est vide ; ensuite chaque ligne possède le nom d'un paquet binaire et la ligne de résumé de la description de ce paquet binaire. Chaque ligne est indentée par un espace.
C'est un champ booléen qui peut apparaître seulement dans un fichier de contrôle d'un paquet binaire (ou dans le fichier Packages) ou dans un paragraphe concernant les champs d'un paquet dans un fichier principal de contrôle de source.
S'il est positionné à yes, dpkg et dselect refuseront d'enlever ce paquet (bien qu'il puisse être mis à niveau et/ou déplacer). L'autre valeur possible est no, ce qui est la même chose que de n'avoir pas de champ du tout.
Ces deux champs classent le paquet. La Priority représente l'importance du paquet installé ; la Section représente un secteur d'applications dans laquelle le paquet a été classé.
Quand ces champs apparaissent dans le fichier debian/control, ils donnent les valeurs des sous-champs priorité et section du champ Files du fichier .changes, et donnent les valeurs par défaut de la section et de la priorité pour les paquets binaires.
La section et la priorité sont représentées (mais pas comme des champs séparés) dans les informations pour chaque fichier dans le champ -File d'un fichier .changes. La valeur de la section dans un fichier .changes est utilisée pour décider où sera installé le paquet dans une archive FTP.
Ces champs ne sont pas utilisés par dpkg, mais par dselect quand il trie les paquets et sélectionne la valeurs par défaut. Voir la charte Debian pour les priorités en usage et les critères pour sélectionner les priorités pour les paquets Debian ; et regarder une archive FTP Debian pour obtenir la liste actuelle des priorités.
Ces champs peuvent apparaître dans les fichiers de contrôle des paquets binaires, dans ce cas, ils fournissent une valeur par défaut au cas où les fichiers Packages ne possèdent pas l'information. dpkg et dselect n'utiliseront seulement la valeur d'un fichier .deb que s'ils n'ont pas d'autres informations ; une valeur listée dans un fichier Packages sera toujours prioritaire. Par défaut dpkg-genchanges n'inclut pas la section et la priorité dans le fichier de contrôle d'un paquet binaire - utilise les options -isp,-is ou -ip pour réaliser cette opération.
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[80]. Actuellement, les paquets doivent être séparés en utilisant seulement des espaces dans le fichier .changes.
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.
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 un 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[81]. 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 source - voir Section et Priority, Section D.2.9.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.
Ce champ contient la version la plus récente des standards (la charte Debian le manuel du programmeur dpkg et les textes associés) auxquels le paquet se conforme. Le champ est mis à jour manuellement lors de l'édition du paquet source pour se conformer aux nouveaux standards ; il peut parfois être utilisé pour signaler qu'un paquet a besoin d'une attention particulière.
Son format est le même que le numéro de version sauf que epoch et la révision Debian ne sont pas autorisés - voir La numérotation des versions, Chapter 4.
Dans un fichier .changes ou dans la sortie analysée de changelog, ce champ contient le ou les noms (séparés par des espaces) de la ou des distributions où cette version du paquet devrait être ou a été installée. Les noms de distribution suivent les règles des noms de paquets (voir Package, Section D.2.1).
Les valeurs des distributions actuelles sont :
On listera toutes les distributions où le paquet sera installé. Sauf dans des circonstances inhabituelles les installations vers stable doivent aussi aller dans frozen(si elle existe) et dans unstable. De même, les installations dans frozen iront aussi dans unstable.
Ce champ est une description de l'importance d'une mise à jour d'une version à l'autre. Il contient un simple mot-clé qui prend habituellement une de ces valeurs LOW, MEDIUM ou HIGH suivi par un commentaire optionnel (séparé par un espace) qui est généralement entre parenthèses. Par exemple :
Urgency: LOW (HIGH for diversions users)
Ce champ apparaît dans le fichier .changes et dans les changelogs analysées ; sa valeur apparaît comme valeur de l'attribut urgency dans le changelog de dpkg-style (voir debian/changelog, Section C.2.3).
Les mot-clé ne tiennent pas compte de la casse.
Dans les fichiers .changes et les changelogs analysables, ce champ donne la date de la construction de paquet ou de la dernière édition.
Le champ apparaît dans les fichiers .changes, et spécifie 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 numérotation des versions, Chapter 4.
Dans un fichier .changes ou dans un changelog analysable, 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 par au moins un espace ; les lignes vides doivent être représentées par une ligne contenant seulement un espace et un point.
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ées d'abord, et les entrées doivent être séparées par une ligne vide (la ligne de « titre » peut aussi être suivi par une ligne vide).
Ces champs dans les fichiers Packages donnent les noms de fichiers d'un paquet dans une distribution, par rapport à la racine de la hiérarchie Debian. Si le paquet a été découpé en plusieurs morceaux, les parties sont toutes listées dans l'ordre, séparées par des espaces.
Ces champs dans les fichiers Packages donnent la taille (en octets, exprimée en décimal) et la somme de contrôle MD5 du ou des fichiers qui composent le paquet de la distribution. Si le paquet est découpé en plusieurs parties, les valeurs pour ces parties sont listées dans l'ordre, séparées par des espaces.
Ce champ dans le fichier status de dpkg enregistre si l'utilisateur veut un paquet installé, enlevé ou laissé tout seul, s'il est défectueux (nécessite une réinstallation) ou non et son état actuel sur le système. Chaque partie de ces informations est un simple mot.
Si un paquet n'est pas installé, ou non configuré, ce champ dans le fichier status de dpkg enregistre la dernière version de ce paquet qui a été configurée avec succès.
Ce champ dans le fichier status de dpkg contient des informations sur les fichiers de configuration automatiquement gérés et maintenus par un paquet. Ce champ ne doit pas apparaître n'importe où dans un paquet !
Ils sont toujours reconnus par dpkg mais ne doivent plus apparaître n'importe où.
La Charte Debian
version 3.5.6.1 cvs 1.68 03/2002ijackson@gnu.ai.mit.edu
schwarz@debian.org
bweaver@debian.org
debian-policy@lists.debian.org