deb-changes - Format des fichiers
« .changes » Debian
Chaque envoi dans Debian est composé d'un fichier de
contrôle .changes qui contient un certain nombre de champs au format
deb822(5).
Chaque champ commence par une étiquette, telle que
Source ou Binary (la casse n'importe pas), suivie d'un
« : », et du contenu du champ (sensible à
la casse à moins que cela ne soit spécifié autrement).
Les champs sont séparés seulement par des étiquettes de
champ. En d'autres termes, le contenu d'un champ peut s'étendre sur
plusieurs lignes, mais les outils d'installation joindront en
général les lignes pendant le traitement du contenu du champ
(sauf pour les champs à lignes multiples Description,
Changes, Files, Checksums-Sha1 et
Checksums-Sha256, voir ci-dessous).
Les données de contrôle pourraient être
incluses dans une signature OpenPGP « ASCII
Armored », comme spécifié dans la RFC4880.
- Format:
version-format (requis)
- La valeur de ce champ déclare la version du format du fichier. La
syntaxe de la valeur du champ est un numéro de version avec un
composant majeur et mineur. Les modifications incompatibles avec les
versions précédentes du format incrémenteront la
version majeure, tandis que les modifications compatibles (telles que les
ajouts de champ) incrémenteront la version mineure. La version de
format actuelle est 1.8.
- Date:
date-publication (requis)
- La date à laquelle le paquet a été construit ou
modifié pour la dernière fois. Elle doit avoir le
même format que la date dans l'entrée de
deb-changelog(5).
La valeur de ce champ est habituellement extraite du fichier
debian/changelog.
- Source:
nom-source [(version-source)] (requis)
- Le nom du paquet source. Si la version du source diffère de la
version binaire, alors le nom-source sera suivi par une
version-source entre parenthèses. Cela peut arriver quand il
s'agit d'un envoi seulement binaire NMU (« non-maintainer
upload »).
- Binary:
liste-paquets-binaires (requis selon le contexte)
- Ce champ coupé est une liste, séparée par des
espaces, de paquets binaires à envoyer. Si l'envoi ne concerne que
les sources, le champ est omis (depuis dpkg 1.19.3).
- Architecture:
liste-architectures
- Liste des architectures des fichiers actuellement envoyés. Voici
quelques architectures habituelles : amd64, armel,
i386, etc. Remarquez que l'option all signifie que le paquet
est indépendant de toute architecture. Si les sources du paquet
sont également envoyées, l'entrée spéciale
source est aussi présente. Les architectures joker ne
doivent jamais être présentes dans la liste.
- Version:
chaîne-de-la-version (requis)
- C'est classiquement le numéro de version du paquet d'origine dans
la forme choisie par l'auteur du programme. Il peut y avoir aussi un
numéro de révision Debian (pour les paquets non natifs). Le
format exact et l'algorithme de tri sont décrits dans
deb-version(7).
- Distribution:
distributions (requis)
- Liste une ou plusieurs distributions, séparées par des
espaces, dans lesquelles cette version peut être installée
après envoi dans l'archive.
- Urgency:
urgence (recommandé)
- L'urgence de l'envoi. Les valeurs actuelles reconnues sont, par ordre
croissant d'urgence : low, medium, high,
critical et emergency.
- Maintainer:
nom-complet-et-adresse-électronique (requis)
- Le format de ce champ sera « Jean Dupont
<jdupont@example.org> » ; et c'est bien sûr le
créateur du paquet, par opposition à l'auteur du programme
mis en paquet.
- Changed-By:
nom-complet-et-adresse-électronique
- Le format de ce champ sera « Jean Dupont
<jdupont@example.org> » ; et c'est bien sûr
celui qui a préparé les modifications du paquet pour cette
version.
- Description:
(recommandé)
- nom-du-paquet-binaire -
résumé-du-paquet-binaire
- Ce champ à lignes multiples contient une liste de noms de paquets
binaires suivis d'une espace, d'un tiret
(« - ») et de leur description courte
éventuellement tronquée. Si l'envoi ne concerne que les
sources, le champ est omis (depuis dpkg 1.19.3).
- Closes:
liste-numéros-bogue
- Une liste de numéros de rapports des bogues séparés
par des espaces qui ont été résolus par cet envoi. Le
logiciel d'archive de la distribution pourrait utiliser ce champ pour
fermer automatiquement les bogues dont les numéros sont
référencés dans le système de suivi de bogues
(BTS) de la distribution.
- Binary-Only:
yes
- Ce champ indique que l'envoi est une construction seulement binaire
indépendante (NMU). Il est issu de la paire clé/valeur
binary-only=yes de l'entrée metadata du changelog.
- Built-For-Profiles:
liste-de-profils
- Ce champ définit une liste, séparée par des espaces,
de profils de construction avec lesquels cet envoi a été
construit.
- Changes:
(requis)
- entrées-du-journal-des-modifications
- Ce champ à lignes multiples fournit le texte
concaténé de toutes les entrées de changelog faisant
partie de cet envoi. Pour rendre ce champ à lignes multiples
valable, les lignes vides sont remplacées par un point
« . » et toutes les lignes sont
indentées par une seule espace. Le contenu exact dépend du
format du changelog.
- Files:
(requis)
- md5sum taille section priorité
nom-de-fichier
- Ce champ à lignes multiples fournit une liste de fichiers avec la
md5sum, la taille, la section et la priorité de chacun.
La première ligne de la valeur du champ (la partie sur
la même ligne que le nom du champ suivi par deux-points) est
toujours vide. Le contenu du champ est exprimé sous la forme de
lignes de continuation, un ligne par fichier. Chaque ligne consiste en
des entrées, séparées par des espaces,
décrivant le fichier : la md5sum, la taille du fichier, sa
section, sa priorité et son nom.
Ce champ liste tous les fichiers qui composent l'envoi. La
liste de fichiers de ce champ doit correspondre à celle
présente dans les autres champs relatifs aux
Checksums.
- Checksums-Sha1:
(requis)
- Checksums-Sha256:
(requis)
- somme-de-contrôle taille
nom-du-fichier
- Ces champs à lignes multiples fournissent une liste de fichiers
avec la somme de contrôle et la taille de chacun. Ces champs ont la
même syntaxe et ne diffèrent que par l'algorithme de somme
de contrôle utilisé : SHA-1 pour
Checksums-Sha1 et SHA-256 pour Checksums-Sha256.
La première ligne de la valeur du champ (la partie sur
la même ligne que le nom du champ suivi par deux-points) est
toujours vide. Le contenu du champ est exprimé par des lignes de
continuation, une ligne par fichier. Chaque ligne consiste en des
entrées séparées par des espaces décrivant
le fichier :la somme de contrôle, la taille du fichier et
le nom du fichier.
Ces champs listent tous les fichiers qui composent l'envoi. La
liste de fichiers de ce champ doit correspondre à celle
présente dans le champ Files et les autres champs relatifs
aux Checksums.
Le champ Files n'est pas cohérent avec des autres
champs Checksums. Les champs Changed-By et Maintainer
ont des noms qui provoquent la confusion. Le champ Distribution
fournit des informations sur ce à quoi une suite fait
référence habituellement.
Ariel VARDI <ariel.vardi@freesbee.fr>, 2002. Philippe
Batailler, 2006. Nicolas François, 2006. Veuillez signaler toute
erreur à <debian-l10n-french@lists.debian.org>.