+ <sect2 id="details">
+ <heading>Détails</heading>
+ <p>
+Si vous êtes intéressé par les détails, voici comment fonctionne britney :
+ <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, 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>
+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>unstable</em> n'est pas moins
+ininstallable après la mise à jour qu'avant celle-ci. (Avant et après cette
+partie, certains coups de pouce 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>
+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>
+Les coups de pouce sont visibles sur <url
+id="http://ftp-master.debian.org/testing/hints/">.
+
+
+ <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>
+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>
+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>
+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>
+Veuillez vous assurer que vous n'oubliez aucun des éléments suivants lors de
+votre envoi :
+<list>
+<item> vérifiez que votre paquet doit vraiment aller dans
+<em>testing-proposed-updates</em> et ne peut pas passer par
+<em>unstable</em> ;
+<item> vérifiez que vous n'incluez que le minimum de changements ;
+<item> vérifiez que vous incluez une explication appropriée dans le
+changelog ;
+<item> vérifiez que vous avez bien indiqué <em>testing</em> ou
+<em>testing-proposed-updates</em> comme votre distribution cible ;
+<item> vérifiez que vous avez construit et testé votre paquet dans
+<em>testing</em> et non dans <em>unstable</em> ;
+<item> 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> ;
+<item> après l'envoi et la construction réussie sur toutes les plates-formes,
+contactez l'équipe de diffusion à &email-debian-release; et demandez-leur
+d'approuver votre envoi.
+</list>
+
+
+ <sect1 id="faq">
+ <heading>Questions fréquemment posées</heading>
+ <p>
+
+ <sect2 id="rc">
+ <heading>Qu'est-ce que 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>
+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>
+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 condisé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>
+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.
+
+ <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>
+
+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>
+Évidemment, cela touche principalement des paquets qui fournissent des jeux
+changeants de paquets binaires dans différentes version (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>
+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>
+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.
+ </sect>
+
+
+ <chapt id="best-pkging-practices">
+ <heading>Les meilleurs pratiques pour la construction des paquets
+<p>
+La qualité de Debian est principalement due à la <url id="&url-debian-policy;"
+name="charte Debian"> qui définit explicitement les obligations que tous les
+paquets doivent suivre. Mais c'est également grâce à une histoire partagée
+d'expériences qui va au-delà de la charte Debian, une accumulation d'années
+d'expérience pour la construction des paquets ; des développeurs de grand
+talent ont créé de bons outils qui vous aideront, vous, responsable Debian, à
+créer et maintenir d'excellents paquets.
+
+<p>
+Ce chapitre fournit les meilleurs pratiques pour les développeurs Debian. Ce ne
+sont que des recommandations, non pas des obligations ou des règles. Ce sont
+seulement des astuces et conseils subjectifs et des liens collectés pour les
+développeurs Debian. Prenez et choisissez ce qui vous convient le mieux.
+
+ <sect id="bpp-debian-rules">
+ <heading>Les meilleures pratiques pour le fichier <file>debian/rules</file></heading>
+ <p>
+Les recommandations suivantes s'appliquent au fichier <file>debian/rules</file>.
+Comme ce fichier contrôle le processus de compilation et qu'il sélectionne les
+fichiers inclus dans le paquet (directement ou indirectement), il s'agit
+habituellement du fichier sur lequel les responsables passent le plus de temps.
+
+
+ <sect1 id="helper-scripts">Scripts d'aide
+<p>
+La raison sous-jacente à l'utilisation des scripts d'aide dans le fichier
+<file>debian/rules</file> est que cela permet aux responsables d'utiliser et de
+partager une logique commune pour un grand nombre de paquets. Prenez, par
+exemple, l'installation des entrées de menu : vous avez besoin de
+placer un fichier dans <file>/usr/lib/menu</file> et d'ajouter des commandes aux
+scripts de maintenance pour enregistrer et désenregistrer ces entrées de menu.
+Comme il s'agit d'une chose très commune, pourquoi chaque
+responsable devrait-il écrire sa propre version, parfois avec des bogues ?
+Supposons également que le répertoire de menu soit modifié, chaque paquet
+devrait être modifié.
+<p>
+Les scripts d'aide peuvent résoudre ces problèmes. En supposant que vous vous
+conformiez aux conventions attendues par le script d'aide, celui-ci prend soin
+de tous les détails. Les changements dans la charte peuvent alors être faits
+dans le script d'aide ; les paquets ont alors simplement besoin d'être
+reconstruits avec la nouvelle version du script et sans aucun changement
+supplémentaire.
+<p>
+L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus
+courant et le meilleur (à notre avis) système est <package>debhelper</package>.
+Les précédents systèmes d'aide comme <package>debmake</package> étaient
+« monolithiques » : vous ne pouviez pas choisir quelles parties
+intéressantes vous pouviez utiliser, mais vous étiez obligé de choisir le
+système pour tout faire. <package>debhelper</package>, à l'inverse, consiste en
+un certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple,
+<prgn>dh_installman</prgn> installe et 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>
+Vous pouvez débuter avec <package>debhelper</package> en lisant <manref
+name="debhelper" section="1"> et en regardant les exemples fournis avec le
+paquet. <prgn>dh_make</prgn> du paquet <package>dh-make</package> (voir <ref
+id="dh-make">) peut être utilisé pour convertir un paquet source
+« vierge » en une version utilisant <package>debhelper</package>. Ce
+raccourci ne devrait cependant pas vous faire croire que vous n'avez pas besoin
+de comprendre les scripts individuels <prgn>dh_*</prgn>. Si vous comptez
+utiliser un système d'aide, vous devez prendre le temps d'apprendre à utiliser
+ce système pour savoir ce que vous pouvez en attendre ainsi que son
+comportement.
+<p>
+Plusieurs personnes pensent que des fichiers <file>debian/rules</file> vierges
+sont préférables car vous n'avez pas à apprendre les détails internes d'un
+quelconque système d'aide. La décision vous appartient complètement. Utilisez ce
+qui vous convient. Plusieurs exemples de fichiers <file>debian/rules</file> sont
+disponibles à <url id="&url-rules-files;">.
+
+ <sect1 id="multiple-patches">
+ <heading>Séparer vos correctifs en plusieurs fichiers</heading>
+<p>
+Les gros paquets peuvent avoir plusieurs bogues que vous devez gérer. Si
+ vous corrigez sans faire attention les bogues dans les sources, vous ne
+ pourrez pas différencier facilement les nombreux correctifs que vous aurez
+ appliqués. Cela peut devenir très compliqué de mettre à jour le paquet avec
+ une nouvelle version amont qui intègre certains correctifs (mais pas tous).
+ Vous ne pouvez pas prendre l'ensemble des correctifs (par exemple, dans les
+ fichiers <file>.diff.gz</file>) et décider quels correctifs il vous faut
+ enlever parce que les bogues ont été corrigés en amont.
+<p>
+Malheureusement, le système de création des paquets tel qu'il est actuellement
+ne fournit pas de moyen de séparer les correctifs en plusieurs fichiers.
+Cependant, il existe des moyens de séparer les correctifs : les fichiers
+correctifs sont livrés dans le fichier correctif Debian
+(<file>.diff.gz</file>), habituellement dans le répertoire <file>debian/</file>.
+La seule différence est qu'ils ne sont pas appliqués immédiatement par
+dpkg-source, mais par la règle <tt>build</tt> du fichier
+<file>debian/rules</file>. Inversement, ils sont annulés par la règle
+<tt>clean</tt>.
+<p>
+<prgn>dbs</prgn> est l'une des approches les plus populaires pour cela. Il fait
+ce qui est décrit ci-dessus et fournit la possibilité de créer de nouveaux
+correctifs et de mettre à jour d'anciens correctifs. Veuillez vous reporter au
+paquet <package>dbs</package> pour plus d'informations et au paquet
+<package>hello-dbs</package> pour un exemple.
+<p>
+<prgn>dpatch</prgn> fournit également ces fonctions, mais il est prévu pour être
+encore plus facile d'utilisation. Veuillez voir le paquet
+<package>dpatch</package> pour la documentation et des exemples (dans
+<file>/usr/share/doc/dpatch</file>).
+<p>
+
+ <sect1 id="multiple-binary">Paquets binaires multiples
+<p>
+Un simple paquet source va souvent permettre de construire plusieurs paquets
+ binaires différents, que ce soit pour fournir plusieurs saveurs du même
+ paquet (par exemple, le paquet source <package>vim</package>) ou pour créer
+ plusieurs petits paquets au lieu d'un seul gros (par exemple, si
+ l'utilisateur peut n'installer que la partie nécessaire et ainsi
+ économiser de l'espace disque).
+<p>
+Le second cas peut facilement être géré dans le fichier
+ <file>debian/rules</file>. Vous avez simplement besoin de déplacer les fichiers
+ appropriés du répertoire de construction dans les arborescence temporaires du
+ paquet. Vous pouvez le faire en utilisant <prgn>install</prgn>
+ ou <prgn>dh_install</prgn> du paquet <package>debhelper</package>.
+ Assurez-vous de vérifier les différentes permutations de paquets, en
+ garantissant que vous avez bien défini les dépendances entre les paquets dans
+ le fichier <file>debian/control</file>.
+<p>
+Le premier cas est un peu plus 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.
+
+<!-- &FIXME; Find a good debhelper example with multiple configure/make cycles
+ -->
+</sect1>
+
+
+ <sect id="bpp-debian-control">
+ <heading>Les meilleures pratiques pour le fichier
+ <file>debian/control</file></heading>
+ <p>
+Les pratiques suivantes sont relatives au fichier <file>debian/control</file>.
+Elles viennent en complément des <url
+id="&url-debian-policy;ch-binary.html#s-descriptions" name="règles pour
+les descriptions des paquets">.
+<p>
+La description du paquet, telle qu'elle est définie par le champ correspondant
+dans le fichier <file>control</file>, contient à la fois le résumé du paquet et
+la description longue pour le paquet. <ref id="bpp-desc-basics"> décrit des
+lignes générales pour les deux parties de la description. Ensuite, <ref
+id="bpp-pkg-synopsis"> fournit des principes spécifiques pour le résumé et <ref
+id="bpp-pkg-desc"> contient des principes spécifiques pour la description
+longue.
+
+ <sect1 id="bpp-desc-basics">
+ <heading>Les règles générales pour les descriptions des paquets</heading>
+<p>
+La description du paquet devrait être écrite pour l'utilisateur moyen,
+l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple, les paquets
+de développement sont pour les développeurs et leur description peut utiliser un
+langage technique. Pour les applications à but plus général comme un éditeur, la
+description devrait être écrite pour un non-spécialiste.
+<p>
+Notre critique des descriptions des paquets nous amène à conclure que la plupart
+des descriptions des paquets sont techniques, c'est-à-dire, qu'elles ne sont pas
+écrites pour être comprises par les non-spécialistes. À moins que
+votre paquet ne soit que pour les techniciens, c'est un problème.
+<p>
+Comment écrire pour les non-spécialistes ? Évitez le jargon.
+Évitez de vous référer à d'autres applications et cadres de travail avec
+lesquels l'utilisateur n'est pas forcément familier — « GNOME »
+ou « KDE » sont corrects car les utilisateurs sont probablement
+familiers avec ces termes, mais « GTK+ » ne l'est probablement pas.
+Ne supposez aucune connaissance. Si vous devez utiliser des termes techniques,
+introduisez-les.
+<p>
+Soyez objectif. Les descriptions de paquet ne sont pas un endroit pour
+promouvoir votre paquet, quel que soit l'amour que vous lui portez.
+Rappelez-vous que le lecteur n'a pas forcément les mêmes priorités que vous.
+<p>
+Des références aux noms de tout autre paquet de logiciels, noms de protocoles,
+standards ou spécifications devraient utiliser leurs formes canoniques si elles
+existent. Par exemple, utilisez « X Window System », « X11 »
+ou « X » et non « X Windows », « X-Windows » ou
+« X Window ». Utilisez « GTK+ » et non « GTK » ou
+« gtk ». Utilisez « GNOME » et non « Gnome ».
+Utilisez « PostScript » et non « Postscript » ou
+« postscript ».
+<p>
+Si vous avez des problèmes pour écrire votre description, vous pouvez l'envoyer à
+&email-debian-l10n-english; et demander un retour d'informations.
+
+ </sect1>
+
+<sect1 id="bpp-pkg-synopsis">
+ <heading>Le résumé du paquet ou description courte</heading>
+<p>
+La ligne de résumé (la description courte) devrait être concise. Elle ne doit
+pas répéter le nom du paquet (c'est une règle).
+<p>
+C'est une bonne idée de penser au résumé comme à une clause apposée et non une
+phrase complète. Une clause apposée est définie dans WordNet comme une relation
+grammaticale entre un mot et une phrase pronominale qui la suit, par exemple
+« Rudolph, le renne au nez rouge ». La clause apposée ici est
+« le renne au nez rouge ». Comme le résumé est une clause et non une
+phrase complète, nous recommandons de ne pas la commencer par une majuscule et
+de ne pas la finir par un point. Il ne doit pas non plus commencer avec un
+article, défini (« le ») ou indéfini (« un »).
+<p>
+Cela peut vous aider d'imaginer le résumé combiné avec le nom du paquet de
+la façon suivante :
+
+<example><var>nom-paquet</var> est un <var>résumé</var>.</example>
+
+Sinon, il peut être plus compréhensible de le voir comme
+
+<example><var>nom-paquet</var> est <var>résumé</var>.</example>
+
+ou, si le nom du paquet est lui-même un pluriel (comme
+« developer-tools »)
+
+<example><var>nom-paquet</var> sont <var>résumé</var>.</example>
+
+Cette façon de former une phrase à partir du nom du paquet et du résumé devrait
+être considérée comme une heuristique et non comme une règle stricte. Il y a
+certains cas où cela n'a aucun sens de former une phrase.
+
+ </sect1>
+
+ <sect1 id="bpp-pkg-desc">
+ <heading>La description longue</heading>
+<p>
+La description longue du paquet est la première information dont dispose
+l'utilisateur avant d'installer un paquet. Aussi, elle devrait fournir toutes
+les informations nécessaires pour le laisser décider de l'installation du
+paquet. Vous pouvez supposer que l'utilisateur a déjà lu le résumé du paquet.
+<p>
+La description longue devrait toujours être constituée de phrases complètes.
+<p>
+Le premier paragraphe de la description longue devrait répondre aux questions
+suivantes : qu'est-ce que fait le paquet ? Quelle tâche aide-t-il
+l'utilisateur à accomplir ? Il est important de décrire ceci d'une manière
+non technique, à moins que le paquet ne s'adresse qu'à un auditoire de techniciens.
+<p>
+Les paragraphes suivants devraient répondre aux questions suivantes :
+Pourquoi, en tant qu'utilisateur, ai-je besoin de ce paquet ? Quelles
+sont les autres fonctionnalités dont dispose le paquet ? Quelles
+sont les fonctionnalités marquantes et les déficiences de ce paquet comparé à
+d'autres paquets (par exemple, « si vous avez besoin de X, utilisez Y à la
+place ») ? Est-ce que le paquet est lié à d'autres paquets d'une
+certaine façon qui n'est pas gérée par le gestionnaire de paquet (par exemple,
+« il s'agit d'un client pour le serveur foo ») ?