Table des matières
debian/rulesdebian/controldebian/changelogdebconforig.tar.gzLa qualité de Debian est largement due à la Charte Debian qui définit les prérequis explicites 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 la construction de paquets. 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 pou rles mainteneurs Debian. La majorité de son contenu est constitué 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.
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
mainteneurs s'occupent généralement le plus.
La justification à l'utilisation de 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'installaiton d'entrées de menu, il est nécessaire de
placer le fichier dans /usr/lib/menu (ou
/usr/lib/menu des fichiers de menu exécutables, s'il en
existe), puis d'ajouter des commandes aux scripts des mainteneurs pour
enregistrer ou désenregistrer les entrées de menu. Comme cette action est
commune à de très nombreux paquets, pourquoi faudrait-il que chaque
mainteneur ait à réécrire ses propres méthodes pour cela, 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 d'être compatible avec 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.
Annexe A, Aperçu des outils du responsable Debian contient un certain nombre d'assistants variés. Le
système le plus répandu et (selon nous) 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, en
obligeant à 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 istalle 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.
Pour démarrer avec debhelper, il est
conseillé de lire debhelper(1) et de consulter les exemples
fournis avec le paquet. dh_make, fourni avec le paquet
dh-make (voir Section A.3.3, « dh-make » ) peut être utilisé pour convertir un paquet source
originel en paquet géré par debhelper. Cette méthode rapide ne doit
cependant pas se substituer à une compréhension individuelle des commandes
dh_*. Si vous utilisez un assistant, vous devez prendre
le temps de l'apprendre, pour comprendre ses besoins et son comportement.
Certains mainteneurs pensent que l'utilisation de fichiers
debian/rules sans assistants est préférable car elle
évite d'avoir à apprendre les subtilité de ces systèmes
d'assistance. Utiliser l'une ou l'autre méthode est un entièrement à la
discrétion du mainteneur d'un paquet qui devrait utiliser la méthode qui lui
convient le mieux. De nombreux exemples de fichiers
debian/rules qui n'utilisent pas d'assistants sont
disponibles à l'adresse http://arch.debian.org/arch/private/srivasta/.
Les paquets complexes ont souvent de nombreux bogues qui doivent être gérés
par le mainteneur. Si certains de ces bogues sont corrigés par des
modifications effectuées directement dans le code source, sans discernement,
il peut devenir difficile de retrouver l'origine et la motivation de ces
modifications. Cela peut également rendre bien plus complexe l'intégration
d'une nouvelle version amont qui pourrait inclure certaines de ces
modifications (mais pas toutes). Il est en effet alors quasiment impossible
de reprendre le jeu initial de changements (p. ex. dans le fichier
.diff.gz) et supprimer ceux qui correspondent à des
correctifs appliqués par le mainteneur amont.
Unfortunately, the packaging system as such currently doesn't provide for
separating the patches into several files. Nevertheless, there are ways to
separate patches: the patch files are shipped within the Debian patch file
(.diff.gz), usually within the
debian/ directory. The only difference is that they
aren't applied immediately by dpkg-source, but by the
build rule of debian/rules, through
a dependency on the patch rule. Conversely, they are
reverted in the clean rule, through a dependency on the
unpatch rule.
quilt is the recommended tool for this. It does all of
the above, and also allows to manage patch series. See the quilt package for more information.
There are other tools to manage patches, like dpatch, and
the patch system integrated with cdbs.
A seul paquet source créera souvent plusieurs paquets binaires, soit pour
fournir plusieurs variantes du même logiciels (p. ex. le paquet source
vim) ou pour répartir les fichiers
en plusieurs paquets plus petits au lieu d'un seul paquet monolithique (ce
qui peut permettre à un utilisateur de d'installer que les éléments
nécessaires et donc préserver l'espace disque).
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,
avec la gestion manuelle de l'ensemble des actions dans le fichier
debian/rules géré manuellement.
Les conseils qui suivent sont destinés au fichier
debian/control. Ils complètent la Charte Debian
pour ce qui concerne 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. Section 6.2.1, « Conseils généraux pour les descriptions de paquets » donne des
indications communes à ces deux parties, Section 6.2.2, « Le résumé, ou description courte, d'un paquet »
donne des indications spécifiques pour le résumé et Section 6.2.3, « La description longue » donne des indications pour la description.
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, tels que les éditeurs, doivent avoir une description accessible à tout utilisateur.
Un examen général des description 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 des recommendations pour rester accessibles à 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>.
Policy says the synopsis line (the short description) must be concise, not repeating the package name, but also informative.
The synopsis functions as a phrase describing the package, not a complete sentence, so sentential punctuation is inappropriate: it does not need extra capital letters or a final period (full stop). It should also omit any initial indefinite or definite article - "a", "an", or "the". Thus for instance:
Package: libeg0 Description: exemplification support library
Technically this is a noun phrase minus articles, as opposed to a verb phrase. A good heuristic is that it should be possible to substitute the package name and synopsis into this formula:
The package name provides {a,an,the,some}
synopsis.
Sets of related packages may use an alternative scheme that divides the synopsis into two parts, the first a description of the whole suite and the second a summary of the package's role within it:
Package: eg-tools Description: simple exemplification system (utilities) Package: eg-doc Description: simple exemplification system - documentation
These synopses follow a modified formula. Where a package
"name" has a synopsis
"suite (role)" or
"suite - role", the
elements should be phrased so that they fit into the formula:
The package name provides {a,an,the}
role for the suite.
La description longue est l'information principale disponible pour les utilisateurs avant qu'ils ne décident d'installer un paquet. Elle doit fournir toute l'information nécessaire pour détermienr 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 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 (p. ex., « 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 (p. ex., « ceci est le client destiné au serveur toto ») ?
Veillez à éviter les erreurs d'orthographe et de grammaire. Vérifier
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 attente 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 : ceci est un agent utilisateur pour le courrier électronique, avec une interface répide 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é avec 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 focntionnalités ? Des fonctionnalités différentes ? Pourquoi devrais-je choisir ce paquet ?
Il est recommandé d'ajouter l'URL d'accès à la page d'accueil du paquet dans
le champ Homepage de la section
Sourcedu fichier
debian/control. L'ajout de cette information à la
description même du paquet est une pratique considérée comme obsolète.
Des champs supplémentaires permettent d'indiquer l'emplacement du système de
gestion de versions dans debian/control.
La valeur de ce champ doit être une URL http:// 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 (p. ex. à la recherche d'un correctif qui
corrige un bogue marqué pending dans le système de suivi
des bogues.
La valeur de ce champ doit être une chaîne identifiant sans équivoque
l'emplacement du dépôt de gestion de versions utilisé pour la maintenance de
ce paquet, s'il est disponible. * doit être rempalcé par
le système de gestion de versions. Les systèmes suivants sont actuellement
gérés par le système de suivi des paquets : arch,
bzr (Bazaar), cvs,
darcs, git, hg
(Mercurial), mtn (Monotone), svn
(Subversion). Il est possible d'indiquer plusieurs champs VCS pour le même
paquet : ils seront alors tous mentionnés dans l'interface web du système de
suivi des paquets.
Cette information est destiné 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éveloppemnt (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 snonyme 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 Subversion
du paquet vim. Veuillez noter que
l'URL a la forme svn:// (au lieu de
svn+ssh://) et pointe sur la branche
trunk/. Une utilisation des champs
Vcs-Browser et Homepage, décrits
précédemments, est aussi indiquée.
Source: vim Section: editors Priority: optional <snip> Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim Homepage: http://www.vim.org
Les indications de cette partie complètent la Charte Debian pour ce qui concerne les fichiers de journaux de changements (« changelog »).
La document de suivi des modifications ( « changelog ») documente uniquement les changement 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 (p. ex. 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. Cel 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 Section 5.8.4, « When bugs are closed by new uploads » pour plus d'informations.
Les entrée de journal des modifications ne devraient pas documenter les points spécifiques de la réalisation du paquet (« si vous cherchez le fichief toto.conf, il est situé dans /etc/titi ») car les administateurs 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 mavaise habitude. Veuillez consulter Section 5.8.4, « When bugs are closed by new uploads » .
Les entrées du journal des modifications ne devraient pas être utilisées pour des discussions variées avec les émetteurs des rapports de bogues (p. ex. : « 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 encours du paquet. Veuillez vous reporter à Section 5.8.2, « Responding to bugs » pour plus d'informations sur l'utilisation du système de gestion des bogues.
Une tradition assez ancienne veut que les bogues fixés dans les NMU soient acquittés dans la première entrée du journal des modification d'une nouvelle version construite par le mainteneur. 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 modification des NMUs. Il est éventuellement possible de simplement mentionner les NMUs dans votre propre entrée de journal des modifications.
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 FU w/ ancient CRTs.
Trop d'acronymes qui rendent difficile de savoir ce qu'était le « merdoyage » (NdT : FU signifie « fsckup », donc cet exemple ajoute la vulgarité à l'incompréhensibilité) 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 de simplement 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, il n'y a pas de problèmes : il suffit de clôturer 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.
Les nouvelles importantes sur les modifications survenues dans un paquet
peuvent êre palcées dans des fichiers NEWS.Debian. Ces
nouvelles seront arriché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 alors qu'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érisques et chaque entrée utilise un paragraphe
complet plutôt que les mentions succinctes qui prendraient pas 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, au contraire du journal des modifications. Voici un exemple d'un
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/.
Il est compressé et porte toujours ce nom même pou rles paquets Debian
natifs. Si vous utilisez paquet/NEWS.Debian.gzdebhelper,
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 !
Les scripts du responsable (« maintainer scripts ») sont les fichiers
debian/postinst, debian/preinst,
debian/prerm and
debian/postrm. Ces scripts peuvent prendre en charge
les phases d'installation ou de désinstallation non autonatiquement gérées
dans la phasesla création ou la suppression de fichiers ou de
répertoires. Les instruction qui suivent complètent celles de la charte
Debian.
Les scripts du responsable doivent être robustes. 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 (p. ex. dans des tuyaux) pour des besoins de journalisation. Il est donc recommandé qu'il 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.
Vous devriez garder les scripts du responsable 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 reponsable, 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 qu'il a supprimé tous les fichiers qu'il a créé, directement ou indirectement dans ses scripts du responsable.
Si vous avez besoin de vérifier l'existence d'une commande, vous devriez utiliser quelque chose comme
if [ -x /usr/sbin/install-docs ]; then ...
Si vous ne voulez pas coder en dur le chemin d'une commande dans vos scripts de responsable, la fonction shell conforme à POSIX suivante peut vous aider :
pathfind() {
OLDIFS="$IFS"
IFS=:
for p in $PATH; do
if [ -x "$p/$*" ]; then
IFS="$OLDIFS"
return 0
fi
done
IFS="$OLDIFS"
return 1
}
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, type, et which ne sont
pas conformes à POSIX.
Bien que which soit acceptable car fourni dans le paquet
requis debianutils, il n'est pas
disponible sur la partition racine mais est situé dans le répertoire
/usr/bin au lieu de /bin, ce qui
rend son utilisation impossible si /usr n'est pas
encore monté. De nombreux scripts ne seront toutefois pas affectés par cela,
cependant.
Debconf est un système de gestion de
configuration qui peut être utilisé 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'utilisateurs doivent être prohibées en faveur de debconf, notamment pour permettre des
installations non interactives.
Debconf est un outil très partique
mais souvent mal utilisé. De nombreuses erreurs classiques sotn mentionnées
dans la page de manuel debconf-devel(7). Il est indispensable de lire cette page de manuel avant de
décider d'utiliser debconf. Quelques bonnes pratiques sont également
indiquées dans le présent document.
Les présents conseils 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).
Depuis que debconf est apparu dans
Debian, il a été largement trop utilisé et 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 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 » ou « basse ».
La plupart des responsables de paquets Debian ne sont pas anglophones. Il n'est donc pas nécessairement facile pour eux d'écrire des écrans correctement.
Penez à utiliser, voire abuser, 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 le plus possible le jargon technique.Si certains termes vous sont familiers, ils peuvent être impossible à comprendre pour 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 verbiage.
Les écrans de debconf peuvent être
traduits. Debconf et son paquet
jumeau po-debconf fournissent un
ensemble simple permettant la traduction des écrans par des équipes de
traductions 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).
Avoid changing templates too often. Changing templates text induces more
work to translators which will get their translation fuzzied. A fuzzy
translation is a string for which the original changed since it was
translated, therefore requiring some update by a translator to be usable.
When changes are small enough, the original translation is kept in PO files
but marked as fuzzy.
If you plan to do changes to your original templates, please use the
notification system provided with the po-debconf package, namely the
podebconf-report-po, to contact translators. Most active
translators are very responsive and getting their work included along with
your modified templates will save you additional uploads. If you use
gettext-based templates, the translator's name and e-mail addresses are
mentioned in the PO files headers and will be used by
podebconf-report-po.
A recommended use of that utility is:
cd debian/po && podebconf-report-po --languageteam --withtranslators --call --deadline="+10 days"
This command will first synchronize the PO and POT files in debian/po with
the templates files listed in debian/po/POTFILES.in.
Then, it will send a call for translation updates to the language team
(mentioned in the Language-Team field of each PO file)
as well as the last translator (mentioned in
Last-translator). Finally, it will also send a call for
new translations, in the <debian-i18n@lists.debian.org> mailing list.
Giving a deadline to translators is always appreciated, so that they can organize their work. Please remember that some translation teams have a formalized translate/review process and a delay lower than 10 days is considered as unreasonable. A shorter delay puts too much pressure on translation teams and should be kept for very minor changes.
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>.
When the text of a debconf template is corrected and you are sure that the change does not affect translations, please be kind to translators and unfuzzy their translations.
Si cela n'est pas fait, l'ensemble de l'écran debconf ne sera plus traduit tant qu'un traducteur n'aura pas réenvoyé un fichier corrigé.
To unfuzzy translations, you can use two methods. The first method does preventive search and replace actions in the PO files. The latter uses gettext utilities to unfuzzy strings.
Preventive unfuzzy method:
Try finding a complete translation file before the change:
for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done
The file only showing translated items will be used as the reference file. If there is none (which should not happen if you take care to properly interact with translators), you should use the file with the most translated strings.
Identify the needed change. In this example, let's assume the change is
about fixing a typo in the word typo which was
inadvertently written as tpyo. Therefore, the change is
s/tpyo/typo.
Check that this change is only applied to the place where you really intend to make it and not in any other place where the original string is appropriate. This specifically applies to change in punctuation, for instance.
Modify all PO files by using sed. The use of that command is recommended over any text editor to guarantee that the files encoding will not be broken by the edit action.
cd debian/po for i in *.po; do sed -i 's/tpyo/typo/g' $i; done
Change the debconf template file to fix the typo.
Run debconf-updatepo
Check the foo.po reference file. Its statistics should
not be changed:
msgfmt -o /dev/null --statistics debian/po/foo.po
<debian-i18n@lists.debian.org> mailing list.
Gettext utilities method:
Déplacez les fichiers PO incomplets à un endroit temporaire. Les fichiers
peuvent être contrôlés avec la commande suivante (qui nécessite
l'installation du paquet gettext) :
for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done
déplacez tous les fichiers qui indiquent comporter des chaînes floues (fuzzy) dans un répertoire temporaire. Les fichiers qui ne comportent pas de chaînes floues (seulement des chaînes traduites ou non traduites) peuvent être laissés en place.
maintenant et pas avant, vous pouvez corriger le fichier « templates » en vous assurant à nouveau que les traductions ne risquent pas d'être affectées (des fautes de frappes, des erreurs grammaticales et parfois des erreurs typographiques ne posent en général pas de problèmes).
exécutez la commande debconf-updatepo. Cette commande va rendre floues les traductions des chaînes que vous avez modifiées. Cela peut être contrôlé avec la commande ci-dessus à nouveau.
utilisez la commande suivante :
for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done
replacez à nouveau dans debian/po les fichiers
précédemment déplacés.
exécutez la commande debconf-updatepo à nouveau
Templates text should not make reference to widgets belonging to some debconf interfaces. Sentences like If you answer Yes... have no meaning for users of graphical interfaces which use checkboxes for boolean questions.
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 mainteneur (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.
You should avoid the use of first person (I will do this... or We recommend...). The computer is not a person and the Debconf templates do not speak for the Debian developers. You should use neutral construction. Those of you who already wrote scientific publications, just write your templates like you would write a scientific paper. However, try using active voice if still possible, like Enable this if ... instead of This can be enabled if....
Les informations présentées dans cette partie proviennent pour l'essentiel de la page de manuel debconf-devel(7)
offre un champ de saisie où l'utilisateur peut entrer n'importe quelle chaîne de caractère.
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 donnes dès que possible.
offre un choix vrai/faux. Veuillez noter que c'est bien d'un choix vrai/faux, pas oui/non...
A choice between one of a number of values. The choices must be specified
in a field named 'Choices'. Separate the possible values with commas and
spaces, like this: Choices: yes, no, maybe.
If choices are translatable strings, the 'Choices' field may be marked as
translatable by using __Choices. The double underscore
will split out each choice in a separate string.
The po-debconf system also offers interesting possibilities to only mark some choices as translatable. Example:
Template: foo/bar Type: Select #flag:translate:3 __Choices: PAL, SECAM, Other _Description: TV standard: Please choose the TV standard used in your country.
In that example, only the 'Other' string is translatable while others are acronyms that should not be translated. The above allows only 'Other' to be included in PO and POT files.
The debconf templates flag system offers many such possibilities. The po-debconf(7) manual page lists all these possibilities.
similaire au type « select », mais permet de choisir plusieurs (ou aucune) valeurs parmi la liste de choix.
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 est visible et notamment interrompra l'installation en attente qu'une touche soit appuyée, voire envoyer la note par courrier électronique dans certains cas.
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 (ainsi l'interface « dialog » 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.
Les descriptions de modèles 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 (environ 50 caractères) afin de pouvoir être gérée par la majorité des interfaces de debconf. La garder courte facilite également le travail des traducteurs car les traductions sont en général 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 « Que voulez-vous faire maintenant ? »
La description courte ne doit pas nécessairement être une phrase entière. Cela 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..et 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. Un maximum de 20 lignes est une limite que vous ne devriez pas dépasser car, avec l'interface standard « dialog », les utilisateurs devront monter et descendre avec des ascenseurs, ce qui sera omis par la plupart des utilisateurs.
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.).
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.
Pas d'indication particulière si ce n'est choisir le type adapté en se référant à la section précédente.
Vous trouverez ici des instruction particulières pour l'écriture du champ Description (parties courtes et longue) selon le type de modèle.
La description courte est une invite et pas un titre. Il faut éviter la forme interrogative (« Adresse IP ? ») et préférer 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 répéter la même demande. Utilisez des phrases complètes. Un style d'écriture abrégé est déconseillé.
La partie courte doit utiliser la forme interrogative 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 vont être plus longues que la version originale).
Il est important d'éviter de faire référence aux objets de certains interfaces spécifiques. Une erreur classique est d'utiliser une construction comme « If you answer Yes... » (« Si vous répondez Oui... »).
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 également indiquer que l'utilisateur peut choisir plus d'un parmi les choix disponibles, dans le cas de modèles « multiselect » (bien que l'interface rende en général cela tout à fait clair).
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 conseillé d'éviter d'y utiliser un style abrégé.
N'abusez pas de debconf.. Les notes sont un des abus les plus fréquents de debconf. Comm eindiqué dans la page de manuel de debconf, elle devraient être réservée pour avertir les utilisateurs de problème très importants. Les fichiers NEWS.Debian ou README.Debian sont les endroits appropriés pour l'information qu'affichent la majorité des notes. Si, à la lecture de ces conseils, vous envisagez de convertir vos modèles de type note en entrée dans NEWS.Debian ou README.Debian, pensez à conserver d'éventuelles traductions existantes.
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.
Si la valeur par défaut d'un modèle « select » peut être dépendante de la langue utilisée (par exemple s'il s'agit du choix d'une langue par défaut), pensez à utiliser l'astuce « DefaultChoice ».
This special field allow translators to put the most appropriate choice according to their own language. It will become the default choice when their language is used while your own mentioned Default Choice will be used when using English.
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 FORM of your language # For instance, the french translator will need to put French (fr) here. _DefaultChoice: English (en)[ 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 DefaultChoice est parfois déroutante pour les traducteurs qui doivent y mettre leur propre choix et non une simple traduction.
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, pensez à rendre ce champ traduisible si vous pensez qu'il peut l'être.
Si la valeur par défaut peut dépendre de la lanue ou du pays (par exemple une langue par défaut dans un programme), pensez à utiliser le type « _DefaultChoice » documenté dans la page de manuel po-debconf(7).
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 rend plus
simple le travail des traducteurs et des responsables et des scripts de
transition sont fournis.
Avec po-debconf, les traductions
sont gérées dans des fichiers po (hérités des
techniques de traduction utilisées avec gettext). Des
fichiers modèles contiennent les messages d'origine et les champs à traduire
y sont marqués spécifiquement. Lorsque le contenu d'un champ traduisible est
modifié, l'emploi de la commande debconf-updatepo permet
d'indiquer que la traduction a besoin d'une mise à jour par les
traducteurs. Ensuite, au moment de la construction du paquet, le programme
dh_installdebconf s'occupe des opérations nécessaires
pour ajouter le modèle avec les traductions à jour dans les paquets
binaires. Vous pouvez consulter la page de manuel de po-debconf(7) pour plus d'informations.
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 toute le travail nécessaire, il est possible de faciliter le travail 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 boot-floppies, 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 CVS.
Si vous maintenez de la documentation en format XML ou SGML, il est conseillé d'isoler l'information indépendant 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.
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 applicable à tout paquet qui utilise
autoconf et/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.
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 simple 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.
Les bonnes pratiques pour la maintenance de paquets fournissant des bibliothèques ont été rassemblées dans le guide de gestion des paquets de bibliothèques.
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.
Plusieurs types particuliers de paquets utilisent des chartes spécifiques avec les règles et de bonnes pratiques particulières.
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.
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 considérer de les
fournir dans un paquet séparé, indépendant de l'architecture
(_all.deb). Cela permet ainsi d'aviter 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 Section A.2, « Package lint tools »
) lorsqu'il est utilisé sur l'archive Debian en entier.
Si des paramètres régionaux (« locale ») sont nécessaires pour la construction d'un paquet, vous pouvez créer un fichier temporaire avec cette astuce :
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é dans 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
Deborphan est un programme qui permet aux utilisateurs d'identifier les paquets qui peuvent être supprimés sans crainte du système, c'est à dire ceux dont aucun autre paquet ne dépend. Par défaut, l'utilitaire n'effectue sa recherche que parmi les paquets de bibliothèques et les sections « oldlibs », afin de traquer les bibliothèques inutilisées. Cependant, avec le paramètre approprié, il peut rechercher d'autres paquets inutiles.
Par exemple, le paramètre --guess-dummy de la commande
deborphan permet de rechercher les paquets de transition
qui étaient nécessaires lors de mises à niveau mais peuvent être supprimés
sans problème. Pour cela, il recherche la chaîne « dummy » ou
« transitional » dans leur description courte.
Ainsi, lorsque vous avez besoin de créer un tel paquet, veuillez prendre soin d'ajouter ce texte à sa description courte. Il est facile de trouver des exemples avec les commandes apt-cache search .|grep dummy ou apt-cache search .|grep transitional.
Il existe deux sortes différentes d'archives source d'origine. Les sources originelles (« pristine ») et les sources reconstruites (« repackaged »).
The defining characteristic of a pristine source tarball is that the
.orig.tar.gz file is byte-for-byte identical to a tarball
officially distributed by the upstream author. [5] This makes it possible to use checksums to easily verify that all
changes between Debian's version and upstream's are contained in the Debian
diff. Also, if the original source is huge, upstream authors and others who
already have the upstream tarball can save download time if they want to
inspect your packaging in detail.
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 le plupart des archives amont comme des sources originelles. La stratégie de cette commande est la suivante :
Elle extrait l'archive dans un répertoire temporaire :
zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf -
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é;
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).
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, le responsable doit construire menuellement une archive
.orig.tar.gz . 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
séparé et son numéro de version est toujours composé de
<version-amont> et
<révision-debian>.
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 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 reconstruit
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. It is also a
good idea to provide a get-orig-source target in your
debian/rules file that repeats the process, as
described in the Policy Manual, Main building script:
debian/rules.
should not contain any file that does not come from the upstream author(s), or whose contents has been changed by you. [6]
should, except where impossible for legal
reasons, preserve the entire building and portablility 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.
(Rationale: It is common for Debian users who need to build software for non-Debian platforms to fetch the source from a Debian mirror rather than trying to locate a canonical upstream distribution point).
should use
<packagename>-<upstream-version>.orig as the
name of the top-level directory in its tarball. This makes it possible to
distinguish pristine tarballs from repackaged ones.
should be gzipped with maximal compression.
The canonical way to meet the latter two points is to let
dpkg-source -b construct the repackaged tarball from an
unpacked directory.
Sometimes it is necessary to change binary files contained in the original
tarball, or to add binary files that are not in it. If this is done by
simply copying the files into the debianized source tree,
dpkg-source will not be able to handle this. On the
other hand, according to the guidelines given above, you cannot include such
a changed binary file in a repackaged orig.tar.gz.
Instead, include the file in the debian directory in
uuencoded (or similar) form [7]. The file would then be decoded and copied to its place during the
build process. Thus the change will be visible quite easy.
Some packages use dbs to manage patches to their upstream
source, and always create a new orig.tar.gz file that
contains the real orig.tar.gz in its toplevel directory.
This is questionable with respect to the preference for pristine source. On
the other hand, it is easy to modify or add binary files in this case: Just
put them into the newly created orig.tar.gz file, besides
the real one, and copy them to the right place during the build process.
A debug package is a package with a name ending in -dbg, that contains additional information that gdb can use. Since Debian binaries are stripped by default, debugging information, including function names and line numbers, is otherwise not available when running gdb on Debian binaries. Debug packages allow users who need this additional debugging information to install it, without bloating a regular system with the information.
It is up to a package's maintainer whether to create a debug package or not. Maintainers are encouraged to create debug packages for library packages, since this can aid in debugging many programs linked to a library. In general, debug packages do not need to be added for all programs; doing so would bloat the archive. But if a maintainer finds that users often need a debugging version of a program, it can be worthwhile to make a debug package for it. Programs that are core infrastructure, such as apache and the X server are also good candidates for debug packages.
Some debug packages may contain an entire special debugging build of a
library or other binary, but most of them can save space and build time by
instead containing separated debugging symbols that gdb can find and load on
the fly when debugging a program or library. The convention in Debian is to
keep these symbols in
/usr/lib/debug/, where
pathpath is the path to the executable or library.
For example, debugging symbols for /usr/bin/foo go in
/usr/lib/debug/usr/bin/foo, and debugging symbols for
/usr/lib/libfoo.so.1 go in
/usr/lib/debug/usr/lib/libfoo.so.1.
The debugging symbols can be extracted from an object file using objcopy --only-keep-debug. Then the object file can be stripped, and objcopy --add-gnu-debuglink used to specify the path to the debugging symbol file. objcopy(1) explains in detail how this works.
The dh_strip command in debhelper supports creating debug
packages, and can take care of using objcopy to separate
out the debugging symbols for you. If your package uses debhelper, all you
need to do is call dh_strip --dbg-package=libfoo-dbg, and
add an entry to debian/control for the debug package.
Note that the debug package should depend on the package that it provides debugging symbols for, and this dependency should be versioned. For example:
Depends: libfoo (= ${binary:Version})
[5] We cannot prevent upstream authors from changing the tarball they distribute
without also incrementing the version number, so there can be no guarantee
that a pristine tarball is identical to what upstream
currently distributing at any point in time. All that
can be expected is that it is identical to something that upstream once
did distribute. If a difference arises later (say, if
upstream notices that he wasn't using maximal compression in his original
distribution and then re-gzips it), that's just too bad.
Since there is no good way to upload a new .orig.tar.gz
for the same version, there is not even any point in treating this situation
as a bug.
[6] As a special exception, if the omission of non-free files would lead to the source failing to build without assistance from the Debian diff, it might be appropriate to instead edit the files, omitting only the non-free parts of them, and/or explain the situation in a README.source file in the root of the source tree. But in that case please also urge the upstream author to make the non-free components easier seperable from the rest of the source.
[7] The file should have a name that makes it clear which binary file it
encodes. Usually, some postfix indicating the encoding should be appended
to the original filename. Note that you don't need to depend on sharutils to get the uudecode
program if you use perl's pack
function. The code could look like
uuencode-file:
perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded
uudecode-file:
perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file)