Provided by: dpkg-dev_1.21.21ubuntu1_all bug

NOM

       deb-changes - Format des fichiers « .changes » Debian

SYNOPSIS

       nom-du-fichier.changes

DESCRIPTION

       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.

LES CHAMPS

       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.

BOGUES

       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.

VOIR AUSSI

       deb822(5), deb-src-control(5), deb-version(7).

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>.