+Avant de mettre à jour votre paquet vous ferez quelques tests de base. Vous
+devrez au moins faire les tests suivants (il vous faut une ancienne version
+du paquet) :
+ <list compact>
+ <item>
+ Installez le paquet et vérifiez que le logiciel fonctionne. Si le
+ paquet existait déjà dans une version plus ancienne, faites une mise à
+ jour.
+
+ <item>
+ Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
+ <prgn>lintian</prgn> comme suit : <tt>lintian -v
+ <var>package-version</var>.changes</tt>. Ce programme fera une
+ vérification sur les paquets source et binaire. Si vous ne comprenez
+ pas les messages générés par <prgn>lintian</prgn> essayez l'option
+ <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
+ bavard dans sa description du problème.
+ <p>
+ En principe, un paquet pour lequel
+ <prgn>lintian</prgn> génère des erreurs (elles commencent par
+ <tt>E</tt>) <em>ne doit pas</em> être installé dans l'archive.
+ <p>
+ Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la
+ section lintian <ref id="lintian">.
+
+ <item>
+ Faites régresser le paquet
+ vers sa version précédente si elle existe — cela permet de tester les
+ scripts <tt>postrm</tt> et <tt>prerm</tt>.
+
+ <item>
+ Désinstallez le paquet et réinstallez-le.
+
+ </list>
+
+
+
+ <sect>Générer le fichier « changes »
+<p>
+Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit
+être accompagnée d'un fichier <tt>.changes</tt>. Ce fichier explique à
+l'administrateur de l'archive Debian ce qu'il doit faire du paquet. Il est en
+général créé par <prgn>dpkg-genchanges</prgn> au cours du processus de
+fabrication du paquet.
+
+<p>
+Le fichier <tt>changes</tt> est un fichier de contrôle qui contient les champs
+suivants :
+
+<p>
+&control-file-fields;
+
+<p>
+Tous ces champs sont obligatoires pour une installation sur les serveurs
+Debian. Vous pouvez consulter la liste des champs de contrôle dans le
+<url id="&url-debian-policy;" name="Debian Policy Manual"> pour connaître
+les valeurs que prennent ces champs. Vous pouvez fermer un rapport de bogue
+automatiquement avec le champ <tt>Description</tt> (voir <ref
+id="upload-bugfix">).
+
+
+ <sect1>L'archive des sources amonts
+<p>
+La première fois qu'un paquet est installé dans l'archive pour une version
+amont donnée, le fichier <tt>tar</tt> de cette version amont doit être
+téléchargé et mentionné dans le fichier <tt>.changes</tt>. Par la suite, ce
+fichier <tt>tar</tt> sera utilisé pour générer les fichiers <tt>diff</tt> et
+<tt>.dsc</tt> et il ne sera pas nécessaire de le télécharger à nouveau.
+
+<p>
+Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn>
+incluront le fichier <tt>tar</tt> amont si et seulement si le numéro de
+révision du paquet source est 0 ou 1, ce qui indique une nouvelle version
+amont. Ce comportement peut être modifié en utilisant <tt>-sa</tt> pour
+l'inclure systématiquement ou <tt>-sd</tt> pour ne jamais l'inclure.
+
+<p>
+Si la mise à jour ne contient pas le fichier <tt>tar</tt> des sources
+originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
+fichiers <tt>.dsc</tt> et <tt>diff</tt> de la mise à jour, utilisez un fichier
+<tt>tar</tt> identique à l'octet près à celui sur le serveur. Si pour une
+raison ou pour une autre il y a une différence, la nouvelle version de ce
+fichier doit à nouveau être incluse dans la mise à jour (en utilisant l'option
+<tt>-sa</tt> par exemple).
+
+
+
+
+ <sect1 id="upload-dist">Choisir une distribution
+
+<p>
+Le champ <tt>Distribution</tt>, qui provient de la première ligne du fichier
+<file>debian/changelog</file>, indique à quelle distribution le paquet est
+destiné.
+
+<p>
+Il y a trois valeurs possibles pour ce champ : <em>stable</em>,
+<em>unstable</em> et <em>experimental</em> . En temps
+normal, les paquets sont téléchargés dans <em>unstable</em>.
+
+<p>
+Vous devriez éviter de combiner <em>stable</em> avec d'autres cibles à cause
+des problèmes potentiels de dépendance de bibliothèque (pour votre paquet et
+pour les paquets fabriqués par le démon de compilation pour les autres
+architectures). Se reporter à <ref id="upload-stable"> pour savoir quand et
+comment faire une mise à jour de <em>stable</em>.
+
+<p>
+Notez bien que combiner <em>experimental</em> avec quelque distribution
+que ce soit n'a pas de sens.
+
+
+ <sect2 id="upload-stable">Mettre à jour un paquet de la distribution <em>stable</em>
+
+<p>
+Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
+sera dirigé vers le répertoire <tt>proposed-updates</tt> des archives Debian
+pour y être testé avant d'être effectivement inclus dans <em>stable</em>.
+
+<p>
+Une livraison pour la distribution <em>stable</em> requière des soins
+supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
+que dans les cas suivants :
+
+ <list>
+ <item>un problème de sécurité (un avis de sécurité
+ Debian<footnote>Debian security advisory.</footnote>),
+ <item>un probleme fonctionnel vraiment critique,
+ <item>un paquet devenu ininstallable,
+ <item>un paquet indisponible pour une architecture.
+ </list>
+
+<p>
+Il est fortement déconseillé de changer quoi que ce soit si ce n'est pas
+important car même une modification triviale peut causer un bogue plus
+tard. Livrer une nouvelle version amont d'un logiciel pour corriger un
+problème de sécurité est désapprouvé ; dans la plupart des cas la
+bonne solution consiste à prendre la rustine correspondante de la
+nouvelle version amont et à l'appliquer à l'ancienne (faire un
+portage (<em>backport</em>) de la rustine.
+
+<p>
+Les paquets livrés pour <em>stable</em> doivent être compilés avec la
+distribution <em>stable</em> pour que leurs dépendances se limitent aux
+bibliothèques (et autres paquets) disponibles dans <em>stable</em> ;
+un paquet livré pour la distribution <em>stable</em> qui dépend d'une
+bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté.
+Modifier les dépendances d'autres paquets (en manipulant le champ
+<tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
+ininstallables, est fortement déconseillé.
+
+<p>
+L'équipe responsable de la distribution<footnote><em>the Release
+team</em></footnote> (joignable à l'adresse &email-debian-release;) évaluera
+régulièrement le contenu de <em>proposed-updates</em> et décidera si votre
+paquet peut être inclus dans la distribution <em>stable</em>. Soyez précis
+(et, si nécéssaire, généreux) quand vous décrivez, dans le fichier changelog,
+vos changements pour une livraison vers <em>stable</em> sinon le paquet ne
+sera pas considéré.
+
+
+
+ <sect id="uploading">Mettre à jour un paquet
+
+
+ <sect1 id="upload-ftp-master">Installer un paquet sur
+ <tt>ftp-master</tt>
+
+<p>
+Pour installer un paquet vous avez besoin d'un compte sur
+<ftpsite>ftp-master</ftpsite>, ce que vous devez avoir en tant que
+développeur Debian. Si vous utilisez <prgn>scp</prgn> ou <prgn>rsync</prgn>
+pour télécharger vos paquets, placez-les dans
+<tt>&us-upload-dir;</tt>. Si vous utilisez un FTP anonyme,
+placez-les dans <ftppath>/pub/UploadQueue/</ftppath>. Attention, il est
+préférable de transférer le fichier <tt>changes</tt> en dernier. Dans le cas
+constraire, votre livraison pourrait être rejetée car l'outil de maintenance
+de l'archive pourrait lire le fichier <tt>changes</tt> et constater que les
+fichiers ne sont pas tous présents. Si vous ne voulez pas vous embêter avec
+l'ordre de transfert des fichiers, vous pouvez tout simplement copier vos
+fichiers dans un répertoire temporaire de <tt>ftp-master</tt> et les déplacer
+ensuite vers <tt>&us-upload-dir;</tt>.
+
+<p>
+<em>Note :</em> ne téléchargez pas de paquet contenant un logiciel
+protégé par des brevets américains sur <tt>ftp-master</tt>, de même n'y
+téléchargez pas de paquet cryptographique qui appartiendrait a
+<em>contrib</em> ou <em>non-free</em>. Quand vous ne pouvez télécharger sur
+<tt>ftp-master</tt>, vous ne pouvez pas non plus télécharger sur
+<tt>chiark</tt> ou <tt>erlangen</tt>. Les livraisons de ces logiciels doivent
+aller sur <tt>non-us</tt> (voir <ref id="upload-non-us">). Si vous ne savez
+pas si votre paquet est protégé par un brevet ou s'il est soumis aux lois de
+contrôle des exportations américaines posez la question sur la liste
+&email-debian-devel;.
+
+<p>
+Les paquets <package>dupload</package> ou <package>dput</package> pourront
+vous faciliter le travail lors du téléchargement. Ces programmes, bien
+pratique, sont configurés par défaut pour
+se connecter par FTP sur les serveurs <tt>ftp-master</tt>,
+<tt>chiark</tt> et <tt>erlangen</tt>. Ils peuvent aussi être configurés pour
+utiliser <prgn>ssh</prgn> ou <prgn>rsync</prgn>. Se reporter à <manref
+name="dupload" section="1">, <manref name="dupload" section="5"> et <manref
+name="dput" section="1"> pour en savoir plus.
+
+<p>
+Après avoir téléchargé votre paquet, vous pouvez vérifier ce qu'en fera le
+logiciel de maintenance de l'archive en exécutant <prgn>dinstall</prgn>
+sur votre fichier <file>.changes</file> :
+
+<example>dinstall -n foo.changes</example>
+
+
+
+
+
+ <sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
+ (pandora)
+
+<p>
+Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
+exportations américain ne doivent pas être installés sur <tt>ftp-master</tt>.
+Installez le paquet sur <ftpsite>non-us.debian.org</ftpsite> dans le
+répertoire <tt>&non-us-upload-dir;</tt> (<ref id="dupload"> et <ref
+id="dput">, avec les options adéquates, peuvent tous deux être utilisés pour
+cela). Par défaut, vous pouvez utiliser le même <em>login/mot de passe</em>
+que pour <tt>ftp-master</tt>. Si vous utilisez
+une connexion FTP anonyme pour le téléchargement, placez vos fichiers dans le
+répertoire <ftppath>/pub/UploadQueue/</ftppath>.
+
+<p>
+Tout comme sur <tt>ftp-master</tt>, vous pouvez vérifier votre téléchargement
+avec :
+
+<example>dinstall -n foo.changes</example>
+
+
+<p>
+Attention, les personnes résidant aux États-Unis et les citoyens américains
+sont soumis à des restrictions sur l'exportation des logiciels de
+cryptographie. Au moment où j'écris, les citoyens américains peuvent exporter
+quelques logiciels de cryptographie soumis à une obligation de déclaration
+auprès du département du commerce américain. Toutefois, cette restriction a
+été abandonnée pour des logiciels qui sont déjà disponible en dehors des
+États-Unis. En conséquence, tout logiciel de cryptographie de la section
+<em>main</em> de l'archive Debian qui ne dépend d'aucun paquet d'une
+autre section — il ne doit pas dépendre de <em>non-US/main</em> —
+peut être téléchargé sur ftp-master ou l'une de ses files d'attente décrites
+plus haut.
+
+
+<p>
+Le <em>Debian Policy Manual</em> n'empêche pas les résidents et citoyens
+américains de livrer des paquets sur <tt>non-US</tt> mais ils devront être
+vigilants en le faisant. Nous recommandons aux responsables concernés de
+prendre toutes les précautions nécessaires, <em>y compris la consultation d'un
+juriste</em>, pour s'assurer qu'ils n'enfreignent pas une loi américaine en
+livrant un paquet sur <tt>non-US</tt>.
+
+<p>
+Pour les paquets des sections <em>non-US/main</em> et <em>non-US/contrib</em>
+les responsables devraient au moins suivre la <url id="&url-u.s.-export;"
+name="procédure décrite par le gouvernement américain">. Les responsables de
+paquets <em>non-US/non-free</em> devront en plus consulter les <url
+id="&url-notification-of-export;" name="règles de déclaration d'exportation
+pour les logiciels commerciaux">.
+
+<p>
+Cette section a pour seul but d'informer, elle n'a pas valeur de conseil
+juridique. Une fois encore, nous recommandons aux résidents et citoyens
+américains de consulter un juriste avant de livrer un paquet sur
+<tt>non-US</tt>.
+
+
+ <sect1>Installer un paquet via <tt>chiark</tt>
+
+<p>
+Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs
+possibilités. L'une d'elles consiste à télécharger vos fichiers dans
+<tt>Incoming</tt> en passant par le serveur <tt>chiark</tt> en Europe. Pour
+les détails consultez <url id="&url-chiark-readme;">.
+
+<p>
+Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux
+lois de contrôle des exportations américaines sur <tt>chiark</tt>.
+Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>,
+les indications de la section <ref id="upload-ftp-master"> sont applicables ici
+aussi.
+
+<p>
+Le programme <prgn>dupload</prgn> est capable de télécharger sur
+<tt>chiark</tt> ; consultez la documentation de ce programme pour en savoir
+plus.
+
+
+
+ <sect1>Installer un paquet via <tt>erlangen</tt>
+
+<p>
+Vous pouvez aussi accéder à un serveur situé en Allemagne : il vous suffit
+d'ouvrir une connexion anonyme sur :
+
+<p>
+ <url id="&url-upload-erlangen;">.
+
+<p>
+Le téléchargement fait sur ce serveur doit être aussi complet que s'il
+était fait dans le répertoire <tt>Incoming</tt> sur <tt>ftp-master</tt> :
+il doit comporter le fichier <file>.changes</file> et tous les fichiers
+mentionnés dans ce dernier. Le serveur vérifie que le fichier
+<tt>.changes</tt> est bien signé avec la clé PGP d'un développeur Debian pour
+éviter que des faux paquets n'atteignent <tt>ftp-master</tt>. Vérifiez bien
+que le champ <tt>Maintainer</tt> du fichier <tt>.changes</tt> contient
+<em>votre</em> adresse électronique. De même que sur <tt>ftp-master</tt>,
+cette adresse est ensuite utilisée pour toutes les réponses.
+
+<p>
+Il n'est pas nécessaire de déplacer votre fichier dans un autre répertoire
+après le téléchargement, contrairement au serveur <tt>chiark</tt>. Vous
+devriez ensuite recevoir un courrier du serveur expliquant ce qu'il a fait de
+votre paquet. Normalement, il devrait avoir été déplacé vers
+<tt>ftp-master</tt> ;
+vous serez informé par le même biais si une erreur s'est produite au cours du
+processus.
+
+<p>
+Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux
+lois de contrôle des exportations américaines sur <tt>erlangen</tt>.
+Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>,
+les indications de la section <ref id="upload-ftp-master"> sont applicables ici
+aussi.
+
+<p>
+Le programme <prgn>dupload</prgn> est capable de télécharger sur
+<tt>erlangen</tt> ; consultez la documentation de ce programme pour en savoir
+plus.
+
+
+
+
+
+ <sect1>Les autres serveurs
+
+<p>
+Un autre serveur est disponible aux États-Unis ; c'est un bon point
+de repli quand il est difficile de joindre <tt>ftp-master</tt>. Livrez vos
+paquets à l'adresse <url id="&url-upload-samosa;"> comme vous le feriez sur
+<tt>erlangen</tt>.
+<p>
+Il existe aussi un serveur au Japon : téléchargez vos paquet par FTP
+anonyme sur <url id="&url-upload-jp;">.
+
+
+
+
+ <sect id="upload-announce">Annoncer une mise à jour
+
+<p>
+Quand un paquet est mis à jour, une annonce doit être envoyée sur l'une des
+listes « debian-changes ». Ceci est maintenant géré automatiquement
+par le logiciel de gestion de l'archive quand il est exécuté (en principe une
+fois par jour). Vous devez juste utiliser une version récente de
+<package>dpkg-dev</package> (>= 1.4.1.2). Le courrier généré par le
+logiciel de maintenance de l'archive contiendra le fichier <tt>.changes</tt>
+signé que vous avez livré avec votre paquet. Précédemment, cette charge
+revenait à <prgn>dupload</prgn> ; vérifiez que vous avez bien configuré
+<prgn>dupload</prgn> pour qu'il n'envoie pas ces annonces (cherchez
+<tt>dinstall_runs</tt> dans la documentation de <prgn>dupload</prgn>).
+
+<p>
+Si un paquet est mis à jour avec un champ <tt>Distribution:</tt> à
+<em>stable</em>, l'annonce est envoyée sur la liste :
+
+<p>
+<tt> &email-debian-changes;.</tt>
+
+<p>
+S'il est mis à jour avec un champ <tt>Distribution:</tt> à <em>unstable</em>
+ou <em>experimental</em>, l'annonce est envoyée sur la liste
+&email-debian-devel-changes;.
+
+<p>
+Le programme <prgn>dupload</prgn> est suffisamment intelligent pour déterminer
+où devra aller l'annonce et pour envoyer le courrier sur la bonne liste. Voir <ref
+id="dupload">.
+
+
+
+
+ <sect id="upload-notification">
+ <heading>Notification de l'installation d'un nouveau paquet</heading>
+
+<p>
+Les administrateurs de l'archive Debian sont responsables de l'installation
+des mises à jour. La plupart des mises à jour sont gérées
+quotidiennement par le logiciel de gestion de l'archive <prgn>katie</prgn>.
+Les mises à jour
+de paquets sur la distribution <em>unstable</em>, en particulier, sont
+installés ainsi. Dans les autres cas et notamment dans le cas d'un nouveau
+paquet, celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois
+entre le téléchargement d'un paquet vers un serveur et son installation
+effective. Soyez patients.
+
+<p>
+Dans tous les cas vous recevrez un accusé de réception par courrier
+électronique indiquant que votre paquet a été installé et quels rapports
+de bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous
+les rapports de bogues que vous vouliez clore sont bien dans cette liste.
+
+<p>
+L'accusé de réception indique aussi la section dans laquelle le paquet a
+été installé. S'il ne s'agit pas de votre choix, vous recevrez un second
+courrier qui vous informera de cette différence (voir plus loin).
+
+
+
+
+ <sect1 id="override-file">Le fichier <em>override</em>
+
+<p>
+Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
+<file>debian/control</file> n'indiquent ni où le paquet sera installé dans
+l'archive Debian ni sa priorité. Afin de conserver la
+cohérence de l'archive, ce sont les administrateurs qui contrôlent ces
+champs. Les valeurs du fichier <file>debian/control</file> sont juste des
+indications.
+
+<p>
+Les administrateurs de l'archive indiquent les sections et priorités des paquets
+dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le
+fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez
+informé par courrier électronique quand votre paquet sera installé dans
+l'archive. Vous pourrez corriger votre fichier <em>debian/control</em>
+avant votre prochain téléchargement ou alors vous aurez envie de modifier le
+fichier <em>override</em>.
+
+<p>
+Pour modifier la section dans laquelle un paquet est archivé, vous devez
+d'abord vérifier que fichier <file>debian/control</file> est correct. Ensuite,
+envoyez un courrier à &email-override; ou un rapport de bogue sur le pseudo
+paquet <package>ftp.debian.org</package> demandant la modification de la
+section ou de la priorité de votre paquet. Exposez bien les raisons qui vous
+amènent à demander ces changements.
+
+<p>
+Pour en savoir plus sur le fichier <em>override</em>, reportez-vous à <manref
+name="dpkg-scanpackages" section="8">, &file-bts-mailing; et &file-bts-info;.
+
+
+
+
+ <chapt id="nmu">Mise à jour indépendante
+
+<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>
+Ces mises à jour indépendantes font partie du travail normal des porteurs qui
+compilent les paquets pour d'autres architectures (voir <ref id="porting">).
+Nous faisons aussi des mises à jour indépendantes quand un développeur Debian
+corrige le paquet d'un autre développeur pour éliminer un trou de sécurité
+ou un bogue paralysant. Cela se produit plus particulièrement en période de
+gel de la distribution de développement ou quand le responsable officiel du
+paquet ne peut pas fournir une correction dans un délai raisonnable.
+
+<p>
+Ce chapitre contient des informations qui vous expliqueront quand et comment
+faire des mises à jour indépendantes. Une distinction fondamentale doit être
+faite entre les mises à jour indépendantes sources et les mises à jour
+indépendantes binaires. Elle est explicitée dans la section suivante.
+
+
+ <sect id="nmu-terms">Terminologie
+
+<p>
+Deux nouvelles expressions sont introduites dans cette section :
+« mise à jour indépendante source » et « mise à
+jour indépendante binaire ». Ces expressions ont une définition
+précie dans le monde Debian. 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>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">).</footnote>.
+
+<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, un fichier <em>diff</em>
+modifié ou, plus rarement, des nouveaux sources amonts.
+
+<p>
+Une mise à jour indépendante binaire est 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>
+Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
+par l'expression « mise à jour indépendante »
+(NMU<footnote>Non-maintainer upload</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. Dans ce chapitre, si nous utilisons « mise à jour
+indépendante » seul, il s'agit des deux types de livraisons.
+
+
+
+
+
+ <sect id="nmu-who">Qui peut faire une mise à jour indépendante ?
+
+<p>
+Seuls les responsables Debian officiels peuvent faire des mises à jour
+indépendantes. Un responsable officiel est une personne dont la clé est dans
+le porte-clés Debian. Toute personne est 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 rustines qui le méritent au
+système de suivi des bogues. Les responsables apprécient presque toujours les
+rustines et les rapports de bogue soignés.
+
+
+ <sect id="nmu-when">Quand faire une mise à jour indépendante source ?
+
+<p>
+Les recommandations pour déterminer quand faire une mise à jour indépendante
+source dépendent de la distribution visée (i.e. stable, instable ou
+experimentale). Les porteurs, ayant une activité particulière, obéissent à des règles
+légèrement différentes (voir <ref id="source-nmu-when-porter">).
+
+<p>
+Quand une faille de sécurité est détectée, un
+paquet corrigé doit être livré le plus tôt possible. Dans ce cas, un membre de
+l'équipe de sécurité Debian<footnote>Debian Security officer</footnote>
+entrera en contact
+avec le responsable du paquet pour s'assurer qu'un paquet corrigé sera livré dans
+un délai raisonnable (moins de 48 heures). Si le mainteneur ne peut
+fournir une mise à jour suffisamment vite ou s'il ne peut être joint à temps,
+l'équipe de sécurité pourra corriger le paquet (i.e. faire une mise à jour
+indépendante source).
+
+<p>
+Pendant le cycle de mise au point (<em>release cycle</em>, voir <ref
+id="sec-dists">), les livraisons qui
+corrigent les bogues de gravité <em>sérieuse</em> (i.e. <em>serious</em>) et
+supérieures sont encouragées et acceptées. Même pendant cette période, vous
+devrez tenter d'entrer en contact avec le responsable du paquet ; il pourrait
+bien être sur le point de livrer un paquet corrigé lui aussi. Comme pour
+n'importe quelle mise à jour indépendante source, les recommandations de la
+section <ref id="nmu-guidelines"> doivent être respectées.
+
+<p>
+Les mises à jour indépendantes sont aussi acceptable pour la distribution
+instable mais seulement en dernier ressort
+ou avec une autorisation. Essayez d'abord ce qui suit et si cela ne fonctionne
+pas il est probablement correct de faire une mise à jour indépendante
+<em>(NMU)</em> :
+
+<p>
+ <list compact>
+ <item>
+ Vérifiez que le bogue est bien référencé dans le système de suivi des
+ bogues. S'il n'y est pas, faites un rapport de bogue.
+
+ <item>
+ Envoyez un courrier au responsable du paquet et proposez votre aide
+ pour corriger le bogue. Donnez-lui quelques jours.
+
+ <item>
+ Lancez-vous. Corrigez le bogue et envoyez votre rustine au système de
+ suivi des bogues. Construisez le paquet et testez-le comme décrit dans
+ la section <ref id="upload-checking">. Utilisez le paquet chez vous.
+
+ <item>
+ Attendez une réponse pendant quelques semaines.
+
+ <item>
+ Envoyez un courrier au responsable lui demandant son accord pour faire
+ une mise à jour indépendante <em>(NMU)</em>.
+
+ <item>
+ Vérifiez une nouvelle fois que votre modification n'a pas d'effet de
+ bord inattendu et qu'elle est aussi minimaliste et peu intrusive que
+ possible.
+
+ <item>
+ Attendez une réponse une semaine encore.
+
+ <item>
+ Faites votre mise à jour indépendante comme décrit dans la section
+ <ref id="nmu-guidelines">.
+
+ </list>
+
+
+
+
+
+
+ <sect id="nmu-guidelines">Comment faire une mise à jour indépendante
+ source ?
+
+<p>
+Les règles qui suivent s'appliquent aux porteurs tant qu'ils jouent le double
+rôle de correcteur de bogue et de porteur. Si un porteur doit modifier le
+paquet source, cette mise à jour est automatiquement une mise à jour
+indépendante source et est soumise aux règles qui suivent. Si un porteur
+construit un paquet binaire recompilé, les règles sont différentes (voir <ref
+id="porter-guidelines">.
+
+<p>
+Tout d'abord il est capital que ces mises à jour indépendantes soient aussi peu
+intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
+modules ou des fichiers, ne déplacez pas les répertoires ; plus généralement ne
+corrigez pas ce qui n'est pas cassé. Faites une rustine aussi petite 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 faits lors d'une mise à jour indépendante.
+
+
+
+
+
+ <sect1 id="nmu-version">Numéro de version pour les mises à jour
+ indépendantes sources
+
+<p>
+Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
+changer, même pour la plus triviale des modifications. Notre système de
+gestion de paquets s'appuie sur ces numéros de version.
+
+<p>
+Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
+un numéro de version mineur à la partie <var>debian-revision</var> du numéro
+de version (la partie qui suit le dernier trait d'union). Ce numéro
+supplémentaire débutera à « 1 ». Prenons pour exemple le paquet
+« foo » qui porte le numéro de version 1.1-3. Dans l'archive, le
+fichier de contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
+version amont est « 1.1 » et la révision Debian est « 3 ».
+La mise à jour indépendante suivante ajouterait le numéro de version mineur
+« .1 » au numéro de révision Debian; le nouveau fichier de contrôle
+du paquet source serait alors <file>foo_1.1-3.1.dsc</file>.
+
+<p>
+Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro
+de version au responsable officiel du paquet, ce qui pourrait perturber son
+travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas
+été livré par le responsable officiel.
+
+<p>
+S'il n'y a pas de partie <var>debian-revision</var> dans le numéro de version
+du paquet, il faut en créer une en démarrant à « 0.1 ». S'il est
+absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
+fasse une livraison basée sur une nouvelle version amont, cette personne
+doit choisir « 0.1 » comme numéro de révision Debian. Le mainteneur
+du paquet doit, lui, démarrer sa numérotation à « 1 ». Notez que pour
+faire cela vous devrez utiliser <prgn>dpkg-buildpackage</prgn> avec l'option
+<tt>-sa</tt> pour le forcer à utiliser le nouveau paquet source (par défaut il
+reconnaît les numéros de révisions « 0 » ou « 1 » — il
+n'est pas suffisamment intelligent pour reconnaître « 0.1 »).
+
+<p>
+Attention, les porteurs qui ne font que recompiler les paquets pour d'autres
+architectures n'ont pas besoin de renuméroter les paquets. Les porteurs ne
+doivent utiliser de nouveaux numéros de version que s'ils modifient les
+paquets sources qu'ils recompilent, c'est-à-dire s'ils font une mise à jour
+indépendante source et non une mise à jour indépendante binaire.
+
+
+
+
+
+ <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 la mise à jour ainsi que la
+version livrée.
+
+<p>
+Par convention, dans le cas d'une mise à jour indépendante source
+<em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne
+
+<example>
+ * Non-maintainer upload
+</example>
+
+
+
+
+
+ <sect1 id="nmu-patch">Mise à jour indépendante source et système
+ de suivi des bogues
+
+<p>
+Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
+modifications que possible et doit toujours envoyer ses modifications au
+système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).
+
+<p>
+En cas de simple recompilation du paquet, le processus diffère
+suivant que vous agissez en tant que porteur ou pas. Si vous faites une mise
+à jour indépendante qui ne nécessite rien de plus qu'une recompilation et
+n'agissez pas en temps que porteur (i.e. une nouvelle bibliothèque partagée
+est disponible, un bogue a été corrigé dans <package>debhelper</package>),
+vous devez tout de même ajouter une entrée dans le fichier <em>changelog</em>;
+il y aura donc une modification. Si vous êtes porteur, vous êtes probablement
+en train de faire une mise à jour indépendante binaire. (Note : ce système ne
+tient pas compte des porteurs qui font des recompilations — tenez cela pour
+une faiblesse de notre système de gestion des paquets.)
+
+<p>
+Si la mise à jour indépendante source (<em>source NMU</em>) corrige des
+bogues, ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système
+de suivi des bogues plutôt que clos. Par convention, seul le responsable du
+paquet et la personne qui a ouvert le rapport de bogue peuvent clore ce
+rapport. Heureusement, le système d'archivage Debian reconnait 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 changelog). Ce passage au statut
+<em>fixed</em> assure que chacun sait que le bogue est corrigé par une mise
+à jour indépendante tout en laissant le rapport de bogue ouvert jusqu'à ce que
+le responsable du paquet incorpore les modifications de cette mise à jour dans
+la version officielle du paquet.
+
+<p>
+Après avoir fait une mise à jour indépendante, il vous faudra aussi ouvrir un
+nouveau rapport de bogue qui inclura une rustine contenant toutes les
+modifications que vous avez faites.
+Le responsable officiel pourra choisir d'appliquer la rustine, 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 rustines de la mise à jour
+indépendante, il devra s'assurer que cette nouvelle version corrige
+effectivement chacun des bogues corrigés dans la mise à jour indépendante.
+
+<p>
+De plus, le responsable officiel devrait <em>toujours</em> conserver les
+entrées documentant une mise à jour indépendante dans le fichier
+<file>changelog</file>.
+
+
+
+
+
+
+ <sect1 id="nmu-build">Fabriquer une mise à jour indépendante source
+
+<p>
+Les paquets faisant l'objet d'une mise à jour indépendante source sont
+construits comme les
+autres. Sélectionnez une distribution en utilisant les règles décrites dans
+la section <ref id="upload-dist"> et construisez un fichier <tt>.changes</tt>
+classique avec tout ce qui l'accompagne conformément à la description <ref
+id="uploading">.
+
+<p>
+En fait, toutes les prescriptions de la section <ref id="upload"> sont
+applicables ici, y compris l'obligation d'annoncer la mise à jour sur la liste
+idoine.
+
+<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 <tt>.changes</tt>.
+
+
+
+
+ <chapt id="porting">Le portage
+
+<p>
+Debian supporte un nombre croissant d'architectures. Même si vous n'êtes pas
+un porteur et même si vous n'utilisez qu'une architecture, il est de votre
+responsabilité de développeur d'être attentif aux questions de portabilité.
+C'est pourquoi il est important que vous lisiez ce chapitre même si vous
+n'êtes pas un porteur.
+
+<p>
+Porter un paquet consiste à faire un paquet binaire pour une architecture
+différente de celle du paquet binaire fait par le responsable du paquet.
+C'est une
+activité remarquable et essentielle. En fait, les porteurs sont à l'origine
+de la plupart des compilations de paquet Debian. Pour un paquet binaire
+<em>i386</em>, par exemple, il faut compter une recompilation pour chaque
+autre architecture, soit un total de &number-of-arches; recompilations.
+
+
+
+
+ <sect id="kind-to-porters">Être gentil avec les porteurs
+
+<p>
+Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un
+grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
+modification. Malheureusement, c'est rarement le cas. Cette section contient
+une liste d'erreurs commises régulièrement par les responsables Debian —
+problèmes courants qui bloquent souvent les porteurs et compliquent
+inutilement leur travail.
+
+<p>
+Ici, le mot d'ordre est de répondre rapidement aux rapports de bogues et
+remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
+étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine
+manière). Merci pour votre indulgence envers des rapports de bogues succincts ou
+peu clairs ; faites de votre mieux pour éliminer le problème.
+
+<p>
+Les problèmes les plus couramment rencontrés par les porteurs sont causés par
+des erreurs de mise en paquet dans le paquet source. Voici une
+<em>checklist</em> de choses auxquelles vous devez être attentif :
+
+ <enumlist>
+ <item>
+ Vérifiez que les champs <tt>Build-Depends</tt> et
+ <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
+ corrects. Le meilleur moyen pour vérifier cela est d'utiliser le
+ paquet <package>debootstrap</package> pour créer un environnement
+ <em>unstable</em> <em>chrooté</em>. Dans cet environnement
+ <em>chrooté</em> il faudra installer le paquet
+ <package>build-essential</package> et tous les paquets mentionnés dans
+ les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
+ Ensuite, vous essayerez de fabriquer votre paquet dans cette
+ environnement.
+ <p>
+ Consultez le <url id="&url-debian-policy;" name="Debian Policy
+ Manual"> pour en savoir plus sur les dépendances de fabrication.
+ <item>
+ Ne choisissez pas d'autre valeur que <em>all</em> ou <em>any</em> pour
+ le champ architecture sans avoir de bonnes raisons pour le faire. Trop
+ souvent, les développeurs ne respectent pas les instructions du
+ <url id="&url-debian-policy;" name="Debian Policy Manual">. Choisir
+ la valeur « i386 » est la plupart du temps incorrect.
+
+ <item>
+ Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
+ <var>package</var>.dsc</tt> pour vous assurer que le paquet se
+ désarchive correctement. En utilisant le résultat de ce test,
+ construisez votre paquet binaire à l'aide de la commande
+ <tt>dpkg-buildpackage</tt>.
+
+ <item>
+ 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>.
+
+ <item>
+ 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.
+
+ <item>
+ Ne vous appuyez pas sur une installation préexistante de votre paquet
+ (un sous-cas de la remarque précédente).
+
+ <item>
+ Si possible, ne vous appuyez pas sur une particularité présente dans
+ un compilateur précis ou dans 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.
+
+ <item>
+ Vérifiez que votre <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>.
+
+ </enumlist>
+
+
+
+
+ <sect id="porter-guidelines">Instructions pour les mises à jour des
+ porteurs
+
+<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 mise à
+jour indépendante 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>
+Pour une mise à jour indépendante binaire, ne faites pas de changement
+dans les sources. Vous n'avez pas besoin de modifier les fichiers du paquet
+source (cela inclut <file>debian/changelog</file>).
+
+<p>
+La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante :
+<tt>dpkg-buildpackage -B -e<var>adresse-porteur</var></tt>. Bien sûr,
+remplacez <var>adresse-porteur</var> par votre adresse électronique. Cette
+commande construira les portions du paquet qui dépendent de l'architecture, en
+utilisant la cible <em>binary-arch</em> de <file>debian/rules</file>.
+
+
+ <sect1 id="recompile-nmu-versioning">
+ <heading>Numéro de version des mises à jour indépendantes
+ binaires</heading>
+
+<p>
+Parfois il est nécessaire de recompiler des paquets quand d'autres paquets,
+tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez
+changer le numéro de version pour que le système de comparaison des numéros de
+version fonctionne correctement. 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>
+Ces recompilations nécessitent des numéros de version « magiques » pour que le
+système de maintenance de l'archive comprennent 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>
+Cette magie associée à une mise à jour par recompilation est déclenchée en
+utilisant un troisième nombre dans la partie debian du numéro de version. Si,
+par exemple, la dernière version du paquet que vous recompilez était
+« 2.9-3 », votre mise à jour portera le numéro
+« 2.9-3.0.1 ». Si cette version était « 3.4-2.1 » votre
+mise à jour portera le numéro « 3.4-2.1.1 ».
+
+
+
+
+ <sect1 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.
+
+<!--
+FIXME: commented out until I can work out how to upload to testing directly
+
+Une correction
+cruciale (i.e. rendre un paquet compilable sur une architecture supportée par
+la prochaine distribution) peut être installée <em>sans</em> délai pour la
+distribution gelée.
+-->
+
+<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).
+
+<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>
+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>
+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.
+
+
+
+
+ <sect>Outils pour les porteurs
+
+<p>
+Il y a plusieurs outils pour le travail de portage. Cette section contient
+une courte description de ces outils ; reportez-vous à la documentation de
+leurs paquets ou aux références citées ci-après pour une description complète.
+
+
+
+
+ <sect1 id="quinn-diff">
+ <heading><package>quinn-diff</package>
+
+<p>
+<package>quinn-diff</package> est utilisé pour localiser les différences d'une
+architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de
+l'architecture <var>X</var> doivent être portés sur l'architecture <var>Y</var>.
+
+
+
+
+
+ <sect1 id="buildd">
+ <heading><package>buildd</package>
+
+<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>
+<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. Il regroupe un ensemble de composants très utiles,
+continuellement utilisés mais non encore mis en paquet, tels que
+<prgn>andrea</prgn>, <prgn>sbuild</prgn> et <prgn>wanna-build</prgn>.
+
+<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> Nous sommes très
+enthousiasmés par 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 la Debian — qui peuvent être ou ne pas être
+intéressantes pour tous (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.
+
+
+
+
+ <sect1 id="dpkg-cross">
+ <heading><package>dpkg-cross</package>
+
+<p>
+<package>dpkg-cross</package> est un outil qui installe les bibliothèques et
+les entêtes nécessaires à une compilation croisée<footnote><em>cross-compilation</em>
+</footnote> d'une manière similaire à <package>dpkg</package>. De plus
+<prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
+améliorés pour supporter les compilations croisées.
+
+
+
+
+
+ <chapt id="archive-manip">
+ <heading>Déplacer, effacer, renommer, adopter et abandonner des
+ paquets</heading>
+
+<p>
+Certaines manipulations de l'archive ne sont pas accessibles avec le processus
+de mise à jour automatisé. Elles sont appliquées manuellement par les
+développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.
+
+
+
+
+ <sect>Déplacer des paquets
+
+<p>
+Parfois un paquet pourra changer de section. Une nouvelle version d'un paquet
+de la section <tt>non-free</tt> pourrait par exemple être distribuée sous
+licence LGP GNU ; dans ce cas le paquet doit être déplacé dans la section
+<tt>main</tt> ou <tt>contrib</tt><footnote> Reportez-vous au <url
+id="&url-debian-policy;" name="Debian Policy Manual"> pour savoir dans quelle
+section un paquet doit être classé.</footnote>.
+
+<p>
+Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez
+les informations de contrôle du paquet pour le placer dans la section désirée
+et téléchargez à nouveau votre paquet dans l'archive. Reportez-vous au
+<url id="&url-debian-policy;" name="Debian Policy Manual"> pour en savoir
+plus. Lisez attentivement le rapport d'installation qui vous sera envoyé lors
+de l'archivage de votre paquet. Si pour une raison ou une autre le paquet
+est toujours à son ancien emplacement, envoyez un rapport de bogue sur le
+pseudo-paquet <tt>ftp.debian.org</tt> demandant la suppression dudit paquet.
+Décrivez précisément vos manipulations car il pourrait s'agir d'un bogue dans
+le logiciel de gestion de l'archive.
+
+<p>
+Si vous avez besoin de modifier la sous-section de l'un de vos paquets
+(<tt>devel</tt> ou <tt>admin</tt> par exemple) la procédure est légèrement
+différente. Modifiez la sous-section dans le fichier de contrôle de votre
+paquet et téléchargez-le. Il vous faudra ensuite demander la modification du
+fichier <em>override</em> comme décrit dans la section <ref
+id="override-file">.
+
+
+
+
+ <sect id="removing-pkgs">Supprimer des paquets
+
+<p>
+Si pour une raison ou une autre vous avez besoin de supprimer un paquet
+de l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile,
+que l'on conservait pour des raisons de compatibilité), il vous faudra
+envoyer un rapport de bogue concernant le pseudo-paquet
+<tt>ftp.debian.org</tt> et demandant sa suppression. N'oubliez pas de
+préciser de quelle distribution le paquet doit être supprimé.
+
+<p>
+Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
+autres développeurs sur la liste &email-debian-devel;. Le programme
+<prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
+utile. La commande <tt>apt-cache showpkg <var>package</var> </tt> vous
+indiquera, entre autres, les paquets qui dépendent de <var>package </var>.
+
+ <sect1>Supprimer des paquets dans <tt>Incoming</tt>
+<p>
+Par le passé, il était possible de supprimer un paquet de <tt>Incomming</tt>.
+Ce n'est plus possible depuis la mise en place du nouveau système
+de file d'attente. Il vous faudra télécharger une nouvelle version de votre
+paquet avec un numéro de version postérieur à celui que vous voulez remplacer.
+Les deux versions seront installées dans l'archive mais seule la plus récente
+sera accessible dans <em>unstable</em> car la précédente sera immédiatement
+replacée par la nouvelle. Toutefois, si vous testez correctement vos paquets,
+le besoin d'en remplacer un ne devrait pas être trop fréquent.
+
+
+
+ <sect>Remplacer ou renommer un paquet
+
+<p>
+Il peut vous arriver de vous tromper en nommant un paquet et avoir besoin de le
+renommer. Dans ce cas, vous devrez intervenir en deux étapes. D'abord,
+modifiez votre fichier <file>debian/control</file> pour que votre paquet
+renommé remplace et entre en conflit avec le nom de paquet que vous voulez
+remplacer. Reportez-vous au <url id="&url-debian-policy;" name="Debian Policy
+Manual"> pour les détails. Une fois que votre paquet est installé dans
+l'archive, faites un rapport de bogue concernant le pseudo-paquet
+<tt>ftp.debian.org</tt> et demandant la suppression du paquet mal nommé.
+l'archive, faites un rapport de bogue concernant le pseudo-paquet
+<tt>ftp.debian.org</tt> et demandant la suppression du paquet mal nommé.
+
+
+
+
+
+ <sect id="orphaning">Abandonner un paquet
+
+<p>
+Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres
+et faire le nécessaire pour qu'il soit marqué <em>abandonné</em>(i.e.
+<em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
+Group &orphan-address;</tt> dans le champ
+<tt>maintainer</tt> du paquet et faire un rapport de bogue sur le
+pseudo-paquet <tt>wnpp</tt>. Le titre de votre rapport de bogue devra être
+« <tt>O<footnote><em>Orphaned</em> : abandonné.</footnote>:
+<var>paquet</var> — <var>courte description</var></tt> » pour indiquer
+que le paquet est orphelin. La gravité du bogue sera <em>normale</em>.
+Si vous le jugez nécessaire, envoyez une copie à
+&email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
+l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le
+sujet du message ne contiendra pas le numéro du bogue.
+
+<p>
+Si le paquet est particulièrement important pour la distribution il vous
+faudra faire un rapport de bogue sur le pseudo-paquet <tt>wnpp</tt>, titrer
+« <tt>RFA<footnote><em>Request For Adoption</em> : offre
+d'adoption.</footnote>: <var>paquet</var> — <var>courte
+description</var></tt> » et lui affecter la gravité <em>importante</em>.
+Envoyez une copie de votre rapport de bogue à la liste debian-devel comme
+décrit précédemment.
+
+<p>
+Reportez-vous à la page WNPP<footnote><em>Work-needing and prospective
+packages</em> : paquets en souffrance et paquets souhaités.</footnote> <url
+id="&url-wnpp;"> pour en savoir plus.
+
+
+
+
+
+ <sect id="adopting">Adopter un paquet
+
+<p>
+Une liste des paquets en attente de nouveau responsable est disponible à la
+page <url id="&url-wnpp;" name="Work-Needing and Prospective Packages">. Si
+vous voulez prendre en charge un paquet de cette liste reportez-vous à la page
+susmentionnée pour connaître la procédure à suivre.
+
+<p>
+Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
+correct — ce serait une prise d'otage. Vous pouvez prendre contact avec le
+responsable actuel et lui demander si vous pouvez prendre en charge ce paquet.
+Vous ne pouvez le faire sans son accord. Qu'il vous ignore n'est pas une
+raison suffisante pour le faire. Si vous avez le sentiment qu'un responsable
+est parti sans prévenir depuis un moment, demandez-le sur la liste
+&email-debian-private;.
+
+<p>
+Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de
+suivi des bogues indique que vous êtes le responsable du paquet. Cela se
+produira automatiquement une fois que vous aurez installé une nouvelle version
+du paquet dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut
+prendre quelques heures après le téléchargement. Si vous pensez ne pas avoir
+de mise à jour à faire pour un moment, envoyez un courrier électronique à
+&email-override; pour pouvoir recevoir les rapports de bogue.
+
+
+
+
+
+ <chapt id="bug-handling">Gérer les bogues
+
+
+
+ <sect>Superviser les rapports de bogues
+
+<p>
+Si vous voulez être un bon responsable, consultez régulièrement la
+page du <url id="&url-bts;" name="système de suivi des bogues">. Cette page
+contient tous les rapports de bogue qui concernent vos paquets.
+
+<p>
+Les responsables interagissent avec le système de suivi des bogues en
+utilisant l'adresse électronique <tt>bugs.debian.org</tt>. Vous trouverez une
+documentation sur les commandes disponibles à l'adresse <url id="&url-bts;">
+ou, si vous avez installé le paquet <package>doc-debian</package>, dans les
+fichiers locaux &file-bts-docs;.
+
+<p>
+Certains trouvent utile de recevoir régulièrement une synthèse des rapports de
+bogues ouverts. Si vous voulez recevoir une synthèse hebdomadaire relevant
+tous les rapports de bogue ouverts pour vos paquets, vous pouvez configurer
+<prgn>cron</prgn> comme suit :
+
+<p>
+<example>
+# Synthèse hebdomadaire des rapports de bogue qui me concernent
+&cron-bug-report;
+</example>
+
+<p>
+Remplacez <var>address</var> par votre adresse officielle de responsable
+Debian.
+
+
+
+
+ <sect id="submit-bug">Ouvrir un rapport de bogue
+
+<p>
+En tant que responsable Debian, vous trouvez des bogues dans d'autres paquets
+En tant que responsable Debian, vous trouvez des bogues dans d'autres paquets,
+ou bien vous voulez réassigner à d'autres paquets des rapports de bogue
+concernant vos paquets. La page d'aide du <url id="&url-bts-control;"
+name="système de suivi des bogues"> vous explique comment procéder.
+
+<p>
+Nous vous encourageons à ouvrir des rapports de bogue s'il y a des problèmes.
+Essayez de soumettre ces rapports depuis un compte utilisateur où vous pouvez
+recevoir du courrier. Ne les envoyez pas en tant que <em>root</em>.
+
+<p>
+Vérifiez que le bogue n'a pas encore été déclaré. Essayez de faire un travail
+propre en déclarant le bogue et en l'envoyant à la bonne adresse.
+
+<p>
+Pour faire encore mieux, vous pouvez consulter d'autres paquets, grouper les
+bogues qui ont été rapportés plusieurs fois ou affecter la gravité
+<em>corrigé</em> (i.e. <em>fixed</em>) à un rapport dont le bogue a été
+corrigé. Attention, quand vous n'êtes ni le rapporteur d'un bogue ni le
+responsable du paquet vous ne devez pas clore le rapport (à moins que vous
+n'ayez l'autorisation du responsable).
+
+
+
+
+ <sect>Répondre à des rapports de bogues
+
+<p>
+Assurez-vous que toutes vos discussions concernant les bogues sont envoyées au
+rapporteur du bogue et au bogue lui-même (<email>123@bugs.debian.org</email>
+par exemple).
+
+<p>
+Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la
+commande <em>close</em> à l'adresse :
+
+<p>
+<tt> &email-bts-control;</tt>
+
+<p>
+Si vous le faites, le rapporteur n'aura aucun retour sur la clôture de son
+rapport.
+
+
+
+
+ <sect id="upload-bugfix">Quand les rapports sont fermés par une
+ mise à jour
+
+<p>
+Si vous corrigez un bogue dans vos paquets, il est de votre responsabilité de
+fermer le rapport de bogue associé. Pourtant vous ne devez pas le fermer avant
+que le paquet n'ait été accepté dans l'archive Debian. C'est pourquoi, vous
+pouvez et vous devez clore le rapport dans le système de suivi des bogues une
+fois que vous avez reçu l'avis indiquant que votre nouveau paquet a été
+installé dans l'archive.
+
+<p>
+Si vous utilisez une version récente de <package>dpkg-dev</package> et que
+vous remplissez convenablement le fichier <file>changelog</file>, le logiciel de
+maintenance de l'archive fermera les rapports de bogue automatiquement. Tout ce
+que vous avez à faire est de respecter la syntaxe suivante dans votre fichier
+<file>debian/changelog</file> :
+<example>
+acme-cannon (3.1415) unstable; urgency=low
+
+ * Frobbed with options (closes: Bug#98339)
+ * Added safety to prevent operator dismemberment, closes: bug#98765,
+ bug#98713, #98714.
+ * Added manpage. Closes: #98725.
+</example>
+
+Techniquement parlant, l'expression régulière suivante est utilisée :
+<example>
+ /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
+</example>
+
+L'auteur préfère la syntaxe <tt>(closes: Bug#<var>XXX</var>)</tt>, car elle
+est facilement repérable dans le fichier <file>changelog</file>.
+
+<p>
+Si vous voulez fermer un rapport de bogue manuellement — à l'ancienne — il
+suffit d'envoyer le fichier <tt>.changes</tt> à l'adresse
+<email>XXX-done@bugs.debian.org</email> où <var>XXX</var> est le numéro du
+bogue.
+
+
+
+
+ <sect id="lintian-reports">Les rapports Lintian
+
+<p>
+Vous devriez récupérer la dernière version de <package>lintian</package>
+depuis <em>unstable</em> régulièrement et vérifier tous vos paquets. Vous
+pouvez aussi chercher votre adresse électronique dans la page de <url
+id="&url-lintian;" name="rapport lintian">. Cette page, mise à jour
+automatiquement, contient les rapports lintian concernant la
+dernière version de la distribution (en général <em>unstable</em>) générés
+avec la dernière version de <package>lintian</package>.
+
+
+
+
+
+ <sect>Ouvrir un grand nombre de rapports d'un seul coup
+
+<p>
+Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
+paquet — plus de dix — est une pratique que nous déconseillons. Prenez
+toutes les mesures possibles pour éviter cette situation. Si le problème peut
+être détecté automatiquement par exemple, ajoutez un nouveau test dans le
+paquet <package>lintian</package> pour générer une erreur ou un avertissement.
+
+<p>
+Si vous ouvrez plus de dix rapports sur le même sujet, il est préférable
+d'indiquer votre intention sur la liste &email-debian-devel;. Cela donnera à
+d'autres développeurs la possibilité de vérifier que le problème existe
+vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent
+les mêmes rapports de bogue simultanément.
+
+<p>
+Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez
+les envoyer à <email>maintonly@bugs.debian.org</email> pour qu'ils ne soient
+pas redirigés vers les listes de diffusions.
+
+
+
+
+
+
+
+ <chapt id="tools">Aperçu des outils du responsable Debian
+
+<p>
+Cette section contient un aperçu rapide des outils dont dispose le
+responsable. Cette liste n'est ni complète ni définitive, il s'agit juste
+d'un guide des outils les plus utilisés.
+
+<p>
+Les outils du responsable Debian sont destinés à améliorer le confort des
+responsables et libérer leur temps des tâches plus cruciales. Comme le dit
+Larry Wall, il y a plus d'une manière de le faire.
+
+<p>
+Certaines personnes préfèrent utiliser des outils de haut niveau, d'autres pas.
+Debian n'a pas de position officielle sur la
+question ; tout outil conviendra du moment qu'il fait le boulot. C'est pourquoi
+cette section n'a pas été conçue pour indiquer à chacun
+quel outil il devrait utiliser ou comment il devrait faire pour gérer sa
+charge de responsable Debian. Elle n'est pas non plus destinée à
+favoriser l'usage d'un outil aux dépens d'un autre.
+
+<p>
+La plupart des descriptions de ces outils proviennent des descriptions de
+leurs paquets. Vous trouverez plus d'information dans les
+documentations de ces paquets.
+Vous pouvez aussi obtenir plus d'information avec la commande <tt>apt-cache
+show <var>package_name</var></tt>.
+
+
+
+ <sect id="dpkg-dev">
+ <heading><package>dpkg-dev</package>
+
+<p>
+Le paquet <package>dpkg-dev</package> contient les outils (y compris
+<prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des
+paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas
+niveau indispensables pour créer et manipuler les paquets ; en tant que tels,
+ils sont indispensables à tout responsable Debian.
+
+
+
+
+ <sect id="lintian">
+ <heading><package>lintian</package>
+
+<p>
+<package>lintian</package> dissèque les paquets pour y repérer des bogues et
+des manquements aux règles de développement. Il contient des tests automatisés pour
+vérifier de nombreuses règles et quelques erreurs courantes. L'utilisation de
+<package>lintian</package> a déjà été discutée dans <ref id="upload-checking">
+et <ref id="lintian-reports">.
+
+ <sect id="debconf">
+ <heading><package>debconf</package></heading>
+
+<p>
+Le paquet <package>debconf</package> fournit une interface consistante pour
+configurer les paquets interactivement. Il est indépendant de l'interface et
+permet une configuration en mode texte, par une interface HTML ou par boîtes
+de dialogues. D'autres types d'interface peuvent être ajoutés sous forme
+de modules.
+
+<p>
+Vous trouverez la documentation de ce paquet dans le paquet
+<package>debconf-doc</package>.
+
+<p>
+Beaucoup pensent que ce système devrait être utilisé pour tout paquet
+nécessitant une configuration interactive. <package>debconf</package> n'est
+pas requis par le <em>Debian Policy Manual</em> pour le moment ; cela
+pourra changer dans le futur.
+
+
+ <sect id="debhelper">
+ <heading><package>debhelper</package>
+
+<p>
+Le paquet <package>debhelper</package> regroupe un ensemble de programmes qui
+peuvent être utilisés dans <file>debian/rules</file> pour automatiser les
+tâches courantes relatives à la fabrication des paquets Debian binaires. Ce
+paquet contient des utilitaires pour installer différents fichiers, les
+compresser, ajuster leurs droits et intégrer votre paquet dans le
+système de menu Debian.
+
+<p>
+Au contraire d'autres approches, <package>debhelper</package> est
+divisé en plusieurs petits utilitaires qui agissent de manière cohérente.
+Ce découpage permet un contrôle des opérations plus fin que
+d'autres outils « <em>debian/rules</em> ».
+
+<p>
+Il existe aussi un certain nombre de petites extensions
+<package>debhelper</package> trop éphémères pour être documentées. Vous en
+listerez la plupart en faisant <tt>apt-cache search ^dh-</tt>.
+
+
+
+ <sect id="debmake">
+ <heading><package>debmake</package>
+
+<p>
+<package>debmake</package> — un précurseur de <package>debhelper</package> —
+est un assistant moins modulaire pour manipuler le fichier
+<file>debian/rules</file>. Il inclut deux programmes principaux :
+<prgn>deb-make</prgn>, utile au développeur Debian pour convertir un paquet
+source normal (non-Debian) en paquet source Debian, et <prgn>debstd</prgn> qui
+regroupe le type de fonction que l'on trouve dans
+<package>debhelper</package>.
+
+<p>
+Le consensus actuel est que l'usage de <package>debmake</package> est
+déconseillé au profit de <package>debhelper</package> mais ce n'est pas une
+erreur d'utiliser <package>debmake</package>.
+
+
+
+ <sect id="yada">
+ <heading><package>yada</package>
+
+<p>
+Le paquet <package>yada</package> est un autre assistant pour la création de
+paquets. Il utilise un fichier <file>debian/packages</file> pour générer
+<file>debian/rules</file> et d'autres fichiers nécessaires dans
+le sous-répertoire <file>debian/</file>.
+
+<p>
+Remarque : <package>yada</package> est qualifié de « quasiment non
+maintenu » par son responsable, Charles Briscoe-Smith. Son usage est donc
+déconseillé.
+
+
+
+ <sect id="equivs">
+ <heading><package>equivs</package>
+
+<p>
+<package>equivs</package> est un autre paquet pour faire des paquets. Il est
+souvent conseillé pour un usage local, si vous avez besoin de faire un paquet
+pour satisfaire des dépendances. Il est aussi parfois utilisé pour faire des
+« méta-paquets » qui sont des paquets dont l'unique objet est de
+dépendre d'autres paquets.
+
+
+
+ <sect id="cvs-buildpackage">
+ <heading><package>cvs-buildpackage</package>
+
+<p>
+Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou
+récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer
+un paquet Debian depuis le référentiel CVS et il assiste le développeur lors
+de l'intégration de modifications amont dans le référentiel.
+
+<p>
+Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS
+pour le responsable. Il permet de conserver des branches CVS distinctes
+pour les distributions <em>stable</em>, <em>unstable</em> et probablement
+<em>experimental</em>.
+
+
+ <sect id="dupload">
+ <heading><package>dupload</package>
+
+<p>
+Le paquet <package>dupload</package> contient un script du même nom pour
+mettre à jour des paquets dans l'archive Debian, tracer ces mises à jour et
+les annoncer par courrier électronique automatiquement. Vous pouvez le
+configurer pour faire des mises à jour à d'autres endroits et avec d'autres
+méthodes.
+
+
+ <sect id="dput">
+ <heading><package>dput</package>
+<p>
+Le script <package>dput</package> fait à peu près la même chose que
+<package>dupload</package> mais il le fait différemment. Il a aussi quelques
+fonctions supplémentaires telles que la possibilité de vérifier la signature
+GnuPG et les sommes de contrôles avant le téléchargement et la possibilité de
+démarrer <tt>dinstall</tt> en mode simulation (<em>dry-run</em>) après le
+téléchargement.
+
+ <sect id="fakeroot">
+ <heading><package>fakeroot</package>
+
+<p>
+<package>fakeroot</package> simule les privilèges <em>root</em>. Cela permet
+de fabriquer un paquet sans être root (en général les paquets installent des
+fichiers appartenant à <em>root</em>). Si vous avez installé
+<package>fakeroot</package> vous pouvez construire un paquet en étant
+utilisateur : <tt>dpkg-buildpackage -rfakeroot</tt>.
+
+
+ <sect id="debootstrap">
+ <heading><package>debootstrap</package>
+
+<p>
+Le paquet <package>debootstrap</package> vous permet d'amorcer un système
+Debian de base à n'importe quel endroit dans votre système de fichier. Par
+« système de base » nous entendons le strict minimum nécéssaire pour
+fonctionner et installer le reste du système.
+
+<p>
+Avoir un système comme celui-ci peut vous servir de différentes manières. Vous
+pouvez par exemple déplacer votre racine dans ce système avec
+<prgn>chroot</prgn> pour tester vos dépendances de fabrication. Vous pouvez
+aussi l'utiliser pour voir comment se comporte votre paquet quand il est
+installé dans un environnement minimum.
+
+
+ <sect id="devscripts">
+ <heading><package>devscripts</package>
+
+<p>
+Le paquet <package>devscripts</package> contient quelques scripts et outils
+que vous trouverez peut-être utiles pour maintenir vos paquets Debian. Parmi
+ces scripts, vous trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui
+manipulent votre fichier
+<file>debian/changelog</file> depuis la ligne de commande et
+<prgn>debuild</prgn> qui est construit au-dessus de
+<prgn>dpkg-buildpackage</prgn>.
+
+
+
+ <sect id="dpkg-dev-el">
+ <heading><package>dpkg-dev-el</package>
+
+<p>
+<package>dpkg-dev-el</package> fournit des macros Emacs lisp qui apportent une
+aide lors de l'édition des fichiers du répertoire <file>debian</file> de votre
+paquet. À l'édition de <file>debian/changelog</file>, par exemple, vous
+disposez de fonctions pour finaliser une version et consulter la liste des
+rapports de bogue ouverts.
+
+
+ <sect id="debget">
+ <heading><package>debget</package>
+
+<p>
+Le paquet <package>debget</package> contient un script qui peut être utile
+pour télécharger des paquets depuis l'archive Debian. Vous pouvez par exemple
+l'utiliser pour télécharger des paquets sources (bien que <tt>apt-get source
+<var>package</var></tt> fasse à peu près la même chose).
+
+
+
+<!-- FIXME: add the following
+ dpkg-awk
+ alien
+ dpkg-repack
+ grep-dctrl
+ pbuilder -->
+
+
+
+