# 6. Meilleures pratiques d'empaquetage

La qualité de Debian est largement due à la Charte Debian qui définit explicitement les exigences de base que tous les paquets Debian doivent satisfaire. Cependant, il existe également une expérience générale partagée qui va bien au delà de la Charte Debian et constitue une somme d'années d'expérience dans l'empaquetage. De nombreux contributeurs talentueux ont créé d'excellents outils qui peuvent vous aider, en tant que mainteneur Debian, à créer et maintenir des paquets d'excellente qualité.

Ce chapitre rassemble les meilleures pratiques pour les responsables Debian. La majorité de son contenu est constituée de recommandations plus que d'obligations. Il s'agit essentiellement d'informations subjectives, d'avis et de pointeurs, rassemblés par les développeurs Debian. Il est conseillé d'y choisir ce qui vous convient le mieux.

## 6.1. Meilleures pratiques pour `debian/rules`

Les recommandations qui suivent s'appliquent au fichier `debian/rules`. Comme ce fichier contrôle le processus de construction des paquets et fait le choix des fichiers qui entreront dans ce paquet (directement ou indirectement), il s'agit du fichier dont les responsables s'occupent généralement le plus.

### 6.1.1. Scripts d'assistance

La motivation pour utiliser des scripts d'assistance dans `debian/rules` est de permettre aux mainteneurs de définir puis utiliser une logique commune pour de nombreux paquets. Si on prend par exemple l'installation d'entrées de menu, il est nécessaire de placer le fichier dans `/usr/share/menu` (ou `/usr/lib/menu` pour les fichiers de menu exécutables, si besoin), puis d'ajouter des commandes aux scripts des responsables pour ajouter ou enlever les entrées de menu. Comme cette action est commune à de très nombreux paquets, pourquoi faudrait-il que chaque responsable doivent réécrire ses propres méthodes, bogues compris ? De plus, si jamais le répertoire des menus venait à changer, chaque paquet devrait être modifié.

Les scripts d'assistance s'occupent de ce type de tâche. À condition de suivre les conventions utilisées par le script d'assistance, celui-ci s'occupe de tous les détails. Les modifications dans la Charte peuvent alors être implémentées dans le script d'assistance et les paquets n'ont plus qu'à être reconstruits sans autre modification.

Aperçu des outils du responsable Debian contient un certain nombre d'assistants variés. Le système le plus répandu et (de l'avis général) le plus adapté est `debhelper`. Des systèmes antérieurs, tels que `debmake`, étaient monolithiques : ils ne permettaient pas de choisir quelle partie de l'assistant serait utile et obligeaient à se servir de l'ensemble de l'assistant. A contrario, `debhelper` est constitué d'un grand nombre de petits programmes `dh_*` différents. Par exemple, `dh_installman` installe et compresse les pages de manuel, `dh_installmenu` installe les fichiers de menu, et ainsi de suite. En conséquence, il offre la possibilité d'utiliser certains des scripts d'assistance tout en conservant des commandes manuelles dans `debian/rules`.

You can get started with `debhelper` by reading debhelper(7) and looking at the examples that come with the package. `dh_make`, from the `dh-make` package (see dh-make), can be used to convert a vanilla source package to a `debhelper`ized package. This shortcut, though, should not convince you that you do not need to bother understanding the individual `dh_*` helpers. If you are going to use a helper, you do need to take the time to learn to use that helper, to learn its expectations and behavior.

### 6.1.2. Paquets binaires multiples

Un paquet source unique construira souvent plusieurs paquets binaires, soit pour fournir plusieurs variantes du même logiciel (par exemple, le paquet source `vim`) ou pour créer plusieurs petits paquets à la place d'un seul grand paquet (par exemple, l'utilisateur peut installer uniquement le sous-ensemble nécessaire et ainsi économiser de l'espace disque, voir par exemple le paquet source `libxml2`).

Le second cas est simple à gérer dans le fichier `debian/rules`. Il suffit de déplacer les fichiers nécessaires depuis le répertoire de construction vers l'arborescence temporaire du paquet. Cela peut se faire avec les commandes `install` ou `dh_install` du paquet `debhelper`. Veillez alors à contrôler les différentes permutations des paquets, afin de pouvoir indiquer les dépendances inter-paquets appropriées dans `debian/control`.

Le premier cas est plus délicat à gérer, car il implique des recompilations multiples du même logiciel avec différentes options de configuration. Le paquet source `vim` en est un exemple, l'ensemble des actions dans le fichier `debian/rules` étant géré manuellement.

## 6.2. Meilleures pratiques pour `debian/control`

Les conseils qui suivent sont destinés au fichier `debian/control`. Ils complètent la Charte Debian concernant les descriptions de paquets.

La description d'un paquet telle que définie par le champ correspondant du fichier `control`, comprend à la fois le résumé et la description longue du paquet. Conseils généraux pour les descriptions de paquets donne des indications communes à ces deux parties, Résumé, ou description courte, d'un paquet donne des indications spécifiques pour le résumé et Description longue donne des indications pour la description.

### 6.2.1. The package name

The package name:

- Must be consistent with widely established conventions, e.g.

  - C and C++ libraries are typically prefixed with lib

  - for many other languages, package names are prefixed or a suffixed with the language name (the actual convention depends on the language).

- Should not be a common, unqualified word. In particular, words that represent a whole class of applications (e.g. reader, browser) should be reserved for virtual packages.

- Should ideally be at least 4 characters long, unless the upstream name is shorter than that and the project is already widely recognized by that name (e.g. fzf).

### 6.2.2. Conseils généraux pour les descriptions de paquets

La description d'un paquet doit être écrite pour son utilisateur moyen, c'est-à-dire la personne qui utilisera et tirera profit du paquet. Par exemple, les paquets de développement sont destinés aux développeurs et leur description peut comporter des détails techniques alors que les applications d'usage plus général, telles que les éditeurs, doivent avoir une description accessible à tout utilisateur.

Un examen général des descriptions de paquets tend à montrer que la plupart d'entre elles ont une orientation fortement technique et ne sont donc pas destinées à l'utilisateur moyen. Sauf dans le cas de paquets destinés à des spécialistes, cela doit être considéré comme un problème.

Une recommandation pour rester accessible à tout utilisateur est d'éviter l'utilisation de jargon. Il est déconseillé de faire référence à des applications ou environnements qui pourraient être inconnus de l'utilisateur : parler de GNOME ou KDE est correct, car la plupart des utilisateurs sont familiers avec ces termes, mais parler de GTK ne l'est pas. Il est préférable de supposer que le lecteur n'aura pas de connaissance du sujet et, si des termes techniques doivent être utilisés, ils doivent être expliqués.

Il est conseillé de rester objectif. Les descriptions de paquets ne sont pas une plaquette publicitaire, quelles que soient vos opinions personnelles. Le lecteur peut très bien ne pas avoir les mêmes centres d'intérêt que vous.

Les références aux noms d'autres logiciels, de protocoles, normes ou spécifications doivent utiliser leur forme canonique si elle existe. Par exemple, utilisez « X Window System », « X11 » ou « X », mais pas « X Windows », « X-Windows », ou « X Window ». Utilisez « GTK » et non « GTK+ » ou « gtk », « GNOME » et non « Gnome », « PostScript » et non « Postscript » ou « postscript ».

Si vous rencontrez des difficultés pour écrire la description d'un paquet, vous pouvez demander de l'aide ou une relecture sur `debian-l10n-english@lists.debian.org`.

### 6.2.3. Résumé, ou description courte, d'un paquet

La Charte indique que la ligne de résumé (la description courte) doit être concise, ne doit pas répéter le nom du paquet, mais doit être informative.

La description courte est une expression qui décrit le paquet, pas une phrase complète, donc les conventions de ponctuation sont inappropriées : pas besoin de commencer par une majuscule ou de finir par un point. Elle devrait éviter également la présence d'article défini ou indéfini — « `a` », « `an` », ou « `the` ». Par exemple :

    Package: libeg0
    Description: exemplification support library

Techniquement, c'est une phrase nominale sans article, par opposition à une phrase verbale. Une bonne vérification est de pouvoir remplacer le nom du paquet et son résumé dans la phrase :

Le paquet nom fournit {un,une,le,la,l',du,de la} résumé (« `the package` nom `provides {a,an,the,some}` résumé »).

Les ensembles de paquets peuvent utiliser un schéma alternatif qui divise la description courte en deux parties, la première une description de l'ensemble et la seconde un résumé du rôle du paquet dans l'ensemble :

    Package: eg-tools
    Description: simple exemplification system (utilities)

    Package: eg-doc
    Description: simple exemplification system - documentation

Ces descriptions courtes suivent un modèle modifié. Quand un paquet « nom » possède une description courte « ensemble (rôle) » ou « ensemble - rôle », les éléments peuvent être placés dans la phrase :

Le paquet nom fournit {un,une,le,la,l'} rôle pour {le,la,l'} ensemble (« `the package` nom `provides {a,an,the}` rôle `for the` ensemble »).

### 6.2.4. Description longue

La description longue est l'information principale disponible pour les utilisateurs avant d'installer un paquet. Elle devrait fournir toutes les informations nécessaires pour déterminer si le paquet doit être installé. Elle complète le résumé qui est donc supposé avoir été lu précédemment.

La description longue est constituée de phrases complètes.

Le premier paragraphe de cette description devrait tenter de répondre aux questions suivantes : « Que fait ce paquet ? », « Dans quelle tâche aidera-t-il l'utilisateur ? ». Il est important que cette description se fasse de la manière la moins technique possible, sauf si le public auquel est destiné le paquet est par définition technique.

Les descriptions longues de paquets associés, par exemple construits à partir du même paquet source, peuvent partager des paragraphes afin d'améliorer la cohérence et de réduire la charge de travail pour les traducteurs, mais il faut qu'il y ait au moins un paragraphe distinct qui décrive le rôle spécifique du paquet.

Les paragraphes suivants devraient répondre aux questions : « Pourquoi, en tant qu'utilisateur, ai-je besoin de ce paquet ? », « Quelles autres fonctionnalités ce paquet apporte-t-il ? », « Quelles fonctionnalités et défauts comporte-t-il par rapport à d'autres paquets (par exemple, « si vous avez besoin de X, utilisez plutôt Y ») ? », « Ce paquet est-il lié à d'autres paquets d'une manière non gérée par le système de gestion des paquets (par exemple, « cela est le client destiné au serveur toto ») ? ».

Veillez à éviter les erreurs d'orthographe et de grammaire. Vérifiez l'orthographe avec un outil adapté. Les deux programmes `ispell` et `aspell` comportent un mode spécial permettant de contrôler un fichier `debian/control` files :

    ispell -d american -g debian/control

    aspell -d en -D -c debian/control

Les utilisateurs attendent en général des descriptions de paquets les réponses aux questions suivantes.

- Que fait ce paquet ? S'il s'agit d'un additif à un autre paquet, la description de cet autre paquet doit y être reprise.

- Pourquoi ai-je besoin de ce paquet ? Cela est lié à la remarque précédente, de manière différente (cela est un agent utilisateur pour le courrier électronique, avec une interface rapide et pratique vers PGP, LDAP et IMAP et les fonctionnalités X, Y ou Z).

- Si ce paquet ne doit pas être installé seul, mais est installé par un autre paquet, cela devrait être mentionné.

- Si le paquet est `expérimental` ou ne doit pas être utilisé pour toute autre raison et que d'autres paquets doivent être utilisés à la place, cela doit également être mentionné.

- En quoi ce paquet diffère-t-il de ses concurrents ? Est-il une meilleure implémentation ? A-t-il plus de fonctionnalités ? Des fonctionnalités différentes ? Pourquoi devrais-je choisir ce paquet ?

### 6.2.5. Page d'accueil amont

Il est recommandé d'ajouter l'URL d'accès à la page d'accueil du paquet dans le champ `Homepage` de la section `Source` du fichier `debian/control`. L'ajout de cette information à la description même du paquet est une pratique considérée obsolète.

### 6.2.6. Emplacement du système de gestion de versions

Des champs supplémentaires permettent d'indiquer l'emplacement du système de gestion de versions dans `debian/control`.

#### 6.2.6.1. Vcs-Browser

La valeur de ce champ doit être une URL `https://` pointant sur la copie navigable par le web du dépôt de gestion de versions utilisé pour la maintenance du paquet, s'il est disponible.

Cette information est destinée à l'utilisateur final qui voudrait parcourir le travail en cours sur le paquet (par exemple à la recherche d'un correctif qui corrige un bogue marqué `pending` (en attente) dans le système de suivi des bogues.

#### 6.2.6.2. Vcs-*

Value of this field should be a string identifying unequivocally the location of the Version Control System repository used to maintain the given package, if available. `*` identifies the Version Control System; currently the following systems are supported by the package tracking system: `arch`, `bzr` (Bazaar), `cvs`, `darcs`, `git`, `hg` (Mercurial), `mtn` (Monotone), `svn` (Subversion).

Cette information est destinée aux utilisateurs qui ont une connaissance suffisante du système de gestion de versions et qui veulent construire une version à jour du paquet depuis les sources du système de suivi. Une autre utilisation possible de cette information pourrait être la construction automatique de la dernière version, dans le système de suivi, d'un paquet donné. À cet effet, l'emplacement pointé devrait éviter d'être lié à une version spécifique et pointer vers la branche principale de développement (pour les systèmes qui ont un tel concept). De plus, l'emplacement indiqué doit être accessible à l'utilisateur final, par exemple en indiquant une adresse d'accès anonyme au dépôt, plutôt qu'une version accessible par SSH.

L'exemple qui suit montre une instance de ce champ pour un dépôt Git du paquet `vim`. Veuillez noter que l'URL a la forme `https://` (au lieu de `ssh://`). Une utilisation des champs `Vcs-Browser` et `Homepage`, décrits précédemment, est aussi indiquée.

    Source: vim
    <snip>
    Vcs-Git: https://salsa.debian.org/vim-team/vim.git
    Vcs-Browser: https://salsa.debian.org/vim-team/vim
    Homepage: https://www.vim.org

Maintaining the packaging in a version control system, and setting a Vcs-* header is good practice and makes it easier for others to contribute changes.

Almost all packages in Debian that use a version control system use Git; if you create a new package, using Git is a good idea simply because it's the system that contributors will be familiar with.

DEP-14 defines a common layout for Debian packages.

## 6.3. Meilleures pratiques pour `debian/changelog`

Les indications de cette partie complètent la Charte Debian pour ce qui concerne les fichiers de journaux des modifications (« `changelog` »).

### 6.3.1. Entrées de journalisation utiles

Le journal des modifications (« `changelog` ») présente uniquement les changements intervenus dans la version courante. Il est suggéré de mettre l'accent sur les modifications visibles ou affectant potentiellement les utilisateurs, réalisées depuis la version précédente.

Il est conseillé de mettre l'accent sur ce qui a été modifié, plutôt que comment, par qui et quand elle a été réalisée. Cela dit, il est conseillé, par courtoisie, d'indiquer les auteurs qui ont apporté une aide significative à la maintenance du paquet (par exemple lorsque ces personnes ont envoyé des correctifs).

Il n'est pas indispensable d'indiquer les détails des modifications triviales. Il est également possible de grouper plusieurs modifications sur une même entrée. Cependant, évitez une documentation trop concise pour les modifications majeures. Il est particulièrement conseillé d'être très clair sur les modifications qui affectent le comportement du programme. Pour des explications plus détaillées, vous pouvez aussi utiliser le fichier `README.Debian`.

Utilisez un anglais simple que la majorité des lecteurs puissent comprendre. Évitez les abréviations et le jargon technique lorsque des modifications permettent la clôture de bogues. Cela est vrai notamment quand vous pensez que les utilisateurs qui les ont envoyés n'ont pas de connaissances techniques importantes. Une formulation polie est à préférer et la vulgarité à prohiber.

Il est parfois souhaitable de faire précéder les entrées du journal des modifications par les noms des fichiers modifiés. Cependant, rien n'oblige à mentionner le moindre fichier modifié, notamment si la modification est simple ou répétitive. L'utilisation de caractères joker est possible.

Ne faites pas de suppositions lorsque vous faites référence à un bogue. Indiquez quel était le problème, comment il a été corrigé et ajoutez la chaîne closes: #nnnnn. Veuillez consulter Fermeture des rapports de bogue lors des mises à jour pour plus d'informations.

### 6.3.2. Sélection de l’urgence du téléversement

The release team have indicated that they expect most uploads to `unstable` to use urgency=medium. That is, you should choose urgency=medium unless there is some particular reason for the upload to migrate to `testing` more quickly or slowly (see also Mise à jour depuis unstable). For example, you might select urgency=low if the changes since the last upload are large and might be disruptive in unanticipated ways.

The delays are currently 2, 5 or 10 days, depending on the urgency (high, medium or low). The actual numbers are actually controled by the britney configuration which also includes accelerated migrations when Autopkgtest passes.

### 6.3.3. Idées reçues sur les entrées de journalisation

Les entrées de journal des modifications ne devraient pas documenter les points spécifiques de la réalisation du paquet (« si vous cherchez le fichier toto.conf, il est situé dans /etc/titi »), car les administrateurs et les utilisateurs sont censés avoir l'habitude de la façon dont ces aspects sont traités sur un système Debian. Pensez, par contre, à documenter la modification de l'emplacement d'un fichier de configuration.

Les seuls bogues fermés par une entrée de journal de modifications devraient être ceux qui sont corrigés par la version correspondante du paquet. Fermer de cette manière des bogues qui n'ont aucun rapport avec la nouvelle version est considéré comme une mauvaise habitude. Veuillez consulter Fermeture des rapports de bogue lors des mises à jour.

Les entrées du journal des modifications ne devraient pas être utilisées pour des discussions variées avec les émetteurs des rapports de bogue (par exemple : « je n'ai pas d'erreur de segmentation quand je lance toto avec l'option titi, merci d'envoyer plus d'informations »). De même, les considérations générales sur la vie, l'univers et le reste (« désolé, cet envoi m'a pris plus longtemps que prévu, mais j'avais un rhume ») ou encore des demandes d'aide (« la liste de bogues de ce paquet est très longue, merci de me donner un coup de main ») sont à éviter. Ces mentions ne seront généralement pas remarquées par leur public potentiel et peuvent ennuyer les personnes qui cherchent à lire les modifications concrètes du paquet. Voir Réponses aux bogues pour plus d'informations sur l'utilisation du système de gestion des bogues.

Une tradition assez ancienne veut que les bogues corrigés dans les NMU soient pris en compte dans la première entrée du journal des modifications d'une nouvelle version construite par le responsable. Depuis l'existence du suivi de version pour le système de gestion de bogues, cette pratique est obsolète à condition de conserver les entrées du journal des modifications des NMU. Il est éventuellement possible de simplement mentionner les NMU dans votre propre entrée de journal des modifications.

### 6.3.4. Erreurs usuelles dans les entrées de journalisation

Les exemples suivants sont des erreurs usuelles ou des exemples de mauvaises pratiques dans le style des entrées de journaux de modifications (NdT : le texte est volontairement laissé non traduit).

    * Fixed all outstanding bugs.

Cela ne donne évidemment aucune indication au lecteur.

    * Applied patch from Jane Random.

Que faisait ce correctif ?

    * Late night install target overhaul.

Qu'est-ce que cela a amené ? Est-ce que la mention du fait que cela ait été fait tard la nuit doit nous alerter sur la probable mauvaise qualité du code ?

    * Fix vsync fw glitch w/ ancient CRTs.

Trop d'acronymes (que signifie « `fw` », « `firmware` » ?), et la nature réelle du problème n'est pas claire, ou comment il a été corrigé.

    * This is not a bug, closes: #nnnnnn.

Il est inutile de faire un nouvel envoi de paquet pour envoyer cette information. Il suffit simplement d'utiliser le système de suivi des bogues. De plus, aucune explication n'est donnée sur les raisons qui font que le problème n'est pas un bogue.

    * Has been fixed for ages, but I forgot to close; closes: #54321.

Si, pour une raison donnée, vous avez omis de mentionner un numéro de bogue dans une entrée précédente, ce n'est pas grave : il suffit de clore le bogue normalement dans le système de suivi des bogues. Il est inutile de changer le journal des modifications si on suppose que les explications sur la correction du bogue sont dans le bogue lui-même (cela s'applique également au suivi des bogues des auteurs amont : il est inutile de suivre, dans le journal des modifications, les bogues qu'ils ont corrigés depuis longtemps).

    * Closes: #12345, #12346, #15432

Où est la description ? Si vous ne trouvez pas de message suffisamment explicite, vous pouvez au moins utiliser le titre du rapport de bogue.

### 6.3.5. Complément des journaux de modifications dans les fichiers `NEWS.Debian`

Les nouvelles importantes sur les modifications survenues dans un paquet peuvent être placées dans des fichiers `NEWS.Debian`. Ces nouvelles seront affichées par des outils tels que `apt-listchanges` avant tout le reste des modifications. Cette méthode est à privilégier pour diffuser aux utilisateurs d'un paquet les modifications importantes qu'il subit. Il est préférable de l'utiliser plutôt que des notes `debconf`, car ce système permet de revenir lire les fichiers `NEWS.Debian` après l'installation. Il est également préférable de faire la liste des modifications majeures dans `README.Debian`, car un utilisateur peut assez facilement ne pas remarquer l'affichage d'une note `debconf` (Ndt : a contrario, les fichiers `NEWS.Debian` ne peuvent être traduits).

Le format de ce fichier est analogue à un journal de modifications Debian, mais n'utilise pas d'astérisque et chaque nouveau message utilise un paragraphe complet plutôt que les mentions succinctes qui seraient utilisées dans le journal des modifications. Il est conseillé de traiter le fichier avec `dpkg-parsechangelog`, ce qui permet d'en vérifier la mise en forme, car il ne sera pas automatiquement modifié pendant la construction du paquet, contrairement au journal des modifications. Voici un exemple de fichier `NEWS.Debian` réel :

    cron (3.0pl1-74) unstable; urgency=low

        The checksecurity script is no longer included with the cron package:
        it now has its own package, checksecurity. If you liked the
        functionality provided with that script, please install the new
        package.

     -- Steve Greenland <stevegr@debian.org>  Sat,  6 Sep 2003 17:15:03 -0500

Le fichier `NEWS.Debian` est installé sous le nom `/usr/share/doc/`paquet`/NEWS.Debian.gz`. Il est compressé et porte toujours ce nom même pour les paquets Debian natifs. Si vous utilisez `debhelper`, `dh_installchangelogs` installera les fichiers `debian/NEWS` automatiquement.

À la différence des journaux de modifications, vous n'avez pas besoin de mettre `NEWS.Debian` à jour à chaque nouvelle version. Il est suffisant de le mettre à jour quand une information importante doit être diffusée aux utilisateurs. Si vous n'avez pas d'information importante à diffuser, il n'est pas nécessaire d'utiliser un fichier `NEWS.Debian` avec le paquet. Pas de nouvelles, bonnes nouvelles !

## 6.4. Best practices around security

When an upstream publishes a cryptographic signature for every new release, you should setup `uscan` to automatically verify the latter. For details, refer to the section on `Upstream source location: "debian/watch"` in the The Debian Policy Manual.

https://wiki.debian.org/Hardening has suggestions on how to build security hardened executables.

## 6.5. Meilleures pratiques pour les scripts du responsable

Les scripts du responsable (« `maintainer scripts` ») sont les fichiers `debian/postinst`, `debian/preinst`, `debian/prerm` et `debian/postrm`. Ces scripts peuvent prendre en charge les phases d'installation ou de désinstallation non automatiquement gérées par la création ou la suppression de fichiers ou de répertoires. Les instructions qui suivent complètent celles de la Charte Debian.

Les scripts du responsable doivent être idempotents. Cela signifie que vous devez vous assurer que rien de grave ne se produit si un script est lancé deux fois au lieu d'une.

L'entrée et la sortie standard peuvent être redirigées (par exemple dans des tuyaux, ou « `pipes` ») pour des besoins de journalisation. Il est donc recommandé qu'ils ne soient pas dépendants d'un terminal.

Toute interaction avec l'utilisateur doit être limitée au maximum. Lorsqu'elle est nécessaire, vous devriez utiliser le paquet `debconf` comme interface. Veuillez noter que l'interaction doit impérativement se faire à l'étape `configure` du script `postinst`.

Les scripts du responsable doivent rester aussi simples que possible et utiliser de préférence des scripts shell POSIX stricts. Veuillez noter que si vous avez besoin de spécificités de Bash, vous devez utiliser une ligne « `shebang` » pour Bash. Les scripts POSIX ou Bash sont encouragés par rapport aux scripts Perl, car `debhelper` peut alors y ajouter des fonctions.

Si vous modifiez les scripts du responsable, veillez à vérifier la suppression du paquet, la double installation et la purge. Vérifiez qu'un paquet purgé est entièrement éliminé, c'est-à-dire que les fichiers créés, directement ou indirectement dans les scripts du responsable, sont tous supprimés.

Pour vérifier l'existence d'une commande, vous devriez utiliser quelque chose comme :

    if command -v install-docs > /dev/null; then ...

Vous pouvez utiliser cette fonction pour rechercher dans `$PATH` une commande donnée, passée en paramètre. Elle renvoie « `true` » (zéro) si la commande est trouvée et « `false` » dans le cas contraire. Il s'agit de la méthode la plus portable, car `command -v` est une commande interne pour plusieurs interpréteurs de commande et elle est définie dans POSIX.

L'utilisation de `which` est une alternative acceptable dans la mesure où elle est fournie par le paquet `debianutils` qui est requis.

## 6.6. Gestion de la configuration avec `debconf`

`debconf` est un système de gestion de configuration utilisable par les divers scripts des paquets (`postinst` notamment) pour interagir avec l'utilisateur sur des choix à opérer pour la configuration du paquet. Les interactions directes avec l'utilisateur doivent maintenant être évitées en faveur de `debconf`, notamment pour permettre des installations non interactives dans le futur.

Debconf is a great tool but it is often poorly used. Many common mistakes are listed in the debconf-devel(7) man page. It is something that you must read if you decide to use debconf. Also, we document some best practices here.

Les conseils qui suivent comportent des indications sur le style d'écriture et la typographie, des considérations générales sur l'utilisation de `debconf` ainsi que des recommandations plus spécifiques relatives à certaines parties de la distribution (le système d'installation notamment).

### 6.6.1. Proscrire les abus de `debconf`

Depuis que `debconf` est apparu dans Debian, il a été tellement utilisé que de nombreuses critiques ont été émises à l'encontre de la distribution Debian pour abus d'utilisation de `debconf`, avec la nécessité de répondre à un nombre très important de questions avant d'avoir un quelconque outil installé.

Les notes d'utilisation doivent être réservées à leur emplacement naturel : le fichier `NEWS.Debian` ou `README.Debian`. N'utilisez les notes que pour des points importants qui peuvent directement concerner l'utilisabilité du paquet. Les notes interrompent l'installation tant qu'elles ne sont pas confirmées et elles peuvent conduire à des envois de courriers électroniques aux utilisateurs.

Choisissez soigneusement les priorités des questions posées dans les scripts du responsable. Veuillez consulter la page de manuel debconf-devel 7 pour plus de détails sur les priorités. La plupart des questions devraient utiliser les priorités intermédiaire (`medium`) ou basse (`low`).

### 6.6.2. Recommandations générales pour les auteurs et les traducteurs

#### 6.6.2.1. Utilisation d'un anglais correct

La plupart des responsables de paquet Debian ne sont pas anglophones. Il n'est donc pas nécessairement facile pour eux d'écrire des écrans correctement.

Pensez à utiliser (voire abuser de) la liste `debian-l10n-english@lists.debian.org`. Faites relire vos écrans.

Des écrans mal écrits fournissent une image négative de votre paquet, de votre travail ou même de Debian en général.

Évitez autant que possible le jargon technique. Si certains termes vous sont familiers, ils peuvent être incompréhensibles à d'autres. Si vous ne pouvez les éviter, tentez de les expliquer (avec la description étendue). Dans ce cas, tentez de faire la part des choses entre simplicité et verbosité.

#### 6.6.2.2. Courtoisie avec les traducteurs

Les écrans `debconf` peuvent être traduits. Les paquets `debconf` et `po-debconf` fournissent un cadre simple permettant la traduction des écrans par des équipes de traduction ou des traducteurs isolés.

Utilisez des écrans permettant l'utilisation de `gettext`. Installez le paquet `po-debconf` sur votre machine de développement et lisez sa documentation (`man po-debconf` est un bon début).

Évitez de changer les écrans trop souvent. Les modifications de texte ont une incidence sur le travail des traducteurs dont les traductions vont devenir approximatives (« `fuzzy` »). Une chaîne de caractères devient approximative quand la version originale a été modifiée depuis la traduction, demandant ainsi une mise à jour par un traducteur pour être utilisable. Si les modifications sont mineures, la traduction originale est conservée dans le fichier PO, mais marquée `fuzzy`.

Si vous prévoyez de modifier les écrans d'origine, veuillez utiliser le système de notification `podebconf-report-po`, fourni avec le paquet `po-debconf`, pour contacter les traducteurs. La plupart des traducteurs sont réactifs, et inclure leur mise à jour en même temps que les modifications des écrans d'origine vous évitera des envois ultérieurs pour mettre à jour des traductions. Si vous utilisez des écrans se servant de `gettext`, le nom et l'adresse électronique des traducteurs sont mentionnés dans les en-têtes des fichiers PO et seront utilisés par `podebconf-report-po`.

Une façon recommandée de se servir de cet utilitaire est :

    cd debian/po && podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"

Cette commande synchronisera d'abord les fichiers PO et POT de `debian/po` avec les fichiers d'écrans listés en `debian/po/POTFILES.in`. Ensuite, elle déclenchera un appel à de nouvelles traductions sur la liste de diffusion `debian-i18n@lists.debian.org`. Enfin, elle déclenchera un appel à mise à jour de traduction aux équipes de traductions (indiquées dans le champ `Language-Team` de chaque fichier PO) ainsi qu'au dernier traducteur (indiqué en `Last-translator`).

La mention d'une date limite aux traducteurs est toujours appréciée, pour leur permettre d'organiser leur travail. Veuillez ne pas oublier que certaines équipes ont formalisé leur processus de traduction et révision de telle sorte qu'un délai inférieur à dix jours n'est pas considéré comme raisonnable. Un délai plus court met trop de pression sur les équipes de traduction et ne devrait être réservé qu'aux modifications mineures.

Dans le doute, vous pouvez également contacter l'équipe de traduction d'une langue donnée (debian-l10n-xxxxx@lists.debian.org) ou la liste de diffusion `debian-i18n@lists.debian.org`.

#### 6.6.2.3. Correction (« `unfuzzy` ») des traductions pour des erreurs typographiques ou de frappe

Lorsque le texte d'un écran `debconf` est corrigé et que vous avez la certitude que la modification n'affecte pas les traductions, pensez aux traducteurs et rendez leur traductions à nouveau complètes (« unfuzzy »).

Si cela n'est pas fait, l'ensemble de l'écran `debconf` ne sera plus traduit tant qu'un traducteur n'aura pas envoyé de mise à jour.

Pour rendre les traductions à nouveau complètes (« unfuzzy »), vous pouvez utiliser `msguntypot` (du paquet `po4a`).

1. Recréez les fichiers POT et PO.

       debconf-updatepo

2. Faites une copie du fichier POT.

       cp templates.pot templates.pot.orig

3. Faites une copie de tous les fichiers PO.

       mkdir po_fridge; cp *.po po_fridge

4. Modifier les fichiers d'écrans `debconf` (`templates`) pour corriger les fautes de frappe.

5. Recréez les fichiers POT et PO (de nouveau).

       debconf-updatepo

   À ce moment-là, la correction a marqué certaines chaînes approximatives, et ce changement est malheureusement la seule modification entre les fichiers PO du répertoire et ceux de po_orig. Voici comment corriger cela.

6. Abandonnez les traductions approximatives, récupérer celles du répertoire originel.

       cp po_fridge/*.po .

7. Fusionnez manuellement les fichiers PO avec le nouveau fichier POT, en prenant en compte le fait que les étiquettes « fuzzy » sont inutiles.

       msguntypot -o templates.pot.orig -n templates.pot *.po

8. Nettoyage.

       rm -rf templates.pot.orig po_fridge

#### 6.6.2.4. Proscrire toute supposition sur les interfaces utilisateurs

Les textes des écrans ne devraient pas faire référence aux éléments disponibles sur certaines interfaces de `debconf`. Des phrases telles que « If you answer Yes » ne signifient rien avec les interfaces graphiques où des boutons radio sont utilisés pour les questions booléennes.

Les écrans de type `string` ne devraient pas faire référence aux valeurs par défaut dans leur description. Cela est tout d'abord redondant avec les valeurs visibles par les utilisateurs. Mais également, les valeurs présentées par défaut peuvent être différentes du choix du responsable (par exemple, lorsque la base de données de `debconf` a été pré-renseignée).

De manière plus générale, évitez de faire référence à des actions particulières des utilisateurs et donnez simplement des faits.

#### 6.6.2.5. Proscrire l'utilisation de la première personne

Vous devriez éviter l'utilisation de la première personne (« I will do this... » ou « We recommend... »). L'ordinateur n'est pas une personne et les écrans de `debconf` ne parlent pas au nom des développeurs de Debian. Vous devriez utiliser des constructions neutres. Pour les personnes familières de la publication scientifique, il suffit en général d'adopter le style d'écriture qui y est utilisé. Tentez cependant d'utiliser la forme active si possible. Par exemple : « Enable this if... » au lieu de « This can be enabled if... ».

#### 6.6.2.6. Neutralité en genre

Pour se conformer à notre engagement de diversité et équité, veuillez utiliser des constructions de genre neutre dans votre écriture. Cela signifie éviter les pronoms tels que il ou elle lors d’une référence à un rôle (tel que « responsable ») dont le genre est inconnu. À la place, vous devriez utiliser une forme plurielle (They singulier).

### 6.6.3. Définition des champs de modèles (« `templates` »).

This part gives some information which is mostly taken from the debconf-devel(7) manual page.

#### 6.6.3.1. `Type`

##### 6.6.3.1.1. `string`

offre un champ de saisie où l'utilisateur peut entrer n'importe quelle chaîne de caractères.

##### 6.6.3.1.2. `password`

demande un mot de passe. Ce champ est à utiliser avec précaution, car le mot de passe saisi sera conservé dans la base de données de `debconf`. Il est conseillé d'effacer cette valeur de la base de données dès que possible.

##### 6.6.3.1.3. `boolean`

offre un choix du type « vrai » ou « faux ». N'oubliez pas, c'est bien un choix « vrai » ou « faux », pas « oui » ou « non »...

##### 6.6.3.1.4. `select`

offre le choix entre différentes valeurs. Les choix doivent être indiqués dans un champ appelé « `Choices` ». Les différentes valeurs doivent être séparées par des virgules et des espaces, comme ceci : « `Choices: yes, no, maybe` ».

Si les choix sont traduisibles, le champ « `Choices` » peut être marqué traduisible en utilisant « `__Choices` ». Les deux tirets bas permettent à chaque choix de devenir une chaîne différente proposée à la traduction.

Le système `po-debconf` offre également la possibilité intéressante de ne marquer que certains choix traduisibles. Par exemple :

    Template: foo/bar
    Type: Select
    #flag:translate:3
    __Choices: PAL, SECAM, Other
    _Description: TV standard:
     Please choose the TV standard used in your country.

Dans cet exemple, seule la chaîne « `Other` » est traduisible, alors que les autres sont des acronymes qui ne devraient pas êtres traduits. Seul « `Other` » sera inclus dans les fichiers PO et POT.

The debconf templates flag system offers many such possibilities. The po-debconf(7) manual page lists all these possibilities.

##### 6.6.3.1.5. `multiselect`

similaire au type `select`, mais permet de choisir plusieurs (ou aucune) valeurs parmi la liste de choix.

##### 6.6.3.1.6. `note`

plus qu'une vraie question, ce type indique une note affichée aux utilisateurs. Elle doit être réservée à des informations importantes que l'utilisateur doit absolument voir, car `debconf` fera tout pour s'assurer qu'elle soit visible, en interrompant l'installation jusqu'à ce qu'une touche soit appuyée, voire en envoyant la note par courrier électronique dans certains cas.

##### 6.6.3.1.7. `text`

ce type est maintenant obsolète : il ne faut pas l'utiliser.

##### 6.6.3.1.8. `error`

ce type permet de gérer des messages d'erreur. Il est analogue au type `note`. Les interfaces utilisateur peuvent le présenter différemment (par exemple l'interface `cdebconf` dessine un écran à fond rouge au lieu de l'écran bleu habituel).

Il est recommandé d'utiliser ce type pour tout message qui requiert l'attention de l'utilisateur pour procéder à une correction, quelle qu'elle soit.

#### 6.6.3.2. `Description` : descriptions courte et étendue

Les descriptions de modèle comportent deux parties : la partie courte et la partie étendue. La partie courte est celle qui est placée sur la ligne `Description` du modèle.

La partie courte doit rester courte (une cinquantaine de caractères) afin d'être gérée par la majorité des interfaces de `debconf`. La garder courte facilite également le travail des traducteurs, car les traductions sont souvent plus longues que les textes originaux.

La description courte doit être autonome. Certaines interfaces ne montrent pas la description longue par défaut ou ne la montrent que si l'utilisateur le demande explicitement. Il est ainsi déconseillé d'utiliser des phrases comme « `What do you want to do?` » (« Que voulez vous faire ? »)

La description courte ne doit pas nécessairement être une phrase entière. C'est une façon de la garder courte et efficace.

La partie longue ne doit pas répéter la partie courte. Si vous ne trouvez pas de partie longue appropriée, réfléchissez un peu plus. Demandez dans debian-devel. Demandez de l'aide. Prenez un cours d'écriture ! La description longue est importante. Si, malgré tout cela, vous ne trouvez rien d'intéressant à ajouter, laissez-la vide.

La partie longue doit utiliser des phrases complètes. Les paragraphes doivent rester courts pour améliorer la lisibilité. Ne placez pas deux idées différentes dans le même paragraphe, mais séparez-les en deux paragraphes.

Ne soyez pas trop verbeux. Les utilisateurs ont tendance à ne pas lire les écrans trop longs. Une vingtaine de lignes est une limite que vous ne devriez pas dépasser car, avec l'interface `dialog` standard, les utilisateurs devront monter et descendre avec des ascenseurs, ce que la plupart des utilisateurs ne font simplement pas.

La partie longue de la description ne devrait jamais comporter de question.

Les parties qui suivent donnent des recommandations spécifiques pour certains types de modèles (`string`, `boolean`, etc.).

#### 6.6.3.3. `Choices`

Ce champ doit être utilisé pour les types `select` et `multiselect`. Il contient les choix proposés aux utilisateurs. Ces choix doivent être séparés par des virgules.

#### 6.6.3.4. `Default`

Ce champ optionnel contient la réponse par défaut pour les modèles `string`, `select` et `multiselect`. Dans ce dernier cas, il peut comporter une liste de choix multiples, séparés par des virgules.

### 6.6.4. Guide de style spécifique à certains champs de modèle

#### 6.6.4.1. Champ `Type`

Pas d'indication particulière si ce n'est choisir le type adapté en se référant à la section précédente.

#### 6.6.4.2. Champ `Description`

Vous trouverez ici des instructions particulières pour l'écriture du champ `Description` (parties courte et longue) selon le type de modèle.

##### 6.6.4.2.1. Modèles `string` et `password`

- La description courte est une invite et pas un titre. Il faut éviter la forme interrogative (« `IP Address?` ») au profit d'une invite ouverte (« `Adresse IP :` »). L'utilisation d'un deux-points final est recommandée.

- La partie longue complète la partie courte. Il est conseillé d'y expliquer ce qui est demandé, plutôt que de répéter la même demande. Utilisez des phrases complètes. Un style d'écriture abrégé est déconseillé.

##### 6.6.4.2.2. Modèles `boolean`

- La partie courte devrait utiliser la forme interrogative, rester courte et se terminer par un point d'interrogation. Un style abrégé est toléré et même encouragé si la question est complexe (les traductions sont souvent plus longues que les versions originales).

- Il est important de ne pas faire référence aux spécificités de certaines interfaces. Une erreur classique est d'utiliser une construction comme « `If you answer Yes...` » (« Si vous répondez Oui... »).

##### 6.6.4.2.3. Modèles `select` et `multiselect`

- La description courte est une invite et pas un titre. N'utilisez pas de constructions comme « `Please choose...` » (« Veuillez choisir... »). Les utilisateurs sont suffisamment intelligents pour comprendre qu'il est nécessaire de choisir quelque chose.

- La description longue complète la partie courte. Elle peut faire référence aux choix disponibles. Elle peut aussi indiquer que l'utilisateur peut sélectionner plus d'un choix parmi ceux disponibles, pour les modèles `multiselect` (bien que l'interface rende en général cela tout à fait clair).

##### 6.6.4.2.4. Modèles `note`

- La description courte doit être considérée comme un titre.

- La partie longue est ce qui sera affiché comme description plus détaillée de la note. Il est déconseillé d'y utiliser un style abrégé.

- Do not abuse debconf. Notes are the most common way to abuse debconf. As written in the debconf-devel(7) manual page: it's best to use them only for warning about very serious problems. The `NEWS.Debian` or `README.Debian` files are the appropriate location for a lot of notes. If, by reading this, you consider converting your Note type templates to entries in `NEWS.Debian` or `README.Debian`, please consider keeping existing translations for the future.

#### 6.6.4.3. Champ `Choices`

Si les choix changent souvent, il est suggéré d'utiliser l'astuce « `__Choices` ». Avec ce format, chaque choix sera une chaîne différente proposée à la traduction, ce qui facilite grandement le travail des traducteurs.

#### 6.6.4.4. Champ `Default`

Si la valeur par défaut pour un modèle choisi est susceptible de dépendre de la langue de l’utilisateur (par exemple si le choix concerne la langue), pensez à utiliser l’astuce _Default, documentée dans la page de manuel po-debconf 7.

Ce champ spécial permet aux traducteurs de mettre le choix le plus adapté à leur langue, qui deviendra le choix par défaut quand cette langue est utilisée, alors que le choix par défaut que vous avez mentionné sera utilisé en anglais.

N'utilisez pas de champ `Default` vide. Si vous ne souhaitez pas avoir de valeur par défaut, n'utilisez pas du tout ce champ.

Quand vous utilisez `po-debconf`, (et vous devriez, voir Courtoisie avec les traducteurs), veuillez rendre ce champ traduisible si vous pensez qu'il peut l'être.

Exemple, pris dans le paquet geneweb :

    Template: geneweb/lang
    Type: select
    __Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
    # This is the default choice. Translators may put their own language here
    # instead of the default.
    # WARNING : you MUST use the ENGLISH NAME of your language
    # For instance, the French translator will need to put French (fr) here.
    _Default: English[ translators, please see comment in PO files]
    _Description: Geneweb default language:

Veuillez noter l'utilisation de crochets pour autoriser des commentaires internes dans les champs de `debconf`. Notez également l'utilisation de commentaires qui apparaîtront dans les fichiers de travail des traducteurs.

Les commentaires sont très utiles, car l'astuce « `_Default` » est parfois déroutante pour les traducteurs qui pourraient y mettre leur propre choix.

## 6.7. Internationalisation

Cette section fournit des informations générales à destination des développeurs pour simplifier la vie des traducteurs. Vous trouverez plus d'informations à destination des traducteurs et développeurs intéressés par l'internationalisation dans la documentation sur l'internationalisation et la localisation dans Debian.

### 6.7.1. Gestion des traductions `debconf`

Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur de nombreux paquets et doivent collaborer avec de nombreux responsables. De plus, ils n'ont généralement pas la langue anglaise comme langue maternelle et vous devez donc faire preuve d'une patience particulière avec eux.

L'objectif de `debconf` est de rendre la configuration des paquets plus facile pour les responsables de paquets et pour les utilisateurs. Initialement, la traduction des écrans de debconf était gérée avec `debconf-mergetemplate`. Cependant, cette technique est désormais obsolète et la meilleure façon d'internationaliser `debconf` est d'utiliser le paquet `po-debconf`. Cette méthode simplifie le travail des traducteurs et des responsables et des scripts de transition sont fournis.

Using `po-debconf`, the translation is stored in `.po` files (drawing from `gettext` translation techniques). Special template files contain the original messages and mark which fields are translatable. When you change the value of a translatable field, by calling `debconf-updatepo`, the translation is marked as needing attention from the translators. Then, at build time, the `dh_installdebconf` program takes care of all the needed magic to add the template along with the up-to-date translations into the binary packages. Refer to the po-debconf(7) manual page for details.

### 6.7.2. Documentation internationalisée

L'internationalisation de la documentation est primordiale pour les utilisateurs, mais représente un travail très important. Même s'il n'est pas possible de supprimer tout le travail nécessaire, il est possible de faciliter la tâche des traducteurs.

Si vous maintenez une documentation de quelque taille que ce soit, il sera plus pratique pour les traducteurs d'avoir accès au système de suivi des versions source. Cela leur permet de voir les différences entre deux versions de la documentation et, par conséquent, de mieux voir où les traductions doivent être modifiées. Il est recommandé que la documentation traduite contienne l'indication du système de suivi des versions source qui est utilisé. Un système pratique est fourni par doc-check du paquet `debian-installer`, qui permet un survol de l'état de la traduction pour toute langue, par l'utilisation de commentaires structurés dans la version du fichier à traduire et, pour le fichier traduit, la version du fichier sur laquelle est basée la traduction. Il est possible d'adapter ce système dans votre propre dépôt de gestion de versions.

Si vous maintenez de la documentation en format XML ou SGML, il est conseillé d'isoler l'information indépendante de la langue et de la définir sous forme d'entités dans un fichier à part qui sera inclus par toutes les traductions. Cela rend par exemple plus simple la maintenance d'URL dans de nombreux fichiers.

Certains outils (par exemple `po4a`, `poxml`, ou `translate-toolkit`) sont spécialisés dans l'extraction des composants traduisibles depuis différents formats. Ils fabriquent des fichiers PO (un format plutôt habituel pour les traducteurs), qui permettent de voir les traductions à mettre à jour quand le document a été modifié.

## 6.8. Best practices for `debian/patches`

Debian packages might suffer from bugs in the upstream code that you need to deal with. In the source format “3.0 (quilt)” patches are stored in `debian/patches/` and automatically applied as listed in `debian/patches/series` when the source package is unpacked.

Patches should be documented following DEP-3.

Several tools exist to automate managing the patches. If you manage a source package outside of any Git repository, then your best option is likely `quilt`. Otherwise, you should consider to rely on Git's built-in features or on on the git packaging helper that you use (if any). In particular, for packages using `git-buildpackage`, you should use the `gbp pq` commands to manage the contents of the `debian/patches/` directory.

A single patch can be created with e.g. `git format-patch -1 d33286c` from a single commit. Avoid using git show as it lacks the full headers.

If the upstream fix is spread across multiple commits but makes sense to apply (and drop) in Debian as a single patch, one could use a command such as `git format-patch --stdout abc123..def456 > debian/patches/...` and append the `Bug` field only in the commit message of the first commit in the patch.

If one appends .patch to the url of a GitHub commit or Pull Request or GitLab commit or Merge Request, the resulting patch file is using this same format (as if it were generated by `git format-patch`).

Remember to always append a `Bug` header to the patch description so that a reader can follow the link to see where the bug was reported or patch submitted. If the purpose of the patch is to specifically divert from upstream permanently, append the header Forwarded: not-needed to the end of the description.

## 6.9. Situations courantes de gestion de paquets

### 6.9.1. Paquets utilisant `autoconf` ou `automake`

Pouvoir disposer de fichiers `config.sub` et `config.guess` à jour est un point critique pour les porteurs, particulièrement pour les architectures assez volatiles. De très bonnes pratiques applicables à tout paquet qui utilise `autoconf` ou `automake` ont été résumées dans `/usr/share/doc/autotools-dev/README.Debian.gz` du paquet `autotools-dev`. Il est fortement recommandé de lire ce fichier et d'en suivre les recommandations.

### 6.9.2. Bibliothèques

Les paquets fournissant des bibliothèques sont plus difficiles à maintenir pour plusieurs raisons. La Charte impose de nombreuses contraintes pour en faciliter la maintenance et garantir que les mises à niveau sont aussi simples que possible quand une nouvelle version amont est disponible. Des erreurs dans une bibliothèque sont susceptibles de rendre inutilisables de très nombreux paquets.

Good practices for library packaging have been grouped in the library packaging guide.

### 6.9.3. Documentation

Veuillez vous assurer que vous suivez la Charte de documentation.

Si votre paquet contient de la documentation construite à partir de fichiers XML ou SGML, il est recommandé de ne pas fournir ces fichiers source dans les paquets binaires. Les utilisateurs qui souhaiteraient disposer des sources de la documentation peuvent alors récupérer le paquet source.

La Charte indique que la documentation devrait être fournie en format HTML. Il est recommandé de la fournir également dans les formats PDF et texte si cela est pratique et si un affichage de qualité raisonnable est possible. Cependant, il est le plus souvent inapproprié de fournir en format texte simple des versions de documentations dont le format source est HTML.

Les manuels les plus importants qui sont fournis devraient être enregistrés avec `doc-base` lors de leur installation. Veuillez consulter la documentation du paquet `doc-base` pour plus d'informations.

La Charte Debian (section 12.1) indique que des pages de manuel devraient être fournies avec chaque programme, utilitaire et fonction, et suggère d'en fournir pour les autres éléments comme les fichiers de configuration. Si le travail que vous empaquetez ne fournit pas de telles pages de manuel, veuillez envisager de les écrire pour les ajouter à votre paquet et les proposer en amont.

Les pages de manuel n'ont pas besoin d'être écrites directement au format troff. Les formats source populaires Docbook, POD et reST peuvent être convertis en utilisant respectivement `xsltproc`, `pod2man` et `rst2man`. De moins grande ampleur, le programme `help2man` peut aussi être utilisé pour écrire une ébauche.

### 6.9.4. Catégories particulières de paquets

Plusieurs catégories particulières de paquets utilisent des chartes spécifiques avec leurs règles et leurs pratiques d'empaquetage.

- Les paquets liés à Perl utilisent une charte Perl. Des exemples de tels paquets qui appliquent cette charte spécifique sont `libdbd-pg-perl` (module Perl binaire) ou `libmldbm-perl` (module Perl indépendant de l'architecture).

- Les paquets liés à Python utilisent une charte Python. Veuillez consulter le fichier `/usr/share/doc/python/python-policy.txt.gz` du paquet `python` pour plus d'informations.

- Les paquets liés à Emacs utilisent une charte Emacs.

- Les paquets liés à Java utilisent une charte Java.

- Les paquets liés à OCaml utilisent leur propre charte, que l'on peut trouver dans le fichier `/usr/share/doc/ocaml/ocaml_packaging_policy.gz` du paquet `ocaml`. Un bon exemple est fourni par le paquet source `camlzip`.

- Les paquets fournissant des DTD XML ou SGML devraient suivre les recommandations données dans le paquet `sgml-base-doc`.

- Les paquets Lisp doivent s'enregistrer avec `common-lisp-controller`, pour lequel plus d'information est disponible dans `/usr/share/doc/common-lisp-controller/README.packaging`.

- Rust packaging is described in the Debian Rust Team Book;.

- Packages providing services ("daemons") should be functional on a fresh install, to the extent that that is possible without compromising security (e.g. a web server should by default be up and running and serve a dummy page, but must otherwise not allow unauthenticated sensitive operations; consider whether to serve only on the localhost network interface, by default).

- Web application packages should aim to have their dependencies (including javascript) packaged separately, and should carry out whatever setup is necessary for basic and secure functionality out of the box (e.g. create a database, ship configs with reasonable defaults, install files in appropriate location with appropriate permissions, etc). For examples, look at how existing web applications are packaged, e.g. dfsg-new-queue for Go, gitlab for ruby on rails, node-shiny-server for NPM. diaspora-installer is a dummy package which downloads diaspora (also pulling in runtime dependencies as rubygems) and configures it to use PostgreSQL and Nginx.

### 6.9.5. Données indépendantes de l'architecture

Il est fréquent qu'un grand nombre de données indépendantes de l'architecture soient fournies avec un programme. Cela peut être par exemple des fichiers audio, un ensemble d'icônes, des motifs de papier-peint ou d'autres fichiers graphiques. Si la taille de ces données est négligeable par rapport à la taille du reste du paquet, il est probablement préférable de laisser l'ensemble dans un seul paquet.

Cependant, si cette taille est importante, vous devriez réfléchir à les fournir dans un paquet séparé, indépendant de l'architecture (`_all.deb`). Cela permet ainsi d'éviter la duplication des mêmes données dans de nombreux paquets binaires, un par architecture. Bien que cela ajoute des entrées dans les fichiers `Packages`, cela permet d'économiser une place importante sur les miroirs de Debian. La séparation des données indépendantes de l'architecture réduit également le temps de traitement de `lintian` (voir Contrôle de paquets (« lint »)) lorsqu'il est utilisé sur l'archive Debian en entier.

### 6.9.6. Besoin de paramètres régionaux spécifiques lors de la construction

Si des paramètres régionaux (« `locale` ») sont nécessaires pour la construction d'un paquet, vous pouvez créer un fichier temporaire avec l'astuce suivante.

Si la variable `LOCPATH` est placée sur l'équivalent de `/usr/lib/locale` et `LC_ALL` sur le nom des paramètres régionaux à créer, vous devriez pouvoir obtenir le résultat escompté sans avoir les privilèges du superutilisateur. La séquence ressemblera alors à :

    LOCALE_PATH=debian/tmpdir/usr/lib/locale
    LOCALE_NAME=en_IN
    LOCALE_CHARSET=UTF-8

    mkdir -p $LOCALE_PATH
    localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET

    # Using the locale
    LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date

### 6.9.7. Paquets de transition conformes à `deborphan`

Le programme `deborphan` permet aux utilisateurs d'identifier les paquets pouvant être supprimés sans crainte du système, c'est-à-dire ceux dont aucun paquet ne dépend. Par défaut, l'utilitaire n'effectue sa recherche que parmi les paquets de bibliothèque et les sections `libs` et `oldlibs`, afin de traquer les bibliothèques inutilisées. Cependant, avec le paramètre approprié, il peut rechercher d'autres paquets inutiles.

Par exemple, avec l'option `--guess-dummy`, `deborphan` essaye de trouver tous les paquets de transition qu'il était nécessaire de mettre à niveau, mais qui peuvent maintenant être supprimés. Pour ce faire, `deborphan` recherche les chaînes `dummy` ou `transitional` dans leur description courte, bien que ce serait mieux de rechercher les deux, dans la mesure où il y a des paquets `dummy` ou `transitional` qui ont d'autres finalités.

Ainsi, lorsque vous avez besoin de créer un tel paquet, veuillez prendre soin d'ajouter `transitional dummy package` à sa description courte pour rendre ce statut explicite. Il est facile de trouver des exemples avec les commandes `apt-cache search .|grep dummy` ou `apt-cache search .|grep transitional`.

De même, vous devriez configurer sa section en `oldlibs` et sa priorité en `optional` afin de faciliter le travail de `deborphan`.

### 6.9.8. Meilleures pratiques pour les fichiers `.orig.tar.{gz,bz2,xz}`

Il existe deux sortes différentes d'archives source d'origine. Les sources originelles (« `pristine` ») et les sources reconstruites (« `repackaged` »).

#### 6.9.8.1. Source originelle (« `pristine` »)

La caractéristique définissant une archive source originelle est que le fichier `.orig.tar.{gz,bz2,xz}` est strictement identique à l'archive fournie par l'auteur amont. [1]. Cela permet d'utiliser des sommes de contrôle pour vérifier que toutes les modifications effectuées entre la version Debian et la version amont sont contenues dans le fichier de différences Debian. De même, si la taille des sources d'origine est importante, les auteurs amont et tous ceux qui disposent de l'archive amont d'origine peuvent économiser du temps de téléchargement s'ils souhaitent contrôler le paquet en détail.

Il n'existe pas de convention universellement acceptée pour la structure de répertoires que devraient adopter les auteurs amont dans les archives qu'ils publient, mais `dpkg-source` peut de toute manière traiter la plupart des archives amont comme des sources originelles. La stratégie de cette commande est la suivante :

1. elle extrait l'archive dans un répertoire temporaire :

       zcat path/to/packagename_upstream-version.orig.tar.gz | tar xf -

2. si, après cela, le répertoire temporaire ne contient qu'un seul répertoire sans fichiers, `dpkg-source` renomme ce répertoire en nomdupaquet`-`version-amont`(.orig)`. Le nom du répertoire parent de l'archive tar n'a pas d'importance et est oublié ;

3. si ce n'est pas le cas, l'archive amont a été créée sans répertoire parent (honte à l'auteur amont !). Dans ce cas, `dpkg-source` renomme le répertoire temporaire lui-même en nomdupaquet`-`version-amont`(.orig)`.

#### 6.9.8.2. Source amont reconstruite

Vous devriez envoyer les paquets avec une archive source inchangée, dans la mesure du possible. Il existe cependant plusieurs raisons qui peuvent rendre cela impossible. C'est notamment le cas si les auteurs amont ne distribuent pas d'archive tar compressée du tout ou si l'archive amont contient des parties non conformes aux principes du logiciel libre selon Debian, qui doivent être supprimées avant l'envoi.

Dans ces cas, les responsables doivent construire eux-mêmes une archive `.orig.tar.{gz,bz2,xz}`. Cette archive sera appelée une archive amont reconstruite. Il est important de noter qu'elle reste différente d'un paquet natif. Une archive reconstruite est toujours fournie avec les changements propres à Debian dans un fichier `.diff.gz` ou `.debian.tar.{gz,bz2,xz}` séparé et son numéro de version est toujours composé de upstream-version et debian-version.

Il peut exister des cas où il est souhaitable de reconstruire une archive source alors que les auteurs amont fournissent bien une archive `.tar.{gz,bz2,xz}` qui pourrait être utilisée directement. Le plus évident est la recherche d'un gain de place significatif par recompression ou par suppression de scories inutiles de l'archive source d'origine. Il est important que le responsable exerce avec discernement son propre jugement et soit prêt à le justifier si l'archive source est reconstruite alors qu'elle aurait pu être fournie telle quelle.

Un fichier `.orig.tar.{gz,bz2,xz}` reconstruit :

1. should be documented in the resulting source package. Detailed information on how the repackaged source was obtained, and on how this can be reproduced should be provided in `debian/copyright`, ideally in a way that can be done automatically with uscan. If that really doesn't work, at least provide a `get-orig-source` target in your `debian/rules` file that repeats the process, even though that was actually deprecated in the 4.1.4 version of the Debian policy.

2. ne devrait pas contenir de fichier non distribué par les auteurs amont, ou dont vous avez modifié le contenu ; [2]

3. should, except where impossible for legal reasons, preserve the entire building and portability infrastructure provided by the upstream author. For example, it is not a sufficient reason for omitting a file that it is used only when building on MS-DOS. Similarly, a `Makefile` provided by upstream should not be omitted even if the first thing your `debian/rules` does is to overwrite it by running a configure script.

   (Raison : les utilisateurs Debian ont l'habitude, pour compiler des logiciels sur des systèmes non Debian, de prendre les sources depuis les miroirs Debian plutôt que d'essayer de trouver le dépôt officiel amont) ;

4. may use packagename`-`upstream-version`+dfsg` (or any other suffix which is added to the tarball name) as the name of the top-level directory in its tarball. This makes it possible to distinguish pristine tarballs from repackaged ones.

5. devrait être compressé avec `xz` (ou `gzip` ou `bzip`) et utiliser le taux de compression maximal.

#### 6.9.8.3. Modification de fichier binaire

Sometimes it is necessary to change binary files contained in the original tarball, or to add binary files that are not in it. This is fully supported when using source packages in “3.0 (quilt)” format; see the dpkg-source(1) manual page for details. When using the older format “1.0”, binary files can't be stored in the `.diff.gz` so you must store a `uuencode`d (or similar) version of the file(s) and decode it at build time in `debian/rules` (and move it in its official location).

### 6.9.9. Meilleures pratiques pour les paquets de débogage

Un paquet de débogage est un paquet qui contient des informations supplémentaires que `gdb` peut utiliser. Puisque les binaires de Debian sont élagués par défaut, les informations de débogage, comme les noms de fonction et les numéros de ligne, ne sont pas disponibles lors de l'utilisation de `gdb` sur les paquets binaires. Les paquets de débogage permettent aux utilisateurs, qui ont besoin de ces informations de débogage complémentaires, d'ajouter ces informations supplémentaires et d’éviter d’augmenter la taille d'un système normal.

Les paquets de débogage contiennent des symboles de débogage distincts que `gdb` peut trouver et charger à la volée lors du débogage d'un programme ou d'une bibliothèque. Par convention dans Debian, ces symboles sont conservés dans `/usr/lib/debug/`chemin, où chemin est l'arborescence vers l'exécutable ou la bibliothèque. Par exemple, les symboles de débogage pour `/usr/bin/truc` sont dans `/usr/lib/debug/usr/bin/truc`, et les symboles de débogage pour `/usr/lib/libtruc.so.1` sont dans `/usr/lib/debug/usr/lib/libtruc.so.1`.

#### 6.9.9.1. Paquets de débogage créés automatiquement

Les paquets de symboles de débogage peuvent être créés automatiquement pour n’importe quel paquet binaire contenant des exécutables, et sauf cas pathologiques, il ne devrait plus être nécessaire d’utiliser l’ancienne méthode de création manuelle. Le nom de paquet pour un nom de paquet de symboles de débogage généré automatiquement se termine par `-dbgsym`.

Les paquets `dbgsym` ne sont pas installés dans des archives standard, mais dans des archives spéciales. Cela signifie que si vous avez besoin de symboles de débogage pour le débogage, vous devez ajouter ces archives dans votre configuration d’apt et puis installer le paquet `dbgsym` qui vous intéresse. Veuillez lire https://wiki.debian.org/HowToGetABacktrace pour connaître la manière de faire.

#### 6.9.9.2. Paquets -dbg manuels

Avant l’introduction des paquets automatiques `dbgsym`, les paquets de débogage devaient être créés manuellement. Le nom de ces paquets se terminent par `-dbg`. Il est recommandé de migrer de tels anciens paquets vers les nouveaux paquets `dbgsym` autant que possible. La procédure de conversion est décrite dans https://wiki.debian.org/AutomaticDebugPackages, mais l’idée générale est d’utiliser le commutateur `--dbgsym-migration='pkgname-dbg (<< currentversion~)'` de la commande `dh_strip`.

Cependant, parfois il n’est pas possible de convertir vers les nouveaux paquets `dbgsym`, ou vous rencontrerez les anciens paquets manuels -dbg dans les archives, donc vous devrez les gérer. Il n’est pas recommandé de créer des paquets -dbg pour les nouveaux paquets, sauf si les paquets automatiques ne fonctionnent pas pour une raison quelconque.

Une raison peut être que les paquets de débogage contiennent une construction spéciale de débogage d’une bibliothèque ou autre binaire. Cependant, généralement séparer des informations de débogage des binaires déjà construits est suffisant et économisera de l’espace au moment de la compilation.

C’est le cas, par exemple, pour les symboles de débogage des extensions de Python. Pour l’instant, la façon correcte d’empaqueter les symboles de débogage des extensions de Python est d’utiliser les paquets `-dbg` comme décrit dans https://wiki.debian.org/Python/DbgBuilds.

Pour créer des paquets `-dbg`, le responsable doit les stipuler explicitement dans `debian/control`.

Les symboles de débogage peuvent être extraits d'un fichier objet à l'aide de `objcopy --only-keep-debug`. Ensuite les informations de débogage peuvent être supprimées du fichier objet et `objcopy --add-gnu-debuglink` peut être utilisé pour préciser le chemin vers le fichier contenant les symboles de débogage. objcopy 1 explique en détail le fonctionnement.

Remarquez que le paquet de débogage devrait dépendre du paquet dont il fournit les symboles de débogage, et que cette dépendance devrait être spécifique à la version. Par exemple

    Depends: libfoo (= ${binary:Version})

La commande `dh_strip` de `debhelper` permet de créer les paquets de débogage et prend soin d'utiliser `objcopy` pour séparer les symboles de débogage à votre place. Si le paquet utilise `debhelper/9.20151219`, ou une version plus récente, inutile de faire quelque chose. `debhelper` créera les paquets de débogage (sous forme `paquet`-dbgsym) pour vous sans modifications supplémentaires dans votre paquet source.

### 6.9.10. Meilleures pratiques pour les métapaquets

Un métapaquet est un paquet quasiment vide qui facilite l'installation d'un ensemble de paquets cohérents qui peut évoluer avec le temps. Il atteint cet objectif en dépendant de tous les paquets de l'ensemble. Grâce à la puissance d'apt, le responsable du métapaquet peut configurer les dépendances et le système de l'utilisateur obtiendra automatiquement les paquets supplémentaires. Les paquets devenus inutiles qui avaient été installés automatiquement seront aussi marqués comme candidats à la suppression (et même automatiquement supprimés par `aptitude`). Par exemple, `gnome` et `linux-image-amd64` sont deux métapaquets (construits par les paquets source `meta-gnome2` et `linux-latest`).

La description longue du métapaquet doit clairement expliquer son objectif, afin d'informer les utilisateurs sur ce qu'ils perdront s'ils suppriment le paquet. Il est recommandé d'être explicite sur les conséquences. C'est tout particulièrement important pour les métapaquets installés lors de l'installation initiale qui n'ont pas été installés explicitement par l'utilisateur. Ils ont tendance à être importants pour garantir les mises à niveau du système et la description devrait essayer de dissuader les utilisateurs de les désinstaller pour éviter d'éventuels dommages.

[1]

Il est impossible d'empêcher les auteurs amont de modifier l'archive qu'ils distribuent sans également incrémenter le numéro de version. Il est donc impossible de garantir qu'une archive originelle est identique à ce que l'auteur amont distribue à un instant donné. Tout ce qu'il est possible de garantir est qu'elle a été identique à ce que les auteurs amont ont distribué à un moment donné. Si une différence apparaît plus tard (par exemple si les auteurs amont découvrent ne pas avoir utilisé la compression maximale dans leur distribution d'origine et la recompresse, c'est tout simplement dommage. Comme il n'existe pas de méthode adaptée pour envoyer un nouveau fichier `.orig.tar.{gz,bz2,xz}` pour la même version, il est même totalement inutile de traiter cette situation comme un bogue.

[2]

Avec pour exception particulière, si l'omission de fichiers non libres provoque une erreur de compilation du source sans l'aide du diff Debian, il peut être pertinent de modifier les fichiers pour enlever les portions non libres ou d'expliquer la situation dans un fichier `README.source` à la racine de l'arbre des sources. Veuillez dans ce cas encourager l'auteur amont à rendre les portions non libres faciles à séparer du reste des sources.