+ <item>
+ <p>
+ Vérifiez que les fichiers <file>debian/files</file> et
+ <file>debian/substvars</file> ne sont pas dans votre paquet
+ source. Ils doivent être effacés par la cible <em>clean</em> de
+ <file>debian/rules</file>.
+ </p>
+ </item>
+ <item>
+ <p>
+ Assurez-vous que vous ne vous appuyez pas sur des éléments de
+ configuration ou des logiciels installés ou modifiés
+ localement. Par exemple, vous ne devriez jamais appeler des
+ programmes du répertoire <file>/usr/local/bin</file> ou de
+ répertoires équivalents. Essayez de ne pas vous appuyer sur des
+ logiciels configurés de manière spéciale. Essayez de construire
+ votre paquet sur une autre machine, même s'il s'agit de la même
+ architecture.
+ </p>
+ </item>
+ <item>
+ <p>
+ Ne vous appuyez pas sur une installation préexistante de votre
+ paquet (un sous-cas de la remarque précédente).
+ </p>
+ </item>
+ <item>
+ <p>
+ Si possible, ne vous appuyez pas sur une particularité présente
+ dans un compilateur précis ou dans une certaine version d'un
+ compilateur. Si vous ne pouvez pas faire autrement, assurez-vous
+ que les dépendances de fabrication reflètent bien cette
+ restriction. Dans ce cas, vous cherchez sûrement les problèmes car
+ quelques architectures pourraient choisir un compilateur différent.
+ </p>
+ </item>
+ <item>
+ <p>
+ Vérifiez que votre fichier <file>debian/rules</file> distingue les
+ cibles <em>binary-arch</em> et <em>binary-indep</em> comme l'exige
+ la charte Debian. Vérifiez que ces cibles sont indépendantes l'une
+ de l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer
+ l'une de ces cibles avant d'invoquer l'autre. Pour vérifier cela,
+ essayez d'exécuter <tt>dpkg-buildpackage -B</tt>.
+ </p>
+ </item>
+ </enumlist>
+ </p>
+ </sect1>
+ <sect1 id="porter-guidelines">
+ <heading>
+ Instructions pour les mises à jour des porteurs
+ </heading>
+ <p>
+ Si le paquet se construit tel quel sur l'architecture que vous visez,
+ vous avez de la chance et votre travail est facile. Cette section
+ s'applique dans ce cas ; elle décrit comment construire et
+ installer correctement votre paquet binaire dans l'archive Debian. Si
+ vous devez modifier le paquet pour le rendre compilable sur votre
+ architecture cible vous devez faire une mise à jour des sources,
+ consultez la section <ref id="nmu-guidelines">.
+ </p>
+ <p>
+ Pour un envoi de portage, ne faites pas de changement dans les
+ sources. Vous n'avez pas besoin de modifier les fichiers du paquet
+ source (cela inclut le fichier <file>debian/changelog</file>).
+ </p>
+ <p>
+ La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la
+ suivante : <tt>dpkg-buildpackage -B
+ -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
+ <var>adresse-porteur</var> par votre adresse électronique. Cette
+ commande construira les parties du paquet qui dépendent de
+ l'architecture, en utilisant la cible <em>binary-arch</em> de
+ <file>debian/rules</file>.
+ </p>
+ <p>
+ Si vous travaillez sur une machine Debian pour vos efforts de portage
+ et que vous devez signer votre envoi localement pour son acceptation
+ dans l'archive, vous pouvez exécuter <prgn>debsign</prgn> sur votre
+ fichier <file>.changes</file> pour qu'il soit signé de manière commode
+ ou utilisez le mode de signature à distance de <prgn>dpkg-sig</prgn>.
+ </p>
+ <sect2 id="binary-only-nmu">
+ <heading>
+ Mises à jour indépendantes binaires ou recompilations
+ </heading>
+ <p>
+ Parfois, l'envoi du portage initial pose problème car l'environnement
+ dans lequel le paquet a été construit n'était pas bon (bibliothèques
+ plus à jour ou obsolètes, mauvais compilateur, etc.). Il se peut que
+ vous ayez à le recompiler dans un environnement mis à
+ jour. Cependant, dans ce cas, vous devez changer le numéro de version
+ pour que les mauvais anciens paquets soient remplacés dans l'archive
+ Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
+ s'ils n'ont pas un numéro de version supérieur à celui actuellement
+ disponible).
+ </p>
+ <p>
+ Vous devez vous assurer que votre mise à jour indépendante binaire ne
+ rend pas le paquet non installable. Cela peut arriver si un paquet
+ source génère des paquets dépendants et indépendants de
+ l'architecture qui dépendent les uns des autres <em>via</em>
+ $(Source-Version).
+ </p>
+ <p>
+ Malgré les modifications nécessaires du changelog, ce type de mise à
+ jour reste une mise à jour indépendante binaire — il n'est
+ pas nécessaire de reconsidérer le statut des paquets binaires des
+ autres architectures pour les marquer périmés ou à recompiler.
+ </p>
+ <p>
+ Ces recompilations nécessitent des numéros de version
+ « magiques » pour que le système de maintenance de
+ l'archive comprenne que, bien qu'il y ait une nouvelle version, il
+ n'y a pas eu de modification des sources. Si vous ne faites pas cela
+ correctement, les administrateurs de l'archive rejetteront votre mise
+ à jour (car il n'y aura pas de code source associé).
+ </p>
+ <p>
+ La « magie » d'une mise à jour indépendante par
+ recompilation uniquement est déclenchée par l'utilisation d'un
+ suffixe ajouté au numéro de version du paquet de la forme
+ b<numéro>. Par exemple, si la dernière version que vous avez
+ recompilée était la version 2.9.3, votre mise à jour indépendante
+ aura le numéro de version 2.9-3+b1. Si la dernière version était
+ 3.4+b1 (i.e. un paquet natif avec une précédente mise à jour
+ indépendante par recompilation), votre mise à jour indépendant aura
+ le numéro de version 3.4+b2. <footnote><p>Par le passé, de telles
+ mises à jour indépendantes utilisaient le numéro de troisième niveau
+ de la partie Debian de la révision pour dénoter l'état de
+ recompilation uniquement ; cependant, cette syntaxe était
+ ambigüe pour les paquets natifs et ne permettait pas un ordre correct
+ des mises à jour indépendantes par recompilation uniquement, des
+ mises à jour indépendantes de source et des mises à jour
+ indépendantes de sécurité sur le même paquet et elle a donc été
+ abandonnée en faveur de cette nouvelle syntaxe.</p></footnote>
+ </p>
+ <p>
+ De manière similaire aux envois du porteur initial, la façon correcte
+ d'invoquer <prgn>dpkg-buildpackage</prgn> est <tt>dpkg-buildpackage
+ -B</tt> pour ne construire que les parties dépendant de
+ l'architecture du paquet.
+ </p>
+ </sect2>
+ <sect2 id="source-nmu-when-porter">
+ <heading>
+ Quand faire une mise à jour indépendante source pour un
+ portage ?
+ </heading>
+ <p>
+ Les porteurs qui font des mises à jour indépendantes sources suivent
+ généralement les instructions de la section <ref id="nmu"> tout comme
+ les non-porteurs. Les délais d'attente sont cependant plus courts car
+ les porteurs doivent manipuler un grand nombre de paquets. À nouveau,
+ la situation diffère selon la distribution visée. Elle varie
+ également selon que l'architecture est candidate pour inclusion dans
+ la prochaine version stable ; les responsables de publication
+ décident et annoncent quelles architectures sont candidates.
+ </p>
+ <p>
+ Si vous êtes porteur et faites une mise à jour pour
+ <em>unstable</em>, les instructions précédentes sont applicables à
+ deux différences près. Tout d'abord, le temps d'attente raisonnable
+ — délai entre le moment où vous envoyez un rapport au
+ système de suivi des bogues et le moment où vous pouvez faire une
+ mise à jour indépendante <em>(NMU)</em> — est de sept
+ jours. Ce délai peut être raccourci si le problème est crucial et met
+ l'effort de portage en difficulté : c'est à la discrétion de l'équipe
+ de portage. (Souvenez-vous, il ne s'agit pas d'un règlement, mais de
+ recommandations communément acceptées). Pour les envois de
+ <em>stable</em> ou <em>testing</em>, veuillez tout d'abord vous
+ coordonner avec l'équipe de publication appropriée.
+ </p>
+ <p>
+ Deuxième différence, les porteurs qui font des mises à jour
+ indépendantes sources doivent choisir une gravité <em>sérieuse</em>
+ (i.e. <em>serious</em>) ou supérieure quand ils envoient leur rapport
+ au système de suivi des bogues. Ceci assure qu'un paquet source
+ unique permet de produire un paquet binaire pour chaque architecture
+ supportée au moment de la sortie de la distribution. Il est très
+ important d'avoir un paquet source et un paquet binaire pour toutes
+ les architectures pour être conforme à plusieurs licences.
+ </p>
+ <p>
+ Les porteurs doivent éviter d'implémenter des contournements pour des
+ bogues de l'environnement de compilation, du noyau ou de la
+ libc. Quelques fois, ces contournements sont inévitables. Si vous
+ devez faire quelque chose de ce genre, marquez proprement vos
+ modifications avec des <tt>#ifdef</tt> et documentez votre
+ contournement pour que l'on sache le retirer une fois que le problème
+ aura disparu.
+ </p>
+ <p>
+ Les porteurs peuvent aussi avoir une adresse où ils publient le
+ résultat de leur travail pendant le délai d'attente. Ainsi, d'autres
+ personnes peuvent bénéficier du travail du porteur même pendant ce
+ délai. Bien sûr, ces adresses n'ont rien d'officiel, alors soyez sur
+ vos gardes si vous les utilisez.
+ </p>
+ </sect2>
+ </sect1>
+ <sect1 id="porter-automation">
+ <heading>
+ Infrastructure de portage et automatisation
+ </heading>
+ <p>
+ Il existe une infrastructure et plusieurs outils pour faciliter
+ l'automatisation du portage des paquets. Cette section contient un
+ bref aperçu de cette automatisation et du portage de ces outils ;
+ veuillez vous reporter à la documentation des paquets ou les
+ références pour une information complète.
+ </p>
+ <sect2>
+ <heading>
+ Listes de diffusion et pages web
+ </heading>
+ <p>
+ Les pages web contenant l'état de chaque portage peuvent être
+ trouvées à <url id="&url-debian-ports;">.
+ </p>
+ <p>
+ Chaque portage de Debian possède sa propre liste de diffusion. La
+ liste des listes de diffusion de portage peut être trouvée à <url
+ id="&url-debian-port-lists;">. Ces listes sont utilisées pour
+ coordonner les porteurs et pour mettre en relation les utilisateurs
+ d'un portage donné avec les porteurs.
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ Outils pour les porteurs
+ </heading>
+ <p>
+ Les descriptions de plusieurs outils de portage peuvent être trouvées
+ dans les <ref id="tools-porting">.
+ </p>
+ </sect2>
+ <sect2 id="buildd">
+ <heading>
+ <package>buildd</package>
+ </heading>
+ <p>
+ Le système <package>buildd</package> est un système distribué pour la
+ compilation d'une distribution. Il est habituellement utilisé en
+ conjonction avec des automates de compilation ; ce sont des
+ machines « esclaves » qui récupèrent des paquets sources et
+ tentent de les compiler. Il est aussi possible d'interagir par
+ courrier électronique avec ce système. Cette interface est utilisée
+ par les porteurs pour récupérer un paquet source (en général, un
+ paquet qui ne peut être compilé automatiquement) et travailler
+ dessus.
+ </p>
+ <p>
+ <package>buildd</package> n'est pas disponible sous forme de
+ paquet ; pourtant, la plupart des équipes de porteurs
+ l'utilisent aujourd'hui ou ont prévu de l'utiliser bientôt. L'outil
+ de construction automatisé réel est dans le paquet
+ <package>sbuild</package>, voir la description dans <ref
+ id="sbuild">. Le système <package>buildd</package> regroupe également
+ un ensemble de composants très utiles, continuellement utilisés, mais
+ non encore mis en paquet, tels que <prgn>andrea</prgn> et
+ <prgn>wanna-build</prgn>.
+ </p>
+ <p>
+ Une partie des informations produites par <package>buildd</package>
+ — utiles pour les porteurs — est disponible sur
+ la toile à l'adresse <url id="&url-buildd;">. Ces informations
+ incluent les résultats produits toutes les nuits par
+ <prgn>andrea</prgn> (dépendances des sources) et
+ <prgn>quinn-diff</prgn> (paquets à recompiler).
+ </p>
+ <p>
+ Nous sommes très fiers de ce système car il a de nombreux usages
+ potentiels. Des groupes de développeurs indépendants peuvent utiliser
+ ce système pour créer différentes saveurs de Debian — qui
+ peuvent être ou ne pas être intéressantes pour tous (par exemple, une
+ version de Debian compilée avec des vérifications relatives à
+ <prgn>gcc</prgn>). Ce système nous permettra aussi de recompiler
+ rapidement toute une distribution.
+ </p>
+ <p>
+ Les administrateurs des buildds pour chaque architecture peuvent être
+ contactés à l'adresse électronique $arch@buildd.debian.org.
+ </p>
+ </sect2>
+ </sect1>
+ <sect1 id="packages-arch-specific">
+ <heading>
+ Quand votre paquet <em>n'est pas</em> portable
+ </heading>
+ <p>
+ Certains paquets ont encore des problèmes pour être construits et/ou
+ pour fonctionner sur certaines des architectures prises en charge par
+ Debian et ne peuvent pas du tout être portés, ou pas dans un laps de
+ temps raisonnable. Un exemple est un paquet qui est spécifique SGVA
+ (i386 seulement) ou qui utilise des fonctionnalités spécifiques au
+ matériel qui ne sont pas gérées sur toutes les architectures.
+ </p>
+ <p>
+ Pour éviter que des paquets cassés soient envoyés dans l'archive et
+ qu'ils fassent perdre du temps des buildd, vous devez faire plusieurs
+ choses :
+ </p>
+ <p>
+ <list>
+ <item>
+ <p>
+ Tout d'abord, assurez-vous que votre paquet <em>échoue</em> à la
+ compilation sur les architectures qu'il ne gère pas. Il y a
+ plusieurs moyens de faire cela. Le moyen préféré est d'avoir une
+ petite suite de tests pendant la construction qui testera la
+ fonctionnalité et qui échouera si cela ne fonctionne pas. C'est de
+ toute façon une bonne idée et empêchera des (certains) envois
+ cassés pour toutes les architectures, et cela permettra également
+ au paquet d'être construit dès que la fonctionnalité nécessaire est
+ disponible.
+ </p>
+ <p>
+ De plus, si vous croyez que la liste des architectures gérées est
+ plutôt constante, vous devriez changer « any » en une
+ liste des architectures gérées dans le fichier
+ <file>debian/control</file>. Ainsi, la construction échouera
+ également et l'indiquera à un lecteur humain sans vraiment essayer.
+ </p>
+ </item>
+ <item>
+ <p>
+ Pour empêcher les compilateurs automatiques de tenter sans raison
+ de construire votre paquet, il doit être inclus dans
+ <file>packages-arch-specific</file>, une liste utilisée par le
+ script <prgn>wanna-build</prgn>. La version actuelle est disponible
+ à <url
+ id="http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak"> ;
+ veuillez consulter le début du fichier pour savoir qui contacter
+ pour le modifier.
+ </p>
+ </item>
+ </list>
+ </p>
+ <p>
+ Veuillez noter qu'il est insuffisant de simplement ajouter votre
+ paquet à Packages-arch-specific sans le faire également échouer lors
+ de compilation sur les architectures non gérées : un porteur ou
+ toute autre personne essayant de construire votre paquet peut
+ accidentellement l'envoyer sans remarquer qu'il ne fonctionne pas. Si
+ dans le passé, certains paquets binaires ont été envoyés pour des
+ architectures non gérées, demandez leur suppression en remplissant un
+ bogue sur <package>ftp.debian.org</package>.
+ </p>
+ </sect1>
+ </sect>
+ <sect id="nmu">
+ <heading>
+ Mise à jour indépendante
+ </heading>
+ <p>
+ Dans certaines circonstances, il est nécessaire qu'une personne autre
+ que le responsable d'un paquet fasse une mise à jour de ce paquet. Ce
+ type de mise à jour est désigné en anglais par l'expression
+ <em>non-maintainer upload (NMU)</em>. Dans le présent document, nous
+ traduisons librement cette expression par « mise à jour
+ indépendante ».
+ </p>
+ <p>
+ Cette section ne traite que des mises à jour indépendantes de source,
+ c.-à-d., les mises à jour qui envoient une nouvelle version d'un
+ paquet. Pour les mises à jour indépendantes par des porteurs ou des
+ membres de la QA, veuillez consulter <ref id="binary-only-nmu">. Si un
+ buildd construit et envoie un paquet, cela est également à strictement
+ parler une NMU binaire. Veuillez consulter <ref id="buildd"> pour plus
+ d'informations.
+ </p>
+ <p>
+ La raison principale pour laquelle une mise à jour indépendante est
+ réalisée est quand un développeur a besoin de corriger le paquet d'un
+ autre développeur pour résoudre des problèmes sérieux ou des bogues
+ paralysants ou quand le responsable d'un paquet ne peut pas fournir une
+ correction dans un délai raisonnable.
+ </p>
+ <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.
+ </p>
+ <p>
+ Et souvenez-vous du Serment d'Hippocrate « Par dessus tout,
+ ne pas faire de mal ». Il est préférable de laisser un paquet avec
+ un bogue ouvert grave plutôt qu'appliquer un correctif non fonctionnel
+ ou un correctif qui cache le bogue sans le résoudre.
+ </p>
+ <sect1 id="nmu-guidelines">
+ <heading>
+ Comment faire une mise à jour indépendante ?
+ </heading>
+ <p>
+ Les mises à jour indépendantes qui corrigent des bogues de gravité
+ importante, sérieuse et plus élevée sont encouragées et
+ acceptées. Vous devriez vous efforcer de contacter le responsable
+ actuel du paquet : il est peut-être sur le point d'envoyer un
+ correctif pour le problème ou il a peut-être une meilleure solution.
+ </p>
+ <p>
+ Les mises à jour indépendantes doivent être réalisées pour assister un
+ responsable de paquet à résoudre des bogues. Les responsables
+ devraient être reconnaissants pour cette aide et les personnes faisant
+ la mise à jour indépendante devraient respecter les décisions du
+ responsable et tenter d'aider personnellement le responsable dans son
+ travail.
+ </p>
+ <p>
+ Une mise à jour indépendante devrait suivre toutes les conventions
+ décrites dans cette section. Pour un envoi vers <em>testing</em> ou
+ <em>unstable</em>, l'ordre suivant des étapes est recommandé :
+ </p>
+ <p>
+ <list>
+ <item>
+ <p>
+ Vérifiez que les bogues du paquet qui devraient être corrigés par
+ la mise à jour indépendante sont bien référencés dans le système de
+ suivi des bogues. S'ils n'y sont pas, faites des rapports de bogue
+ immédiatement.
+ </p>
+ </item>
+ <item>
+ <p>
+ Attendez la réponse du responsable quelques jours. Si vous
+ n'obtenez aucune réponse, vous pouvez l'aider en lui envoyant le
+ correctif qui corrige le bogue. N'oubliez pas de marquer le bogue
+ avec le mot-clé « patch ».
+ </p>
+ </item>
+ <item>
+ <p>
+ Patientez quelques jours. Si vous n'avez toujours aucune réponse du
+ responsable, envoyez-lui un courrier annonçant votre intention
+ d'effectuer une mise à jour indépendante du paquet. Préparez la NMU
+ comme décrit dans cette section et testez-la soigneusement sur
+ votre machine (cf. <ref id="sanitycheck">). Re-vérifiez que votre
+ correctif n'a aucun effet de bord inattendu. Assurez-vous que votre
+ correctif est aussi minimaliste et non intrusif que possible.
+ </p>
+ </item>
+ <item>
+ <p>
+ Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file>
+ (cf. <ref id="delayed-incoming">), envoyez le correctif final au
+ responsable par le BTS et expliquez-lui qu'il a 7 jours pour réagir
+ s'il veut annuler la NMU.
+ </p>
+ </item>
+ <item>
+ <p>
+ Suivez ce qui se passe, vous êtes responsable pour tout bogue que
+ vous auriez introduit avec votre NMU. Vous devriez probablement
+ utiliser le <ref id="pkg-tracking-system"> (PTS) pour vous tenir
+ informé de l'état du paquet après votre NMU.
+ </p>
+ </item>
+ </list>
+ </p>
+ <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. Veuillez vous
+ reporter à <ref id="qa-bsp"> pour des détails.
+ </p>
+ <p>
+ Pour la distribution <em>testing</em>, les règles peuvent être
+ changées par les responsables de publication. Veuillez porter une
+ attention spéciale au fait que le moyen habituel pour un paquet
+ d'entrer dans <em>testing</em> est de passer par <em>unstable</em>.
+ </p>
+ <p>
+ Pour la distribution <em>stable</em>, veuillez y apporter une
+ attention supplémentaire. Bien sûr, les responsables de publication
+ peuvent également modifier les règles ici. Veuillez vérifier avant
+ votre envoi que tous vos changements sont acceptables pour inclusion
+ dans la prochaine version stable par le responsable de publication.
+ </p>
+ <p>
+ Quand un bogue de sécurité est détecté, l'équipe de sécurité peut
+ effectuer une mise à jour indépendante en utilisant ses propres
+ règles. Veuillez vous référer à <ref id="bug-security"> pour plus
+ d'informations.
+ </p>
+ <p>
+ Pour les différences concernant les mises à jour indépendantes par les
+ porteurs, veuillez voir <ref id="source-nmu-when-porter">.
+ </p>
+ <p>
+ Bien sûr, il est toujours possible de s'accorder avec un responsable
+ pour des règles spéciales (comme quand le responsable demande
+ « merci d'envoyer le correctif directement pour moi et pas de
+ diff nécessaire »).
+ </p>
+ </sect1>
+ <sect1 id="nmu-version">
+ <heading>
+ Numéro de version pour les mises à jour indépendantes
+ </heading>
+ <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>
+ <p>
+ Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez
+ ajouter un numéro de version mineur à la partie
+ <var>révision-debian</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>
+ <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>
+ <p>
+ S'il n'y a pas de partie <var>révision-debian</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 responsable du paquet doit, lui,
+ démarrer sa numérotation à « 1 ».
+ </p>
+ <p>
+ Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>,
+ vous devrez parfois créer une branche (« fork ») dans
+ l'arbre de numéro des version. Pour cela, vous pouvez utiliser des
+ numéros de version comme 1.1-3sarge0.1.
+ </p>
+ </sect1>
+ <sect1 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 l'envoi ainsi que la version livrée.
+ </p>
+ <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>
+ </p>
+ </sect1>
+ <sect1 id="nmu-patch">
+ <heading>
+ Mise à jour indépendante source et système de suivi des bogues
+ </heading>
+ <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>
+ <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>
+ <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 ferment les rapports. 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>
+ <p>
+ Après avoir fait une mise à jour indépendante, il vous faudra aussi
+ envoyer l'information aux bogues existants que vous avez corrigés
+ par votre NMU en incluant le diff unifié. Historiquement, c'était une
+ habitude de créer un
+ nouveau rapport de bogue et inclure un correctif comprenant toutes les
+ modifications que vous avez réalisées. 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>
+ <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> — et bien sûr, également conserver les
+ modifications. Si vous annulez certaines des modifications, veuillez
+ réouvrir les rapports de bogue correspondants.
+ </p>
+ </sect1>
+ <sect1 id="nmu-build">
+ <heading>
+ Fabriquer une mise à jour indépendante source
+ </heading>
+ <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 instructions de la section <ref id="upload">.
+ </p>
+ <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>.
+ </p>
+ </sect1>
+ <sect1 id="ack-nmu">
+ <heading>
+ Valider une mise à jour indépendante
+ </heading>
+ <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. Le moyen le plus simple est
+ d'utiliser l'option <tt>-v</tt> de <prgn>dpkg-buildpackage</prgn> car
+ cela vous permet d'inclure tous les changements depuis votre dernier
+ envoi de responsable. Sinon, 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>
+ <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">).
+ </p>
+ </sect1>
+ <sect1 id="nmu-vs-qa">
+ <heading>
+ Mise à jour indépendante ou envoi de QA ?
+ </heading>
+ <p>
+ Sauf si vous savez que le responsable est toujours actif, il est sage
+ de vérifier le paquet pour voir s'il n'a pas été abandonné. La liste
+ actuelle des paquets orphelins pour lesquels le champ responsable n'a
+ pas été positionné correctement est disponible à <url
+ id="&url-debian-qa-orphaned;">. Si vous effectuez une mise à jour
+ indépendante sur un paquet incorrectement orphelin, veuillez
+ positionner le responsable à « Debian QA Group
+ <packages@qa.debian.org> ».
+ </p>
+ </sect1>
+ <sect1 id="nmu-who">
+ <heading>
+ Qui peut faire une mise à jour indépendante ?
+ </heading>
+ <p>
+ Seuls les responsables Debian officiels peuvent faire des mises à jour
+ indépendantes binaire ou source. Un responsable officiel est une
+ personne dont la clé est dans le porte-clés Debian. Tout autre
+ personne est toutefois invitée à télécharger les paquets sources pour
+ corriger des bogues ; au lieu de faire des mises à jour
+ indépendantes, ils pourront soumettre les correctifs qui le méritent
+ au système de suivi des bogues. Les responsables apprécient presque
+ toujours les correctifs et les rapports de bogue soignés.
+ </p>
+ </sect1>
+ <sect1 id="nmu-terms">
+ <heading>
+ Terminologie
+ </heading>
+ <p>
+ Deux nouvelles expressions sont introduites dans cette section :
+ « mise à jour indépendante source » et « mise à jour
+ indépendante binaire ». Ces deux expressions ont une
+ signification technique précise dans ce document. Elles correspondent
+ toutes deux au même type d'activité ; elles impliquent toutes
+ deux qu'une personne fait une mise à jour d'un paquet alors qu'elle
+ n'est pas officiellement responsable de ce paquet. C'est pourquoi nous
+ qualifions ces mises à jours
+ d'<em>indépendantes</em><footnote><p>Contrairement à ce que pourrait
+ laisser entendre cette traduction de <em>non-maintainer upload</em>,
+ il n'est pas question d'agir sans prévenir le responsable au préalable
+ (voir <ref id="nmu-guidelines">).</p></footnote>.
+ </p>
+ <p>
+ Une mise à jour indépendante source est une livraison de paquet faite
+ par une personne qui n'est pas le responsable officiel de ce paquet
+ avec pour objectif de corriger un bogue dans le paquet. Une mise à
+ jour indépendante source implique toujours une modification des
+ sources du paquet, même s'il ne s'agit que d'un changement dans le
+ fichier <file>debian/changelog</file>. Ce changement peut tout aussi
+ bien concerner la partie amont du source que la partie spécifique à
+ Debian. Une mise à jour indépendante source peut aussi inclure des
+ paquets spécifiques à une architecture tout comme un fichier
+ <em>diff</em> modifié.
+ </p>
+ <p>
+ Une mise à jour indépendante binaire est constituée par la
+ recompilation et l'archivage d'un paquet pour une architecture
+ donnée. Il s'agit souvent du résultat d'un effort de portage. Une mise
+ à jour indépendante binaire est la livraison d'un paquet compilé
+ (souvent pour une autre architecture) à condition que cette
+ compilation n'ait pas nécessité de modifications des sources. Dans de
+ nombreux cas, les porteurs sont obligés de modifier les sources pour
+ les rendre compilables sur leur architecture cible ; il s'agira
+ alors d'une mise à jour indépendante source et non d'une mise à jour
+ indépendante binaire. Comme vous pouvez le remarquer, nous ne faisons
+ pas de distinction entre les mises à jour indépendantes faites par des
+ porteurs et les autres mises à jour indépendantes.
+ </p>
+ <p>
+ Les mises à jour indépendantes sources et binaires sont toutes deux
+ couvertes par l'expression « mise à jour indépendante »
+ (NMU<footnote><p>Non-maintainer upload</p></footnote>). Pourtant, cela
+ conduit souvent à des confusions car beaucoup associent « mise à
+ jour indépendante » et « mise à jour indépendante
+ source ». Il faut donc rester vigilant : utilisez toujours
+ « mise à jour indépendante binaire » ou «NMU binaire »
+ pour les mises à jour indépendantes de binaires seuls.
+ </p>
+ </sect1>
+ </sect>
+ <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>
+ <p>
+ Habituellement, il y a un responsable principal et un ou plusieurs
+ co-responsables. Le responsable principal est la personne 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>
+ <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>.
+ </p>
+ </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>
+ </p>
+ </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.
+ </p>
+ </item>
+ </list>
+ </p>
+ <p>
+ La maintenance collective peut souvent être facilitée par l'utilisation
+ d'outils sur Alioth (voir <ref id="alioth">).
+ </p>
+ </sect>
+ <sect id="testing">
+ <heading>
+ La distribution <em>testing</em>
+ </heading>
+ <p>
+ </p>
+ <sect1 id="testing-basics">
+ <heading>
+ Bases
+ </heading>
+ <p>
+ Les paquets sont habituellement installés dans la distribution
+ <em>testing</em> après avoir atteint un certain degré de test dans
+ <em>unstable</em>.
+ </p>
+ <p>
+ Ils doivent être en synchronisation pour toutes les architectures et
+ ne doivent pas avoir de dépendances qui les rendraient non
+ installables ; ils doivent également n'avoir aucun bogue bloquant
+ l'inclusion du paquet dans une version stable
+ (« release-critical ») au moment où ils sont installés dans
+ <em>testing</em>. Ainsi, <em>testing</em> devrait toujours être prête
+ pour être une version candidate stable. Veuillez voir ci-dessous pour
+ les détails.
+ </p>
+ </sect1>
+ <sect1 id="testing-unstable">
+ <heading>
+ Mises à jour depuis <em>unstable</em>
+ </heading>
+ <p>
+ Les scripts qui mettent à jour la distribution <em>testing</em> sont
+ exécutés chaque jour après l'installation des paquets mis à
+ jour ; ces scripts sont appelés <em>britney</em>. Ils fabriquent
+ les fichiers <file>Packages</file> pour la distribution
+ <em>testing</em>, mais ils le font d'une manière intelligente pour
+ éviter toute incohérence et essayer de n'utiliser que des paquets sans
+ bogue.
+ </p>
+ <p>
+ L'inclusion d'un paquet d'<em>unstable</em> est soumise aux conditions
+ suivantes :
+ <list>
+ <item>
+ <p>
+ Le paquet doit avoir été disponible dans <em>unstable</em> depuis
+ 2, 5 ou 10 jours selon le champ d'urgence de l'envoi (élevée,
+ moyenne ou basse). Veuillez noter que cette urgence est
+ « collante » (« sticky »), ce qui veut dire que
+ l'envoi avec l'urgence la plus élevée depuis la précédente
+ transition dans <em>testing</em> est prise en compte. Ces délais
+ peuvent être doublés lors d'un gel de distribution, ou les
+ transitions dans <em>testing</em> peuvent être complètement
+ désactivées ;
+ </p>
+ </item>
+ <item>
+ <p>
+ Il doit avoir autant ou moins de bogues empêchant l'intégration
+ dans la distribution que la version actuellement disponible dans
+ <em>testing</em> ;
+ </p>
+ </item>
+ <item>
+ <p>
+ Il doit être disponible pour toutes les architectures pour
+ lesquelles il a été auparavant construit. <ref id="madison"> peut
+ être intéressant pour vérifier cette information ;
+ </p>
+ </item>
+ <item>
+ <p>
+ Il ne doit pas casser les dépendances d'un paquet qui est déjà
+ disponible dans <em>testing</em> ;
+ </p>
+ </item>
+ <item>
+ <p>
+ Les paquets dont il dépend doivent soit être déjà disponibles dans
+ <em>testing</em> soit être acceptés dans <em>testing</em> au même
+ moment (et ils doivent remplir tous les critères nécessaires).
+ </p>
+ </item>
+ </list>
+ </p>
+ <p>
+ Pour savoir si un paquet a progressé ou non dans <em>testing</em>,
+ veuillez voir la sortie du script de <em>testing</em> sur la <url
+ id="&url-testing-maint;" name="page web de la distribution testing">
+ ou utilisez le programme <prgn>grep-excuses</prgn> inclus dans le
+ paquet <package>devscripts</package>. Si vous voulez rester informé de
+ la progression de vos paquets dans <em>testing</em>, vous pouvez
+ facilement le mettre dans la <manref section="5" name="crontab">.
+ </p>
+ <p>
+ Le fichier <file>update_excuses</file> ne donne pas toujours la raison
+ précise pour laquelle un paquet est refusé ; on peut avoir à la
+ chercher soi-même en regardant ce qui serait cassé avec l'inclusion du
+ paquet. La <url id="&url-testing-maint;" name="page web de la
+ distribution testing"> donne plus d'informations à propos des
+ problèmes courants qui peuvent occasionner cela.
+ </p>
+ <p>
+ Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce
+ que le jeu des inter-relations est trop compliqué et ne peut être
+ résolu par le script. Voir ci-dessous pour des détails.
+ </p>
+ <p>
+ Des analyses de dépendances plus avancées sont présentées sur <url
+ id="http://bjorn.haxx.se/debian/"> — mais, attention, cette page
+ affiche également les dépendances de construction qui ne sont pas
+ considérées par britney.
+ </p>
+ <sect2 id="outdated">
+ <heading>
+ Désynchronisation
+ </heading>
+ <p>
+ Pour le script de migration dans <em>testing</em>,
+ « désynchronisé » (<em>outdated</em> veut dire ceci :
+ il y a différentes versions dans <em>unstable</em> pour les
+ architectures de version (à l'exception des architectures dans
+ fuckedarches ; fuckedarches est une liste des architectures qui
+ ne suivent pas le rythme (dans update_out.py), mais actuellement
+ cette liste est vide). « Désynchronisé » n'a rien à voir
+ avec les architectures que le paquet fournit pour <em>testing</em>.
+ </p>
+ <p>
+ Considérons cet exemple :
+ </p>
+ <p>
+ <example>
+foo | alpha | arm
+---------+-------+----
+testing | 1 | -
+unstable | 1 | 2
+</example>
+ </p>
+ <p>
+ Le paquet est désynchronisé pour alpha dans <em>unstable</em> et
+ n'entrera pas dans <em>testing</em>. Supprimer foo de
+ <em>testing</em> n'aiderait en rien, le paquet serait toujours
+ désynchronisé pour alpha et ne se propagerait pas dans
+ <em>testing</em>.
+ </p>
+ <p>
+ Cependant, si ftp-master supprime un paquet d'<em>unstable</em> (ici
+ pour arm) :
+ </p>
+ <p>
+ <example>
+foo | alpha | arm | hurd-i386
+---------+-------+-----+----------
+testing | 1 | 1 | -
+unstable | 2 | - | 1
+ </example>
+ </p>
+ <p>
+ Dans ce cas, le paquet est synchronisé pour toutes les architectures
+ de version dans <em>unstable</em> (et l'architecture supplémentaire
+ hurd-i386 ne compte pas car ce n'est pas une architecture de
+ version).
+ </p>
+ <p>
+ Quelquefois, la question est soulevée pour savoir s'il est possible
+ de permettre à des paquets de passer dans <em>testing</em> qui ne
+ sont pas encore construits pour toutes les architectures :
+ non. Simplement non. (Excepté si vous êtes responsable de glibc ou
+ équivalent).
+ </p>
+ </sect2>
+ <sect2 id="removals">
+ <heading>
+ Suppressions de <em>testing</em>
+ </heading>
+ <p>
+ Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre
+ paquet : ceci ne se produit que pour permettre à un
+ <em>autre</em> paquet d'entrer, ce dernier doit être prêt pour tous
+ les autres critères. Considérons, par exemple, qu'un paquet
+ <em>a</em> ne peut pas être installé avec la nouvelle version de
+ <em>b</em> alors <em>a</em> peut être supprimé pour permettre
+ l'entrée de <em>b</em>.
+ </p>
+ <p>
+ Bien sûr, il existe une autre raison pour supprimer un paquet de
+ <em>testing</em> : le paquet est trop bogué (et avoir un seul
+ bogue RC est suffisant pour être dans cet état).
+ </p>
+ <p>
+ De plus, si un paquet a été supprimé d'<em>unstable</em> et qu'aucun
+ paquet de <em>testing</em> n'en dépend plus, il sera alors
+ automatiquement supprimé.
+ </p>
+
+ </sect2>
+ <sect2 id="circular">
+ <heading>
+ Dépendances circulaires
+ </heading>
+ <p>
+ Une situation qui n'est pas très bien gérée par britney est si un
+ paquet <em>a</em> dépend de la nouvelle version d'un paquet
+ <em>b</em> et vice versa.
+ </p>
+ <p>
+ Voici un exemple :
+ </p>
+ <p>
+ <example>
+ | testing | unstable
+--+-----------------+------------
+a | 1; dépend: b=1 | 2; dépend: b=2
+b | 1; dépend: a=1 | 2; dépend: a=2
+ </example>
+ </p>
+ <p>
+ Aucun des paquets <em>a</em> et <em>b</em> ne sera considéré pour
+ mise à jour.
+ </p>
+ <p>
+ Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de
+ publication. Veuillez les contacter en envoyant un courrier
+ électronique à debian-release@lists.debian.org si cela se produit
+ pour l'un de vos paquets.
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ Influence d'un paquet dans <em>testing</em>
+ </heading>
+ <p>
+ Généralement, l'état d'un paquet dans <em>testing</em> ne change rien
+ pour la transition de la prochaine version d'<em>unstable</em> vers
+ <em>testing</em>, avec deux exceptions : si le nombre de bogues
+ RC du paquet est réduit, le paquet peut migrer même s'il a encore des
+ bogues RC. La seconde exception est que si la version du paquet dans
+ <em>testing</em> est désynchronisée entre les différentes
+ architectures, alors toute architecture peut être mise à jour vers la
+ version du paquet source ; cependant, cela ne peut se produire
+ que si le paquet a été précédemment forcé, si l'architecture est dans
+ fuckedarches ou s'il n'y avait pas du tout de paquet binaire de cette
+ architecture présent dans <em>unstable</em> lors de la migration dans
+ <em>testing</em>.
+ </p>
+ <p>
+ En résumé, cela veut dire : la seule influence qu'un paquet de
+ <em>testing</em> a sur la nouvelle version du même paquet est que la
+ nouvelle version peut rentrer plus facilement.
+ </p>
+ </sect2>
+ <sect2 id="details">
+ <heading>
+ Détails
+ </heading>
+ <p>
+ Si vous êtes intéressé par les détails, voici comment fonctionne
+ britney :
+ </p>
+ <p>
+ Les paquets sont examinés pour savoir si ce sont des candidats
+ valides. Cela donne le fichier « update excuses ». Les
+ raisons les plus communes pour lesquelles un paquet n'est pas
+ considéré sont la jeunesse du paquet, le nombre de bogues RC et la
+ désynchronisation pour certaines architectures. Pour cette partie de britney,
+ les responsables de version ont des marteaux de toute taille pour
+ forcer britney à considérer un paquet. (Le gel de la base est
+ également codé dans cette partie de britney.) (Il y a une chose
+ semblable pour les mises à jour binaires pures, mais cela n'est pas
+ décrit ici. Si vous êtes intéressé par cela, veuillez étudier
+ attentivement le code.)
+ </p>
+ <p>
+ Maintenant, la partie la plus complexe se produit : britney
+ tente de mettre à jour <em>testing</em> avec des candidats
+ valides ; en premier, chaque paquet individuellement, puis des
+ groupes de plus en plus larges de paquets ensemble. Chaque tentative
+ est acceptée si <em>testing</em> n'est pas moins non installable
+ après la mise à jour qu'avant celle-ci. (Avant et après cette partie,
+ certains coups de pouce (« hints ») sont traités ;
+ mais, comme seuls les responsables de version peuvent positionner des
+ coups de pouce, cela n'est probablement pas très important pour
+ vous.)
+ </p>
+ <p>
+ Si vous voulez voir plus de détails, vous pouvez le voir dans
+ merkel:/org/ftp.debian.org/testing/update_out/ (ou dans
+ ~aba/testing/update_out pour voir une configuration avec un fichier
+ de paquets plus petit). Par le web, c'est à <url
+ id="http://ftp-master.debian.org/testing/update_out_code/">.
+ </p>
+ <p>
+ Les coups de pouce sont visibles sur <url
+ id="http://ftp-master.debian.org/testing/hints/">.
+ </p>
+ </sect2>
+ </sect1>
+ <sect1 id="t-p-u">
+ <heading>
+ Mises à jour directes dans <em>testing</em>
+ </heading>
+ <p>
+ La distribution <em>testing</em> est peuplée avec des paquets en
+ provenance d'<em>unstable</em> selon des règles expliquées
+ ci-dessus. Cependant, dans certains cas, il est nécessaire d'envoyer
+ des paquets construits seulement pour <em>testing</em>. Pour cela,
+ vous pouvez envoyer vos paquets vers
+ <em>testing-proposed-updates</em>.
+ </p>
+ <p>
+ Souvenez-vous que les paquets envoyés là ne sont pas traités
+ automatiquement, ils doivent passer entre les mains du responsable de
+ distribution. Vous devez donc avoir une bonne raison pour les y
+ envoyer. Pour savoir ce que représente une bonne raison aux yeux des
+ responsables de distribution, vous devriez lire les instructions
+ données qu'ils envoient régulièrement sur
+ &email-debian-devel-announce;.
+ </p>
+ <p>
+ Vous ne devriez pas envoyer un paquet à
+ <em>testing-proposed-updates</em> quand vous pouvez le mettre à jour
+ par <em>unstable</em>. Si vous ne pouvez faire autrement (par exemple,
+ parce que vous avez une nouvelle version de développement dans
+ <em>unstable</em>), vous pouvez utiliser cette facilité, mais il est
+ recommandé de demander l'autorisation du responsable de distribution
+ auparavant. Même si un paquet est gelé, des mises à jour par
+ <em>unstable</em> sont possibles si l'envoi dans <em>unstable</em> ne
+ tire pas de nouvelles dépendances.
+ </p>
+ <p>
+ Les numéros de version sont habituellement choisis en ajoutant le nom
+ de code de la distribution <em>testing</em> et un numéro incrémenté,
+ comme 1.2sarge1 pour le premier envoi dans
+ <em>testing-proposed-updates</em> du paquet en version 1.2.
+ </p>
+ <p>
+ Veuillez vous assurer que vous n'oubliez aucun des éléments suivants
+ lors de votre envoi :
+ <list>
+ <item>
+ <p>
+ vérifiez que votre paquet doit vraiment aller dans
+ <em>testing-proposed-updates</em> et ne peut pas passer par
+ <em>unstable</em> ;
+ </p>
+ </item>
+ <item>
+ <p>
+ vérifiez que vous n'incluez que le minimum de changements ;
+ </p>
+ </item>
+ <item>
+ <p>
+ vérifiez que vous incluez une explication appropriée dans le
+ changelog ;
+ </p>
+ </item>
+ <item>
+ <p>
+ vérifiez que vous avez bien indiqué <em>testing</em> ou
+ <em>testing-proposed-updates</em> comme votre distribution
+ cible ;
+ </p>
+ </item>
+ <item>
+ <p>
+ vérifiez que vous avez construit et testé votre paquet dans
+ <em>testing</em> et non dans <em>unstable</em> ;
+ </p>
+ </item>
+ <item>
+ <p>
+ vérifiez que votre numéro de version est plus élevé que les
+ versions de <em>testing</em> et de
+ <em>testing-proposed-updates</em> et moins élevé que celle de
+ <em>unstable</em> ;
+ </p>
+ </item>
+ <item>
+ <p>
+ après l'envoi et la construction réussie sur toutes les
+ plates-formes, contactez l'équipe de publication à
+ &email-debian-release; et demandez-leur d'approuver votre envoi.
+ </p>
+ </item>
+ </list>
+ </p>
+ </sect1>
+ <sect1 id="faq">
+ <heading>
+ Questions fréquemment posées
+ </heading>
+ <p>
+ </p>
+ <sect2 id="rc">
+ <heading>
+ Quels sont les bogues bloquant l'intégration dans la version stable
+ et comment sont-ils comptés ?
+ </heading>
+ <p>
+ Tous les bogues de gravité assez élevée sont par défaut considérés
+ comme bloquant l'intégration du paquet dans la version stable ;
+ actuellement, ce sont les bogues critiques, graves et sérieux.
+ </p>
+ <p>
+ Certains bogues sont supposés avoir un impact sur les chances que le
+ paquet a d'être diffusé dans la version stable de Debian : en
+ général, si un paquet a des bogues bloquants, il n'ira pas dans
+ <em>testing</em> et par conséquent, ne pourra pas être diffusé dans
+ <em>stable</em>.
+ </p>
+ <p>
+ Le compte des bogues d'<em>unstable</em> est effectué avec tous les
+ bogues bloquants sans étiquette de version (comme <em>potato</em>,
+ <em>woody</em>) ou avec une étiquette <em>sid</em> et également s'ils
+ ne sont ni corrigés ou marqués avec <em>sarge-ignore</em>. Le compte
+ des bogues de <em>testing</em> pour un paquet est considéré comme à
+ peu près le nombre de bogues d'<em>unstable</em> lors du dernier
+ pointage quand la version <em>testing</em> a été égale à la version
+ <em>unstable</em>.
+ </p>
+ <p>
+ Cela changera après la sortie de <em>Sarge</em> dès que nous aurons
+ des versions dans le système de suivi des bogues.
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ Comment est-ce que l'installation d'un paquet dans <em>testing</em>
+ peut casser d'autres paquets ?
+ </heading>
+ <p>
+ La structure des archives de la distribution est faite de telle façon
+ qu'elles ne peuvent contenir qu'une version d'un paquet ; un
+ paquet est défini par son nom. Donc, quand le paquet source acmefoo
+ est installé dans <em>testing</em> avec ses paquets binaires
+ acme-foo-bin, acme-bar-bin, libacme-foo1 et libacme-foo-dev,
+ l'ancienne version est supprimée.
+ </p>
+ <p>
+ Cependant, l'ancienne version pouvait fournir à un paquet binaire un
+ vieux soname d'une bibliothèque, comme libacme-foo0. Supprimer
+ l'ancien acmefoo va supprimer libacme-foo0, ce qui va casser tout
+ paquet qui en dépend.
+ </p>
+ <p>
+ Évidemment, cela touche principalement des paquets qui fournissent
+ des jeux changeant de paquets binaires dans différentes versions (par
+ suite, principalement des bibliothèques). Cependant, cela va aussi
+ toucher des paquets sur lesquels une dépendance versionnée a été
+ déclarée du type ==, <= ou <<.
+ </p>
+ <p>
+ Quand le jeu de paquets binaires fournis par un paquet source change
+ de cette façon, tous les paquets qui dépendent des anciens binaires
+ doivent être mis à jour pour dépendre de la nouvelle version à la
+ place. Comme l'installation d'un tel paquet source dans
+ <em>testing</em> casse tous les paquets qui en dépendent dans
+ <em>testing</em>, une certaine attention doit y être portée :
+ tous les paquets en dépendant doivent être mis à jour et prêts à être
+ installés eux-même pour qu'ils ne cassent pas et, une fois que tout
+ est prêt, une intervention manuelle du responsable de version ou d'un
+ de ses assistants est normalement requise.
+ </p>
+ <p>
+ Si vous avez des problèmes avec des groupes compliqués de paquets
+ comme ceci, contactez debian-devel ou debian-release en demandant de
+ l'aide.
+ </p>
+ </sect2>
+ </sect1>
+ </sect>
+ </chapt>
+ <chapt id="best-pkging-practices">
+ <heading>
+ Les meilleurs pratiques pour la construction des paquets
+ </heading>
+ <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>
+ <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.
+ </p>
+ <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.
+ </p>
+ <sect1 id="helper-scripts">
+ <heading>
+ Scripts d'aide
+ </heading>
+ <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, la question de l'installation des
+ entrées de menu : vous avez besoin de placer un fichier dans
+ <file>/usr/share/menu</file> (ou <file>/usr/lib/menu</file> pour des
+ fichiers de menu binaires exécutables, si nécessaire) 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>
+ <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>
+ <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 compacte 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>
+ <p>
+ Vous pouvez débuter avec <package>debhelper</package> en lisant
+ <manref section="1" name="debhelper"> 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>
+ <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;">.
+ </p>
+ </sect1>
+ <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>
+ <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>
+ <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>
+ <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>
+ <sect1 id="multiple-binary">
+ <heading>
+ Paquets binaires multiples
+ </heading>
+ <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 (afin, par exemple, que l'utilisateur puisse n'installer
+ que la partie nécessaire et ainsi économiser de l'espace disque).
+ </p>
+ <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>
+ <p>
+ Le premier cas est un peu plus difficile 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.
+ </p>
+ </sect1>
+ </sect>
+ <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-binary.html#s-descriptions" name="règles pour
+ les descriptions des paquets">.
+ </p>
+ <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.
+ </p>
+ <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>
+ <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>
+ <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>
+ <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>
+ <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>
+ <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.
+ </p>
+ </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>
+ <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>
+ <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.
+ </p>
+ </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>
+ <p>
+ La description longue devrait toujours être constituée de phrases
+ complètes.
+ </p>
+ <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>
+ <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>
+ <p>
+ Soyez attentif à éviter les fautes d'orthographe et de
+ grammaire. N'oubliez pas votre vérificateur orthographique. Les deux
+ programmes <prgn>ispell</prgn> et <prgn>aspell</prgn> possèdent des
+ modes spéciaux pour vérifier les fichiers
+ <file>debian/control</file> :
+ <example>ispell -d american -g debian/control</example>
+ <example>aspell -d en -D -c debian/control</example>
+ </p>
+ <p>
+ Les utilisateurs s'attendent habituellement à ce que les réponses aux
+ questions suivantes soient présentes dans la description du
+ paquet :
+ <list>
+ <item>
+ <p>
+ Qu'est-ce que fait le paquet ? Si c'est un ajout d'un autre
+ paquet, la description courte du paquet dont c'est un ajout devrait
+ le spécifier.
+ </p>
+ </item>
+ <item>
+ <p>
+ Pourquoi est-ce qu'il voudrait installer ce paquet ? Ceci est
+ lié à ce qui est ci-dessus, mais pas tout à fait (c'est un client
+ de messagerie ; il est cool, rapide, s'interface avec PGP,
+ LDAP et IMAP, a les fonctionnalités X, Y et Z).
+ </p>
+ </item>
+ <item>
+ <p>
+ Si ce paquet ne devrait pas être installé directement, mais être
+ tiré par un autre paquet, cela devrait être mentionné.
+ </p>
+ </item>
+ <item>
+ <p>
+ Si le paquet est expérimental, ou s'il y a d'autres raisons pour
+ lesquelles il ne devrait pas être utilisé, si un autre paquet
+ devrait être utilisé à la place, cela devrait également être
+ présent.
+ </p>
+ </item>
+ <item>
+ <p>
+ En quoi le paquet est différent des paquets concurrents ?
+ Est-ce que c'est une meilleure implémentation ? A-t-il plus de
+ fonctionnalités, des fonctionnalités différentes ? Pourquoi
+ devrait-il choisir ce paquet ?
+ </p>
+ </item>
+ </list>
+ </p>
+ </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>
+ <p>
+ Ne mettez rien s'il n'existe pas de page pour le logiciel.
+ </p>
+ <p>
+ Veuillez noter que nous espérons que ce champ sera remplacé par un
+ vrai champ de <file>debian/control</file> qui serait compris par
+ <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. Veuillez vous assurer que cette ligne correspond à
+ l'expression rationnelle <tt>/^ Homepage: [^ ]*$/</tt> car cela permet
+ à <file>packages.debian.org</file> de l'analyser correctement.
+ </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
+ id="&url-debian-policy;ch-docs.html#s-changelogs" name="directive sur
+ les fichiers changelog">.
+ </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>
+ <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>
+ <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>
+ <p>
+ Utilisez un langage anglais commun pour que la majorité des lecteur
+ puissent le comprendre. Évitez les abré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>
+ <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>
+ <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.
+ </p>
+ </sect1>
+ <sect1 id="bpp-changelog-misconceptions">
+ <heading>
+ idées fausses communes 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>
+ <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>
+ <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>
+ <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. Comme nous avons maintenant le suivi des versions, il
+ est suffisant de garder les entrées de changelog des mises à jour
+ indépendantes et de simplement mentionner ce fait dans votre propre
+ entrée de changelog.
+ </p>
+ </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><p>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.</p></footnote>.
+ </p>
+ <p>
+ <example>
+ * Corrige tous les bogues restants.
+</example>
+ Ceci n'indique visiblement rien d'utile au lecteur.
+ </p>
+ <p>
+ <example>
+ * Correctif de Jane Random appliqué.
+</example>
+ Sur quoi portait le correctif ?
+ </p>
+ <p>
+ <example>
+ * Révision de cible d'installation la nuit dernière.
+</example>
+ Qu'a accompli la révision ? 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>
+ <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>
+ <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>
+ <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 amont également, vous n'avez
+ pas à suivre les bogues qui ont été corrigés il y a longtemps dans
+ votre changelog).
+ </p>
+ <p>
+ <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>
+ <sect1 id="bpp-news-debian">
+ <heading>
+ Compléter les changelogs avec les fichiers NEWS.Debian
+ </heading>
+ <p>
+ Les nouvelles importantes à propos des changements dans un paquet
+ peuvent également être placées dans les fichiers NEWS.Debian. Ces
+ nouvelles seront affichées par des outils comme apt-listchanges, avant
+ le reste des changelogs. Ceci est le moyen préféré pour informer les
+ utilisateurs des changements significatifs dans un paquet. Il est
+ préférable d'utiliser ce fichier plutôt que d'utiliser des notes
+ debconf car c'est moins ennuyeux et l'utilisateur peut y revenir et se
+ référer au fichier NEWS.Debian après l'installation. Et c'est mieux
+ que de lister les changements principaux dans README.Debian car
+ l'utilisateur peut facilement rater de telles notes.
+ </p>
+ <p>
+ Le format du fichier est le même que pour un fichier de changelog
+ Debian, mais il n'utilise pas d'astérisques et décrit chaque élément
+ de nouvelle dans un paragraphe complet si nécessaire plutôt que les
+ résumés concis qui iraient dans un changelog. C'est une bonne idée de
+ passer votre fichier par dpkg-parsechangelog pour vérifier son
+ formatage car il n'est pas vérifié automatiquement pendant la
+ construction comme le changelog. Voici un exemple d'un vrai fichier
+ NEWS.Debian :
+ <example>
+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
+</example>
+ </p>
+ <p>
+ Le fichier NEWS.Debian est installé comme
+ /usr/share/doc/<package>/NEWS.Debian.gz. Il est compressé et a
+ toujours ce nom même dans les paquets natifs Debian. Si vous utilisez
+ debhelper, dh_installchangelogs installera les fichiers debian/NEWS
+ pour vous.
+ </p>
+ <p>
+ À la différence des fichiers changelog, vous n'avez pas besoin de
+ mettre à jour les fichiers NEWS.Debian à chaque nouvelle version. Ne
+ les mettez à jour que si vous avez quelque chose de particulièrement
+ important que l'utilisateur a besoin de savoir. Si vous n'avez pas de
+ nouvelles du tout, il n'est pas nécessaire de fournir de fichier
+ NEWS.Debian dans votre paquet. Pas de nouvelles, bonne nouvelle !
+ </p>
+ </sect1>
+ </sect>
+ <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 en charge 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>
+ <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>
+ <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>
+ <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>
+ <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 préciser bash 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>
+ <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>
+ <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 d'une 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 paramètre. 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>
+ <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.
+ </p>
+ </sect>
+ <sect id="bpp-config-mgmt">
+ <heading>
+ Gestion de la configuration avec <package>debconf</package>
+ </heading>
+ <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.
+ </p>
+ <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="7" name="debconf-devel">. Vous devriez vraiment lire cette
+ page si vous décidez d'utiliser debconf. Nous documentons également
+ plusieurs des meilleures pratiques ici.
+ </p>
+ <p>
+ Ces lignes directives incluent plusieurs recommandations de style
+ d'écriture et de typographie, des considérations générales à propos de
+ l'utilisation de debconf ainsi que des recommandations plus spécifiques
+ pour certaines parties de la distribution (par exemple, le système
+ d'installation).
+ </p>
+ <sect1>
+ <heading>
+ N'abusez pas de debconf
+ </heading>
+ <p>
+ Depuis que debconf est apparu dans Debian, il a été largement abusé et
+ plusieurs critiques reçues par la distribution Debian proviennent
+ d'utilisation abusive de debconf avec la nécessité de répondre à un
+ grand nombre de questions avant d'avoir n'importe quel petit logiciel
+ d'installé.
+ </p>
+ <p>
+ Garder les notes d'utilisation à leur place : le fichier
+ NEWS.Debian ou le fichier README.Debian. N'utilisez des notes que pour
+ des notes importantes qui peuvent directement concerner l'utilisation
+ du paquet. Rappelez-vous que les notes bloqueront toujours
+ l'installation avant leur confirmation ou qu'elles embêtent
+ l'utilisateur par un courriel.
+ </p>
+ <p>
+ Choisissez avec soin les priorités des questions dans les scripts de
+ responsable. Reportez-vous à <manref section="7" name="debconf-devel">
+ pour plus de détails sur les priorités. La plupart des questions
+ devraient utiliser un priorité moyenne ou basse.
+ </p>
+ </sect1>
+ <sect1>
+ <heading>
+ Recommandations générales pour les auteurs et traducteurs
+ </heading>
+ <p>
+ </p>
+ <sect2>
+ <heading>
+ Écrivez un anglais correct
+ </heading>
+ <p>
+ La plupart des responsables de paquets Debian n'ont pas l'anglais
+ comme langue maternelle. Écrire des modèles correctement rédigés peut
+ donc ne pas être facile pour eux.
+ </p>
+ <p>
+ Veuillez utiliser (et abuser de) la liste de discussions
+ &email-debian-l10n-english;. Faites relire vos questionnaires.
+ </p>
+ <p>
+ Des questionnaires écrits incorrectement donnent une pauvre image de
+ votre paquet, de votre travail... ou même de Debian elle-même.
+ </p>
+ <p>
+ Évitez le jargon technique autant que possible. Si certains termes
+ vous semblent courants, ils peuvent être impossibles à expliquer à
+ d'autres personnes. Si vous ne pouvez pas les éviter, essayez de les
+ expliquer (en utilisant la description étendue). Quand vous faites
+ cela, essayez d'équilibrer la verbosité et la simplicité.
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ Être courtois avec les traducteurs
+ </heading>
+ <p>
+ Les questionnaires debconf peuvent être traduits. Debconf, avec son
+ paquet-frêre <package>po-debconf</package>, offre un cadre de travail
+ simple pour obtenir des questionnaires traduits par les équipes de
+ traduction ou même par des individus isolés.
+ </p>
+ <p>
+ Veuillez utiliser les questionnaires basés sur gettext. Installez
+ <package>po-debconf</package> sur votre système de développement et
+ lisez sa documentation (« man po-debconf » est un bon
+ début).
+ </p>
+ <p>
+ Évitez de changer vos questionnaires trop souvent. Modifier le texte
+ des questionnaires entraîne plus de travail pour les traducteurs dont
+ les traductions seront rendues « floues »
+ (« fuzzy »). Si vous prévoyez des modifications dans vos
+ questionnaires d'origine, veuillez contacter les traducteurs. La
+ plupart des traducteurs actifs sont très réactifs et obtenir leur
+ travail inclus avec vos questionnaires modifiés vous économisera des
+ envois supplémentaires. Si vous utilisez des modèles basés sur
+ gettext, le nom et l'adresse électronique du traducteur sont
+ mentionnés dans les en-têtes des fichiers PO.
+ </p>
+ <p>
+ L'utilisation de <prgn>podebconf-report-po</prgn> du paquet
+ <package>po-debconf</package> est hautement recommandée pour avertir
+ les traducteurs qui ont des traductions incomplètes et pour leur
+ demander des mises à jour.
+ </p>
+ <p>
+ En cas de doutes, vous pouvez également contacter l'équipe de
+ traduction pour une langue donnée
+ (debian-l10n-xxxxx@lists.debian.org) ou la liste de discussions
+ &email-debian-i18n;.
+ </p>
+ <p>
+ Les appels à traductions postés sur &email-debian-i18n; avec le
+ fichier <file>debian/po/templates.pot</file> attaché ou référencé
+ dans une URL sont encouragés. Assurez-vous de mentionner dans ces
+ appels pour de nouvelles traductions quelles sont les langues pour
+ lesquelles vous avez déjà des traductions existantes, pour éviter
+ toute duplication de travail.
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ « Dé-fuzzy-fiez » les traductions complètes lors des
+ corrections de typos et d'orthographe
+ </heading>
+ <p>
+ Quand le texte d'un questionnaire debconf est corrigé et que vous
+ êtes <strong>certain</strong> que les changements <strong>n'ont
+ aucun</strong> effet sur les traductions, soyez courtois avec les
+ traducteurs et dé-fuzzy-fiez leurs traductions.
+ </p>
+ <p>
+ Si vous ne le faites pas, le questionnaire entier ne sera pas traduit
+ jusqu'à ce qu'un traducteur vous envoie une mise à jour.
+ </p>
+ <p>
+ Pour <strong>dé-fuzzy-fier</strong> les traductions, vous pouvez
+ procéder ainsi :
+ <enumlist numeration="arabic">
+ <item>
+ <p>
+ enlevez tous les fichiers PO incomplets. Vous pouvez vérifier si
+ les fichiers sont complets en utilisant (il faut que le paquet
+ <package>gettext</package> soit installé) :
+ <example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
+--statistics $i; done</example>
+ </p>
+ </item>
+ <item>
+ <p>
+ déplacez tous les fichiers ayant des chaînes floues
+ (« fuzzy ») dans un emplacement temporaire. Les fichiers
+ n'ayant aucune chaîne floue (seulement des chaînes traduites et
+ non traduites) seront conservées où ils sont placés,
+ </p>
+ </item>
+ <item>
+ <p>
+ maintenant <strong>et seulement maintenant</strong>, corrigez les
+ typos dans le questionnaire et vérifiez que les traductions ne
+ sont pas impactées (les typos, les fautes d'orthographe et parfois
+ les corrections de typographie sont généralement acceptables),
+ </p>
+ </item>
+ <item>
+ <p>
+ exécutez <prgn>debconf-updatepo</prgn>. Cela va fuzzifier toutes
+ les chaînes que vous avez modifiées dans les traductions. Vous
+ pouvez constater cela en exécutant à nouveau la commande
+ ci-dessus,
+ </p>
+ </item>
+ <item>
+ <p>
+ utilisez la commande suivante :
+ <example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
+ </p>
+ </item>
+ <item>
+ <p>
+ déplacez dans debian/po les fichiers qui avaient des chaînes
+ floues dans la première étape,
+ </p>
+ </item>
+ <item>
+ <p>
+ exécutez à nouveau <prgn>debconf-updatepo</prgn>.
+ </p>
+ </item>
+ </enumlist>
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ Ne faites pas de suppositions à propos des interfaces
+ </heading>
+ <p>
+ Le texte des modèles ne doit pas faire référence aux composants
+ appartenant à l'une des interfaces debconf. Des phrases comme
+ « If you answer Yes... » n'a aucun sens pour les
+ utilisateurs d'interfaces graphiques qui utilisent des cases à cocher
+ pour les questions booléennes.
+ </p>
+ <p>
+ Les modèles de chaînes de caractères devraient éviter de mentionner
+ les valeurs par défaut dans leur description. Tout d'abord, parce que
+ cela est redondant avec les valeurs lues par les
+ utilisateurs. Ensuite, parce ces valeurs par défaut peuvent être
+ différentes selon les choix du responsable (par exemple, quand la
+ base de données debconf a été préremplie).
+ </p>
+ <p>
+ Plus généralement, essayez d'éviter de vous référer à toute action de
+ l'utilisation. Donnez simplement des faits.
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ N'utilisez pas la première personne
+ </heading>
+ <p>
+ Vous devriez éviter d'utiliser la première personne (« I will do
+ this... » ou « We recommend... »). L'ordinateur n'est
+ pas une personne et les questionnaires debconf ne parlent pas pour
+ les développeurs Debian. Vous devriez utiliser une construction
+ neutre et souvent une forme passive. Pour ceux d'entre vous qui
+ écrivent déjà des publications scientifiques, écrivez simplement vos
+ questionnaires comme vous écririez un papier scientifique.
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ Soyez neutre dans le genre
+ </heading>
+ <p>
+ Le monde est fait d'hommes et de femmes. Veuillez utiliser des
+ constructions neutres dans le genre dans votre texte. Ce n'est pas du
+ politiquement correct, c'est simplement montrer du respect pour toute
+ l'humanité.
+ </p>
+ </sect2>
+ </sect1>
+ <sect1>
+ <heading>
+ Définition des champs de questionnaires
+ </heading>
+ <p>
+ Cette partie donne plusieurs informations qui sont principalement
+ extraites de la page de manuel <manref section="7"
+ name="debconf-devel">.
+ </p>
+ <sect2>
+ <heading>
+ Type
+ </heading>
+ <p>
+ </p>
+ <sect3>
+ <heading>
+ string: (chaîne de caractères)
+ </heading>
+ <p>
+ Résulte en un champ d'entrée libre dans lequel l'utilisateur peut
+ écrire toute chaîne.
+ </p>
+ </sect3>
+ <sect3>
+ <heading>
+ password: (mot de passe)
+ </heading>
+ <p>
+ Demande un mot de passe à l'utilisateur. Veuillez utiliser ce champ
+ avec précaution ; soyez conscient que le mot de passe que
+ l'utilisateur entre sera écrit dans la base de données debconf. Vous
+ devriez probablement enlever cette valeur de la base de données dès
+ que possible.
+ </p>
+ </sect3>
+ <sect3>
+ <heading>
+ boolean: (booléen)
+ </heading>
+ <p>
+ Un choix vrai/faux. Rappelez-vous : vrai/faux, <strong>pas oui/non</strong>...
+ </p>
+ </sect3>
+ <sect3>
+ <heading>
+ select: (sélection)
+ </heading>
+ <p>
+ Un choix parmi un certain nombre de valeurs. Les choix doivent être
+ spécifiés dans un champ nommé « Choices ». Séparez les
+ valeurs possibles par des virgules et des espaces ainsi :
+ Choices: yes, no, maybe
+ </p>
+ </sect3>
+ <sect3>
+ <heading>
+ multiselect: (sélection multiple)
+ </heading>
+ <p>
+ Comme le type de données select, excepté que l'utilisateur peut
+ choisir un nombre quelconque d'éléments dans la liste de choix (ou
+ aucun d'entre eux).
+ </p>
+ </sect3>
+ <sect3>
+ <heading>
+ note: (note)
+ </heading>
+ <p>
+ Plutôt que d'être une question en tant que telle, ce type de donnée
+ indiqué une note qui peut être affichée à l'utilisateur. Il ne
+ devrait être utilisé que pour des données importantes que
+ l'utilisateur doit réellement voir, car debconf fera tout ce qu'il
+ peut pour s'assurer que l'utilisateur le voit ; il stoppera
+ l'installation en attendant que l'utilisateur appuie sur une touche
+ ou il leur enverra même la note par courrier dans certains cas.
+ </p>
+ </sect3>
+ <sect3>
+ <heading>
+ text: (texte)
+ </heading>
+ <p>
+ Ce type est maintenant considéré comme obsolète : ne l'utilisez
+ pas.
+ </p>
+ </sect3>
+ <sect3>
+ <heading>
+ error: (erreur)
+ </heading>
+ <p>
+ <strong>CE TYPE DE MODÈLE N'EST PAS ENCORE GÉRÉ PAR
+ DEBCONF.</strong>
+ </p>
+ <p>
+ Il a été ajouté à cdebconf, la version C de debconf, utilisé en
+ premier dans l'installateur Debian.
+ </p>
+ <p>
+ Veuillez ne pas l'utiliser à moins que debconf ne le prenne en
+ charge.
+ </p>
+ <p>
+ Ce type est conçu pour gérer des messages d'erreur. Il est presque
+ semblable au type « note ». Des interfaces peuvent le
+ présenter différemment (par exemple, l'interface dialog de cdebconf
+ affiche un écran rouge au lieu de l'écran bleu habituel).
+ </p>
+ </sect3>
+ </sect2>
+ <sect2>
+ <heading>
+ Description: description courte et étendue
+ </heading>
+ <p>
+ Les descriptions des modèles sont composées de deux parties :
+ une courte et une étendue. La description courte est dans la ligne
+ « Description: » du questionnaire.
+ </p>
+ <p>
+ La description courte devrait être gardée courte (50 caractères
+ ou moins) pour qu'elle puisse être ajustée par la plupart des
+ interfaces debconf. La garder courte aide également les traducteurs,
+ car les traductions ont tendance à être plus longues que l'original.
+ </p>
+ <p>
+ La description courte devrait se suffire à elle-même. Certaines
+ interfaces n'affichent pas la description longue par défaut ou
+ seulement si l'utilisateur la demande explicitement ou même ne
+ l'affichent pas du tout. Évitez des choses comme « What do you
+ want to do ? ».
+ </p>
+ <p>
+ Il n'est pas nécessaire que la description courte soit une phrase
+ complète. Cela fait partie de la recommandation « gardez-la
+ courte et efficace ».
+ </p>
+ <p>
+ La description étendue ne devrait pas répéter la description courte
+ mot pour mot. Si vous ne trouvez pas de description longue, commencez
+ par à y réfléchir plus. Envoyez un message sur debian-devel. Demandez
+ de l'aide. Suivez un cours d'écriture ! La description étendue
+ est importante. Si, après tout cela, vous ne trouvez toujours rien,
+ laissez-la vide.
+ </p>
+ <p>
+ La description étendue devrait utiliser des phrases complètes. Des
+ paragraphes devraient être gardés court pour améliorer la
+ lisibilité. Ne mélangez pas deux idées dans le même paragraphe, mais
+ utilisez plutôt un autre paragraphe.
+ </p>
+ <p>
+ Ne soyez pas trop verbeux. Les utilisateurs ont tendance à ignorer les
+ écrans trop longs. Par expérience, 20 lignes est la limite à
+ éviter de dépasser car cela veut dire sinon que, dans l'interface dialogue
+ classique, les utilisateurs devront faire défiler le texte et un grand
+ nombre de personnes ne le font simplement pas.
+ </p>
+ <p>
+ Pour des règles spécifiques selon le type de questionnaire (chaîne de
+ caractères, booléen, etc.), veuillez lire ci-dessous.
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ Choices (choix)
+ </heading>
+ <p>
+ Ce champ devrait utilisé pour des types Select et Multiselect. Il
+ contient les choix possibles qui seront présentés aux
+ utilisateurs. Ces choix devraient être séparés par des virgules.
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ Default (valeur par défaut)
+ </heading>
+ <p>
+ Ce champ est facultatif. Il contient la réponse par défaut pour les
+ modèles chaîne de caractères, sélection et multi-sélection. Pour des
+ questionnaires multi-sélection, il peut contenir une liste de choix
+ séparés par des virgules.
+ </p>
+ </sect2>
+ </sect1>
+ <sect1>
+ <heading>
+ Guide de style spécifique par champ de questionnaires
+ </heading>
+ <p>
+ </p>
+ <sect2>
+ <heading>
+ Champ Type
+ </heading>
+ <p>
+ Aucune indication spécifique excepté : utilisez le type
+ approprié en vous référant à la section précédente.
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ Champ Description
+ </heading>
+ <p>
+ Voici ci-dessous des instructions spécifiques pour écrire
+ correctement la description (courte et étendue) selon le type de
+ questionnaire.
+ </p>
+ <sect3>
+ <heading>
+ questionnaire chaîne de caractères/mot de passe
+ </heading>
+ <p>
+ <list>
+ <item>
+ <p>
+ La description courte est une invite et <strong>non</strong> un
+ titre. Évitez des invites de style question (« IP
+ Address? ») en faveur d'invites « ouvertes »à
+ (« IP address: »). L'utilisation des deux-points est
+ recommandée.
+ </p>