Table des matières
debian/rules
debian/control
debian/changelog
debconf
debconf
unfuzzy
») des traductions pour des erreurs
typographiques ou de frappe
templates
»).
deborphan
.orig.tar.{gz,bz2,xz}
Debian's quality is largely due to the Debian Policy, which defines explicit baseline requirements that all Debian packages must fulfill. Yet there is also a shared history of experience which goes beyond the Debian Policy, an accumulation of years of experience in packaging. Many very talented people have created great tools, tools which help you, the Debian maintainer, create and maintain excellent packages.
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.
The following recommendations apply to the debian/rules
file. Since debian/rules
controls the build process
and selects the files that go into the package (directly or indirectly),
it's usually the file maintainers spend the most time on.
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.
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 (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
.
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.2, « 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 le connaître, pour comprendre ses besoins et son comportement.
Les paquets complexes ont souvent de nombreux bogues qui doivent être gérés
par le responsable. 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
correctifs. Cela peut également rendre bien plus complexe l'intégration
d'une nouvelle version amont qui pourrait inclure certains de ces correctifs
(mais pas tous). Il est en effet alors quasiment impossible de reprendre le
jeu initial de changements (par exemple dans le fichier
.diff.gz
) et supprimer ceux qui correspondent à des
correctifs appliqués par le responsable amont.
Fortunately, with the source format “3.0 (quilt)” it is now possible to keep
patches separate without having to modify debian/rules
to set up a patch system. Patches are stored in
debian/patches/
and when the source package is unpacked
patches listed in debian/patches/series
are
automatically applied. As the name implies, patches can be managed with
quilt.
Avec l'ancien format source « 1.0 », il est aussi possible de séparer les
correctifs mais un système de correctif dédié doit être utilisé : les
correctifs individualisés sont embarqués dans le fichier général de
correctifs Debian (.diff.gz
), en général à l'intérieur
du répertoire debian/
. La seule différence est que ces
correctifs ne sont pas appliqués directement par
dpkg-source mais par la règle build
de
debian/rules
, à travers une dépendance à la règle
patch
. À l'inverse, les correctifs sont retirés par la
règle clean
, à travers une dépendance à la règle
unpatch
.
quilt is the recommended tool for this. It does all of
the above, and also allows one to manage patch series. See the quilt
package for more information.
D'autres outils existent pour gérer les correctifs, comme
dpatch, et le système de correctif intégré à cdbs
.
Un simple paquet source créera souvent plusieurs paquets binaires, soit pour
fournir plusieurs variantes du même logiciel (par exemple 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 n'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
.
The first case is a bit more difficult since it involves multiple recompiles
of the same software but with different configuration options. The
vim
source package is an example of
how to manage this using a hand-crafted debian/rules
file.
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. Section 6.2.1, « Conseils généraux pour les descriptions de paquets » donne des
indications communes à ces deux parties, Section 6.2.2, « Résumé, ou description courte, d'un paquet »
donne des indications spécifiques pour le résumé et Section 6.2.3, « 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, 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>
.
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
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
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.
The following paragraphs should answer the following questions: Why do I as a user need this package? What other features does the package have? What outstanding features and deficiencies are there compared to other packages (e.g., if you need X, use Y instead)? Is this package related to other packages in some way that is not handled by the package manager (e.g., is this the client for the foo server)?
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é.
How is this package different from the competition? Is it a better implementation? more features? different features? Why should I choose this package?
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.
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 (par exemple à la recherche d'un correctif
qui corrige un bogue marqué pending
(en attente) dans le
système de suivi des bogues.
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). It is allowed to specify different VCS
fields for the same package: they will all be shown in the PTS web
interface.
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 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édemment, 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: https://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 des modifications
(« changelog
»).
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 Section 5.8.4, « Fermeture des rapports de bogue lors des mises à jour » pour plus d'informations.
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 Section 5.13.2, « 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.
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 Section 5.8.4, « 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 bogues (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 Section 5.8.2, « 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.
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.
If for some reason you didn't mention the bug number in a previous changelog entry, there's no problem, just close the bug normally in the BTS. There's no need to touch the changelog file, presuming the description of the fix is already in (this applies to the fixes by the upstream authors/maintainers as well; you don't have to track bugs that they fixed ages ago in your changelog).
* 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 ê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/
.
Il est compressé et porte toujours ce nom même pour les 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 !
Maintainer scripts include the files debian/postinst
,
debian/preinst
, debian/prerm
and
debian/postrm
. These scripts take care of any package
installation or deinstallation setup that isn't handled merely by the
creation or removal of files and directories. The following instructions
supplement the Debian Policy.
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 which 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
, 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é. La plupart des scripts ne seront toutefois pas affectés par
cela.
Debconf
is a configuration
management system that can be used by all the various packaging scripts
(postinst
mainly) to request feedback from the user
concerning how to configure the package. Direct user interactions must now
be avoided in favor of debconf
interaction. This will enable non-interactive installations in the future.
debconf
est un outil très pratique
mais souvent mal utilisé. De nombreuses erreurs classiques sont 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 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).
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é.
Keep usage notes to what they belong: the NEWS.Debian
,
or README.Debian
file. Only use notes for important
notes that may directly affect the package usability. Remember that notes
will always block the install until confirmed or bother the user by email.
Carefully choose the questions' priorities in maintainer scripts. See debconf-devel(7) for details about priorities. Most questions should use medium and low priorities.
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é.
Debconf templates may be translated. Debconf, along with its sister package po-debconf, offers a simple framework for getting templates translated by translation teams or even individuals.
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 template text induces more
work for 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
.
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"
This command will first synchronize the PO and POT files in
debian/po
with the template files listed in
debian/po/POTFILES.in
. Then, it will send a call for
new translations, in the <debian-i18n@lists.debian.org>
mailing list. Finally, it will
also 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
).
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>
.
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
).
Recréez les fichiers POT et PO.
debconf-updatepo
Faites une copie du fichier POT.
cp templates.pot templates.pot.orig
Faites une copie de tous les fichiers PO.
mkdir po_orig; cp *.po po_orig
Modifier les fichiers d'écrans debconf
(templates
) pour
corriger les fautes de frappe.
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.
Abandonnez les traductions approximatives, récupérer celles du répertoire originel.
cp po_orig/*.po .
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
Nettoyage.
rm -rf templates.pot.orig po_orig
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 that 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 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.
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 the active voice if still possible, like Enable this if ... instead of This can be enabled if....
As a way of showing our commitment to our diversity statement, please use gender-neutral constructions in your writing. This means avoiding pronouns like he/she when referring to a role (like "maintainer") whose gender is unknown. Instead, you should use the plural form (singular they).
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ères.
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.
offre un choix du type « vrai » ou « faux ». N'oubliez pas, c'est bien un choix « vrai » ou « faux », pas « oui » ou « non »...
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: truc/bidule 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.
Le système d'indicateur (« flag
») d'écrans debconf
permet de faire de telles choses. La
page de manuel po-debconf(7) documente toutes ces possibilités.
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 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.
This type is designed to handle error messages. It is mostly similar to the note type. Front ends may present it differently (for instance, the dialog front end of cdebconf draws a red screen instead of the usual blue one).
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è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.
The short description should be able to stand on its own. Some interfaces do not show the long description by default, or only if the user explicitly asks for it or even do not show it at all. Avoid things like: "What do you want to do?"
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.).
This field should be used for select and multiselect types. It contains the possible choices that will be presented to users. These choices should be separated by commas.
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 instructions particulières pour l'écriture du champ
Description
(parties courte et longue) selon le type de
modèle.
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é.
The short description should be phrased in the form of a question, which should be kept short and should generally end with a question mark. Terse writing style is permitted and even encouraged if the question is rather long (remember that translations are often longer than original versions).
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... »).
The short description is a prompt and not a title. Do not use useless "Please choose..." constructions. Users are clever enough to figure out they have to choose something... :)
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).
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 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.
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.
If the default value for a select template is likely to vary depending on the user language (for instance, if the choice is a language choice), please use the _Default trick.
This special field allows 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 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:
Note the use of brackets, which allow internal comments in debconf fields. Also note the use of comments, which will show up in files the translators will work with.
Les commentaires sont très utiles car l'astuce
« _Default
» est parfois déroutante pour les traducteurs
qui doivent y mettre leur propre choix et non une simple traduction.
Do NOT use an empty default field. If you don't want to use default values, do not use Default at all.
If you use po-debconf (and you should; see Section 6.5.2.2, « Courtoisie avec les traducteurs »), consider making this field translatable, if you think it may be translated.
Si la valeur par défaut peut dépendre de la langue ou du pays (par exemple
une langue par défaut dans un programme), pensez à utiliser le type
« _Default
» documenté dans la page de manuel
po-debconf(7).
This section contains global information for developers to make translators' lives easier. More information for translators and developers interested in internationalization are available in the Internationalisation and localisation in Debian documentation.
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.
The goal of debconf
was to make
package configuration easier for maintainers and for users. Originally,
translation of debconf templates was handled with
debconf-mergetemplate. However, that technique is now
deprecated; the best way to accomplish debconf
internationalization is by using the
po-debconf
package. This method is
easier both for maintainer and translators; transition scripts are provided.
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 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.
If you maintain XML or SGML documentation, we suggest that you isolate any language-independent information and define those as entities in a separate file that is included by all the different translations. This makes it much easier, for instance, to keep URLs up to date across multiple files.
Some tools (e.g. po4a
, poxml
, or the translate-toolkit
) are specialized in extracting
the translatable material from different formats. They produce PO files, a
format quite common to translators, which permits seeing what needs to be
re-translated when the translated document is updated.
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.
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.
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èque.
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.
The manpages do not need to be written directly in the troff format. Popular source formats are DocBook, POD and reST, which can be converted using xsltproc, pod2man and rst2man respectively. To a lesser extent, the help2man program can also be used to write a stub.
Plusieurs catégories particulières de paquets utilisent des chartes spécifiques avec leurs règles et leurs pratiques d'empaquetage.
Perl related packages have a Perl
policy; some examples of packages following that policy are
libdbd-pg-perl
(binary perl module)
or libmldbm-perl
(arch independent
perl module).
Python related packages have their Python policy; see /usr/share/doc/python/python-policy.txt.gz
in the python
package.
Les paquets liés à Emacs utilisent une charte Emacs.
Les paquets liés à Java utilisent une charte Java.
OCaml related packages have their own policy, found in /usr/share/doc/ocaml/ocaml_packaging_policy.gz
from the ocaml
package. A good
example is the camlzip
source
package.
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.
However, if the size of the data is considerable, consider splitting it out
into a separate, architecture-independent package
(_all.deb
). By doing this, you avoid needless
duplication of the same data into ten or more .debs, one per each
architecture. While this adds some extra overhead into the
Packages
files, it saves a lot of disk space on Debian
mirrors. Separating out architecture-independent data also reduces
processing time of lintian (see Section A.2, « Contrôle de paquets (« lint
») ») when run over the entire Debian archive.
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
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, 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.
De même, vous devriez configurer sa section en oldlibs
et
sa priorité en extra
afin de faciliter le travail de
deborphan.
Il existe deux sortes différentes d'archives source d'origine. Les sources
originelles (« pristine
») et les sources reconstruites
(« repackaged
»).
La caractéristique définissant une archive source originelle et que le
fichier .orig.tar.{gz,bz2,xz}
est strictement identique
à l'archive fournie par l'auteur amont.[5]
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.
There are no universally accepted guidelines that upstream authors follow regarding the directory structure inside their tarball, but dpkg-source is nevertheless able to deal with most upstream tarballs as pristine source. Its strategy is equivalent to the following:
elle extrait l'archive dans un répertoire temporaire :
zcat path/to/nomdupaquet
_version-amont
.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
.
Le nom du répertoire parent de l'archive tar n'a pas d'importance et est
oublié ;
nomdupaquet
-version-amont
(.orig)
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, 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 :
devrait être documenté dans le fichier
source. Des informations détaillées sur la façon dont les sources ont été
obtenues et comment il est possible de refaire l'opération devraient être
fournies dans le fichier debian/copyright
. Il est
également suggéré de fournir une cible get-orig-source
dans le fichier debian/rules
, qui permette de refaire
cette opération, comme indiqué dans la Charte Debian à propos du script de construction
principal : debian/rules
;
ne devrait pas contenir de fichier non distribué par les auteurs amont, ou dont vous avez modifié le contenu ;[6]
devrait, sauf si c'est impossible pour
des raisons légales, préserver l'intégralité de l'infrastructure de
construction et de portabilité fournie par l'auteur amont. Par exemple, il
ne faut pas enlever un fichier sous prétexte qu'il ne sert qu'à la
compilation sur MS-DOS. De même, un Makefile
fourni en
amont n'a pas de raison d'être enlevé si la première action de
debian/rules
est de l'écraser en exécutant un script de
configuration.
(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) ;
devrait utiliser
comme nom de répertoire racine de l'archive. Cela permet de distinguer les
sources originelles des sources reconstruites ;
nomdupaquet
-version-amont
(.orig)
devrait utiliser le taux de compression maximal.
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
uuencoded (or similar) version of the file(s) and decode
it at build time in debian/rules
(and move it in its
official location).
Un paquet de débogage est un paquet dont le nom se termine par « -dbg », et qui contient des informations supplémentaires que gdb peut utiliser. Puisque les informations de débogage, comme les noms de fonction et de numéro de ligne, sont par défaut absentes des paquets binaires Debian, elles ne pourraient autrement pas être disponibles lors de l'utilisation de gdb. Les paquets de débogage permettent aux utilisateurs qui le désirent d'ajouter ces informations de débogage supplémentaires, sans augmenter la taille d'un système normal avec ces informations.
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.
Certains paquets de débogage peuvent contenir une compilation spécifique de
débogage complète d'une bibliothèque ou d'un autre programme, mais la
plupart peuvent préserver de la place et du temps de compilation en
contenant plutôt séparément les symboles de débogage 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 gardés dans
/usr/lib/debug/
, où
chemin
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
.
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.
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
, il suffit d'appeler dh_strip
--dbg-package=libtruc-dbg, et d'ajouter une entrée à
debian/control
pour le paquet de débogage.
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: libtruc (= ${binary:Version})
Un métapaquet est un paquet principalement 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
).
The long description of the meta-package must clearly document its purpose so that the user knows what they will lose if they remove the package. Being explicit about the consequences is recommended. This is particularly important for meta-packages that are installed during initial installation and that have not been explicitly installed by the user. Those tend to be important to ensure smooth system upgrades and the user should be discouraged from uninstalling them to avoid potential breakages.
[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 they weren't using maximal compression in their
original distribution and then re-gzip it), that's just
too bad. Since there is no good way to upload a new
.orig.tar.{gz,bz2,xz}
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 to separate from the
rest of the source.