+<p>
+Parfois, le responsable de version ou un groupe organisé de
+ développeurs peut annoncer une certaine période de temps au cours de laquelle
+ les règles de mise à jour indépendante seront plus souples. Ceci implique
+ habituellement une période plus courte d'attente avant d'envoyer des
+ correctifs et une période de délai plus courte. Il est important de noter que,
+ même au cours de ces « chasses aux bogues », la personne
+ désirant faire la mise à jour indépendante doit remplir des bogues et
+ contacter en premier le développeur, et ensuite seulement passer à
+ l'action.
+
+ <sect1 id="nmu-guidelines">Comment faire une mise à jour indépendante
+ source ?
+<p>
+Les règles qui suivent s'appliquent aux porteurs tant qu'ils jouent le double
+ rôle de correcteur de bogue et de porteur. Si un porteur doit modifier le
+ paquet source, cette mise à jour est automatiquement une mise à jour
+ indépendante source et est soumise aux règles qui suivent. Si un porteur
+ construit un paquet binaire recompilé, les règles sont différentes (voir <ref
+ id="porter-guidelines">.
+<p>
+Tout d'abord, il est capital que ces mises à jour indépendantes soient aussi peu
+ intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
+ modules ou des fichiers, ne déplacez pas les répertoires ; plus
+ généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi
+ petit que possible. Si certaines choses froissent votre sens de l'esthétique,
+ parlez-en au responsable du paquet, au responsable amont ou soumettez un
+ rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
+ pas</em> être effectués lors d'une mise à jour indépendante.
+
+
+ <sect2 id="nmu-version">Numéro de version pour les mises à jour
+ indépendantes sources
+<p>
+Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
+ changer, même pour la plus triviale des modifications. Notre système de
+ gestion de paquets s'appuie sur ces numéros de version.
+<p>
+Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
+ un numéro de version mineur à la partie <var>debian-revision</var> du numéro
+ de version (la partie qui suit le dernier trait d'union). Ce numéro
+ supplémentaire débutera à « 1 ». Prenons pour exemple le paquet
+ « foo » qui porte le numéro de version 1.1-3. Dans l'archive, le
+ fichier de contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
+ version amont est « 1.1 » et la révision Debian est
+ « 3 ». La mise à jour indépendante suivante ajouterait le numéro de
+ version mineur « .1 » au numéro de révision Debian; le nouveau
+ fichier de contrôle du paquet source serait alors
+ <file>foo_1.1-3.1.dsc</file>.
+<p>
+Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro de
+ version au responsable officiel du paquet, ce qui pourrait perturber son
+ travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas
+ été livré par le responsable officiel.
+<p>
+S'il n'y a pas de partie <var>debian-revision</var> dans le numéro de version du
+ paquet, il faut en créer une en démarrant à « 0.1 ». S'il est
+ absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
+ fasse une livraison basée sur une nouvelle version amont, cette personne doit
+ choisir « 0.1 » comme numéro de révision Debian. Le mainteneur du
+ paquet doit, lui, démarrer sa numérotation à « 1 ».
+
+
+ <sect2 id="nmu-changelog">
+ <heading>Les mises à jour indépendantes sources doivent être
+ mentionnées dans le fichier changelog</heading>
+<p>
+Une personne qui fait une mise à jour indépendante source doit ajouter une
+ entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
+ et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
+ comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
+ version livrée.
+<p>
+Par convention, dans le cas d'une mise à jour indépendante source
+ <em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne :
+
+<example>
+ * Non-maintainer upload
+</example>
+
+
+ <sect2 id="nmu-patch">Mise à jour indépendante source et système de
+ suivi des bogues
+<p>
+Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
+ modifications que possible et doit toujours envoyer ses modifications au
+ système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).
+<p>
+Et si vous recompilez simplement le paquet ? Si vous avez simplement besoin
+ de recompiler le paquet pour une seule architecture, vous pouvez faire une
+ NMU binaire seulement comme décrit dans <ref id="binary-only-nmu"> qui ne
+ nécessite pas qu'un correctif soit envoyé. Si vous désirez que le paquet soit
+ recompilé pour toutes les architectures, vous devez alors faire une NMU
+ source et vous devrez envoyer un correctif.
+<p>
+Si la mise à jour indépendante source (<em>source NMU</em>) corrige des bogues,
+ ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système de
+ suivi des bogues plutôt que clos. Par convention, seul le responsable du
+ paquet et la personne qui a ouvert le rapport de bogue peuvent clore ce
+ rapport. Heureusement, le système d'archivage Debian reconnaît les mises à
+ jours indépendantes et positionne correctement le statut des bogues à
+ <em>fixed</em> si la personne qui fait la mise à jour a listé tous les bogues
+ dans le fichier changelog en utilisant la syntaxe <tt>Closes:
+ bug#<var>nnnnn</var></tt> (voir <ref id="upload-bugfix"> pour en savoir plus
+ sur la fermeture de bogue par le fichier <file>changelog</file>). Ce passage
+ au statut <em>fixed</em> assure que chacun sait que le bogue est corrigé par
+ une mise à jour indépendante tout en laissant le rapport de bogue ouvert
+ jusqu'à ce que le responsable du paquet incorpore les modifications de cette
+ mise à jour dans la version officielle du paquet.
+<p>
+Après avoir fait une mise à jour indépendante, il vous faudra aussi ouvrir un
+ nouveau rapport de bogue qui inclura un correctif contenant toutes les
+ modifications que vous avez faites. Sinon, vous pouvez envoyer cette
+ information aux bogues qui sont fixés par votre NMU. Le responsable officiel
+ pourra choisir d'appliquer le correctif, il pourra aussi employer une autre
+ méthode pour régler le problème. Certains bogues sont corrigés dans la
+ version amont, ce qui est une bonne raison pour annuler les modifications
+ d'une mise à jour indépendante. Si le responsable choisit de mettre à jour le
+ paquet plutôt que d'utiliser les correctifs de la mise à jour indépendante,
+ il devra s'assurer que cette nouvelle version corrige effectivement chacun
+ des bogues corrigés dans la mise à jour indépendante.
+<p>
+De plus, le responsable officiel devrait <em>toujours</em> conserver les entrées
+ documentant une mise à jour indépendante dans le fichier
+ <file>changelog</file>.
+
+
+ <sect2 id="nmu-build">Fabriquer une mise à jour indépendante source
+<p>
+Les paquets faisant l'objet d'une mise à jour indépendante source sont
+ construits comme les autres. Sélectionnez une distribution en utilisant les
+ règles décrites dans la section <ref id="distribution"> en suivant toutes les
+ prescriptions de la section <ref id="upload">.
+<p>
+Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt> dans
+ le fichier <file>debian/control</file>. Votre nom, mentionné dans l'entrée du
+ fichier <file>debian/changelog</file> concernant la mise à jour, sera utilisé
+ pour signer le fichier <file>.changes</file>.
+
+ <sect1 id="ack-nmu">Valider une mise à jour indépendante
+<p>
+Si l'un de vos paquets a subi une mise à jour indépendante, vous devez récupérer
+ les changements dans votre copie des sources. Ceci est aisé, vous avez
+ simplement à appliquer le correctif qui vous a été envoyé. Une fois ceci fait,
+ vous devez fermer les bogues qui ont été marqués comme fixés par la mise à
+ jour. Vous pouvez soit les fermer manuellement en envoyant les courriers
+ nécessaires au BTS soit ajouter les <tt>closes: #nnnn</tt> nécessaires dans
+ l'entrée du changelog de votre prochain envoi.
+<p>
+Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une NMU n'est
+ pas une attaque personnelle contre le responsable. C'est une preuve que le
+ paquet est important pour quelqu'un et qu'il est désireux de vous aider dans
+ votre travail, vous devriez donc lui être reconnaissant. Vous pouvez également
+ lui demander s'il serait intéressé pour vous aider sur une base plus régulière
+ comme co-responsable ou responsable de secours (cf. <ref
+ id="collaborative-maint">).
+
+
+
+ <sect id="collaborative-maint">
+ <heading>Maintenance collective</heading>
+<p>
+« Maintenance collective » est un terme décrivant le partage des
+ devoirs de la maintenance d'un paquet Debian par plusieurs personnes. Cette
+ collaboration est presque toujours une bonne idée car il en résulte
+ généralement une meilleure qualité et un temps de correction de bogues plus
+ petit. Il est fortement recommandé que les paquets de priorité
+ <tt>Standard</tt> ou qui font partie de la base aient des co-responsables.
+<p>
+Habituellement, il y a un responsable principal et un ou plusieurs
+ co-responsables. Le responsable principal est celui dont le nom est indiqué
+ dans le champ <tt>Maintainer</tt> du fichier <file>debian/control</file>. Les
+ co-responsables sont tous les autres responsables.
+<p>
+Dans sa forme la plus simple, ajouter un nouveau co-responsable est assez
+ simple :
+<list>
+<item><p> Donner au co-responsable un accès aux sources à partir desquelles vous
+ construisez le paquet. Habituellement, cela implique que vous utilisiez un
+ système de contrôle de version comme <prgn>CVS</prgn> ou
+ <prgn>Subversion</prgn>.
+</item>
+<item><p> Ajouter les nom et adresse correctes du co-responsable au champ
+ <tt>Uploaders</tt> dans la partie globale du fichier
+ <file>debian/control</file>.
+<example>
+Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
+</example>
+</item>
+<item><p>
+ En utilisant le PTS (<ref id="pkg-tracking-system">), les
+ co-responsables devraient s'inscrire eux-mêmes aux paquets sources
+ appropriés.
+</item>
+</list>
+
+ <chapt id="best-pkging-practices">
+ <heading>Les meilleurs pratiques pour la construction des paquets
+<p>
+La qualité de Debian est principalement due à la <url id="&url-debian-policy;"
+name="charte Debian"> qui définit explicitement les obligations que tous les
+paquets doivent suivre. Mais c'est également grâce à une histoire partagée
+d'expériences qui va au-delà de la charte Debian, une accumulation d'années
+d'expérience pour la construction des paquets ; des développeurs de grand
+talent ont créé de bons outils qui vous aideront, vous, responsable Debian, à
+créer et maintenir d'excellents paquets.
+
+<p>
+Ce chapitre fournit les meilleurs pratiques pour les développeurs Debian. Ce ne
+sont que des recommandations, non pas des obligations ou des règles. Ce sont
+seulement des astuces et conseils subjectifs et des liens collectés pour les
+développeurs Debian. Prenez et choisissez ce qui vous convient le mieux.
+
+ <sect id="bpp-debian-rules">
+ <heading>Les meilleures pratiques pour le fichier <file>debian/rules</file></heading>
+ <p>
+Les recommandations suivantes s'appliquent au fichier <file>debian/rules</file>.
+Comme ce fichier contrôle le processus de compilation et qu'il sélectionne les
+fichiers inclus dans le paquet (directement ou indirectement), il s'agit
+habituellement du fichier sur lequel les responsables passent le plus de temps.
+
+
+ <sect1 id="helper-scripts">Scripts d'aide
+<p>
+La raison sous-jacente à l'utilisation des scripts d'aide dans le fichier
+<file>debian/rules</file> est que cela permet aux responsables d'utiliser et de
+partager une logique commune pour un grand nombre de paquets. Prenez, par
+exemple, l'installation des entrées de menu : vous avez besoin de
+placer un fichier dans <file>/usr/lib/menu</file> et d'ajouter des commandes aux
+scripts de maintenance pour enregistrer et désenregistrer ces entrées de menu.
+Comme il s'agit d'une chose très commune, pourquoi chaque
+responsable devrait-il écrire sa propre version, parfois avec des bogues ?
+Supposons également que le répertoire de menu soit modifié, chaque paquet
+devrait être modifié.
+<p>
+Les scripts d'aide peuvent résoudre ces problèmes. En supposant que vous vous
+conformiez aux conventions attendues par le script d'aide, celui-ci prend soin
+de tous les détails. Les changements dans la charte peuvent alors être faits
+dans le script d'aide, les paquets ont alors simplement besoin d'être
+reconstruits avec la nouvelle version du script et sans aucun changement
+supplémentaire.
+<p>
+L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus
+courant et le meilleur (à notre avis) système est <package>debhelper</package>.
+Les précédents systèmes d'aide comme <package>debmake</package> étaient
+« monolithiques » : vous ne pouviez pas choisir quelles parties
+intéressantes vous pouviez utiliser, mais vous étiez obligé de choisir le
+système pour tout faire. <package>debhelper</package>, à l'inverse, consiste en
+un certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple,
+<prgn>dh_installman</prgn> installe et compresse les pages de manuel,
+<prgn>dh_installmenu</prgn> installe les fichiers de menu et ainsi de suite.
+Ainsi, il offre une flexibilité suffisante pour pouvoir utiliser les scripts
+d'aide quand ils sont utiles, en complément de commandes définies manuellement
+dans le fichier <file>debian/rules</file>.
+<p>
+Vous pouvez débuter avec <package>debhelper</package> en lisant <manref
+name="debhelper" section="1"> et en regardant les exemples fournis avec le
+paquet. <prgn>dh_make</prgn> du paquet <package>dh-make</package> (voir <ref
+id="dh-make">) peut être utilisé pour convertir un paquet source
+« vierge » en une version utilisant <package>debhelper</package>. Ce
+raccourci ne devrait cependant pas vous faire croire que vous n'avez pas besoin
+de comprendre les scripts individuels <prgn>dh_*</prgn>. Si vous comptez
+utiliser un système d'aide, vous devez prendre le temps d'apprendre à utiliser
+ce système pour savoir ce que vous pouvez en attendre ainsi que son
+comportement.
+<p>
+Plusieurs personnes pensent que des fichiers <file>debian/rules</file> vierges
+sont préférables car vous n'avez pas à apprendre les détails internes d'un
+quelconque système d'aide. La décision vous appartient complètement. Utilisez ce
+qui vous convient. Plusieurs exemples de fichiers <file>debian/rules</file> sont
+disponibles à <url id="&url-rules-files;">.
+
+ <sect1 id="multiple-patches">
+ <heading>Séparer vos correctifs en plusieurs fichiers</heading>
+<p>
+Les gros paquets peuvent avoir plusieurs bogues que vous devez gérer. Si
+ vous corrigez sans faire attention les bogues dans les sources, vous ne
+ pourrez pas différencier facilement les nombreux correctifs que vous aurez
+ appliqués. Cela peut devenir trés compliqué de mettre à jour le paquet avec
+ une nouvelle version amont qui intègre certains correctifs (mais pas tous).
+ Vous ne pouvez pas prendre l'ensemble des correctifs (par exemple, dans les
+ fichiers <file>.diff.gz</file>) et décider quels correctifs il vous faut
+ enlever parce que les bogues ont été corrigés en amont.
+<p>
+Malheureusement, le système de création des paquets tel qu'il est actuellement
+ne fournit pas de moyen de séparer les correctifs en plusieurs fichiers.
+Cependant, il existe des moyens de séparer les correctifs : les fichiers
+correctifs sont livrés dans le fichier correctif Debian
+(<file>.diff.gz</file>), habituellement dans le répertoire <file>debian/</file>.
+La seule différence est qu'ils ne sont pas appliqués immédiatement par
+dpkg-source, mais par la règle <tt>build</tt> du fichier
+<file>debian/rules</file>. Inversement, ils sont annulés par la règle
+<tt>clean</tt>.
+<p>
+<prgn>dbs</prgn> est l'une des approches les plus populaires pour cela. Il fait
+ce qui est décrit ci-dessus et fournit la possibilité de créer de nouveaux
+correctifs et de mettre à jour d'anciens correctifs. Veuillez vous reporter au
+paquet <package>dbs</package> pour plus d'informations et au paquet
+<package>hello-dbs</package> pour un exemple.
+<p>
+<prgn>dpatch</prgn> fournit également ces fonctions, mais il est prévu pour être
+encore plus facile d'utilisation. Veuillez voir le paquet
+<package>dpatch</package> pour la documentation et des exemples (dans
+<file>/usr/share/doc/dpatch</file>).
+<p>
+
+ <sect1 id="multiple-binary">Paquets binaires multiples
+<p>
+Un simple paquet source va souvent permettre de construire plusieurs paquets
+ binaires différents, que ce soit pour fournir plusieurs saveurs du même
+ paquet (par exemple, le paquet source <package>vim</package>) ou pour créer
+ plusieurs petits paquets au lieu d'un seul gros (par exemple, si
+ l'utilisateur peut n'installer que la partie dont il a besoin et ainsi
+ économiser de l'espace disque).
+<p>
+Le second cas peut facilement être géré dans le fichier
+ <file>debian/rules</file>. Vous avez simplement besoin de déplacer les fichiers
+ appropriés du répertoire de construction dans les arborescence temporaires du
+ paquet. Vous pouvez le faire en utilisant <prgn>install</prgn>
+ ou <prgn>dh_install</prgn> du paquet <package>debhelper</package>.
+ Assurez-vous de vérifier les différentes permutations de paquets, en
+ garantissant que vous avez bien défini les dépendances entre les paquets dans
+ le fichier <file>debian/control</file>.
+<p>
+Le premier cas est un peu plus diffile car il implique de multiples
+ recompilations du même logiciel, mais avec différentes options de
+ configuration. Le paquet source <package>vim</package> est un exemple de la
+ façon de gérer cela avec un fichier <file>rules</file> écrit à la main.
+
+<!-- &FIXME; Find a good debhelper example with multiple configure/make cycles
+ -->
+</sect1>
+
+
+ <sect id="bpp-debian-control">
+ <heading>Les meilleures pratiques pour le fichier
+ <file>debian/control</file></heading>
+ <p>
+Les pratiques suivantes sont relatives au fichier <file>debian/control</file>.
+Elles viennent en complément des <url
+id="&url-debian-policy;ch-miscellaneous.html#s-descriptions" name="règles pour
+les descriptions de paquet">.
+<p>
+La description du paquet, telle qu'elle est définie par le champ correspondant
+dans le fichier <file>control</file>, contient à la fois le résumé du paquet et
+la description longue pour le paquet. <ref id="bpp-desc-basics"> décrit des
+lignes générales pour les deux parties de la description. Ensuite, <ref
+id="bpp-pkg-synopsis"> fournit des principes spécifiques pour le résumé et <ref
+id="bpp-pkg-desc"> contient des principes spécifiques pour la description
+longue.
+
+ <sect1 id="bpp-desc-basics">
+ <heading>Les règles générales pour les descriptions des paquets</heading>
+<p>
+La description du paquet devrait être écrite pour l'utilisateur moyen,
+l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple, les paquets
+de développement sont pour les développeurs et leur description peut utiliser un
+langage technique. Pour les applications à but plus général comme un éditeur, la
+description devrait être écrite pour un non-spécialiste.
+<p>
+Notre critique des descriptions des paquets nous amène à conclure que la plupart
+des descriptions des paquets sont techniques, c'est-à-dire, qu'elles ne sont pas
+écrites pour être comprises par les non-spécialistes. À moins que
+votre paquet ne soit que pour les techniciens, c'est un problème.
+<p>
+Comment écrire pour les non-spécialistes ? Évitez le jargon.
+Évitez de vous référer à d'autres applications et cadres de travail avec
+lesquels l'utilisateur n'est pas forcément familier — « GNOME »
+ou « KDE » sont corrects car les utilisateurs sont probablement
+familiers avec ces termes, mais « GTK+ » ne l'est probablement pas.
+Ne supposez aucune connaissance. Si vous devez utiliser des termes techniques,
+introduisez-les.
+<p>
+Soyez objectif. Les descriptions de paquet ne sont pas un endroit pour
+promouvoir votre paquet, quel que soit l'amour que vous lui portez.
+Rappelez-vous que le lecteur n'a pas forcément les mêmes priorités que vous.
+<p>
+Des références aux noms de tout autre paquet de logiciels, noms de protocoles,
+standards ou spécifications devraient utiliser leurs formes canoniques si elles
+existent. Par exemple, utilisez « X Window System », « X11 »
+ou « X » et non « X Windows », « X-Windows » ou
+« X Window ». Utilisez « GTK+ » et non « GTK » ou
+« gtk ». Utilisez « GNOME » et non « Gnome ».
+Utilisez « PostScript » et non « Postscript » ou
+« postscript ».
+<p>
+Si vous avez des problèmes pour écrire votre description, vous pouvez l'envoyer à
+&email-debian-l10n-english; et demander un retour d'informations.
+
+ </sect1>
+
+<sect1 id="bpp-pkg-synopsis">
+ <heading>Le résumé du paquet ou description courte</heading>
+<p>
+La ligne de résumé (la description courte) devrait être concise. Elle ne doit
+pas répéter le nom du paquet (c'est une règle).
+<p>
+C'est une bonne idée de penser au résumé comme à une clause apposée et non une
+phrase complète. Une clause apposée est définie dans WordNet comme une relation
+grammaticale entre un mot et une phrase pronominale qui la suit, par exemple
+« Rudolph, le renne au nez rouge ». La clause apposée ici est
+« le renne au nez rouge ». Comme le résumé est une clause et non une
+phrase complète, nous recommandons de ne pas la commencer par une majuscule et
+de ne pas la finir par un point. Il ne doit pas non plus commencer avec un
+article, défini (« le ») ou indéfini (« un »).
+<p>
+Cela peut vous aider d'imaginer le résumé combiné avec le nom du paquet de
+la façon suivante :
+
+<example><var>nom-paquet</var> est un <var>résumé</var>.</example>
+
+Sinon, il peut être plus compréhensible de le voir comme
+
+<example><var>nom-paquet</var> est <var>résumé</var>.</example>
+
+ou, si le nom du paquet est lui-même un pluriel (comme
+« developer-tools »)
+
+<example><var>nom-paquet</var> sont <var>résumé</var>.</example>
+
+Cette façon de former une phrase à partir du nom du paquet et du résumé devrait
+être considérée comme une heuristique et non comme une règle stricte. Il y a
+certains cas où cela n'a aucun sens de former une phrase.
+
+ </sect1>
+
+ <sect1 id="bpp-pkg-desc">
+ <heading>La description longue</heading>
+<p>
+La description longue du paquet est la première information dont dispose
+l'utilisateur avant d'installer un paquet. Aussi, elle devrait fournir toutes
+les informations nécessaires pour le laisser décider de l'installation du
+paquet. Vous pouvez supposer que l'utilisateur a déjà lu le résumé du paquet.
+<p>
+La description longue devrait toujours être constituée de phrases complètes.
+<p>
+Le premier paragraphe de la description longue devrait répondre aux questions
+suivantes : qu'est-ce que fait le paquet ? Quelle tâche aide-t-il
+l'utilisateur à accomplir ? Il est important de décrire ceci d'une manière
+non technique, à moins que le paquet ne s'adresse qu'à un auditoire de techniciens.
+<p>
+Les paragraphes suivants devraient répondre aux questions suivantes :
+Pourquoi, en tant qu'utilisateur, ai-je besoin de ce paquet ? Quelles
+sont les autres fonctionnalités dont dispose le paquet ? Quelles
+sont les fonctionnalités marquantes et les déficiences de ce paquet comparé à
+d'autres paquets (par exemple, « si vous avez besoin de X, utilisez Y à la
+place ») ? Est-ce que le paquet est lié à d'autres paquets d'une
+certaine façon qui n'est pas gérée par le gestionnaire de paquet (par exemple,
+« il s'agit d'un client pour le serveur foo ») ?
+<p>
+Soyez attentif à éviter les fautes d'orthographe et de grammaire. N'oubliez
+pas votre vérificateur orthographique. <prgn>ispell</prgn> possède une option
+spéciale (<tt>-g</tt>) pour cela :
+
+<example>ispell -d american -g debian/control</example>
+
+ </sect1>
+
+ <sect1 id="bpp-upstream-info">
+ <heading>Page d'accueil amont</heading>
+ <p>
+Nous vous recommandons d'ajouter l'adresse de la page d'accueil du paquet à la
+description du paquet dans le fichier <file>debian/control</file>. Cette
+information devrait être ajoutée à la fin de la description en utilisant le
+format suivant :
+
+<example> .
+ Homepage: http://some-project.some-place.org/</example>
+
+Veuillez noter les espaces au début de la ligne, ils servent à séparer les
+lignes correctement. Pour voir un exemple de ce que cela affiche, veuillez vous
+reporter à <url id="&url-eg-desc-upstream-info;">.
+ <p>
+Ne mettez rien s'il n'existe pas de page pour le logiciel.
+
+ <p>
+Veuillez noter que nous espérons que ce champ sera remplacé par un
+vrai champ de <file>debian/control</file> que comprendraient <prgn>dpkg</prgn>
+et <tt>&packages-host;</tt>. Si vous ne voulez pas vous embêter à déplacer la
+page d'accueil depuis la description vers ce nouveau champ, vous devriez
+probablement attendre qu'il soit disponible.</p>
+ </sect1>
+ </sect>
+
+
+ <sect id="bpp-debian-changelog">
+ <heading>Les meilleures pratiques pour le fichier <file>debian/changelog</file></heading>
+ <p>
+Les pratiques suivantes viennent en complément de la <url name="directive sur
+les fichiers changelog" id="&url-debian-policy;ch-docs.html#s-changelogs">.</p>
+
+ <sect1 id="bpp-changelog-do">
+ <heading>Écrire des entrées de changelog utiles</heading>
+ <p>
+L'entrée de changelog pour une révision de paquet documente les changements dans
+cette révision et seulement ceux-ci. Concentrez-vous sur la description des
+changements significatifs et visibles de l'utilisateur qui ont été effectués
+depuis la dernière version.
+ <p>
+Ciblez <em>ce</em> qui a été changé — qui, comment et quand cela a été fait
+est généralement de moindre importance. Ceci dit, rappelez-vous de nommer
+poliment les personnes qui ont fourni une aide notable pour réaliser le
+paquet (par exemple, ceux qui ont envoyé des correctifs).
+ <p>
+Vous n'avez pas besoin de détailler les changements triviaux et évidents. Vous
+pouvez également regrouper plusieurs de ces changements dans une seule entrée.
+D'un autre côté, ne soyez pas trop concis si vous avez entrepris un changement
+majeur. Soyez tout spécialement clair s'il y a des changements qui modifient le
+comportement du programme. Pour plus d'explications, utilisez le fichier
+<file>README.Debian</file>.
+ <p>
+Utilisez un langage anglais commun pour que la majorité des lecteur puissent le
+comprendre. Évitez les abbréviations, le parler technique et le jargon quand
+vous expliquez des changements fermant un bogue, spécialement pour les rapports
+de bogue créés par des utilisateurs qui ne vous paraissent pas particulièrement
+à l'aise techniquement. Vous devez être poli et ne pas jurer.
+ <p>
+Il est parfois désirable de préfixer les entrées de changelog avec le nom des
+fichiers qui ont été modifiés. Cependant, il n'est pas besoin de lister
+explicitement tous les fichiers modifiés, particulièrement si la modification
+est petite ou répétitive. Vous pouvez utiliser les caractères génériques.
+ <p>
+Quand vous faites référence aux bogues, ne supposez rien a priori. Dites ce
+qu'était le problème, comment il a été résolu et ajoutez la chaîne de caractères
+« closes: #nnnnn ». Veuillez voir <ref id="upload-bugfix"> pour plus
+d'informations.
+
+ <sect1 id="bpp-changelog-misconceptions">
+ <heading>Communes idées fausses sur les entrées de changelog</heading>
+ <p>
+Les entrées de changelog <strong>ne devraient pas</strong> documenter des
+problèmes génériques d'empaquetage (« Hé, si vous cherchez foo.conf, il
+est dans /etc/blah/. ») car les administrateurs et utilisateurs sont
+supposés être au moins vaguement rompus à la façon dont les choses sont
+arrangées sur un système Debian. Mentionnez cependant tout changement
+d'emplacement d'un fichier de configuration.
+ <p>
+Les seuls bogues fermés par une entrée de changelog devraient être ceux qui sont
+vraiment corrigés dans la même révision du paquet. Fermer des bogues non liés
+par le fichier changelog est considéré comme une très mauvaise pratique.
+Veuillez voir <ref id="upload-bugfix">.
+ <p>
+Les entrées de changelog <strong>ne devraient pas</strong> être le lieu de
+discussions avec les émetteurs de bogues (« Je ne vois pas de segfaults
+lors du lancement de foo avec l'option bar ; envoyez-moi plus
+d'informations. »), ni celui de phrases génériques sur la vie, l'univers et
+tout le reste (« Désolé, cet envoi m'a pris du temps, mais j'avais attrapé
+la grippe. ») ou celui de demandes d'aide (" La liste des bogues sur
+ce paquet est énorme, donnez-moi un coup de main. »). Ceci ne sera
+généralement pas remarqué par les personnes ciblées, mais peut ennuyer les
+personnes qui désirent lire des informations sur les changements réels du
+paquet. Veuillez vous reporter à <ref id="bug-answering"> pour plus
+d'informations sur la façon d'utiliser le système de suivi des bogues.
+ <p>
+C'est une vieille tradition de valider les bogues fixés par une mise à jour
+indépendante dans la première entrée du changelog de l'envoi du vrai
+responsable, par exemple, dans une entrée de changelog comme ceci :
+<example>
+ * Maintainer upload, closes: #42345, #44484, #42444.
+</example>
+Ceci fermera les bogues NMU marqués comme corrigé (« fixed ») quand le
+paquet arrivera dans l'archive. Le bogue pour le fait qu'une NMU a été faite
+peut être fermé de la même façon. Bien sûr, il est également parfaitement
+acceptable de fermer les bogues corrigés par NMU par d'autres moyens ; voir
+<ref id="bug-answering">.
+</sect1>
+
+ <sect1 id="bpp-changelog-errors">
+ <heading>Erreurs communes dans les entrées de changelogs</heading>
+<p>
+Les exemples suivants montrent des erreurs communes ou des exemples de mauvais
+style dans les entrées de changelog<footnote>NdT : Les entrées de
+changelog sont ici affichées en français pour faciliter la compréhension, mais
+vos entrées devront naturellement être rédigées en anglais.</footnote>.
+
+<p>
+<example>
+ * Corrige tous les bogues restants.
+</example>
+<p>
+Ceci n'indique visiblement rien d'utile au lecteur.
+<p>
+<example>
+ * Correctif de Jane Random appliqué.
+</example>
+Sur quoi portait le correctif ?
+
+<p>
+<example>
+ * Révision de cible d'installation la nuit dernière.
+</example>
+Révision qui a accompli quoi ? Est-ce que la mention de la nuit dernière
+est supposée nous rappeler que nous ne devons pas faire confiance à ce
+code ?
+
+<p>
+<example>
+ * Corrige MRD vsync av. anciens CRTs.
+</example>
+Trop d'acronymes et il n'est pas très clair de ce qu'était vraiment cette...
+ euh..., merde (oups, un mot interdit !) ou comment cela a été corrigé.
+
+<p>
+<example>
+ * Ceci n'est pas un bogue. Closes: #nnnnnn.
+</example>
+Premièrement, il n'y a absolument pas besoin d'envoyer un paquet pour
+communiquer cette information ; à la place, utilisez le système de suivi des
+bogues. Deuxièmement, il n'y a aucune explication concernant la raison
+pour laquelle le rapport n'était pas un bogue.
+
+<p>
+<example>
+ * A été fixé il y a longtemps, mais j'ai oublié de le fermer. Closes: #54321.
+</example>
+Si, pour toute raison, vous n'aviez pas indiqué le numéro du bogue dans une
+précédente entrée de changelog, ceci n'est pas un problème, fermez simplement le
+bogue normalement dans le BTS. Il n'y a pas besoin de modifier le fichier
+changelog, en supposant que la description de la correction est déjà intégrée
+(ceci s'applique aux correctifs par les auteurs/responsables amonts également,
+vous n'avez pas à suivre les bogues qui ont été corrigés il y a longtemps dans
+votre changelog).
+
+<p> <!-- MANQUE UN . final -->
+<example>
+ * Closes: #12345, #12346, #15432
+</example>
+Où est la description ?! Si vous n'arrivez pas à trouver un message
+descriptif, commencez par insérer le titre de chacun des différents bogues.
+<p>
+</sect1>
+</sect>
+
+<!-- <sect1 id="pkg-mgmt-cvs">Managing a package with CVS
+ <p>
+ &FIXME; presentation of cvs-buildpackage, updating sources
+ via CVS (debian/rules refresh).
+ <url id="http://www.debian.org/devel/cvs_packages">
+-->
+
+ <sect id="bpp-debian-maint-scripts">
+ <heading>Les meilleures pratiques pour les scripts de
+ maintenance</heading>
+ <p>
+Les scripts de maintenance incluent les fichiers <file>debian/postinst</file>,
+<file>debian/preinst</file>, <file>debian/prerm</file> et
+<file>debian/postrm</file>. Ces scripts prennent soin de la configuration
+d'installation ou de désinstallation des paquets, ce qui n'est pas simplement créer ou
+supprimer des fichiers et des répertoires. Les instructions suivantes
+complètent la <url id="&url-debian-policy;" name="charte Debian">.
+ <p>
+Les scripts de maintenance doivent être idempotents. Cela veut dire que vous
+devez vous assurer que rien de grave ne se produit si un script est appelé deux
+fois là où il ne devrait habituellement être appelé qu'une fois.
+ <p>
+Les entrée et sortie standard peuvent être redirigées (par exemple, dans des
+tubes<footnote><p>pipes</p></footnote>) pour des besoins d'enregistrement
+d'activité, donc vous ne devez pas supposer que ce sont des tty.
+ <p>
+Tous les affichages et les configurations interactives devraient être
+minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet
+<package>debconf</package> pour l'interface. Rappelez-vous que, dans tous les
+cas, l'affichage ne doit se faire que dans l'étape de configuration,
+<tt>configure</tt> du script de post-installation, <file>postinst</file>.
+ <p>
+Gardez les scripts de maintenance aussi simples que possible. Nous vous
+suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que si vous
+avez besoin d'une fonctionnalité de Bash, le script de maintenance doit
+l'indiquer dans sa première ligne. Un shell POSIX ou Bash sont préférés à
+Perl car ils permettent à <package>debhelper</package> d'ajouter facilement des
+parties aux scripts.
+ <p>
+Si vous modifiez les scripts de maintenance, assurez-vous de tester la
+suppression du paquet, la double installation et la purge complète. Assurez-vous
+qu'il ne reste rien d'un paquet purgé, c'est-à-dire, que la purge doit enlever
+tout fichier créé, directement ou indirectement, par les scripts de
+maintenance.
+ <p>
+Si vous avez besoin de vérifier l'existence d'une commande, vous devriez
+utiliser quelque chose comme :
+<example>if [ -x /usr/sbin/install-docs ]; then ...</example>
+
+Si vous ne désirez pas mettre en dur le chemin de la commande dans le script de
+maintenance, la fonction de shell suivante conforme à POSIX peut vous
+aider :
+
+&example-pathfind;
+
+Vous pouvez utiliser cette fonction pour rechercher le <tt>$PATH</tt> pour un
+nom de commande passé en argument. Il renvoie vrai (zéro) si la commande a été
+trouvée et faux sinon. Il s'agit réellement de la façon la plus portable de faire
+car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn> ne sont pas
+POSIX.
+<p>
+Bien que <prgn>which</prgn> soit une alternative acceptable car il est
+présent dans le paquet classé <em>required</em> <package>debianutils</package>, il n'est pas
+présent dans la partition racine. Autrement dit, il est placé dans
+<file>/usr/bin</file> au lieu de <file>/bin</file>, il n'est donc pas possible
+de l'utiliser dans les scripts qui sont exécutés avant que la partition
+<file>/usr</file> soit montée. Cependant, la plupart des scripts n'auront pas ce
+problème.
+ </sect>
+
+ <sect id="bpp-config-mgmt">
+ <heading>Gestion de la configuration avec <package>debconf</package></heading>
+
+ <p>
+<p>
+<package>Debconf</package> est un système de gestion de configuration qui
+ peut être utilisé par les divers scripts de maintenance (principalement
+ en post-installation dans le fichier <file>postinst</file>) pour demander à
+l'utilisateur des informations concernant la configuration du paquet. Il
+faut maintenant éviter les interactions directes avec l'utilisateur et
+préférer les interactions utilisant <package>debconf</package>. Ceci permettra
+ à l'avenir des installations non interactives. <!-- pas de trait d'union
+entre non et adjectif -->
+ <p>
+Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs erreurs
+ communes sont référencées dans la page de manuel <manref section="8"
+ name="debconf-devel">. Vous devriez vraiment lire cette page si vous décidez
+ d'utiliser debconf.
+ </sect>
+
+
+ <sect id="bpp-i18n">
+ <heading>Internationalisation</heading>
+
+
+
+ <sect1 id="bpp-i18n-debconf">Gestion des traductions de
+ debconf
+<p>
+Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur
+ un grand nombre de paquets et doivent donc collaborer avec plusieurs
+ responsables différents. De plus, la plupart du temps, l'anglais n'est pas leur
+ langue maternelle, il se peut que vous deviez être particulièrement patient
+ avec eux.
+<p>
+Le but de <package>debconf</package> était de faciliter la configuration des
+paquets aux responsables et aux utilisateurs. À l'origine, les
+traductions des questionnaires debconf étaient gérées avec
+<prgn>debconf-mergetemplate</prgn>. Cependant, cette technique est maintenant
+déconseillée ; la meilleure façon pour l'internationalisation de
+<package>debconf</package> est d'utiliser le paquet
+<package>po-debconf</package>. Cette méthode est plus facile et pour le
+responsable et pour les traducteurs ; des scripts de transition sont
+fournis.
+<p>
+Lors de l'utilisation de <package>po-debconf</package>, la traduction est
+stockée dans des fichiers <file>po</file> (à l'instar des techniques de
+traduction de <prgn>gettext</prgn>). Des fichiers modèles contiennent les
+messages d'origine et indiquent quels sont les champs traduisibles. Quand vous
+modifiez l'état d'un champ traduisible en appelant
+<prgn>debconf-updatepo</prgn>, la traduction est marquée comme ayant besoin de
+l'attention des traducteurs. Puis, lors de la construction du paquet, le
+programme <prgn>dh_installdebconf</prgn> prendra soin de toute la magie
+nécessaire à l'ajout du modèle avec les traductions à jour dans les paquets
+binaires. Veuillez vous reporter à la page de manuel <manref name="po-debconf"
+section="7"> pour les détails.
+ </sect1>
+
+ <sect1 id="bpp-i18n-docs">
+ <heading>Documentation traduite</heading>
+ <p>
+La traduction de la documentation est cruciale pour les utilisateurs, mais elle
+représente un important travail. Il n'existe aucun moyen d'éliminer ce travail,
+mais vous pouvez faciliter les choses pour les traducteurs.
+ <p>
+Si vous êtes responsable d'une documentation quelle que soit sa taille, il est
+plus facile pour les traducteurs d'avoir accès à un système de contrôle de
+source. Ceci permet aux traducteurs de voir les différences entre deux versions
+de la documentation, pour, par exemple, qu'ils puissent voir ce qui a besoin
+d'être retraduit. Il est recommandé que le document traduit inclue une note à
+propos de la révision de contrôle du source sur laquelle la traduction est
+basée. Un système intéressant est fourni par <url id="&url-i18n-doc-check;"
+name="doc-check"> dans le paquet <package>boot-floppies</package> qui donne un
+aperçu de l'état de la traduction pour une langue donnée, en utilisant les
+commentaires structurés pour une révision donnée du fichier à traduire et, pour
+un fichier traduit, la révision du fichier d'origine sur laquelle la traduction
+est basée. Vous pouvez vouloir adapter et fournir ceci dans votre référentiel CVS.
+ <p>
+Si vous maintenez de la documentation au format XML ou SGML, nous vous suggérons
+d'isoler les informations indépendantes de la langue et de les définir
+comme des entités dans un fichier séparé qui sera inclus par les différentes
+traductions. Ceci aide, par exemple, à garder à jour les adresses pour
+plusieurs fichiers.
+ </sect1>
+ </sect>
+
+
+ <sect id="bpp-common-situations">
+ <heading>Pratiques d'empaquetage communes</heading>
+
+<!--
+ <sect1 id="bpp-kernel">Kernel modules/patches
+<p>
+
+ &FIXME; Heavy use of kernel-package. provide files in
+ /etc/modutils/ for module configuration.
+-->
+
+ <sect1 id="bpp-autotools">
+ <heading>Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
+<p>
+Conserver à jour les fichiers d'<prgn>autoconf</prgn>, <file>config.sub</file>
+et <file>config.guess</file>, est critique pour les porteurs, spécialement pour
+les architectures plus changeantes. De très bonnes pratiques d'empaquetage
+utilisant <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été regroupées
+dans &file-bpp-autotools; du paquet <package>autotools-dev</package>. Vous êtes
+vivement encouragé à lire ce fichier et à suivre les recommandations indiquées.
+
+
+ <sect1 id="bpp-libraries">Bibliothèques
+<p>
+Pour diverses raisons, il a toujours été difficile d'empaqueter les
+bibliothèques. La charte impose plusieurs contraintes pour faciliter la maintenance
+ et pour garantir que les mises à jour sont aussi simples que possible quand une
+ nouvelle version amont est disponible. Une erreur dans une bibliothèque peut
+ rendre défectueux une douzaine de paquets qui en dépendent.
+<p>
+Les bonnes pratiques d'empaquetage des bibliothèques ont été regroupées dans
+ <url id="&url-libpkg-guide;" name="le guide d'empaquetage des
+ bibliothèques">.
+
+ <sect1 id="bpp-docs">Documentation
+ <p>
+Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html"
+name="règles sur la documentation">.</p>
+ <p>
+Si votre paquet contient de la documentation construite à partir de XML ou SGML,
+nous vous recommandons de ne pas fournir le source XML ou SGML dans le(s)
+paquet(s) binaire(s). Si les utilisateurs désirent avoir le source de la
+documentation, ils peuvent récupérer le paquet source.</p>
+ <p>
+La charte spécifie que la documentation doit être fournie au format HTML.
+Nous vous recommandons également de la fournir au format PDF et texte simple si
+c'est adapté et qu'une sortie de qualité est possible. Cependant, il n'est
+généralement pas approprié de fournir des versions en texte simple pour la
+documentation dont le format source est du HTML.</p>
+ <p>
+Les principaux manuels fournis devraient être enregistrés par le paquet
+<package>doc-base</package> à l'installation. Reportez-vous à la documentation
+du paquet <package>doc-base</package> pour plus d'information.</p>
+
+
+
+ <sect1 id="bpp-other">Types spécifiques de paquets
+<p>
+Plusieurs types spécifiques de paquets ont des sous-chartes spéciales et des
+ règles et pratiques d'empaquetage correspondantes :
+<list>
+<item>
+ Les paquets liés à Perl ont leur <url id="&url-perl-policy;" name="charte
+ Perl">, quelques exemples de paquets qui suivent cette charte sont
+ <package>libdbd-pg-perl</package> (module perl binaire) ou
+ <package>libmldbm-perl</package> (module perl indépendant de
+ l'architecture).
+</item>
+<item>
+ Les paquets liés à Python ont leur charte Python ; voir
+ &file-python-policy; dans le paquet <package>python</package>.
+</item>
+<item>
+ Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;"
+ name="charte Emacs">.
+</item>
+<item>
+ Les paquets liés à Java ont leur <url id="&url-java-policy;" name="charte
+ Java">.
+</item>
+<item>
+ Les paquets liés à Ocaml ont leur propre charte que l'on trouve dans
+ &file-ocaml-policy; du paquet <package>ocaml</package>. Un bon exemple est
+ le paquet source <package>camlzip</package>.
+</item>
+<item>
+ Les paquets fournissant des DTDs XML ou SGML devraient se conformer aux
+ recommandations que l'on peut trouver dans le paquet
+ <package>sgml-base-doc</package>
+<item>
+ Les paquets Lisp devraient s'enregistrer avec le paquet
+ <package>common-lisp-controller</package> pour lequel vous pouvez vous
+ reporter au fichier &file-lisp-controller;.
+</list>
+
+ </sect1>
+
+ <sect1 id="bpp-archindepdata">Données indépendantes de l'architecture
+ <p>
+ Il n'est pas rare d'avoir une grande quantité de données indépendantes de
+ l'architecture fournie avec un programme. Par exemple, des fichiers
+ audio, une collection d'icônes, des motifs de papiers peints ou autres
+ fichiers graphiques. Si la taille des données est négligeable par
+ rapport à la taille du reste du paquet, il est probablement mieux de
+ tout garder dans le même paquet.
+
+ <p>
+ Cependant, si la taille des données est considérable, vous devez
+ envisager de les partager dans un paquet séparé et indépendant de
+ l'architecture (« _all.deb »). Ainsi, en faisant cela, vous
+ évitez une duplication inutile des mêmes données dans onze fichiers
+ .debs pour chaque architecture. Bien que ceci ajoute une surcharge
+ supplémentaire aux fichiers <file>Packages</file>, ceci sauve beaucoup
+ d'espace disque sur les miroirs Debian. Séparer les données
+ indépendantes de l'architecture réduit également le temps de traitement
+ de <prgn>lintian</prgn> ou de <prgn>linda</prgn> (voir <ref
+ id="tools-lint">) quand ils sont exécutés sur l'ensemble de l'archive
+ Debian.
+ </sect1>
+
+</sect>
+
+</chapt>
+
+ <chapt id="beyond-pkging">
+ <heading>Au-delà de l'empaquetage
+<p>
+Debian, c'est beaucoup plus que de l'empaquetage de logiciels et de
+ la maintenance de paquets. Ce chapitre contient des informations sur les
+ façons, souvent vraiment importantes, de contribuer à Debian au-delà de la
+ simple création et maintenance de paquets.
+<p>
+En tant qu'organisation de volontaires, Debian repose sur la liberté de
+ choisir ce sur quoi l'on désire travailler et de choisir la
+ partie la plus importante à laquelle on veut consacrer son temps.
+
+ <sect id="submit-bug">
+ <heading>Rapporter des bogues
+<p>
+Nous vous encourageons à remplir des rapports de bogue quand vous trouvez des
+ bogues dans les paquets Debian. En fait, les développeurs Debian sont souvent
+ les testeurs de première ligne. Trouver et rapporter les bogues dans les
+ paquets d'autres développeurs améliore la qualité de Debian.
+<p>
+Lisez les <url name="instructions pour créer un rapport de bogue"
+id="&url-bts-report;"> dans le <url name="système de suivi des bogues"
+id="&url-bts;"> Debian.
+<p>
+Essayez de soumettre le bogue à partir d'un compte utilisateur normal sur lequel
+ vous pouvez recevoir des courriers, pour que les personnes puissent vous
+ joindre s'ils ont besoin de plus d'informations à propos du bogue. Ne soumettez
+ pas de bogues en tant que root.
+<p>
+Vous pouvez utiliser un outil comme <manref name="reportbug" section="1"> pour
+soumettre des bogues. Il peut automatiser et dans l'ensemble faciliter le
+processus.
+<p>
+Assurez-vous que le bogue n'a pas déjà été rapporté. Chaque paquet dispose d'une
+liste de bogues facilement accessible à
+<tt>http://&bugs-host;/<var>packagename</var></tt>. Des outils comme <manref
+name="querybts" section="1"> peuvent également vous fournir ces informations (et
+<prgn>reportbug</prgn> invoquera également habituellement <prgn>querybts</prgn>
+avant l'envoi).
+<p>
+Essayer d'envoyer vos bogues au bon emplacement. Quand, par exemple, votre bogue
+concerne un paquet qui réécrit des fichiers d'un autre paquet, vérifiez les
+listes des bogues pour les <em>deux</em> paquets pour éviter de créer des
+rapports de bogues dupliqués.
+<p>
+Vous pouvez également parcourir les bogues d'autres paquets, en les regroupant
+ s'ils sont indiqués plus d'une fois, ou en les marquant avec
+ « fixed » quand ils ont déjà été corrigés. Notez cependant que si
+ vous n'êtes ni le rapporteur du bogue, ni le responsable du paquet, vous ne
+ devriez pas fermer réellement le bogue (à moins que vous n'ayez obtenu la
+ permission du responsable).
+<p>
+De temps en temps, vous pourrez vouloir vérifier ce qui s'est passé à propos des
+ bogues que vous avez rapportés. Saisissez cette occasion pour fermer les bogues
+ que vous ne pouvez plus reproduire. Pour trouver tous les bogues que vous avez
+ rapportés, vous avez simplement besoin d'aller à
+ <tt>http://&bugs-host;/from:<var><your-email-addr></var></tt>.
+
+ <sect1 id="submit-many-bugs">Ouvrir un grand nombre de rapports d'un seul
+ coup
+<p>
+Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
+ paquets — plus de dix — est une pratique que nous déconseillons.
+ Prenez toutes les mesures possibles pour éviter cette situation. Si le problème
+ peut être détecté automatiquement par exemple, ajoutez un nouveau test dans le
+ paquet <package>lintian</package> pour générer une erreur ou un avertissement.
+<p>
+Si vous ouvrez plus de dix rapports sur le même sujet, il est préférable
+ d'indiquer votre intention sur la liste &email-debian-devel;. Cela donnera à
+ d'autres développeurs la possibilité de vérifier que le problème existe
+ vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent
+ les mêmes rapports de bogue simultanément.
+<p>
+Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez
+ les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils ne soient
+ pas redirigés vers les listes de diffusion.
+
+
+ <sect id="qa-effort">Effort d'assurance qualité
+
+ <sect1 id="qa-daily-work">Travail journalier
+<p>
+Bien qu'il y ait un groupe de personnes dédiées à l'assurance qualité, les
+ devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez participer à
+ cet effort en conservant vos paquets aussi exempts de bogues que possible et
+ aussi corrects que possible selon <prgn>lintian</prgn> (reportez-vous à <ref
+ id="lintian">). Si cela vous paraît impossible, vous devriez alors envisager
+ d'abandonner certains de vos paquets (reportez-vous à <ref id="orphaning">).
+ Sinon, vous pouvez demander de l'aide à d'autres personnes pour qu'elles
+ puissent rattraper votre retard dans la correction des bogues (vous pouvez
+ demander de l'aide sur &email-debian-qa; ou &email-debian-devel;). En même
+ temps, vous pouvez rechercher des co-responsables (reportez-vous à <ref
+ id="collaborative-maint">).
+
+ <sect1 id="qa-bsp">Les chasses aux bogues
+<p>
+De temps en temps, le groupe d'assurance qualité organise des chasses aux
+ bogues<footnote><em>Bug Squashing Party</em></footnote> pour essayer de
+ supprimer le plus de problèmes possible. Elles sont annoncées sur
+ &email-debian-devel-announce; et l'annonce explique quel domaine sera visé
+ pendant la chasse : habituellement, il s'agit des bogues empêchant
+ l'intégration du paquet dans la distribution (« Release Critical »),
+ mais il peut arriver qu'ils décident d'aider à finir une transition majeure
+ (comme une nouvelle version de Perl qui demande la recompilation de tous les
+ modules binaires).
+<p>
+Les règles pour les mises à jour indépendantes sont différentes au cours de la
+ chasse parce que l'annonce de la chasse est considérée comme une annonce
+ préalable pour les mises à jour indépendantes. Si vous avez des paquets qui
+ peuvent être affectées par la chasse (parce qu'ils ont des bogues critiques par
+ exemple), vous devriez envoyer une mise à jour pour chaque bogue correspondant
+ pour expliquer leur état actuel et ce que vous attendez de la chasse. Si vous
+ ne voulez pas d'une mise à jour indépendante ou si vous n'êtes intéressé que
+ par un correctif ou si vous voulez gérer vous-même le bogue, veuillez l'expliquer
+ dans le BTS.
+<p>
+Les personnes qui participent à la chasse ont des règles spécifiques pour les
+ mises à jour indépendantes, ils peuvent en faire une sans avertissement
+ préalable s'ils envoient leur paquet avec un délai d'au moins 3 jours dans
+ DELAYED/3-day. Toutes les autres règles de mise à jour indépendante
+ s'appliquent comme d'habitude, ils devraient envoyer le correctif de la
+ mise à jour dans le BTS (pour l'un des bogues ouverts corrigé par la mise à
+ jour ou pour un nouveau bogue marqué comme fixé). Ils devraient également
+ respecter les souhaits du responsable s'il en a exprimés.
+<p>
+Si une personne ne se sent pas à l'aise avec une mise à jour indépendante, elle
+ devrait simplement envoyer un correctif au BTS. C'est de loin meilleur qu'une
+ mise à jour défectueuse.
+
+ <sect id="contacting-maintainers">Contacter d'autres responsables
+<p>
+Pendant vos activités dans Debian, vous aurez à contacter d'autres responsables
+ pour différentes raisons. Vous pourrez vouloir discuter d'une nouvelle
+ façon de coopérer au sein d'un ensemble de paquets liés, ou vous pouvez
+ simplement rappeler à quelqu'un qu'une nouvelle version est disponible et
+ que vous en avez besoin.
+<p>
+Chercher l'adresse d'un responsable d'un paquet peut être fastidieux.
+ Heureusement, il existe un alias de courrier simple,
+ <tt><package>@&packages-host;</tt>, qui fournit un moyen d'envoyer
+ un courrier à un responsable, quelle que soit son adresse (ou ses
+ adresses). Remplacez <tt><package></tt> par le nom du paquet source
+ ou binaire.
+<p>
+Vous pouvez également vouloir contacter les personnes qui sont inscrites à un
+ paquet de source donné par le <ref id="pkg-tracking-system">. Vous pouvez le
+ faire en utilisant l'adresse <tt><package-name>@&pts-host;</tt>.
+
+
+ <sect id="mia-qa">Gérer les responsables non joignables
+<p>
+Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer
+ que le responsable est toujours actif et qu'il continue à travailler sur
+ ses paquets. Il est possible qu'il ne soit plus actif, mais qu'il ne se
+ soit pas désenregistré du système. D'un autre côté, il est possible qu'il
+ ait simplement besoin d'un rappel.
+<p>
+La première étape est de contacter poliment le responsable et d'attendre une
+réponse pendant un temps raisonnable. Il est assez difficile de définir le
+« temps raisonnable », mais il est important de prendre en compte que
+la vraie vie est parfois assez mouvementée. Une façon de gérer cela pourrait
+être d'envoyer un rappel après deux semaines.
+<p>
+Si le responsable ne répond pas après quatre semaines (un mois), on peut
+supposer qu'il n'y aura probablement pas de réponse. Si ceci se produit, vous
+devriez poursuivre vos investigations et essayer de réunir toutes les
+informations utiles sur ce responsable. Ceci inclut :
+ <p>
+ <list>
+ <item>Les informations « echelon » disponibles dans la <url
+ id="&url-debian-db;" name="base de données LDAP des
+ développeurs">, qui indiquent quand le développeur a envoyé un
+ message pour la dernière fois sur une liste de diffusion Debian.
+ (Ceci inclut les envois via les listes debian-*-changes.)
+ Rappelez-vous également de vérifier si le responsable est indiqué
+ comme en vacances dans la base de données.
+
+ <item>Le nombre de paquets de ce responsable et les conditions de ces
+ paquets. En particulier, restent-ils des bogues empêchant
+ l'intégration du paquet dans la distribution qui sont ouverts
+ depuis des lustres ? De plus, combien de bogues y a-t-il en
+ général ? Un autre point d'information important est si les
+ paquets ont subi des mises à jour indépendantes et si oui, par
+ qui ?
+
+ <item>Est-ce que le responsable est actif en dehors de Debian ? Par
+ exemple, il peut avoir envoyé des messages récemment à des
+ listes de diffusion non-Debian ou des groupes de discussion.
+ </list>
+ <p>
+Un gros problème est représenté par les paquets parrainés — le responsable
+n'est pas un développeur Debian officiel. Les informations « echelon »
+ne sont pas disponibles pour les personnes parrainés, par exemple, vous devez
+donc trouver et contacter le responsable Debian qui a réellement envoyé le
+paquet. Étant donné qu'il a signé le paquet, il est responsable de l'envoi de
+toute façon et il devrait savoir ce qui s'est passé avec la personne qu'il
+parraine.
+<p>
+Il est également permis d'envoyer une demande à &email-debian-devel; demandant
+si quelqu'un est au courant d'information sur le responsable manquant.
+<p>
+Une fois que vous avez réuni toutes ces informations, vous pouvez contacter
+&email-debian-qa;. Les personnes de cet alias utiliseront les informations que
+vous aurez fournies pour décider comment procéder. Par exemple, ils peuvent
+abandonner un ou tous les paquets du responsable. Si un paquet a subi une mise à
+jour indépendante, ils peuvent préférer contacter le responsable ayant fait cette
+mise à jour — il est peut-être intéressé par le paquet.
+<p>
+Un dernier mot : veuillez vous souvenir d'être poli. Nous sommes tous des
+volontaires et nous ne pouvons dédier l'intégralité de notre temps à Debian.
+Vous n'êtes pas non plus au courant des circonstances de la personne impliquée.
+Elle est peut-être sérieusement malade ou pourrait même nous avoir quitté
+— vous ne savez pas qui recevra vos courriers — imaginez comme un
+proche se sentira s'il lit un courrier pour la personne décédée et trouve un
+message très impoli, en colère et accusateur !)
+<p>
+D'un autre côté, bien que nous soyons tous volontaires, nous avons une
+responsabilité. Vous pouvez donc insister sur l'importance du plus grand intérêt
+— si un responsable n'a plus le temps ou l'envie, il devrait
+« laisser filer » et donner le paquet à quelqu'un ayant plus de temps.
+
+ <sect id="newmaint">
+ <heading>Interagir avec de futurs développeurs Debian
+<p>
+Le succès de Debian dépend de sa capacité à attirer et retenir de nouveaux et
+ talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous
+ recommandons de vous impliquer dans le processus d'apport des nouveaux
+ responsables. Cette section décrit comment aider les futurs développeurs.
+
+
+ <sect1 id="sponsoring">Parrainer des paquets
+<p>
+Parrainer un paquet veut dire envoyer un paquet pour un responsable qui n'est
+ pas encore autorisé à le faire lui-même, un candidat nouveau responsable.
+ Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité.
+<p>
+Si vous désirez être volontaire pour être parrain, vous pouvez vous inscrire à
+ <url id="&url-sponsors;">.
+<p>
+Les nouveaux responsables ont habituellement certaines difficultés à créer des
+ paquets Debian — ceci est bien compréhensible. C'est pourquoi le parrain
+ est là pour vérifier que le paquet parrainé est assez bon pour être inclus
+ dans Debian. (Notez que si le paquet parrainé est nouveau, les ftpmasters
+ devront également l'inspecter avant de l'intégrer)
+<p>
+Effectuer un parrainage en signant simplement l'envoi ou en recompilant le
+ paquet <strong>n'est définitivement pas recommandé</strong>. Vous devez
+ construire le paquet source comme si vous vouliez construire l'un de vos
+ paquets. Rappelez-vous que cela ne change rien si vous avez laissé le nom du
+ candidat développeur dans le changelog et dans le fichier de
+ contrôle, il est toujours possible de savoir que c'est vous qui avez fait l'envoi.
+<p>
+Si vous êtes un gestionnaire de candidature pour un futur développeur, vous
+ pouvez également être son parrain. Ainsi, vous pourrez vérifier comment le
+ candidat gère la partie « Tâches et Capacités »<footnote>Tasks and
+ Skills</footnote> de sa candidature.
+
+ <sect1>Gérer les paquets parrainés
+<p>
+En envoyant un paquet sponsorisé vers Debian, vous certifiez que le paquet
+ atteint les standards minimum de Debian. Ceci implique que vous devez
+ construire et tester le paquet sur votre propre système avant l'envoi.
+<p>
+Vous ne pouvez pas simplement envoyer un fichier <file>.deb</file> binaire d'un
+ filleul. En théorie, vous devriez seulement demander le fichier diff et
+ l'emplacement de l'archive source d'origine et ensuite vous devriez récupérer
+ le source et appliquer le diff vous-même. En pratique, vous pouvez vouloir
+ utiliser le paquet source construit par votre filleul. Dans ce cas, vous devez
+ vérifier qu'il n'a pas modifié les fichiers sources du fichier
+ <file>.orig.tar.gz</file> qu'il fournit.
+<p>
+N'ayez pas peur de répondre au filleul et de lui indiquer les changements qu'il
+ doit faire. Cela prend souvent plusieurs échanges de courriers avant que le
+ paquet ne soit dans un état acceptable. Être un parrain veut dire être un
+ mentor.
+<p>
+Une fois que le paquet a atteint les standards Debian, construisez le paquet
+ avec
+<example>
+ dpkg-buildpackage -us -uc
+</example>
+ et signez-le avec
+<example>
+ debsign -m <var>"Nom complet</var> <var>votre-adresse-courrier</var> <var>changes-file</var>
+</example>
+ avant de l'envoyer dans le répertoire Incoming.
+<p>
+Le champ Maintainer du fichier <file>control</file> et le fichier
+ <file>changelog</file> devraient lister la personne qui a fait l'empaquetage,
+ c'est-à-dire, le filleul. Celui-ci recevra donc tous les courriers du système
+ de suivi des bogues (BTS) à propos de son paquet.
+<p>
+Si vous préférez laisser une trace plus visible de votre travail de parrainage,
+ vous pouvez ajouter une ligne l'indiquant dans la plus récente entrée du
+ changelog.
+<p>
+Vous êtes encouragé à garder un œil sur le suivi des paquets que vous parrainez
+ en utilisant le <ref id="pkg-tracking-system">.
+
+ <sect1>Recommander un nouveau développeur
+<p>
+Reportez-vous à la page sur les <url id="&url-newmaint-advocate;"
+ name="recommandations pour un développeur prospectif"> sur le site web Debian.
+
+ <sect1>Gérer les candidatures des nouveaux candidats
+<p>
+Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;" name="liste à
+ vérifier pour les responsables de candidatures"> sur le site web Debian.
+
+
+
+ <appendix id="tools">Aperçu des outils du responsable Debian
+<p>
+Cette section contient un aperçu rapide des outils dont dispose le responsable.
+ Cette liste n'est ni complète, ni définitive, il s'agit juste d'un guide
+ des outils les plus utilisés.
+<p>
+Les outils du responsable Debian sont destinés à améliorer le confort des
+ responsables et libérer leur temps des tâches plus cruciales. Comme le dit
+ Larry Wall, il y a plus d'une manière de le faire.
+<p>
+Certaines personnes préfèrent utiliser des outils de haut niveau, d'autres pas.
+ Debian n'a pas de position officielle sur la question ; tout outil
+ conviendra du moment qu'il fait le boulot. C'est pourquoi cette section
+ n'a pas été conçue pour indiquer à chacun quel outil il doit utiliser ou
+ comment il devrait faire pour gérer sa charge de responsable Debian. Elle
+ n'est pas non plus destinée à favoriser l'utilisation d'un outil aux
+ dépens d'un autre.
+<p>
+La plupart des descriptions de ces outils proviennent des descriptions de leurs
+ paquets. Vous trouverez plus d'informations dans les documentations de ces
+ paquets. Vous pouvez aussi obtenir plus d'informations avec la commande
+ <tt>apt-cache show <package_name></tt>.</p>
+
+
+ <sect id="tools-core">
+ <heading>Outils de base</heading>
+ <p>
+Les outils suivants sont pratiquement nécessaires à tout responsable.</p>
+
+
+ <sect1 id="dpkg-dev">
+ <heading><package>dpkg-dev</package></heading>
+<p>
+Le paquet <package>dpkg-dev</package> contient les outils (y compris
+ <prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des
+ paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas
+ niveau indispensables pour créer et manipuler les paquets ; en tant que
+ tels, ils sont indispensables à tout responsable Debian.
+
+ <sect1 id="debconf">
+ <heading><package>debconf</package></heading>
+<p>
+Le paquet <package>debconf</package> fournit une interface unifiée pour
+ configurer les paquets interactivement. Il est indépendant de l'interface et
+ permet une configuration en mode texte, par une interface HTML ou par boîtes de
+ dialogue. D'autres types d'interface peuvent être ajoutés sous forme de
+ modules.
+<p>
+Vous trouverez la documentation de ce paquet dans le paquet
+ <package>debconf-doc</package>.
+<p>
+Beaucoup pensent que ce système devrait être utilisé pour tout paquet
+ nécessitant une configuration interactive ; reportez-vous à la <ref
+ id="bpp-config-mgmt">. <package>debconf</package> n'est pas requis par la
+ <em>charte Debian</em> pour le moment ; cependant, cela pourra changer.
+</sect1>
+
+ <sect1 id="fakeroot">
+ <package>fakeroot</package>
+<p>
+<package>fakeroot</package> simule les privilèges <em>root</em>. Cela permet de
+ fabriquer un paquet sans être root (en général, les paquets installent des
+ fichiers appartenant à <em>root</em>). Si vous avez installé
+ <package>fakeroot</package>, vous pouvez construire un paquet en tant que
+ simple utilisateur avec : <tt>dpkg-buildpackage -rfakeroot</tt>.
+
+
+ <sect id="tools-lint">
+ <heading>Outils du paquet lint</heading>
+ <p>
+Selon le « Free On-line Dictionary of Computing » (FOLDOC),
+« lint » est « un outil de traitement de langage C qui contient
+beaucoup plus de tests complets sur le code que n'en font habituellement les
+compilateurs C. ». Les outils du paquet lint aide les responsables de
+paquet à trouver automatiquement des problèmes habituels et des violations de
+charte dans leurs paquets</p>
+
+ <sect1 id="lintian">
+ <heading><package>lintian</package></heading>
+<p>
+<package>lintian</package> dissèque les paquets pour y repérer des bogues et des
+ manquements aux règles de développement. Il contient des tests automatisés pour
+ vérifier de nombreuses règles et quelques erreurs courantes.
+<p>
+Vous devriez récupérer la dernière version de <package>lintian</package> depuis
+ <em>unstable</em> régulièrement et vérifier tous vos paquets. Notez que
+ l'option <tt>-i</tt> donne des explications détaillées sur la signication de
+ chaque erreur, la partie concernée dans la charte et le moyen habituel de
+ régler le problème.
+<p>
+Veuillez vous reporter à <ref id="sanitycheck"> pour plus d'informations sur
+comment et quand utiliser Lintian.
+<p>
+ Vous pouvez aussi obtenir un résumé de tous les problèmes reportés par Lintian
+ sur vos paquets à <url id="&url-lintian;">. Ces rapports contiennent la sortie
+ de la dernière version de <prgn>lintian</prgn> sur l'ensemble de la
+ distribution de développement (<em>unstable</em>).
+</sect1>
+
+ <sect1 id="linda">
+ <heading><package>linda</package></heading>
+ <p>
+<package>linda</package> est un autre vérificateur de paquet. Il est sembable à
+<package>lintian</package>, mais il a un ensemble de tests différents. Il est écrit
+en Python plutôt qu'en Perl.</p>
+ </sect1>
+
+
+ <sect1 id="debdiff">
+ <heading><package>debdiff</package></heading>
+ <p>
+<prgn>debdiff</prgn> (du paquet <package>devscripts</package>, <ref
+id="devscripts">) compare des listes de fichiers et des fichiers de contrôle de
+deux paquets. C'est un simple test de régression qui peut vous aider à remarquer
+si le nombre de paquets binaires à changer depuis le dernier envoi ou si autre
+chose a changé dans le fichier de contrôle. Bien sûr, certains des changements
+qu'il indique sont normaux, mais il peut aider à empêcher différents accidents.
+ <p>
+Vous pouvez l'exécuter sur un couple de paquets binaires :
+<example>
+debdiff package_1-1_arch.deb package_2-1_arch.deb
+</example>
+ <p>
+Ou même sur un couple de fichiers de changements :
+<example>
+debdiff package_1-1_arch.changes package_2-1_arch.changes
+</example>
+ <p>
+Pour plus d'informations, veuillez voir <manref name="debdiff" section="1">.
+ </sect1>
+
+
+ </sect>
+
+ <sect id="tools-helpers">
+ <heading>Aides pour le fichier <file>debian/rules</file></heading>
+ <p>
+Des outils de construction de paquets rendent le processus d'écriture du fichier
+<file>debian/rules</file> plus facile. Veuillez voir les <ref
+id="helper-scripts"> pour plus d'informations sur les raisons pour lesquelles
+ils peuvent être désirables ou non.
+
+ <sect1 id="debhelper">
+ <heading><package>debhelper</package></heading>
+<p>
+Le paquet <package>debhelper</package> regroupe un ensemble de programmes qui
+ peuvent être utilisés dans <file>debian/rules</file> pour automatiser les
+ tâches courantes relatives à la fabrication des paquets Debian binaires. Ce
+ paquet contient des utilitaires pour installer différents fichiers, les
+ compresser, ajuster leurs droits et intégrer votre paquet dans le système de
+ menu Debian.
+<p>
+À la différence des autres approches, <package>debhelper</package> est divisé en
+ plusieurs petits utilitaires qui agissent de manière cohérente. Ce découpage
+ permet un contrôle des opérations plus fin que d'autres « <em>outils
+ debian/rules</em> ».
+<p>
+Il existe aussi un certain nombre de petites extensions
+ <package>debhelper</package> trop éphémères pour être documentées. Vous en
+ listerez la plupart en faisant <tt>apt-cache search ^dh-</tt>.
+</sect1>
+
+
+ <sect1 id="debmake">
+ <heading><package>debmake</package></heading>
+<p>
+<package>debmake</package> — un précurseur de <package>debhelper</package>
+ — est un assistant moins modulaire pour manipuler le fichier
+ <file>debian/rules</file>. Il inclut deux programmes principaux :
+ <prgn>deb-make</prgn>, utile au développeur Debian pour convertir un paquet
+ source normal (non-Debian) en paquet source Debian, et <prgn>debstd</prgn> qui
+ regroupe le type de fonction que l'on trouve dans <package>debhelper</package>.
+<p>
+Le consensus actuel est que l'usage de <package>debmake</package> est
+ déconseillé au profit de <package>debhelper</package>, mais ce n'est pas une
+ erreur d'utiliser <package>debmake</package>.
+</sect1>
+
+ <sect1 id="dh-make">
+ <heading><package>dh-make</package>
+ <p>
+Le paquet <package/dh-make/ contient <prgn/dh_make/, un programme qui crée un
+squelette de fichiers nécessaires à la construction d'un paquet Debian à partir
+d'une arborescence source. Comme le nom le suggère, <prgn/dh_make/ est une
+ré-écriture de <package/debmake/ et ses fichiers modèles utilisent les
+programmes dh_* de <package/debhelper/.
+ <p>
+Quoique les fichiers de règles générés par <prgn/dh_make/ constituent en général
+une base suffisante pour un paquet fonctionnel, ce ne sont que les
+fondations : la charge incombe toujours au responsable d'affiner
+les fichiers générés et de rendre le paquet complètement fonctionnel et
+en conformité avec la charte.
+ </sect1>
+
+ <sect1 id="yada">
+ <heading><package>yada</package></heading>
+<p>
+Le paquet <package>yada</package> est un autre assistant pour la création de
+ paquets. Il utilise un fichier <file>debian/packages</file> pour générer
+ <file>debian/rules</file> et d'autres fichiers nécessaires dans le
+ sous-répertoire <file>debian/</file>.
+<p>
+Remarque : <package>yada</package> est qualifié de « quasiment non
+ maintenu » par son responsable, Charles Briscoe-Smith. Son usage est donc
+ déconseillé.
+</sect1>
+
+
+ <sect1 id="equivs">
+ <heading><package>equivs</package></heading>
+<p>
+<package>equivs</package> est un autre paquet pour faire des paquets. Il est
+ souvent conseillé pour un usage local, si vous avez besoin de faire un paquet
+ pour satisfaire des dépendances. Il est aussi parfois utilisé pour faire des
+ « méta-paquets » qui sont des paquets dont l'unique objet est de
+ dépendre d'autres paquets.</p>
+ </sect1>
+</sect>
+
+
+ <sect id="tools-builders">
+ <heading>Constructeurs de paquets</heading>
+ <p>
+Les paquets suivants aident le processus de construction des paquets, en général
+en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que la gestion du support de
+tâches.
+
+ <sect1 id="cvs-buildpackage">
+ <heading><package>cvs-buildpackage</package></heading>
+<p>
+Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou de
+ récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer
+ un paquet Debian depuis le référentiel CVS et il assiste le développeur lors de
+ l'intégration de modifications amonts dans le référentiel.
+<p>
+Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS pour le
+ responsable Debian. Il permet de conserver des branches CVS distinctes pour les
+ distributions <em>stable</em>, <em>unstable</em> et probablement
+ <em>experimental</em> et de bénéficier des avantages d'un système de contrôle
+ de version.
+ </sect1>
+
+ <sect1 id="debootstrap">
+ <heading><package>debootstrap</package></heading>
+<p>
+Le paquet <package>debootstrap</package> vous permet d'amorcer un système Debian
+ de base à n'importe quel endroit dans votre système de fichier. Par
+ « système de base », nous entendons le strict minimum nécessaire pour
+ fonctionner et installer le reste du système.
+<p>
+Avoir un système comme celui-ci peut vous servir de différentes manières. Vous
+ pouvez, par exemple, déplacer votre racine dans ce système avec
+ <prgn>chroot</prgn> pour tester vos dépendances de fabrication. Vous pouvez
+ aussi l'utiliser pour voir comment se comporte votre paquet quand il est
+ installé dans un environnement minimum.
+ </sect1>
+
+ <sect1 id="pbuilder">
+ <heading><package>pbuilder</package></heading>
+<p>
+<package>pbuilder</package> construit un système « chrooté » et
+ compile des paquets dans ce système. Ceci est très utile pour vérifier que les
+ dépendances de compilation de votre paquet sont correctes et pour vous assurer
+ qu'aucune dépendance de construction inutile ou incorrecte n'existe dans le
+ paquet résultant. </sect1>
+
+ <sect1 id="sbuild">
+ <heading><package>sbuild</package></heading>
+<p>
+<package>sbuild</package> est un autre compilateur automatique. Il peut aussi
+ être utilisé dans un environnement « chrooté ». Il peut être utilisé
+ seul ou comme partie d'un environnement de compilation distribué en réseau.
+ Comme le précédent, c'est une partie du système utilisé par les porteurs pour
+ construire des paquets binaires pour toutes les architectures disponibles.
+ Veuillez vous reporter à <ref id="buildd"> pour plus d'informations et à <url
+ id="&url-buildd;"> pour voir le système en fonctionnement.</p>
+ </sect1>
+ </sect>
+
+ <sect id="uploaders">
+ <heading>Téléchargeurs de paquets</heading>
+ <p>
+Les paquets suivants aident à automatiser ou à simplifier le processus d'envoi
+de paquets dans l'archive officielle.</p>
+
+ <sect1 id="dupload">
+ <heading><package>dupload</package></heading>
+<p>
+Le paquet <package>dupload</package> contient un script du même nom pour mettre
+ à jour des paquets dans l'archive Debian, tracer les mises à jour et les
+ annoncer par courrier électronique automatiquement. Vous pouvez le configurer
+ pour faire des mises à jour à d'autres endroits et avec d'autres méthodes.
+ </sect1>
+
+ <sect1 id="dput">
+ <heading><package>dput</package></heading>
+<p>
+Le script <package>dput</package> fait à peu près la même chose que
+ <package>dupload</package>, mais il le fait différemment. Il a aussi quelques
+ fonctions supplémentaires telles que la possibilité de vérifier la signature
+ GnuPG et les sommes de contrôles avant le téléchargement et la possibilité de
+ démarrer <prgn>dinstall</prgn> en mode simulation (<em>dry-run</em>) après le
+ téléchargement.
+ </sect1>
+ </sect>
+
+
+ <sect id="tools-maint-automate">
+ <heading>Automatisation de la maintenance</heading>
+ <p>
+Les outils suivants aident à automatiser les différentes tâches de maintenance
+par l'ajout des entrées de changelog ou de lignes de signatures, par la
+recherche de bogues à partir d'Emacs ou par l'utilisation du plus récent fichier
+officiel <file>config.sub</file>.</p>
+
+
+ <sect1 id="devscripts">
+ <heading><package>devscripts</package></heading>
+<p>
+Le paquet <package>devscripts</package> contient des scripts et outils qui sont
+ très utiles pour maintenir vos paquets Debian. Parmi ces scripts, vous
+ trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui manipulent votre
+ fichier <file>debian/changelog</file> depuis la ligne de commande et
+ <prgn>debuild</prgn> qui est construit au-dessus de
+ <prgn>dpkg-buildpackage</prgn>. L'outil <prgn>bts</prgn> est également très
+ utile pour mettre à jour l'état des rapports de bogue depuis la ligne de
+ commande. Le programme <prgn>uscan</prgn> peut être utilisé pour suivre les
+ nouvelles versions amonts de vos paquets. Le programme <prgn>debrsign</prgn>
+ peut être utilisé pour signer à distance un paquet avant de l'envoyer, ce qui
+ est agréable quand la machine sur laquelle vous construisez le paquet est
+ différente de celle où résident vos clés GPG.</p>
+<p>
+Vérifiez la page de manuel <manref section="1" name="devscripts"> pour une liste
+ complète des scripts disponibles.
+
+ <sect1 id="autotools-dev">
+ <heading><package>autotools-dev</package></heading>
+ <p>
+Contient les meilleurs pratiques pour des personnes assurant la maintenance de
+paquets qui utilisent <prgn>autoconf</prgn> et/ou <prgn>automake</prgn>.
+Contient également des fichiers canoniques <file>config.sub</file> et
+<file>config.guess</file> qui sont connus pour fonctionner avec tous les
+portages Debian.</p>
+ </sect1>
+
+ <sect1 id="dpkg-repack">
+ <heading><package>dpkg-repack</package></heading>
+ <p>
+<prgn>dpkg-repack</prgn> crée un paquet Debian à partir d'un paquet qui
+a déjà été installé. Si des changements ont été effectués sur le paquet quand il
+a été décompressé (par exemple, des fichiers dans <file>/etc</file> ont été
+modifés), le nouveau paquet héritera de ces changements.</p>
+ <p>
+Cet utilitaire peut faciliter la copie de paquet d'un ordinateur vers un autre
+ou la re-création de paquets installés sur un système, mais qui ne sont plus
+disponibles ailleurs ou pour stocker l'état actuel d'un paquet avant de le
+mettre à jour.</p>
+ </sect1>
+
+ <sect1 id="alien">
+ <heading><package>alien</package></heading>
+ <p>
+<prgn>alien</prgn> convertit des paquets binaires entre différents formats de
+paquets, y compris des paquets Debian, RPM (RedHat), LSB (Linux Standard Base),
+Solaris et Slackware.</p>
+ </sect1>
+
+ <sect1 id="debsums">
+ <heading><package>debsums</package></heading>
+ <p>
+<prgn>debsums</prgn> vérifie des paquets installés par rapport à leur somme de
+hachage MD5. Veuillez noter que tous les paquets n'ont pas de sommes MD5 car
+elles ne sont pas requises par la charte.</p>
+ </sect1>
+
+ <sect1 id="dpkg-dev-el">
+ <heading><package>dpkg-dev-el</package></heading>
+<p>
+<package>dpkg-dev-el</package> fournit des macros Emacs Lisp qui apportent une
+ aide lors de l'édition des fichiers du répertoire <file>debian</file> de votre
+ paquet. À l'édition de <file>debian/changelog</file>, par exemple, vous
+ disposez de fonctions pour finaliser une version et consulter la liste des
+ rapports de bogue ouverts.</p>
+</sect1>
+
+
+ <sect1 id="dpkg-depcheck">
+ <heading><package>dpkg-depcheck</package></heading>
+ <p>
+<prgn>dpkg-depcheck</prgn> (du paquet <package>devscripts</package>, <ref
+id="devscripts">) exécute une commande sous <prgn>strace</prgn> pour déterminer
+tous les paquets utilisés par la commande.
+ <p>
+Pour les paquets Debian, c'est utile quand vous devez créer une ligne
+<tt>Build-Depends</tt> pour votre nouveau paquet : exécuter le processus de
+compilation avec <prgn>dpkg-depcheck</prgn> vous fournira une bonne première
+approximation des dépendances de compilation. Par exemple :
+<example>
+dpkg-depcheck -b debian/rules build
+</example>
+ <p>
+<prgn>dpkg-depcheck</prgn> peut aussi être utilisé pour vérifier les dépendances
+d'exécution, particulièrement si votre paquet utilise exec(2) pour exécuter
+d'autres programmes.
+ <p>
+Pour plus d'informations, veuillez voir <manref name="dpkg-depcheck" section="1">.
+ </sect1>
+
+
+ <sect id="tools-porting">
+ <heading>Outils de portage</heading>
+ <p>
+Les outils suivants facilitent le travail des porteurs et la compilation
+croisée.</p>
+
+ <sect1 id="quinn-diff">
+ <heading><package>quinn-diff</package></heading>
+<p>
+<package>quinn-diff</package> est utilisé pour localiser les différences d'une
+ architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de
+ l'architecture <var>X</var> doivent être portés sur l'architecture
+ <var>Y</var>.
+
+ <sect1 id="dpkg-cross">
+ <heading><package>dpkg-cross</package></heading>
+<p>
+<package>dpkg-cross</package> est un outil qui installe les bibliothèques et les
+ en-têtes nécessaires à une compilation
+ croisée<footnote><p><em>cross-compilation</em></footnote> d'une manière
+ similaire à <package>dpkg</package>. De plus, les paquets
+ <prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
+ améliorés pour accepter les compilations croisées.
+
+ <sect id="tools-doc">
+ <heading>Documentation et information</heading>
+ <p>
+Les paquets suivants fournissent des informations pour les responsables ou de
+l'aide pour construire de la documentation
+
+ <sect1 id="debiandoc-sgml">
+ <heading><package>debiandoc-sgml</package></heading>
+ <p>
+<package>debiandoc-sgml</package> fournit la DTD DebianDoc SGML qui est
+habituellement utilisée pour la documentation Debian. Ce manuel, par exemple,
+est écrit en DebianDoc. Il fournit également des scripts pour construire et
+décliner le source en de multiples formats de sortie.</p>
+ <p>
+La documentation sur la DTD peut être trouvée dans le paquet
+<package>debiandoc-sgml-doc</package>.</p>
+ </sect1>
+
+ <sect1 id="debian-keyring">
+ <heading><package>debian-keyring</package></heading>
+ <p>
+Contient les clés publiques GPG et PGP des développeurs Debian. Voir <ref
+id="key-maint"> et la documentation du paquet pour plus d'informations.</p>
+ </sect1>
+
+ <sect1 id="debview">
+ <heading><package>debview</package></heading>
+ <p>
+<package>debview</package> fournit un mode Emacs pour voir les paquets binaires
+Debian. Il vous permet d'examiner un paquet sans le décompresser.</p>
+ </sect1>
+ </sect>
+
+
+<!-- FIXME: add the following
+
+questionable:
+ dbs (referred to above)
+ dpatch (referred to above)
+ debarchiver
+ ucf
+ dpkg-awk
+ grep-dctrl
+ d-shlibs
+ wajig
+ magpie
+ apt-dpkg-ref
+ apt-show-source
+ apt-show-versions
+ pdbv
+ epm
+ apt-src
+ apt-build
+
+rejected:
+ debaux: too new, unmaintained?
+ dh-make-perl: too new, unmaintained?
+-->
+
+ </appendix>
+ </book>
+</debiandoc>