[developers-reference.git] / developers-reference.fr.sgml

<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
  <!-- include version information so we don't have to hard code it
       within the document -->
  <!entity % versiondata SYSTEM "version.ent"> %versiondata;
  <!-- common, language independant entities -->
  <!entity % commondata  SYSTEM "common.ent" > %commondata;

  <!-- CVS revision of this document -->
  <!entity cvs-rev "$Revision: 1.35 $">
  <!-- if you are translating this document, please notate the CVS
       revision of the developers reference here -->
  <!--
    <!entity cvs-en-rev "1.197">
    -->

  <!--  -->
  <!entity FIXME "<em>FIXME:</em>&nbsp;">

]>
<debiandoc>

  <book>
      <title>Référence du développeur Debian

      <author>L'équipe de la Référence du développeur &email-devel-ref;
      <author>Adam Di Carlo, éditeur
      <author>Raphaël Hertzog
      <author>Christian Schwarz
      <author>Ian Jackson
      <author>&nbsp;
      <translator>version française par Antoine Hulin
      <translator>et Frédéric Bothamy (traducteur actuel)
      <translator>et les membres de la liste <email>debian-l10n-french@lists.debian.org</email>
      <version>Version &version;, &date-fr; (version française 20030418).</version>

      <copyright>
        <copyrightsummary>Copyright &copy; 1998&mdash;2003 Adam Di Carlo</copyrightsummary>
        <copyrightsummary>Copyright &copy; 2002 Raphaël Hertzog</copyrightsummary>
        <copyrightsummary>Copyright &copy; 1997, 1998 Christian Schwarz.</copyrightsummary>
<p>
Ce manuel est un logiciel libre&nbsp;; il peut être redistribué et/ou modifié
selon les termes de la licence publique générale du projet GNU (GNU GPL), telle
que publiée par la «&nbsp;Free Software Foundation&nbsp;» (version 2 ou toute
version postérieure).

<p>
Il est distribué dans l'espoir qu'il sera utile, mais <em>sans aucune
garantie</em>, sans même la garantie implicite d'une possible valeur marchande
ou d'une adéquation à un besoin particulier. Consultez la licence publique
générale du projet GNU pour plus de détails.

<p>Une copie de la licence publique générale du projet GNU est disponible dans
le fichier &file-GPL; de la distribution &debian-formal; ou sur la toile&nbsp;:
<url id="&url-gpl" name="la licence publique générale du projet GNU">. Vous
pouvez également l'obtenir en écrivant à la &fsf-addr;.

    <toc detail="sect1">

    <chapt id="scope">Portée de ce document

<p>
Le but de ce document est de donner une vue d'ensemble des procédures à suivre
et des ressources mises à la disposition des développeurs Debian.

<!-- FIXME: rewrites -->
<p>
Les procédures décrites ci-après expliquent comment devenir responsable Debian
(<ref id="new-maintainer">), comment créer de nouveaux paquets (<ref
id="newpackage">) et comment les installer dans l'archive (<ref id="upload">),
comment gérer les rapports de bogues (<ref id="bug-handling">), comment
déplacer, effacer ou abandonner un paquet (<ref id="archive-manip">), comment
faire le portage d'un paquet (<ref id="porting">), quand et comment faire la
mise à jour du paquet d'un autre responsable (<ref id="nmu">).

<p>
Les ressources présentées dans ce manuel incluent les listes de diffusion (<ref
id="mailing-lists">) et les serveurs (<ref id="server-machines">), une
présentation de la structure de l'archive Debian (<ref id="archive">), des
explications sur les serveurs qui acceptent les mises à jour de paquets (<ref
id="upload-ftp-master">) et une présentation des outils qui peuvent aider un
responsable à améliorer la qualité de ses paquets (<ref id="tools">).

<p>
Ce manuel de référence ne présente pas les aspects techniques liés aux paquets
Debian, ni comment les créer. Il ne décrit pas non plus les règles que doivent
respecter les paquets Debian. Cette information est disponible dans la <url
id="&url-debian-policy;" name="charte Debian">.

<p>
De plus ce document <em>n'est pas l'expression d'une politique officielle</em>.
Il contient de la documentation sur le système Debian et des conseils pratiques
largement suivis. C'est une sorte de guide pratique.

        <sect>Introduction à la version française

        <sect1>Avertissement

<p>
Bien que ce document soit en français, l'activité de responsable Debian implique
une maîtrise de la langue anglaise. Le projet Debian est un projet international
auquel participent des japonais, néo-zélandais, américains, allemands,
finlandais, français, espagnols, danois, etc.

<p>
En conséquence, la langue utilisée dans toutes les listes de diffusion destinées
aux développeurs (à l'exception de la liste
<email>debian-devel-french@&lists-host;</email>) est l'anglais et les rapports
de bogue doivent être rédigés en anglais. En fait, sauf exception rare, tout
dialogue avec les autres responsables Debian se fera en anglais quel que soit le
média.


        <sect1>Glossaire

<p>
Cette section liste les termes techniques qui ont un sens spécifique dans le
projet Debian. Pour chacune de ces expressions, vous trouverez la traduction
française utilisée dans ce manuel, une définition et une référence à la section
du manuel qui traite de ce sujet.


<list>
        <item><em>Upload</em>&nbsp;: mise à jour, téléchargement (parfois
        livraison). Opération qui consiste à télécharger un nouveau paquet ou
        une nouvelle version de paquet dans l'archive Debian (<ref
        id="upload">).

        <item><em>Non-maintainer upload (NMU)</em>&nbsp;: mise à jour
        indépendante. Téléchargement d'une nouvelle version de paquet dans
        l'archive Debian par une personne qui n'est pas officiellement
        responsable de ce paquet (<ref id="nmu">).

        <item><em>Source NMU</em>&nbsp;: mise à jour indépendante source. Il
        s'agit d'une mise à jour indépendante pour un paquet source (<ref
        id="nmu-terms">).

        <item><em>Binary NMU</em>&nbsp;: mise à jour indépendante binaire. Mise
        à jour indépendante pour un paquet binaire (<ref id="nmu-terms">).

        <item><em>Bug Tracking System (BTS)</em>&nbsp;: système de suivi des
        bogues. Il s'agit du système utilisé par le projet Debian pour suivre
        les bogues et leur correction (<ref id="bug-handling">).

        <item><em>Bug submitter</em>&nbsp;: rapporteur du bogue. Personne qui
        envoie un rapport de bogue au système de suivi des bogues (<ref
        id="submit-bug">).

        <item><em>Release critical bug</em>&nbsp;: bogue empêchant l'intégration
        du paquet dans la distribution. Bogues de gravité <em>critique</em>,
        <em>grave</em> et <em>sérieuse</em>. Ces bogues ne doivent pas
        apparaître dans une distribution <em>stable</em>. Ils doivent être
        corrigés ou bien les paquets en cause doivent être supprimés (<ref
        id="rc-bugs">).

        <item><em>Package Tracking System (PTS)</em>&nbsp;: système de suivi des
        paquets. Il s'agit du système utilisé par le projet Debian pour suivre
        les paquets sources des différentes distributions (<ref
        id="pkg-tracking-system">).

        <item><em>Unstable</em>&nbsp;: nom de la distribution en cours de
        développement. Cette distribution contient les paquets envoyés par les
        développeurs. Ceux-ci étant humains, elle est parfois cassée (<ref
        id="sec-dists">).

        <item><em>Testing</em>&nbsp;: nom de la distribution en test. Cette
        distribution reçoit les paquets des développeurs qui ont passé une
        période de deux semaines dans <em>unstable</em> et pour lesquels aucun
        bogue remettant en cause la distribution (cf. <em>Release critical
        bug</em>) n'a été découvert. Cette distribution n'a pas été testée en
        profondeur. Elle est cependant censée être plus stable
        qu'<em>unstable</em> (<ref id="sec-dists">).

        <item><em>Stable</em>&nbsp;: Nom de la distribution stable. Cette
        distribution a été testée, validée et diffusée (<ref id="sec-dists">).

        <item><em>Debian maintainer</em>&nbsp;: responsable Debian, développeur
        Debian (parfois mainteneur). Personne qui fait officiellement partie du
        projet Debian. Elle a accès aux serveurs Debian et participe au
        développement &mdash;&nbsp;au sens large&nbsp;&mdash; de la distribution (<ref
        id="developer-duties">). La plupart des responsables font de la mise en
        paquet, mais il existe d'autres activités telles que la documentation,
        la gestion du site web, la création des cédéroms, l'administration des
        serveurs, etc.

        <item><em>Upstream version</em>&nbsp;: version amont. Il s'agit du
        logiciel tel qu'il est fourni par le responsable amont &mdash; par
        opposition à la version fournie par la distribution Debian. (Voir <ref
        id="upstream-coordination">.)

        <item><em>Upstream maintainer</em>&nbsp;: responsable amont ou
        développeur amont. Personne responsable du développement ou de la
        maintenance d'un logiciel. En général, le responsable amont n'a rien à
        voir avec le projet Debian (<ref id="upstream-coordination">).

        <item><em>Debian keyring</em>&nbsp;: porte-clés Debian. Le porte-clés
        Debian contient les clés publiques de tous les responsables Debian (<ref
        id="key-maint">).

        <item><em>Work-needing and prospective packages (WNPP)</em>&nbsp;:
        paquets en souffrance et paquets souhaités. La liste des paquets en
        souffrance indique les paquets qui n'ont plus de responsable. La liste
        des paquets souhaités indique les logiciels que des utilisateurs
        aimeraient bien voir dans la distribution (<ref id="upload">).

        </list>


    <chapt id="new-maintainer">Devenir responsable Debian
        
      <sect id="getting-started">Pour commencer
<p>
Vous avez lu toute la documentation, vous avez examiné le <url
 id="&url-newmaint-guide;" name="guide du nouveau responsable">, vous comprenez
 l'intérêt de tout ce qui se trouve dans le paquet d'exemple
 <package>hello</package> et vous vous apprêtez à mettre en paquet votre
 logiciel préféré. Comment devenir responsable Debian et intégrer votre travail
 au projet&nbsp;?
<p>
Si vous ne l'avez pas encore fait, commencez par vous inscrire à la
 liste &email-debian-devel;. Pour cela, envoyez un courrier à l'adresse
 &email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne
 <em>Objet</em><footnote><p><em>Subject</em> en anglais</footnote> de votre
 message. En cas de problème, contactez l'administrateur de la liste
 &email-listmaster;. Vous trouverez plus d'informations dans la section <ref
 id="mailing-lists">. &email-debian-devel-announce; est une autre liste
 incontournable pour qui veut suivre les développements de Debian.
<p>
Vous suivrez les discussions de cette liste (sans poster) pendant quelque temps
 avant de coder quoi que ce soit et vous informerez la liste de votre intention
 de travailler sur quelque chose pour éviter de dupliquer le travail d'un autre.
<p>
Une autre liste intéressante est &email-debian-mentors;. Voir la section <ref
 id="mentors"> pour les détails. Le canal IRC <tt>#debian</tt> pourra aussi être
 utile.

<p>
Quand vous avez choisi la manière dont vous contribuerez au projet
 &debian-formal;, prenez contact avec les responsables Debian qui travaillent
 sur des tâches similaires. Ainsi vous pourrez apprendre auprès de personnes
 expérimentées. Si, par exemple, vous voulez mettre en paquet des logiciels
 existants, trouvez-vous un parrain. Un parrain est une personne qui travaillera
 sur vos paquets avec vous et les téléchargera dans l'archive Debian une fois
 qu'il sera satisfait de votre mise en paquet. Pour trouver un parrain, envoyez
 une demande de parrainage à la liste &email-debian-mentors; en vous présentant
 et en décrivant votre paquet (voir <ref id="sponsoring"> pour en savoir plus
 sur le sujet). Si vous préférez porter Debian sur une architecture ou un noyau
 alternatif, abonnez-vous aux listes dédiées au portage et demandez-y comment
 démarrer. Finalement, si vous êtes intéressé par la documentation ou
 l'assurance qualité (QA), vous pouvez contacter les responsables qui
 travaillent déjà sur ces tâches et proposer des correctifs et des
 améliorations.
 

      <sect id="registering">S'enregistrer comme responsable Debian
<p>
Avant de décider de devenir responsable Debian, il vous faudra lire toute la
 documentation disponible dans le <url id="&url-newmaint;" name="coin du nouveau
 responsable">. Elle décrit toutes les étapes préparatoires qu'il vous faudra
 franchir avant de déposer votre candidature.

Par exemple, avant d'être candidat, il vous faudra lire le <url
 id="&url-social-contract;" name="contrat social Debian">. Devenir responsable
 Debian implique que vous adhériez à ce contrat social et que vous vous engagiez
 à le soutenir&nbsp;; il est très important que les responsables soient en
 accord avec les principes fondamentaux qui animent le projet &debian-formal;.
 Lire le <url id="&url-gnu-manifesto;" name="Manifeste GNU"> est aussi une bonne
 idée.
<p>
Le processus d'enregistrement a pour but de vérifier votre identité, vos
 intentions et vos compétences. Le nombre de personnes travaillant pour
 &debian-formal; a atteint &number-of-maintainers; et notre système est utilisé
 dans plusieurs endroits très importants&nbsp;: nous devons rester vigilants
 pour éviter un acte malveillant. C'est pourquoi nous contrôlons les nouveaux
 responsables avant de leur donner un compte sur nos serveurs et de les autoriser à
 ajouter des paquets dans l'archive.
<p>
Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail
 et que vous serez un bon contributeur. Pour cela, vous pourrez proposer des correctifs
 par le système de suivi des bogues (BTS) ou maintenir un paquet parrainé
 pendant un temps. Nous attendons aussi des contributeurs qu'ils soient
 intéressés par le projet dans son ensemble et pas uniquement par leurs propres
 paquets. Si vous pouvez aider d'autres responsables en fournissant des
 informations sur un bogue ou même avec un correctif, faites-le&nbsp;!
<p>
Pour votre candidature, vous devrez être familiarisé avec la philosophie du
 projet Debian et avec sa documentation technique. Il vous faudra aussi une clé
 GnuPG signée par un responsable Debian. Si votre clé GnuPG n'est pas encore
 signée, vous devriez essayer de rencontrer un responsable Debian pour le faire.
 La <url id="&url-gpg-coord;" name="page de coordination des signatures de clé
 GnuPG"> devrait vous aider à trouver un responsable Debian près de chez vous.
 (Si vous ne trouvez pas de responsable près de chez vous, il existe un second
 moyen pour valider votre identité. Vous pouvez envoyer une photo d'identité
 signée avec votre clé GnuPG. Privilégiez tout de même la clé GnuPG signée pour
 valider une identité. Reportez-vous à la <url id="&url-newmaint-id;" name="page
 d'identification"> pour en savoir plus sur ces deux options.)

<p>
Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin d'une clé
 OpenPGP pour signer et vérifier les mises à jour de paquets. Vous lirez la
 documentation du logiciel de cryptographie que vous utiliserez car elle
 contient des informations indispensables pour la sécurité de votre clé. Les
 défaillances de sécurité sont bien plus souvent dues à des erreurs humaines
 qu'à des problèmes logiciels ou à des techniques d'espionnage avancées. Voir
 <ref id="key-maint"> pour plus d'informations sur la gestion de votre clé
 publique.
<p>
Debian utilise <prgn>GNU Privacy Guard</prgn> (paquet <package>gnupg</package>
 version 1 ou supérieure) comme standard de base. Vous pouvez aussi utiliser une
 autre implémentation d'OpenPGP. OpenPGP est un standard ouvert basé sur la <url
 id="&url-rfc2440;" name="RFC 2440">.
<p>
L'algorithme à clé publique recommandé pour les développements Debian est DSA
 (parfois appelé «&nbsp;DSS&nbsp;» ou «&nbsp;DH\ElGamal&nbsp;»). Vous pouvez
 aussi utiliser d'autres types de clés. La longueur de votre clé doit être au
 minimum de 1024 bits&nbsp;; il n'y a pas de raison d'utiliser une clé plus
 courte et le faire serait beaucoup moins sûr. Votre clé doit être signée avec
 votre propre identifiant&nbsp;; cela évite les falsifications. <prgn>GNU
 Privacy Guard</prgn> le fait automatiquement.
<p>
Si votre clé publique n'est pas sur un serveur public tel que &pgp-keyserv;,
 reportez-vous à la documentation disponible localement dans &file-keyservs;.
 Cette documentation explique comment mettre votre clé publique sur un serveur.
 L'équipe <em>New maintainer</em> mettra votre clé publique sur les serveurs de
 clés si elle n'y est pas déjà.
<p>
Certains pays limitent l'usage des logiciels de cryptographie. Cela ne devrait
 cependant pas avoir d'impact sur l'activité d'un responsable de paquet car il
 peut être tout à fait légal d'utiliser des logiciels de cryptographie pour
 l'authentification plutôt que pour le chiffrement. &debian-formal; ne nécessite
 en aucune façon l'utilisation de chiffrement. Si vous vivez dans un pays où
 l'utilisation de la cryptographie pour authentification est interdite,
 contactez-nous pour que nous prenions des dispositions particulières.
<p>
Pour faire acte de candidature, il vous faut un responsable Debian qui vérifiera
 votre candidature (un <em>avocat</em>). Après avoir contribué au projet Debian
 pendant un temps, quand vous choisissez de devenir un responsable Debian
 officiel, un responsable déjà enregistré avec qui vous aurez travaillé dans les
 derniers mois devra exprimer que, d'après lui, vous pouvez contribuer avec
 succès au projet Debian.
<p>
Quand vous avez trouvez un <em>avocat</em>, quand votre clé GnuPG est signée et
 quand vous avez déjà contribué au projet, vous êtes prêt à faire
 acte de candidature. Il vous suffit pour cela de vous enregistrer sur notre
 <url id="&url-newmaint-apply;" name="page de candidature">. Ensuite, votre
 avocat devra confirmer votre candidature. Quand il aura accompli cette tâche,
 un responsable de candidature<footnote><p>Application manager</footnote> sera
 désigné pour vous accompagner dans le processus d'enregistrement. Vous pouvez
 toujours consulter le <url id="&url-newmaint-db;" name="tableau de bord des
 candidatures"> pour connaître l'état de votre candidature.
<p>
Pour en savoir plus, consultez le <url id="&url-newmaint;" name="coin des
 nouveaux responsables"> sur le site Debian. Assurez-vous de bien connaître les
 étapes nécessaires au processus d'enregistrement avant de vous porter candidat.
 Vous gagnerez beaucoup de temps si vous êtes bien préparé.


      <sect id="mentors">Mentors et parrains Debian
<p>
La liste de diffusion &email-debian-mentors; a été créée pour les responsables
 débutants qui cherchent de l'aide pour leur première création de paquet ainsi
 que pour des problèmes spécifiques aux développeurs. Tout responsable débutant
 est invité à s'y inscrire (voir <ref id="mailing-lists"> pour plus de détails).
<p>
Ceux qui préfèrent une aide personnalisée (via une correspondance privée)
 doivent aussi poster dans cette liste, un développeur expérimenté se portera
 volontaire pour les aider.
<p>
Si vos paquets sont prêts à être intégrés mais que vous attendiez le
 résultat de votre candidature, vous pouvez chercher un parrain qui téléchargera
 les paquets à votre place. Les parrains sont des responsables Debian officiels
 volontaires pour examiner et télécharger vos paquets. Vous pouvez
 demander un parrainage à l'adresse <url id="&url-sponsors;">.
<p>
Si vous désirez être mentor ou parrain, reportez-vous à <ref id="newmaint">.


    <chapt id="developer-duties">Les charges du responsable Debian

      <sect id="user-maint">Mise à jour de vos références Debian
<p>
Il existe une base de données LDAP contenant des informations concernant les
développeurs Debian à <url id="&url-debian-db;">. Vous devriez y entrer vos
informations et les mettre à jour quand elles changent. Le plus important est de
vous assurer que l'adresse vers laquelle est redirigée votre adresse debian.org
est toujours à jour, de même que l'adresse à laquelle vous recevez votre
abonnement à debian-private si vous choisissez d'être abonné à cette liste.
<p>
Pour plus d'informations à propos de cette base de données, veuillez consulter
<ref id="devel-db">.

      <sect id="key-maint">Gérer votre clé publique
<p>
Soyez très vigilant en utilisant votre clé privée. Ne la placez pas sur un
 serveur public ou sur des machines multi-utilisateurs telles que les serveurs
 Debian (voir <ref id="server-machines">). Sauvegardez vos clés et gardez-en une
 copie hors connexion. Lisez la documentation fournie avec votre logiciel et la
 <url id="&url-pgp-faq;" name="FAQ PGP">.
<p>
Si vous ajoutez des signatures ou des identifiants à votre clé publique, vous
 pouvez mettre à jour le porte-clés Debian en envoyant votre clé publique à
 <tt>&keyserver-host;</tt>. Si vous voulez ajouter ou supprimer une clé, envoyez
 un courrier à &email-debian-keyring;. Les procédures d'extraction de clé
 décrites dans <ref id="registering"> s'appliquent ici.
<p>
Vous pouvez trouver une présentation approfondie de la gestion de clé Debian
 dans la documentation du paquet <package>debian-keyring</package>.

       <sect id="voting">Voter
<p>
Bien que Debian ne soit pas vraiment une démocratie, nous disposons d'un
processus démocratique pour élire nos chefs et pour approuver les résolutions
générales. Ces procédures sont définies par la <url id="&url-constitution;"
name="charte Debian">.
<p>
En dehors de l'élection annuelle du chef, les votes ne se tiennent pas
régulièrement et ils ne sont pas entrepris à la légère. Chaque proposition est
tout d'abord discutée sur la liste de diffusion &email-debian-vote; et elle a
besoin de plusieurs approbations avant que le secrétaire du projet n'entame la
procédure de vote.
<p>
Vous n'avez pas besoin de suivre les discussions précédant le vote car le
secrétaire enverra plusieurs appels au vote sur la liste
&email-debian-devel-announce; (et tous les développeurs devraient être inscrits
à cette liste). La démocratie ne fonctionne pas si les personnes ne prennent pas
part au vote, c'est pourquoi nous encourageons tous les développeurs à voter. Le
vote est conduit par messages signés ou chiffrés par GPG.

<p>
La liste de toutes les propositions (passées et présentes) est disponible à la
 page <url id="&url-vote;" name="Informations sur les votes Debian">, ainsi que
 des informations complémentaires sur la procédure à suivre pour effectuer une
 proposition, la soutenir et voter pour elle.

      <sect id="inform-vacation">Prendre des vacances courtoisement
<p>
<!-- à relire -->
Il est courant pour les développeurs de s'absenter, que ce
soit pour des vacances prévues ou parce qu'ils sont submergés de travail. La
chose importante à noter est que les autres développeurs ont besoin de savoir
que vous êtes en vacances pour qu'ils puissent agir en conséquence si un
problème se produit pendant vos vacances.
<p>
Habituellement, cela veut dire que les autres développeurs peuvent faire des NMU
(voir <ref id="nmu">) sur votre paquet si un gros problème (bogues empêchant 
l'intégration dans la distribution, mise à jour de sécurité, etc.) se produit pendant que vous êtes en
vacances. Parfois, ce  n'est pas très important, mais il est de
toute façon approprié d'indiquer aux autres que vous n'êtes pas disponible.
<p>
Il y a deux choses à faire pour informer les autres développeurs.
Premièrement, envoyez un courrier électronique à &email-debian-private; en
commençant le sujet de votre message par «&nbsp;[VAC]&nbsp;»<footnote>Ainsi, le
message peut être facilement filtré par les personnes qui ne veulent pas lire
ces annonces de vacances.</footnote> et donnez la période de vos
vacances. Vous pouvez également donner quelques instructions pour
indiquer comment agir si un problème survenait.
<p>
L'autre chose à faire est de vous signaler comme «&nbsp;en
 vacances&nbsp;»<footnote><p><em>on vacation</em> en anglais</footnote> dans la
 <qref id="devel-db">base de données Debian LDAP</qref> (l'accès à cette
 information est réservé aux développeurs). N'oubliez pas de retirer votre
 indicateur «&nbsp;en vacances&nbsp;» lorsque celles-ci sont terminées&nbsp;!

      <sect id="upstream-coordination">Coordination avec les développeurs amonts
<p>
Une grande part de votre travail de responsable Debian sera de rester en contact
 avec les développeurs amonts. Parfois, les utilisateurs établissent des
 rapports de bogue qui ne sont pas spécifiques à Debian. Vous devez transmettre
 ces rapports de bogue aux développeurs amonts pour qu'ils soient corrigés dans
 les prochaines versions. Il n'est pas de votre responsabilité de corriger les
 bogues qui ne sont pas spécifiques à Debian. Toutefois, si vous êtes capable de
 le faire, nous vous encourageons à contribuer au développement amont en
 proposant un correctif qui corrige le bogue. Les utilisateurs et responsables
 Debian proposent souvent des correctifs pour corriger des bogues amonts, il
 vous faudra alors évaluer ce correctif puis le transmettre aux développeurs
 amonts.
<p>
Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
 paquet conforme à la charte Debian, alors vous devriez proposer un correctif
 aux développeurs amonts pour qu'il soit inclus dans leur version. Ainsi, vous
 n'aurez plus besoin de modifier les sources lors des mises à jour amonts
 suivantes. Quels que soient les changements dont vous avez besoin, il faut
 toujours essayer de rester dans la lignée des sources amonts.

      <sect id="rc-bugs">Comment gérer les bogues empêchant l'intégration du
      paquet dans la distribution&nbsp;?
<p>
Habituellement, vous devriez traiter les rapports de bogue sur vos paquets tel
 que cela est décrit dans <ref id="bug-handling">. Cependant, il y a une
 catégorie spéciale de bogues qui nécessite particulièrement votre
 attention&nbsp;: les bogues empêchant l'intégration du paquet dans la
 distribution<footnote>Traduction de l'anglais <em>Release-critical bug (RC
 Bugs)</em></footnote>. Tous les rapports de bogue de gravité <em>critique</em>,
 <em>grave</em> et <em>sérieuse</em><footnote>Respectivement <em>critical</em>,
 <em>grave</em> et <em>serious</em> en anglais</footnote> sont considérés comme
 ayant un impact sur la présence du paquet dans la prochaine version stable de
 Debian. Ces bogues peuvent retarder la diffusion d'une distribution Debian
 ou peuvent justifier la suppression d'un paquet d'une distribution gelée.
 C'est pourquoi ces bogues doivent être corrigés au plus vite.
<p>
Les développeurs faisant partie de l'équipe d'<url id="&url-debian-qa;"
 name="assurance qualité Debian"> surveillent ces bogues et essaient de vous
 aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas corriger un bogue de
 ce type dans les deux semaines, vous devriez soit demander de l'aide en
 envoyant un courrier à l'équipe d'assurance qualité (<em>QA group</em>) à
 &email-debian-qa;, soit expliquer vos difficultés et présenter un plan pour
 corriger le problème en répondant au rapport de bogue concerné. Si rien n'est
 fait, des personnes de l'équipe d'assurance qualité pourraient chercher à
 corriger votre paquet (voir <ref id="nmu">) après avoir tenté de vous contacter
 (ils pourraient attendre moins longtemps que d'habitude pour faire leur mise à
 jour s'il n'y a pas trace d'activité récente de votre part dans le système de
 suivi des bogues).


      <sect>Démissionner
<p>
Si vous choisissez de quitter le projet Debian, procédez comme suit&nbsp;:
<enumlist compact="compact">
  <item><p>abandonnez tous vos paquets comme décrit dans <ref
        id="orphaning">&nbsp;;</item>
  <item><p>envoyez un courrier électronique à &email-debian-private; indiquant
        pourquoi vous quittez le projet&nbsp;;</item>
  <item><p>signalez aux responsables du porte-clés Debian que vous quittez le
        projet en écrivant à &email-debian-keyring;.</item>
</enumlist>



   <chapt id="resources">Ressources pour le responsable Debian
<p>
Dans ce chapitre, vous trouverez une brève description des listes de diffusion,
 des machines Debian qui seront à votre disposition en tant que responsable
 Debian ainsi que toutes les autres ressources à votre disposition pour vous
 aider dans votre travail de responsable.

      <sect id="mailing-lists">Les listes de diffusion
<p>
Le serveur de liste de diffusion est <tt>&lists-host;</tt>.
<p>
Les archives des listes de diffusion sont consultables à <url
 id="&url-lists-archives;">.

        <sect1 id="core-devel-mailing-lists">Principales listes pour les
        responsables
<p>
Les principales listes de diffusion de Debian que les développeurs
 devraient suivre sont&nbsp;:
<list>
<item>&email-debian-devel-announce;, utilisée pour les annonces importantes
      faites aux responsables. Tous les responsables Debian sont censés être
      inscrits à cette liste,</item>
<item>&email-debian-devel;, utilisée pour discuter de diverses questions
      techniques relatives au développement,</item>
<item>&email-debian-policy; où l'on discute et vote les modifications de la
      charte Debian,</item>
<item>&email-debian-project;, utilisée pour discuter de questions non
      techniques.</item>
</list>
<p>
Il existe d'autres listes de diffusion spécialisées dans différents thèmes.
 Reportez-vous à la page <url id="&url-debian-lists-subscribe;"> pour en obtenir
 la liste complète.

        <sect1 id="mailing-lists-subunsub">S'abonner et se désabonner
<p>
Pour vous abonner ou vous désabonner de n'importe quelle liste, envoyez un
 courrier électronique à
 <tt>debian-<var>foo</var>-REQUEST@&lists-host;</tt>, où
 <tt>debian-<var>foo</var></tt> est le nom de la
 liste<footnote><var>foo</var> étant le thème de la liste</footnote>, avec
 le mot <tt>subscribe</tt> dans le champ
 <em>Objet</em><footnote><p><em>Subject</em> en anglais</footnote> pour vous
 abonner à la liste ou <tt>unsubscribe</tt> pour vous désabonner.
<p>
Si vous préférez utiliser une page web pour vous inscrire à plusieurs listes,
 celle-ci se trouve à l'adresse <url id="&url-debian-lists-subscribe;">.
<p>
Vous pouvez télécharger la liste des listes de diffusion et quelques
 instructions depuis <url id="&url-debian-lists-txt;"> ou installer le paquet
 <package>doc-debian</package> et en disposer localement dans le fichier
 &file-mail-lists;.

        <sect1 id="mailing-lists-rules">Règles d'usage simple
<p>
Lorsque vous répondez aux messages d'une liste de diffusion, n'envoyez pas de
 copie (<tt>CC</tt>) à l'auteur du courrier à moins qu'il ne l'ait demandé
 explicitement. Celui qui envoie un message à une liste de diffusion se doit
 d'y lire les réponses.
<p>
La multi-diffusion (envoyer le même message à plusieurs listes) est déconseillée.
 Comme toujours sur Internet, veuillez réduire le texte cité des messages
 auxquels vous répondez. En général, veuillez adhérer aux conventions usuelles
 d'envoi de messages.
<p>
Veuillez lire le <url id="&url-debian-lists;" name="code de conduite"> pour plus
 d'informations.

        <sect1 id="mailing-lists-special">Listes spéciales
<p>
&email-debian-private; est une liste de diffusion destinée aux discussions
 privées entre développeurs Debian. Elle doit être utilisée pour tout message
 qui ne doit pas être publié, quelle qu'en soit la raison. C'est une liste à
 faible trafic et les utilisateurs sont priés de ne l'utiliser qu'en cas de
 réelle nécessité. De plus, il ne faut <em>jamais</em> faire suivre un courrier
 de cette liste à qui que ce soit. Pour des raisons évidentes, les archives de
 cette liste ne sont pas disponibles sur la toile. Vous pouvez les consulter en
 visitant le répertoire <file>~debian/archive/debian-private</file> avec votre
 compte sur <tt>lists.debian.org</tt>.
<p>
&email-debian-email; est une liste de diffusion fourre-tout. Elle est utilisée
 pour les correspondances relatives à Debian qu'il serait utile d'archiver,
 telles que des échanges avec les auteurs amonts à propos de licences, de bogues
 ou encore des discussions sur le projet avec d'autres personnes.


      <sect id="irc-channels">Canaux IRC
<p>
Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont
 principalement hébergés sur le réseau <url id="&url-openprojects;"
 name="freenode"> (anciennement connu sous le nom de Open Projects Network).
 L'entrée DNS <tt>irc.debian.org</tt> est simplement un alias vers
 <tt>irc.freenode.net</tt>.
<p>
Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un
canal important, généraliste, où les utilisateurs peuvent trouver des nouvelles
 récentes dans le sujet et qui est administré par des robots. <em>#debian</em>
 est destiné aux anglophones&nbsp;; il existe également <em>#debian.de</em>,
 <em>#debian-fr</em>, <em>#debian-br</em> et d'autres canaux avec des noms
 semblables pour les personnes parlant d'autres langues.
<p>
Le canal principal pour le développement Debian est <em>#debian-devel</em>.
 C'est un canal très actif avec habituellement plus de 150 personnes connectées
 en permanence. C'est un canal pour les personnes qui travaillent sur Debian, ce
 n'est pas un canal d'aide (il existe <em>#debian</em> pour cela). Il est
 cependant ouvert à tous ceux qui veulent écouter (et apprendre). Le sujet est
 toujours rempli d'informations intéressantes.
<p>
Comme <em>#debian-devel</em> est un canal ouvert, vous ne devriez pas y parler
 de problèmes discutés sur &email-debian-private;. Il existe un canal protégé
 par clé <em>#debian-private</em> dans ce but. La clé est disponible dans les
 archives de debian-private à
 <file>master.debian.org:&file-debian-private-archive;</file>, effectuez
 simplement un <prgn>zgrep</prgn> avec <em>#debian-private</em> dans tous les
 fichiers.
<p>
Il existe d'autres canaux dédiés à des sujets spécifiques. <em>#debian-bugs</em>
 est utilisé pour la coordination des <em>chasses aux bogues</em>.
 <em>#debian-boot</em> est utilisé pour la coordination du travail sur les
 disquettes de démarrage (i.e., l'installeur). <em>#debian-doc</em> est utilisé
 occasionnellement pour travailler sur la documentation comme celle que vous
 lisez actuellement. D'autres canaux sont dédiés à une architecture ou un
 ensemble de paquets&nbsp;: <em>#debian-bsd</em>, <em>#debian-kde</em>,
 <em>#debian-jr</em>, <em>#debian-edu</em>, <em>#debian-sf</em> (paquet
 SourceForge), <em>#debian-oo</em> (paquet OpenOffice), etc.
<p>
Certains canaux pour développeurs non anglophones existent, par exemple,
 <em>#debian-devel-fr</em> pour les francophones intéressés dans le
 développement de Debian.
<p>
Il existe également des canaux dédiés pour Debian sur d'autres réseaux IRC,
 notamment sur le réseau IRC <url name="Open and free technology community
 (OFTC)" id="http://www.oftc.net/">.


      <sect id="doc-rsrcs">Documentation
<p>
Ce document contient beaucoup d'informations très utiles aux développeurs
 Debian, mais il ne peut pas tout contenir. La plupart des autres documents
 intéressants sont référencés dans le <url id="&url-devel-docs;" name="coin
 du développeur Debian">. Prenez le temps de parcourir tous les liens, vous
 apprendrez encore beaucoup de choses.


      <sect id="server-machines">Les serveurs Debian
<p>
Debian possède plusieurs ordinateurs employés comme serveurs, dont la plupart hébergent
 les fonctions critiques du projet Debian. La plupart des machines sont
 utilisées pour des activités de portage et elles ont toutes un accès permanent
 à Internet.
<p>
La plupart des machines peuvent être utilisées par les développeurs
 tant qu'ils respectent les règles définies dans la <url
 id="&url-dmup;" name="charte d'utilisation des machines Debian">.
<p>
Dans l'ensemble, vous pouvez faire usage de ces machines pour des buts relatifs
 à Debian comme vous l'entendez. Veuillez cependant être gentil avec les
 administrateurs système et ne pas utiliser de grandes quantités d'espace
 disque, de ressource réseau ou CPU sans obtenir auparavant l'accord des
 administrateurs. Habituellement, ces machines sont administrées par des
 volontaires.
<p>
Veuillez prendre soin de votre mot de passe Debian ainsi que des clés SSH
 installées sur les machines Debian. Évitez les méthodes de connexion ou d'envoi
 de données qui envoient les mots de passe en clair par l'Internet comme telnet,
 FTP, POP, etc.
<p>
Veuillez ne pas déposer de données non relatives à Debian sur les serveurs
Debian à moins que vous n'ayez préalablement obtenu la permission de le faire.
<p>
La liste actuelle des machines Debian est disponible à <url
 id="&url-devel-machines;">. Cette page web contient les noms des machines, les
 informations de contact, les informations sur qui peut s'y connecter, les clés
 SSH, etc.
<p>
Si vous avez un problème en utilisant un serveur Debian et si vous estimez que
 les administrateurs système devraient en être avertis, l'équipe des
 administrateurs système peut être jointe à
 <email>debian-admin@lists.debian.org</email>.
<p>
Si votre problème est lié à un certain service ou n'est pas lié au système
 (paquet à supprimer de l'archive ou suggestion pour le site web par exemple),
 il vous faudra en général ouvrir un rapport de bogue sur un
 «&nbsp;pseudo-paquet&nbsp;». Reportez-vous à la section <ref id="submit-bug">
 pour connaître la procédure à suivre.

      <sect1 id="servers-bugs">Le serveur pour les rapports de bogues
<p>
<tt>&bugs-host;</tt> est le serveur maître du système de suivi des bogues
 (BTS<footnote><p>Système de suivi des bogues se dit <em>Bug Tracking
 System</em> en anglais</footnote>). Si vous envisagez de manipuler les rapports
 de bogue ou d'en faire une analyse statistique, ce sera le bon endroit pour le
 faire. Informez la liste &email-debian-devel; de votre intention avant
 d'implémenter quoi que ce soit afin d'éviter un travail en double ou un
 gaspillage de temps machine.
<p>
Tous les développeurs Debian ont un compte sur
 <tt>&bugs-host;</tt>.

      <sect1 id="servers-ftp-master">Le serveur ftp-master
<p>
Le serveur <tt>ftp-master.debian.org</tt> est le serveur maître de l'archive
 Debian (exception faite des paquets non-US). En général, les mises à jour de
 paquets se font sur ce serveur. Reportez-vous à la section <ref id="upload">
 pour en savoir plus.
<p>
Les problèmes avec l'archive Debian FTP doivent généralement être rapportés
 comme bogues sur le pseudo-paquet <package>ftp.debian.org</package> ou par
 courrier électronique à &email-ftpmaster;&nbsp;; reportez-vous à la section
 <ref id="archive-manip"> pour connaître la procédure à suivre.

      <sect1 id="servers-non-us">Le serveur non-US
<p>
Le serveur non-US <tt>non-us.debian.org</tt> est le serveur maître de la partie
 non-US de l'archive Debian. Si vous avez besoin d'envoyer un paquet dans l'une
 des sections non-US, envoyez-le vers ce serveur. Reportez-vous à la section
 <ref id="upload-non-us"> pour en savoir plus.
<p>
Les problèmes avec l'archive de paquets non-US doivent généralement être
 rapportés comme bogues sur le pseudo-paquet <package>nonus.debian.org</package>
 (remarquez l'absence de trait d'union entre "non" et "us" dans le nom du
 pseudo-paquet &mdash; c'est dû à la compatibilité descendante). Rappelez-vous
 de vérifier si quelqu'un n'aurait pas déjà rempli un rapport de bogue
 concernant le problème sur le <url id="http://&bugs-host;/nonus.debian.org"
 name="système de suivi des bogues">.

      <sect1 id="servers-www">Le serveur www-master
<p>
Le serveur web principal est <tt>www-master.debian.org</tt>. Il héberge les
 pages web officielles, la façade de Debian pour la plupart des débutants.
<p>
Si vous rencontrez un problème avec un serveur web Debian, vous devez
 généralement envoyer un rapport de bogue sur le pseudo-paquet
 <package>www.debian.org</package>. Vérifiez d'abord sur le <url
 id="http://&bugs-host;/www.debian.org" name="système de suivi des bogues">
 que personne ne l'a déjà rapporté avant vous.

      <sect1 id="servers-people">Le serveur web people
<p>
<tt>people.debian.org</tt> est le serveur utilisé par les développeurs pour 
leurs pages concernant Debian.
<p>
Si vous avez des informations spécifiques Debian que vous voulez rendre
 disponibles sur le web, vous pouvez le faire en les plaçant dans le répertoire
 <file>public_html</file> de votre répertoire personnel sur
 <tt>people.debian.org</tt>. Elles seront accessibles à l'adresse
 <tt>http://people.debian.org/~<var>votre-user-id</var>/</tt>.
<p>
Vous ne devriez utiliser que cet emplacement particulier car il sera sauvegardé
 alors que sur les autres serveurs, ce ne sera pas le cas.
<p>
Habituellement, la seule raison pour utiliser un serveur différent est que vous
 avez besoin de publier des informations soumises aux restrictions d'exportation 
 américaines, dans ce cas, vous pouvez utiliser l'un des autres serveurs situés
 en dehors des États-Unis, comme le serveur mentionné ci-dessus
 <tt>non-us.debian.org</tt>.
<p>
Veuillez envoyer un courrier à &email-debian-devel; si vous avez une question.

      <sect1 id="servers-cvs">Le serveur CVS
<p>
Notre serveur CVS est situé sur <tt>cvs.debian.org</tt>.
<p>
Si vous avez besoin d'un serveur CVS accessible par tous pour, par exemple,
 coordonner le travail de plusieurs développeurs sur un paquet, vous pouvez
 demander un espace CVS sur ce serveur.
<p>
Le serveur <tt>cvs.debian.org</tt> autorise les accès CVS locaux, les accès en
 lecture seule pour les connexions client-serveur anonymes et les accès
 client-serveur complets pour les connexions <prgn>ssh</prgn>. L'espace CVS peut
 aussi être consulté par la toile à l'adresse <url id="&url-cvsweb;">.
<p>
Pour obtenir un espace CVS, envoyez une demande à l'adresse &email-debian-admin;
 en précisant le nom de l'espace, le compte Debian propriétaire du répertoire
 racine et pourquoi vous en avez besoin.


    <sect id="devel-db">La base de données des développeurs
<p>
La base de données des développeurs à <url id="&url-debian-db;"> est un annuaire
 LDAP de gestion des informations des développeurs Debian. Vous pouvez utiliser
 cette ressource pour rechercher la liste des développeurs Debian. Une partie de
 ces informations est également disponible à travers le service finger sur les
 serveurs Debian, essayez <prgn>finger yourlogin@debian.org</prgn> pour voir ce
 qu'il indique.
<p>
Les développeurs peuvent <url name="se connecter à la base de données"
id="&url-debian-db-login;"> pour modifier différentes informations les
concernant, comme&nbsp;:
<list>
        <item>l'adresse de suivi pour leur adresse debian.org,
        <item>l'abonnement à debian-private,
        <item>l'état en vacances ou non,
        <item>des informations personnelles comme les adresse, pays, latitude et
        longitude de l'endroit où ils vivent pour utilisation dans la <url
        name="carte mondiale des développeurs Debian" id="&url-worldmap">,
        numéros de téléphone et de fax, surnom IRC et page web,
        <item>le mot de passe et le shell préféré sur les machines du projet Debian.
</list>
<p>
La plupart des informations ne sont naturellement pas accessibles publiquement.
Pour plus d'informations, veuillez lire la documentation en ligne que vous
pouvez trouver à <url id="&url-debian-db-doc;">.

<p>
Il est également possible d'envoyer ses clés SSH pour les utiliser pour
 autorisation sur les machines Debian officielles et même d'ajouter de nouvelles
 entrées DNS du type *.debian.net. Ces fonctionnalités sont documentées à <url
 id="&url-debian-db-mail-gw;">.


    <sect id="archive">L'archive Debian
<p>
La distribution &debian-formal; est composée d'un grand nombre de paquets
 (fichiers <tt>.deb</tt>&nbsp;: actuellement, à peu près &number-of-pkgs;) et de
 quelques autres fichiers (comme la documentation et des images des disquettes
 d'installation).
<p>
Voici un exemple d'arborescence pour une archive Debian complète&nbsp;:
<p>
&sample-dist-dirtree;
<p>
Comme vous pouvez le voir, le répertoire racine contient deux répertoires,
 <file>dists/</file> et <file>pool/</file>. Le second est un ensemble de
 répertoires où sont stockés les paquets. Ceux-ci sont manipulés grâce à la base
 de données de l'archive et aux logiciels qui l'accompagnent. Le premier
 répertoire contient les distributions <em>stable</em>, <em>testing</em> et
 <em>unstable</em>. Les fichiers <file>Packages</file> et <file>Sources</file>
 qui se trouvent dans les répertoires de distribution peuvent faire référence à
 des fichiers du répertoire <file>pool/</file>. Le découpage en sous-répertoires
 est identique d'un répertoire de distribution à l'autre&nbsp;. Ce que nous
 exposerons ci-dessous pour la distribution <em>stable</em> est également
 applicable aux distributions <em>unstable</em> et <em>testing</em>.
<p>
Le répertoire <file>dists/stable</file> contient trois répertoires nommés
  <file>main</file>, <file>contrib</file> et <file>non-free</file>.
<p>
Dans chacune de ces sections, se trouve un répertoire contenant les paquets
  sources (<file>source/</file>) et un répertoire pour chaque architecture
  acceptée (<file>binary-i386/</file>, <file>binary-m68k/</file>, etc.).
<p>
La section <em>main</em> contient d'autres répertoires destinés aux images de
 disquettes et à plusieurs documents essentiels pour installer la distribution
 Debian sur une architecture particulière (<file>disk-i386/</file>,
 <file>disk-m68k/</file>, etc.).

      <sect1>Les sections
<p>
La section <em>main</em> constitue la <strong>distribution &debian-formal;
 officielle</strong>. Elle est officielle parce qu'elle est entièrement conforme
 à toutes nos recommandations. Les deux autres sections divergent de ces
 recommandations à différents degrés, elles <strong>ne</strong> font donc <strong>pas</strong>
 officiellement partie de &debian-formal;.
<p>
Chaque paquet de la section <em>main</em> doit être conforme aux <url
 id="&url-dfsg;" name="directives Debian pour le logiciel
 libre"><footnote>Debian Free Software Guidelines</footnote> et à toutes les
 autres recommandations décrites dans <url id="&url-debian-policy;" name="la
 charte Debian"><footnote>Debian Policy Manual</footnote>. Les
 DFSG<footnote><em>Debian Free Software Guidelines</em></footnote> constituent
 notre définition de «&nbsp;logiciel libre&nbsp;». Reportez-vous à la <em>charte
 Debian</em> pour en savoir plus.
<p>
Les paquets de la section <em>contrib</em> doivent être conformes aux DFSG, mais
 ne respectent pas d'autres contraintes. Ils peuvent, par exemple, dépendre de
 paquets de la section <em>non-free</em>.
<p>
Les paquets qui ne sont pas conformes aux DFSG sont rangés dans la section
 <em>non-free</em>. Bien que nous supportions l'usage de ces paquets et qu'ils
 bénéficient de nos infrastructures (système de suivi des bogues, listes de
 diffusion, etc.), ces paquets <em>non-free</em> ne font pas partie de la
 distribution Debian.
<p>
La <em>charte Debian</em> donne des définitions plus précises pour ces trois
 sections. Les paragraphes précédents ne constituent qu'une introduction.
<p>
La séparation de l'archive en trois sections est importante pour toute personne
 qui désire distribuer Debian, que ce soit par serveur FTP ou sur cédérom. Il
 suffit de distribuer les sections <em>main</em> et <em>contrib</em> pour éviter
 tout problème légal. Certains paquets de la section <em>non-free</em>
 interdisent leur distribution à titre commercial par exemple.
<p>
D'un autre côté, un distributeur de cédérom pourra facilement vérifier
 la licence de chacun des paquets de la section <em>non-free</em> et
 inclure tous les paquets qu'il lui sera autorisé (dans
 la mesure où cela varie énormément d'un distributeur à l'autre, ce travail ne
 peut être fait par les développeurs Debian).
<p>
Notez que le terme «&nbsp;section&nbsp;» est également utilisé pour faire
 référence aux catégories qui simplifient l'organisation des paquets 
disponibles et leur recherche, e.g. <em>admin</em>, <em>net</em>, <em>utils</em> etc. Il
 fut un temps où ces sections (sous-sections, plutôt) existaient sous la forme
 de sous-répertoires dans l'archive Debian. Actuellement, elles n'existent plus
 que dans le champ en-tête «&nbsp;Section&nbsp;» des paquets.

      <sect1>Les architectures
<p>
À ses débuts, le noyau Linux existait uniquement pour les architectures Intel
 x86&nbsp;; il en était de même pour Debian. Linux devenant de plus en plus
 populaire, il a été porté vers d'autres architectures.
<p>
Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC,
 Motorola, 680x0 (Atari, Amiga, et Macintosh), MIPS et PowerPC. Le noyau 2.2
 reconnaît de nouvelles architectures, comme ARM et UltraSPARC. Puisque Linux
 reconnaît ces architectures, le projet Debian a décidé qu'il devait également les
 accepter. C'est pourquoi plusieurs portages sont en cours&nbsp;; en fait, il y
 a aussi des portages vers d'autres noyaux. À côté d'<em>i386</em> (notre nom
 pour Intel x86), nous avons, au moment où j'écris, <em>m68k</em>,
 <em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
 <em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>, <em>mips</em>,
 <em>mipsel</em> et <em>sh</em>.
<p>
&debian-formal; 1.3 est disponible uniquement pour <em>i386</em>. Debian 2.0
 reconnaît les architectures <em>i386</em> et <em>m68k</em>. Debian 2.1 reconnaît
 les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et
 <em>sparc</em>. Debian 2.2 accepte en plus les architectures
 <em>powerpc</em> et <em>arm</em>. Debian 3.0 accepte cinq
 nouvelles architectures&nbsp;: <em>ia64</em>, <em>hppa</em>, <em>s390</em>,
 <em>mips</em> et <em>mipsel</em>.
<p>
Pour chaque portage, vous trouverez des informations destinées aux développeurs
 et utilisateurs sur la page <url id="&url-debian-ports;" name="Portage
 Debian">.

      <sect1>Les paquets
<p>
Il existe deux types de paquets Debian&nbsp;: les paquets sources et les paquets
 binaires.
<p>
Les paquets sources sont constitués de deux ou trois fichiers&nbsp;: un fichier
 <file>.dsc</file> et soit un fichier <file>.tar.gz</file>, soit un fichier
 <file>.orig.tar.gz</file> et un fichier <file>.diff.gz</file>.
<p>
Si un paquet est développé spécifiquement pour le projet Debian et n'est pas
 distribué en dehors de Debian, il n'y a qu'un fichier <file>.tar.gz</file> qui
 contient les sources du programme. Si un paquet est distribué ailleurs, le
 fichier <file>.orig.tar.gz</file> contient ce que l'on appelle <em>code source
 amont</em>, c'est-à-dire, le code source distribué par le <em>mainteneur
 amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le fichier
 <file>.diff.gz</file> contient les modifications faites par le responsable
 Debian.
<p>
Le fichier <file>.dsc</file> liste tous les fichiers sources avec leurs sommes
 de contrôle (<prgn>md5sums</prgn>) et quelques informations supplémentaires
 concernant le paquet (responsable, version, etc.).

      <sect1>Les répertoires des distributions
<p>
L'organisation des répertoires présentée précédemment est elle-même englobée par
 les <em>répertoires des distributions</em>. Chaque distribution est incluse
 dans le répertoire <file>pool</file> à la racine de l'archive Debian.
<p>
En résumant, une archive Debian a un répertoire racine sur un serveur FTP. Par
 exemple, sur le site miroir <ftpsite>ftp.us.debian.org</ftpsite>, l'archive
 Debian se trouve dans <ftppath>/debian</ftppath> ce qui est un emplacement
 courant. Un autre emplacement courant est <file>/pub/debian</file>.
<p>
Une distribution est composée de paquets sources et binaires et des
 fichiers <file>Sources</file> et <file>Packages</file> correspondants qui
 contiennent toutes les méta-informations sur les paquets. Les premiers sont
 conservés dans le répertoire <file>pool/</file> tandis que les seconds sont
 conservés dans le répertoire <file>dists/</file> de l'archive (pour
 compatibilité descendante).

        <sect2 id="sec-dists"><em>Stable</em>, <em>testing</em> et
        <em>unstable</em>
<p>
Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire
 <file>dists/stable</file>), une distribution appelée <em>testing</em> (dans le
 répertoire <file>dists/testing</file>) et une distribution appelée
 <em>unstable</em> (dans le répertoire <file>dists/unstable</file>). Ceci
 reflète le processus de développement du projet Debian.
<p>
Les développements se font sur la distribution
 <em>unstable</em><footnote><p><em>unstable</em> signifie
 «&nbsp;instable&nbsp;»</footnote> (c'est pourquoi elle est aussi appelée
 <em>distribution de développement</em>). Chaque développeur Debian peut
 modifier ses paquets à tout moment dans cette distribution. Ainsi son contenu
 change tous les jours. Comme aucun effort particulier n'est fait pour s'assurer
 que tout fonctionne correctement dans cette distribution, elle est parfois
 littéralement «&nbsp;instable&nbsp;».
<p>
<ref id="testing"> est générée automatiquement en prenant les paquets
 d'<em>unstable</em> s'ils satisfont à certains critères. Ces critères
 garantissent que les paquets de <em>testing</em> sont de bonne qualité. La
 mise à jour de <em>testing</em> est lancée chaque jour après que les
 nouveaux paquets ont été installés.
<p>
Après une période de développement, quand le responsable de
 distribution<footnote><p><em>Release manager</em></footnote> le juge opportun,
 la distribution <em>testing</em> est gelée, ce qui signifie que les conditions
 à remplir pour qu'un paquet passe d'<em>unstable</em> à <em>testing</em> sont
 durcies. Les paquets trop bogués sont supprimés et les seules mises à jours
 autorisées concernent les corrections de bogues. Après quelque temps, selon
 l'avancement, la distribution entre dans une phase de «&nbsp;gel complet&nbsp;»
 où les seules modifications acceptées concernent la procédure d'installation.
 Cette phase s'appelle un «&nbsp;cycle de test&nbsp;» et cela peut durer jusqu'à
 deux semaines. Il peut y avoir plusieurs cycles de tests avant que le
 responsable de distribution ne la déclare prête pour la diffusion. À la fin du
 dernier cycle de test, la distribution <em>frozen</em> devient <em>stable</em>,
 remplaçant l'ancienne distribution <em>stable</em> qui est enlevée à cette
 occasion (elle peut être retrouvée à l'adresse <tt>&archive-host;</tt>).
<p>
Ce cycle de développement est basé sur l'idée que la distribution
 <em>unstable</em> devient <em>stable</em> après une période de test
 (<em>testing</em>). Une distribution contient inévitablement des bogues, même
 si elle est classée stable. C'est pourquoi les distributions stables sont mises
 à jour de temps en temps. Les corrections introduites sont testées avec une
 grande attention et sont ajoutées une à une à l'archive pour diminuer les
 risques d'introduire de nouveaux bogues. Vous pouvez trouver des paquets
 proposés pour les mises à jour de <em>stable</em> dans le répertoire
 <file>proposed-updates</file>. De temps en temps, les paquets de ce répertoire
 qui ne présentent pas de problème sont installés dans la distribution
 <em>stable</em> et le numéro de révision de cette distribution est incrémenté
 («&nbsp;3.0&nbsp;» devient «&nbsp;3.0r1&nbsp;», «&nbsp;2.0r4&nbsp;» devient
 «&nbsp;2.0r5&nbsp;» et ainsi de suite).
<p>
Notez que, pendant la période de gel, les développements continuent sur la
 distribution <em>unstable</em> car cette distribution reste en place.

        <sect2 id="experimental">Experimental
<p>
La distribution <em>experimental</em> est une distribution particulière. Ce n'est
   pas une distribution à part entière comme le sont <em>stable</em> et
   <em>unstable</em>. Elle est prévue pour servir de plate-forme de
   développement pour les projets expérimentaux qui risquent vraiment de
   détruire le système ou bien pour des logiciels qui sont vraiment trop
   instables pour être inclus dans la distribution <em>unstable</em> (mais pour
   lesquels une mise en paquet est justifiée). Les utilisateurs qui téléchargent
   et installent des paquets depuis <em>experimental</em> sont prévenus&nbsp;:
   on ne peut pas faire confiance à la distribution <em>experimental</em>.
<p>
Voici les lignes de <manref name="sources.list" section="5"> pour
   <em>experimental</em>&nbsp;:
<example>
deb http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
deb-src http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
</example>
<p>
Si un logiciel peut causer des dégats importants, il sera sûrement
   préférable de le mettre dans la distribution <em>experimental</em>. Un
   système expérimental de fichier compressé, par exemple, devrait probablement
   aller dans <em>experimental</em>.
<p>
Une nouvelle version amont qui ajoute de nouvelles fonctions tout en supprimant
   de nombreuses autres ne devra pas être téléchargée dans l'archive Debian,
   elle pourra cependant être téléchargée dans <em>experimental</em>. Une
   nouvelle version non finalisée d'un logiciel qui utilise une méthode de
   configuration complètement différente pourrait aller dans
   <em>experimental</em> au gré du responsable. Si vous travaillez sur un cas de
   mise à jour complexe ou incompatible, vous pouvez aussi utiliser
   <em>experimental</em> comme plate-forme d'intégration et ainsi fournir un
   accès aux testeurs.
<p>
Quelques logiciels expérimentaux peuvent cependant aller dans <em>unstable</em>,
   avec un avertissement dans la description, mais ce n'est pas recommandé car
   les paquets d'<em>unstable</em> se propagent dans <em>testing</em> et
   aboutissent dans <em>stable</em>. Vous ne devriez pas avoir peur d'utiliser
   <em>experimental</em> car ceci ne cause aucun souci aux ftpmasters, les
   paquets expérimentaux sont automatiquement enlevés quand vous envoyez le
   paquet dans <em>unstable</em> avec un numéro de version supérieur.
<p>
Un nouveau logiciel qui ne risque pas d'endommager le système ira directement
   dans <em>unstable</em>.
<p>
Une alternative à <em>experimental</em> consiste à utiliser vos pages
   personnelles sur le serveur <tt>people.debian.org</tt>.

      <sect1 id="codenames">Les noms de distribution
<p>
Chaque distribution Debian diffusée a un <em>nom de code</em>&nbsp;: Debian 1.1
 s'appelle «&nbsp;buzz&nbsp;»&nbsp;; Debian 1.2, «&nbsp;rex&nbsp;»&nbsp;; Debian
 1.3, «&nbsp;bo&nbsp;»&nbsp;; Debian 2.0, «&nbsp;hamm&nbsp;»&nbsp;; Debian 2.1,
 «&nbsp;slink&nbsp;»; Debian 2.2, «&nbsp;potato&nbsp;» et Debian 3.0,
 «&nbsp;woody&nbsp;». Il y a aussi une pseudo-distribution nommée
 «&nbsp;sid&nbsp;», il s'agit de la distribution <em>unstable</em>&nbsp;; comme
 les paquets vont d'<em>unstable</em> à <em>testing</em> quand ils approchent
 de la stabilité, la distribution «&nbsp;sid&nbsp;» n'est jamais diffusée. En
 plus du contenu habituel d'une distribution Debian, «&nbsp;sid&nbsp;» contient
 des paquets pour des architectures qui ne sont pas encore officiellement
 reconnues ou pour lesquelles la distribution n'a pas encore été diffusée. Ces
 architectures seront intégrées ulterieurement à la distribution principale.
<p>
Comme Debian est un projet de développement ouvert (i.e. tout le monde peut
 participer et suivre les développements), même les distributions
 <em>unstable</em> et <em>testing</em> sont disponibles sur les serveurs HTTP et
 FTP de Debian. Si nous avions nommé le répertoire qui contient la prochaine
 distribution à diffuser «&nbsp;testing&nbsp;», il aurait fallu changer son nom en
 «&nbsp;stable&nbsp;» au moment de la diffusion, ce qui aurait forcé les miroirs
 FTP à télécharger à nouveau la distribution complète (qui est plutôt volumineuse).
<p>
D'un autre côté, si une distribution s'appelait <em>Debian-x.y</em> dès le
 départ, des personnes pourraient s'imaginer que la distribution Debian
 <em>x.y</em> est disponible. (Cela s'est produit par le passé, un distributeur
 avait gravé des cédéroms Debian 1.0 en utilisant une version de développement
 pré-1.0. C'est pour cette raison que la première version officielle était la
 version 1.1 et non la 1.0).
<p>
En conséquence, les noms de répertoire des distributions dans l'archive sont
 déterminés par leur nom de code et non par leur statut (exemple&nbsp;:
 slink). Ces noms sont identiques pendant la période de développement et une
 fois la distribution diffusée&nbsp;; des liens symboliques, qui peuvent être
 modifiés facilement, indiquent la distribution stable actuelle. Tout ceci
 explique pourquoi les répertoires des distributions sont nommés à partir des
 noms de code des distributions alors que <em>stable</em>, <em>testing</em> et
 <em>unstable</em> sont des liens symboliques qui pointent vers les répertoires
 appropriés.


    <sect id="mirrors">Les miroirs Debian
        <p>
Les différentes archives de téléchargement et le site web disposent de plusieurs
miroirs pour soulager les serveurs principaux d'une lourde charge. En fait,
certains de ces serveurs ne sont pas publics et la charge est
répartie sur une première série de serveurs. De cette façon, les
utilisateurs ont toujours accès aux miroirs et s'y habituent, ce qui permet à
Debian de mieux répartir les besoins en bande passante sur plusieurs serveurs et
plusieurs réseaux différents et évitent aux utilisateurs de surcharger
l'emplacement primaire. Notez que, dans cette première série, les serveurs sont aussi à jour
que possible car la mise à jour est déclenchée par les sites maîtres internes.
        <p>
Toutes les informations sur les miroirs Debian peuvent être trouvées à <url
id="&url-debian-mirrors;">, y compris une liste des miroirs publics disponibles
FTP/HTTP. Cette page utile inclut également des informations et des outils pour
créer son propre miroir, soit en interne soit pour un accès public.
        <p>
Les miroirs sont en général mis en &oelig;uvre par des tiers qui veulent aider
 Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces
 machines.


    <sect id="incoming-system">
        <heading>Le système Incoming
<p>
Le système Incoming est responsable de la collecte des paquets mis à jour et de
 leur installation dans l'archive Debian. Il est constitué d'un ensemble de
 répertoires et de scripts qui sont installés à la fois sur
 <tt>&ftp-master-host;</tt> et sur <tt>&non-us-host;</tt>.
<p>
Les paquets sont envoyés par tous les responsables Debian dans un répertoire
 nommé <file>unchecked</file>. Ce répertoire est parcouru toutes les 15 minutes
 par le script <prgn>katie</prgn> qui vérifie l'intégrité des paquets envoyés et
 les signatures de chiffrage. Si le paquet est considéré comme prêt à être
 installé, il est déplacé dans le répertoire <file>accepted</file>. S'il s'agit
 du premier envoi du paquet, il est déplacé dans le répertoire <file>new</file>
 où il attend l'approbation des ftpmasters. Si le paquet contient des fichiers
 devant être installés <em>à la main</em>, il est déplacé dans le répertoire
 <file>byhand</file> où il attend une installation manuelle par les ftpmasters.
 Sinon, si une erreur a été détectée, le paquet est refusé et il est déplacé
 dans le répertoire <file>reject</file>.
<p>
Une fois que le paquet est accepté, le système envoie une confirmation par
 courrier au responsable et ferme les bogues corrigés par l'envoi, puis
 les compilateurs automatiques peuvent commencer la recompilation. Le paquet est
 maintenant accessible publiquement à <url id="&url-incoming;"> (une telle
 adresse n'existe pas pour les paquets de l'archive non-US) jusqu'à ce qu'il
 soit vraiment installé dans l'archive Debian. Ceci se produit seulement une
 fois par jour, le paquet est alors supprimé de <file>Incoming</file> et
 installé dans le pool avec les autres paquets. Une fois que toutes les autres
 mises à jour (générant des nouveaux fichiers d'index <file>Packages</file> et
 <file>Sources</file> par exemple) ont été effectuées, un script spécial est
 appelé pour demander aux miroirs primaires de se mettre à jour.
<p>
Le logiciel de maintenance de l'archive enverra également le fichier
<file>.changes</file> signé avec OpenPGP/GnuPG que vous avez envoyé, à la liste
de diffusion appropriée. Si un paquet est diffusé avec le champ
<tt>Distribution:</tt> positionné à «&nbsp;stable&nbsp;», l'annonce sera envoyée
à &email-debian-changes;. Si un paquet est diffusé avec le champ
<tt>Distribution:</tt> positionné à «&nbsp;unstable&nbsp;» ou
«&nbsp;experimental&nbsp;», l'annonce sera à la place envoyée à
&email-debian-devel-changes;.
<p>
Tous les développeurs Debian ont un droit d'écriture dans le répertoire
 <file>unchecked</file> pour pouvoir y envoyer leurs paquets, ils ont également
 accès au répertoire <file>reject</file> pour supprimer les mauvais envois ou
 déplacer certains fichiers dans le répertoire <file>unchecked</file>. Mais 
 seuls les ftpmasters ont droit d'écriture dans les autres répertoires.
 C'est pourquoi vous ne pouvez pas supprimer un envoi une fois qu'il a été
 accepté.

      <sect1 id="delayed-incoming">Incoming différé
<p>
Le répertoire <file>unchecked</file> comprend un sous-répertoire spécial,
 <file>DELAYED</file><footnote>Différé en anglais</footnote>. Celui-ci est
 lui-même subdivisé en neuf répertoires nommés <file>1-day</file> à
 <file>9-day</file>. Les paquets qui sont envoyés dans l'un de ces
 répertoires seront déplacés dans le vrai répertoire <file>unchecked</file>
 après le nombre correspondant de jours. Un script, exécuté chaque jour, 
déplace les paquets entre les répertoires. Ceux
 qui sont dans «&nbsp;1-day&nbsp;» sont installés dans
 <file>unchecked</file> alors que les autres sont déplacés dans le
 répertoire adjacent (par exemple, un paquet dans <file>5-day</file> sera
 déplacé dans <file>4-day</file>). Cette fonctionnalité est particulièrement
 utile pour les personnes qui effectuent des mises à jour indépendantes
 (NMU, «&nbsp;non-maintainer uploads&nbsp;»). Au lieu d'attendre avant
 d'envoyer la NMU, elle est envoyée dès qu'elle est prête dans l'un de ces
 répertoires <file>DELAYED/<var>x</var>-day</file>. Ceci laisse le nombre
 correspondant de jours au responsable pour réagir et envoyer lui-même une
 autre correction s'il n'est pas complètement satisfait par la NMU. Il peut
 également enlever complètement la NMU.
<p>
L'utilisation de ce délai peut être simplifiée en
 l'intégrant à votre outil d'envoi. Par exemple, si vous utilisez
 <prgn>dupload</prgn> (voir <ref id="dupload">), vous pouvez ajouter cette
 partie à votre fichier de configuration&nbsp;:
<example>
$delay = ($ENV{DELAY} || 7);
$cfg{'delayed'} = {
         fqdn => "&ftp-master-host;",
         login => "yourdebianlogin",
         incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/",
         dinstall_runs => 1,
         method => "scpb"
};</example>
Une fois que vous avez fait ce changement, <prgn>dupload</prgn> peut être
utilisé pour envoyer facilement dans l'un des répertoires de délai ainsi&nbsp;:
<example>DELAY=5 dupload --to delayed &lt;changes-file&gt;</example>


    <sect id="testing">
        <heading>La distribution «&nbsp;testing&nbsp;»
<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. Ils génèrent 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>
L'inclusion d'un paquet d'<em>unstable</em> est soumise aux
 conditions suivantes&nbsp;:
<list compact="compact">
<item><p>Le paquet doit avoir été disponible dans <em>unstable</em> depuis
      plusieurs jours&nbsp;; le nombre précis dépend du champ d'urgence de
      l'envoi. Il s'agit de 10 jours pour une urgence faible, 5 jours pour une
      urgence moyenne et 2 jours pour une urgence élevée. Ces délais peuvent
      être doublés lors d'un gel de distribution&nbsp;;</item>
<item><p>Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
      version disponible dans <em>testing</em>&nbsp;;</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&nbsp;;</item>
<item><p>Il ne doit pas casser les dépendances d'un paquet qui est déjà
      disponible dans <em>testing</em>&nbsp;;</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 eux-mêmes respecter tous ces
      critères).</item>
</list>
<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 name="page web de la distribution testing"
id="&url-testing-maint;"> ou utilisez le programme <prgn>grep-excuses</prgn>
inclus dans le paquet <package>devscripts</package>. Si l'on veut rester 
informé de la progression de ses paquets dans <em>testing</em>, on peut 
facilement le mettre dans la <manref
 section="5" name="crontab">.
<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>
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. Dans ce cas, le responsable de version doit être contacté et il forcera
 l'inclusion du paquet.
        <p>
En général, veuillez vous référer à la <url name="page web de la distribution testing"
id="&url-testing-maint;"> pour plus d'informations. Cette page inclut également
des réponses aux questions fréquemment posées.


    <sect id="pkg-info">Informations sur un paquet
<p>

      <sect1 id="pkg-info-web">Sur le web
<p>
Chaque paquet a plusieurs pages web dédiées.
 <tt>http://&packages-host;/<var>package-name</var></tt> affiche chaque version
 du paquet disponible dans les différentes distributions. Les informations
 détaillées par version incluent la description du paquet, les dépendances et
 des liens pour récupérer le paquet.
<p>
Le système de suivi des bogues trie les bogues par paquet. Vous pouvez regarder
 les bogues de chaque paquet à
 <tt>http://&bugs-host;/<var>package-name</var></tt>.

      <sect1 id="madison">L'outil <prgn>madison</prgn>
<p>
<prgn>madison</prgn> est un outil en ligne de commande qui est disponible sur
 <tt>&ftp-master-host;</tt> et sur <tt>&non-us-host;</tt>. Il utilise un seul
 argument qui correspond au nom du paquet. Il affiche comme résultat quelle
 version du paquet est disponible pour chaque combinaison d'architecture et de
 distribution. Un exemple l'expliquera mieux.
<p>
<example>
$ madison libdbd-mysql-perl
libdbd-mysql-perl |   1.2202-4 |        stable | source, alpha, arm, i386, m68k, powerpc, sparc
libdbd-mysql-perl |   1.2216-2 |       testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
libdbd-mysql-perl | 1.2216-2.0.1 |       testing | alpha
libdbd-mysql-perl |   1.2219-1 |      unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc</example>
<p>
Dans cet exemple, vous pouvez voir que la version dans <em>unstable</em> diffère
 de celle de <em>testing</em> et qu'il y a eu une NMU binaire seulement pour
 l'architecture alpha. À chaque fois, le paquet a été recompilé sur la plupart
 des architectures.


    <sect id="pkg-tracking-system">Système de suivi des paquets
<!-- FIXME: talk about 
http://qa.debian.org/developer.php?login=aph@debian.org
http://packages.qa.debian.org/
http://packages.qa.debian.org/pkgname -->
<p>
Le système de suivi des paquets (PTS)<footnote>«&nbsp;Package Tracking
 System&nbsp;»</footnote> est un outil pour suivre par courrier l'activité
 concernant un paquet source. Il suffit simplement de s'inscrire à un
 paquet source pour recevoir les courriers liés à celui-ci. Vous
 recevrez les mêmes courriers que le responsable. Chaque courrier envoyé par le
 PTS est classé et associé à l'un des mots-clés listés ci-dessous. Ceci vous
 permettra de sélectionner les courriers que vous voulez recevoir.
<p>
Par défaut, vous recevrez&nbsp;:
<taglist>
  <tag><tt>bts</tt>
  <item>Tous les rapports de bogue et les discussions qui
        suivent.

  <tag><tt>bts-control</tt>
  <item>Les courriers de contrôle notifiant le changement d'état de l'un des
        bogues.

  <tag><tt>upload-source</tt>
  <item>Le courrier de confirmation de <prgn>katie</prgn> quand un paquet
        source envoyé a été accepté.

  <tag><tt>katie-other</tt>
  <item>Les autres courriers d'avertissement et d'erreur de
        <prgn>katie</prgn> (comme une incohérence de forçage pour les champs
        section ou priorité).

  <tag><tt>default</tt>
  <item>Tout courrier non automatique envoyé au PTS par les personnes qui
        veulent contacter les inscrits au paquet.

  <tag><tt>summary</tt>
  <item>À l'avenir, vous pourriez recevoir des courriers de résumé pour vous
        tenir informé de l'état du paquet (statistiques sur les bogues, vue
        générale du portage, progression dans <em>testing</em>,
        etc.).
</taglist>

<p>
Vous pouvez également décider de recevoir plus d'informations&nbsp;: 
<taglist>
  <tag><tt>upload-binary</tt>
   <item>Le courrier d'information de <prgn>katie</prgn> quand un paquet
        binaire envoyé est accepté (pour vérifier que votre paquet est
        recompilé pour toutes les architectures).

  <tag><tt>cvs</tt>
  <item>Les modifications CVS<footnote><p><em>CVS commits</em></footnote> si le
        responsable a mis en place un système pour faire suivre les
        notifications de modifications vers le PTS.

   <tag><tt>ddtp</tt>
   <item>Les traductions des descriptions ou des questionnaires debconf soumis
         au Projet de traduction des descriptions de paquets
         Debian<footnote><p><em>Debian Description Translation Project,
         DDTP</em></footnote>

</taglist>

        <sect1 id="pts-commands">L'interface de courrier du PTS
<p>
Vous pouvez contrôler votre (vos) inscription(s) au PTS en envoyant différents
 commandes à <email>pts@qa.debian.org</email>.

<taglist>
  <tag><tt>subscribe &lt;srcpackage&gt; [&lt;email&gt;]</tt>
  <item>Inscrit <var>email</var> aux communications liées au paquet source
        <var>srcpackage</var>. L'adresse de l'expéditeur est utilisée si le
        second argument n'est pas présent. Si <var>srcpackage</var> n'est pas
        un paquet source valide, vous obtiendrez un avertissement. Cependant,
        s'il s'agit d'un paquet binaire valide, le PTS vous inscrira pour le
        paquet source correspondant.

  <tag><tt>unsubscribe &lt;srcpackage&gt; [&lt;email&gt;]</tt>
  <item>Supprime une inscription précédente au paquet source
        <var>srcpackage</var> en utilisant l'adresse spécifiée ou l'adresse de
        l'expéditeur si le second argument n'est pas rempli.

  <tag><tt>which [&lt;email&gt;]</tt>
  <item>Liste les inscriptions pour l'expéditeur ou pour l'adresse indiquée
        si elle est spécifiée.

  <tag><tt>keyword [&lt;email&gt;]</tt>
  <item>Donne les mots-clés que vous acceptez. Chaque courrier envoyé par le
        PTS est associé à un mot-clé et vous ne recevez que les courriers associés
        aux mots-clés que vous avez acceptés. Voici la liste des mots-clés
        disponibles&nbsp;:
        <list>
        <item><tt>bts</tt>&nbsp;: courriers venant du système de gestion de bogues (BTS) Debian
        <item><tt>bts-control</tt>&nbsp;: réponses aux courriers envoyés à
              &bugs-host;&email-bts-control;
        <item><tt>summary</tt>&nbsp;: courriers de résumé automatique sur l'état
              d'un paquet
        <item><tt>cvs</tt>&nbsp;: notifications de modifications CVS
        <item><tt>ddtp</tt>&nbsp;: traductions des descriptions et
              questionnaires debconf
        <item><tt>upload-source</tt>&nbsp;: annonce d'un nouvel envoi de paquet
              source qui a été accepté
        <item><tt>upload-binary</tt>&nbsp;: annonce d'un nouvel envoi de binaire
              seulement (portage)
        <item><tt>katie-other</tt>&nbsp;: autres courriers des ftpmasters
              (incohérence de forçage, etc.)
        <item><tt>default</tt>&nbsp;: tous les autres courriers (ceux qui ne sont
              pas automatiques)
        </list>

  <tag><tt>keyword &lt;srcpackage&gt; [&lt;email&gt;]</tt>
  <item>Identique à l'élément précédent, mais pour un paquet source donné
        car vous pouvez sélectionner un ensemble de mots-clés différent pour
        chaque paquet source.

  <tag><tt>keyword [&lt;email&gt;] {+|-|=} &lt;list of keywords&gt;</tt>
  <item>Accepte (+) ou refuse (-) les courriers associés au(x) mot(s)-clé(s).
        Définit la liste (=) des mots-clés acceptés.

  <tag><tt>keyword &lt;srcpackage&gt; [&lt;email&gt;] {+|-|=} &lt;list of keywords&gt;</tt>
  <item>Identique à l'élément précédent, mais remplace la liste des mots-clés
        pour le paquet source indiqué.

  <tag><tt>quit | thanks | --</tt>
  <item>Arrête le traitement des commandes. Toutes les lignes suivantes sont
        ignorées par le robot.
</taglist>

        <sect1 id="pts-mail-filtering">Filtrer les courriers du PTS
<p>
Une fois que vous vous êtes inscrit à un paquet, vous recevrez les courriers
 envoyés à <tt><var>srcpackage</var>@packages.qa.debian.org</tt>. Ces courriers
 ont des en-têtes spéciaux ajoutés pour vous permettre de les filtrer dans des
 boîtes aux lettres avec <prgn>procmail</prgn>. Les en-têtes ajoutés sont
 <tt>X-Loop</tt>, <tt>X-PTS-Package</tt>, <tt>X-PTS-Keyword</tt> et
 <tt>X-Unsubscribe</tt>.
<p>
Voici un exemple d'en-têtes ajoutés pour une notification d'envoi de
source sur le paquet <package>dpkg</package>&nbsp;:
<example>
X-Loop: dpkg@&pts-host;
X-PTS-Package: dpkg
X-PTS-Keyword: upload-source
X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
</example>

        <sect1 id="pts-cvs-commit">Faire suivre les modifications de CVS vers le PTS
<p>
Si vous utilisez un référentiel CVS accessible publiquement pour maintenir votre
 paquet Debian, vous pouvez vouloir faire suivre les notifications de
 modifications vers le PTS pour que les inscrits (par exemple, des
 co-responsables) puissent suivre de près l'évolution du paquet.
<p>
C'est très facile à mettre en place. Une fois que votre référentiel génère des
 notifications de modifications, vous devez simplement vous assurer qu'il envoie une
 copie de tous ces courriers à <tt><var>srcpackage</var>_cvs@&pts-host;</tt>.
 Seules les personnes qui ont accepté le mot-clé <em>cvs</em> recevront les
 notifications.


    <sect id="ddpo">Vue d'ensemble des paquets d'un développeur
<p>
Un portail web pour l'Assurance Qualité (QA) est disponible à <url
 id="&url-ddpo;"> qui affiche un tableau de tous les paquets d'un
 développeur (y compris ceux pour lequel il est co-responsable). Le tableau donne
 un bon résumé sur les paquets d'un développeur&nbsp;: nombre de bogues par
 gravité, liste des versions disponibles, état des tests et des liens vers
 d'autres informations utiles.
<p>
C'est une bonne idée de vérifier régulièrement vos données pour ne pas oublier
 de bogues ouverts et pour ne pas oublier quels paquets sont sous votre
 responsabilité.


   <chapt id="pkgs">Gestion des paquets
<p>
Ce chapitre contient des informations relatives à la création, l'envoi, la
 maintenance et le portage des paquets.


    <sect id="newpackage">Nouveaux paquets
<p>
Si vous voulez créer un nouveau paquet pour la distribution Debian, vous devriez
 commencer par consulter la liste des <url id="&url-wnpp;" name="paquets en
 souffrance et paquets souhaités">. Vous pourrez ainsi vérifier que personne ne
 travaille déjà sur ce paquet et éviter un double travail. Consultez aussi cette
 page si vous voulez en savoir plus.
<p>
Supposons que personne ne travaille sur le paquet que vous visez, vous devez
 alors envoyer un rapport de bogue (voir <ref id="submit-bug">) concernant le
 pseudo-paquet <package>wnpp</package>. Ce courrier devra décrire le paquet que
 vous projetez de créer, la licence de ce paquet et l'URL à laquelle le source
 peut être téléchargé. Cette liste n'est pas limitative.
<p>
Le sujet de votre rapport de bogue devra être &lt;ITP<footnote><p><em>Intent To
 Package</em>&nbsp;: intention de mise en paquet</footnote>&nbsp;:
 <var>NomDuPaquet</var> &mdash; <var>courte description</var>&gt;, en remplaçant
 <var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera
 <em>wishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
 &email-debian-devel; en mettant cette adresse dans le champ
 <tt>X-Debbugs-CC:</tt> de l'en-tête du message. N'utilisez pas le champ
 <tt>CC:</tt> car de cette manière le sujet du message ne contiendrait pas le
 numéro du bogue.
<p>
Il faudra aussi ajouter une entrée <tt>Closes: bug#<var>nnnnn</var></tt> dans le
 fichier <file>changelog</file> du nouveau paquet. Cette indication fermera
 automatiquement le rapport de bogue à l'installation du nouveau paquet sur les
 serveurs d'archivage (voir <ref id="upload-bugfix">).
<p>
Plusieurs raisons nous poussent à demander aux responsables
 d'annoncer leur intention&nbsp;:
<list compact>
<item>Les responsables ont ainsi la possibilité de puiser dans l'expérience
      des autres responsables et cela leur permet de savoir si une autre
      personne travaille déjà dessus.
<item>D'autres personnes qui envisagent de travailler sur le même paquet
      apprendront ainsi qu'il existe déjà un volontaire, l'effort peut alors
      être partagé.</item>
<item>Cela permet aux autres responsables de connaître le nouveau
      paquet mieux que ne le permettent la description d'une ligne et l'habituelle
      entrée de type changelog <em>Initial release</em> postée sur
      <tt>debian-devel-changes</tt>.
<item>C'est une information utile pour
      les gens qui utilisent la distribution <em>unstable</em> et qui sont nos
      premiers testeurs. Nous devons faciliter la tâche de ces gens.
<item>Avec ces annonces, les développeurs Debian et toutes les autres personnes
      intéressées peuvent se faire une meilleure idée des évolutions et des
      nouveautés du projet.
</list>


      <sect id="changelog-entries">Enregistrer les modifications dans le paquet
<p>
Les modifications que vous apportez au paquet doivent être notifiées dans le
   fichier <file>debian/changelog</file>. Ces notes doivent donner une
   description concise des changements, expliquer les raisons de ceux-ci (si
   ce n'est pas clair) et indiquer si des rapports de bogue ont été clos. Il
   faut aussi indiquer quand le paquet a été terminé. Ce fichier sera
   installé dans
   <file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
   <file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un paquet
   natif.
<p>
Le fichier <file>debian/changelog</file> a une structure précise comportant
   différents champs. Le champ <em>distribution</em> est décrit dans <ref
   id="distribution">. Vous trouverez plus d'informations sur la structure de ce
   fichier dans la section «&nbsp;<file>debian/changelog</file>&nbsp;» de la
   <em>charte Debian</em>.
<p>
Les entrées du fichier <file>changelog</file> peuvent être
   utilisées pour fermer des rapports de bogue au moment où le paquet est
   installé dans l'archive. Voir la section <ref id="upload-bugfix">.
<p>
Par convention, l'entrée changelog d'un paquet qui contient une nouvelle version
   amont ressemble à&nbsp;:
<example>
  * new upstream version
</example>
<p>
Quelques outils peuvent vous aider à créer des entrées et à finaliser le fichier
   <file>changelog</file> pour une livraison &mdash; voir les sections <ref
   id="devscripts"> et <ref id="dpkg-dev-el">.
<p>
Voir aussi <ref id="bpp-debian-changelog">.


      <sect id="sanitycheck">Tester le paquet
<p>
Avant d'envoyer votre paquet, vous devriez faire quelques tests de base. Vous
   devriez au moins faire les tests suivants (il vous faut une ancienne version
   du paquet)&nbsp;:
<list>
<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&nbsp;: <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
      <ref id="lintian">.
<item>Vous pouvez facultativement exécuter <ref id="debdiff"> pour analyser les
      modifications depuis une ancienne version si celle-ci existe.
<item>Faites régresser le paquet vers sa version précédente si elle existe
      &mdash; cela permet de tester les scripts <file>postrm</file> et
      <file>prerm</file>.
<item>Désinstallez le paquet et réinstallez-le.
</list>


<sect id="sourcelayout">Disposition du paquet source
<p>
Il existe deux types de paquets sources Debian&nbsp;:
          <list>
          <item>les paquets soi-disant appelés <em>natifs</em> pour lesquels il
                n'y a pas de distinction entre les sources d'origine et les
                correctifs appliqués pour Debian
          <item>les paquets (plus courants) où il y a un fichier archive source
                d'origine accompagné par un autre fichier contenant les
                correctifs pour Debian.
          </list>
<p>
Pour les paquets natifs, le paquet source inclut un fichier de contrôle source
Debian (<tt>.dsc</tt>) et l'archive source (<tt>.tar.gz</tt>). Un paquet source
d'un paquet non natif inclut un fichier de contrôle source Debian, l'archive
source d'origine (<tt>.orig.tar.gz</tt>) et les correctifs Debian
(<tt>.diff.gz</tt>).
<p>
Le caractère natif d'un paquet est déterminé lorsqu'il est construit par <manref
name="dpkg-buildpackage" section="1">. Le reste de cette section ne se rapporte
qu'aux paquets non natifs.

<p>
La première fois qu'un paquet est installé dans l'archive pour une version amont
   donnée, le fichier <file>tar</file> de cette version amont doit être
   téléchargé et mentionné dans le fichier <file>.changes</file>. Par la suite,
   ce fichier <file>tar</file> sera utilisé pour générer les fichiers
   <file>diff</file> et <file>.dsc</file> 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 <file>tar</file> 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 <file>tar</file> des sources
   originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
   fichiers <file>.dsc</file> et <file>diff</file> de la mise à jour, utiliser
   un fichier <tt>tar</tt> identique à l'octet près à celui déjà présent dans
   l'archive.

        <sect1 id="distribution">Choisir une distribution
<p>
Chaque envoi doit spécifier à quelle distribution le paquet est destiné. Le
processus de construction de paquet extrait cette information à partir de la
première ligne du fichier <file>debian/changelog</file> et la place dans le champ
<tt>Distribution</tt> du fichier <tt>.changes</tt>.
<p>
Il existe plusieurs valeurs possibles pour ce champ&nbsp;: «&nbsp;stable&nbsp;»,
    «&nbsp;unstable&nbsp;», «&nbsp;testing-proposed-updates&nbsp;» et
    «&nbsp;experimental&nbsp;».
<p>
En fait, il y a deux autres possibilités&nbsp;:
    «&nbsp;stable-security&nbsp;» et «&nbsp;testing-security&nbsp;», mais
    veuillez lire <ref id="bug-security"> pour plus d'informations sur celles-ci.
<p>
Il est techniquement possible d'envoyer un paquet dans plusieurs distributions
   en même temps, mais ceci n'a habituellement aucun sens d'utiliser cette
   fonctionnalité car les dépendances d'un paquet peuvent varier selon les
   distributions. En particulier, il est absurde de combiner la distribution
   <em>experimental</em> avec tout autre chose.

          <sect1 id="upload-stable">Mise à jour d'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 <file>stable-proposed-updates</file> 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> requiert des soins
     supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
     que dans les cas suivants&nbsp;:
<list>
<item>un problème de sécurité (un avis de sécurité Debian<footnote>Debian
      security advisory</footnote>),
<item>un problème 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 provoquer un
     bogue. Livrer une nouvelle version amont d'un logiciel pour
     corriger un problème de sécurité est désapprouvé&nbsp;; dans la plupart
     des cas, la bonne solution consiste à prendre le correctif correspondant de
     la nouvelle version amont et à l'appliquer à l'ancienne (faire un
     rétroportage<footnote><em>backport</em></footnote> du correctif).
<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>&nbsp;;
     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>stable-proposed-updates</em> et
     décidera si votre paquet peut être inclus dans la distribution
     <em>stable</em>. Soyez précis (et, si nécessaire, prolixe) quand vous
     décrivez, dans le fichier changelog, vos changements pour une livraison
     vers <em>stable</em>, sinon le paquet ne sera pas pris en considération.

    <sect1 id="upload-t-p-u">Mise à jour d'un paquet de la distribution
    <em>testing-proposed-updates</em>
<p>
La distribution <em>testing</em> est peuplée avec des paquets en provenance
     d'<em>unstable</em> selon des règles expliquées dans <ref id="testing">.
     Cependant, le responsable de distribution peut stopper les scripts de
     <em>testing</em> quand il veut geler la distribution. Dans ce cas, vous
     pouvez envoyer vos paquets vers <em>testing-proposed-updates</em> pour
     fournir des paquets corrigés durant le gel.
<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 du responsable de distribution, vous
     devriez lire les instructions données qu'il envoie 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 dans
     <em>unstable</em>), vous pouvez l'utiliser, mais il est recommandé de
     demander l'autorisation du responsable de distribution auparavant.


      <sect id="upload">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-host;</ftpsite>, ce que vous devriez déjà 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
   &us-upload-dir;. Si vous utilisez un FTP anonyme, placez-les dans
   &upload-queue;. Attention, il est préférable de transférer le fichier
   <tt>changes</tt> en dernier. Dans le cas contraire, 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 &us-upload-dir;.
<p>
<em>Note&nbsp;:</em> ne téléchargez pas sur <tt>ftp-master</tt> de paquet
   concernant la cryptographie qui appartiendrait à <em>contrib</em> ou <em>non-free</em>.
   Ces logiciels doivent aller sur <tt>non-us</tt> (voir <ref
   id="upload-non-us">). De plus, les paquets contenant un logiciel protégé par
   des brevets américains ne peuvent pas être envoyés sur
   <tt>ftp-master</tt>&nbsp;; selon le cas, ils peuvent peut-être pourtant être
   envoyés vers <file>non-US/non-free</file> (le paquet est dans
   <em>non-free</em> à cause de problèmes de distribution et non pas à cause de
   la licence du logiciel). 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>. 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 <ref id="dupload"> ou <ref id="dput"> pourront vous faciliter le
   travail lors du téléchargement. Ces programmes, bien pratiques, aident à
   automatiser le processus d'envoi de paquets vers Debian
<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>&nbsp;: 
<example>dinstall -n foo.changes</example>
<p>
Notez que <prgn>dput</prgn> peut le faire automatiquement pour vous.

        <sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
<p>
Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
   exportations américaines 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 &non-us-upload-dir;
   (<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 &upload-queue;.
<p>
Tout comme sur <tt>ftp-master</tt>, vous pouvez vérifier votre téléchargement
   avec&nbsp;: <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à disponibles 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 &mdash; il ne doit pas dépendre de <em>non-US/main</em> &mdash; peut
   être téléchargé sur <tt>ftp-master</tt> ou l'une de ses files d'attente
   décrites plus haut.
<p>
La <em>charte Debian</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
   <file>Incoming</file> 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>&nbsp;; 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&nbsp;: il vous suffit
   d'ouvrir une connexion anonyme sur <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 <file>Incoming</file> 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
   <file>.changes</file> 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 <file>.changes</file>
   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>&nbsp;; 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>&nbsp;; consultez la documentation de ce programme pour en
   savoir plus.

        <sect1>Les autres serveurs
<p>
Un autre serveur est disponible aux États-Unis&nbsp;; 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&nbsp;: téléchargez vos paquet par FTP
   anonyme sur <url id="&url-upload-jp;">.

      <sect1 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> sont installées
 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
 patient.
<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 bogue 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 ci-dessous).


        <sect id="override-file">Déterminer la section et la priorité d'un paquet
<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 pourrez vouloir 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 les <em>fichiers override</em>, reportez-vous à <manref
name="dpkg-scanpackages" section="8"> et <url
id="&url-bts-devel;#maintincorrect">.
        <p>
Notez également que le terme «&nbsp;section&nbsp;» est utilisé pour la
 séparation des paquets selon leur licence, e.g <em>main</em>, <em>contrib</em>
 et <em>non-free</em>. Ceci est décrit dans une autre section, <ref
 id="archive">.


    <sect id="bug-handling">Gérer les bogues
<p>
Chaque développeur doit être capable de travailler avec le <url name="système de
suivi des bogues" id="&url-bts;"> Debian. Il faut savoir comment remplir
des rapports de bogue correctement (voir <ref id="submit-bug">), comment les
mettre à jour et les réordonner et comment les traiter et les fermer.
<p>
Les fonctionnalités du système de suivi des bogues qui intéressent les
développeurs sont décrites dans la <url id="&url-bts-devel;" name="documentation
du BTS pour les développeurs">. Ceci inclut la fermeture des bogues, l'envoi des
messages de suivi, l'assignation des niveaux de gravité, des marques,
l'indication que les bogues ont été envoyés au développeur amont et autres
problèmes.
<p>
Des opérations comme réassigner des bogues à d'autres paquets, réunir des
rapports de bogues séparés traitant du même problème ou réouvrir des bogues
quand ils ont été prématurément fermés, sont gérées en utilisant le serveur de
courrier de contrôle. Toutes les commandes disponibles pour ce serveur sont
décrites dans la <url id="&url-bts-control;" name="documentation du serveur de
contrôle du BTS">.

      <sect1 id="bug-monitoring">Superviser les rapports de bogue
<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. Vous pouvez les vérifier avec
 cette page&nbsp;: <tt>http://&bugs-host;/<var>yourlogin</var>@debian.org</tt>.
<p>
Les responsables interagissent avec le système de suivi des bogues en utilisant
 l'adresse électronique <tt>&bugs-host;</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&nbsp;:
<example>
# Synthèse hebdomadaire des rapports de bogue qui me concernent
&cron-bug-report;
</example>
Remplacez <var>address</var> par votre adresse officielle de responsable Debian.

      <sect1 id="bug-answering">Répondre à des rapports de bogue
<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-host;</email>
 par exemple). Si vous rédigez un nouveau courrier et que vous ne vous souvenez
 plus de l'adresse du rapporteur de bogue, vous pouvez utiliser l'adresse
 <email>123-submitter@&bugs-host;</email> pour contacter le rapporteur
 <em>et</em> enregistrer votre courrier dans le journal du bogue (ce qui veut
 dire que vous n'avez pas besoin d'envoyer une copie du courrier à
 <email>123@&bugs-host;</email>).
<p>
Une fois que vous avez traité un rapport de bogue (i.e. que vous l'avez
 corrigé), marquez-le comme <em>done</em> (fermez-le) en envoyant un message
 d'explication à <email>123-done@&bugs-host;</email>. Si vous corrigez un
 bogue en changeant et en envoyant une nouvelle versions du paquet, vous pouvez
 fermer le bogue automatiquement comme décrit dans <ref id="upload-bugfix">.
<p>
Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la commande
 <tt>close</tt> à l'adresse &email-bts-control;.Si vous le faites, le rapporteur
 n'aura aucune information sur la clôture de son rapport.

      <sect1 id="bug-housekeeping">Gestion générale des bogues
<p>
En tant que responsable de paquet, vous trouverez fréquemment des bogues dans
 d'autres paquets ou vous aurez des bogues sur vos paquets qui sont en fait des
 bogues sur d'autres paquets. Les fonctions intéressantes du système de suivi
 des bogues pour les développeurs sont décrites dans la <url
 id="&url-bts-devel;" name="documentation du BTS pour les développeurs Debian">.
 Les <url id="&url-bts-control;" name="instructions du serveur de contrôle du
 BTS"> documentent les opérations techniques du BTS, telles que comment remplir,
 réassigner, regrouper et marquer des bogues. Cette section contient des lignes
 directrices pour gérer vos propres bogues, définies à partir de l'expérience
 collective des développeurs Debian.
<p>
Remplir des rapports de bogue pour des problèmes que vous trouvez dans d'autres
 paquet est l'une des «&nbsp;obligations civiques&nbsp;» du responsable,
 reportez-vous à <ref id="submit-bug"> pour les détails. Cependant, gérer les
 bogues de vos propres paquets est encore plus important.
<p>
Voici une liste des étapes que vous pouvez suivre pour gérer un rapport de
 bogue&nbsp;:
<enumlist>
  <item>
        Décider si le rapport correspond à un bogue réel ou non. Parfois, les
        utilisateurs exécutent simplement un programme de la mauvaise façon car
        ils n'ont pas lu la documentation. Si c'est votre diagnostic, fermez
        simplement le bogue avec assez d'informations pour laisser l'utilisateur
        corriger son problème (donnez des indications vers la bonne
        documentation et ainsi de suite). Si le rapport de bogue revient
        régulièrement, vous devriez vous demander si la documentation est assez
        bonne ou si le programme ne devrait pas détecter une mauvaise
        utilisation pour donner un message d'erreur informatif. Il s'agit d'un
        problème qui peut être présenté à l'auteur amont.
        <p>
        Si le rapporteur de bogue n'est pas d'accord avec votre décision de
        fermeture du bogue, il peut le ré-ouvrir jusqu'à ce que vous trouviez un
        accord sur la façon de le gérer. Si vous n'en trouvez pas, vous pouvez
        marquer le bogue avec <tt>wontfix</tt> pour indiquer aux personnes que
        le bogue existe, mais ne sera pas corrigé. Si cette situation n'est pas
        acceptable, vous (ou le rapporteur) pouvez vouloir demander une décision
        par le comité technique en réattribuant le bogue à
        <package>tech-ctte</package> (vous pouvez utiliser la commande
        <tt>clone</tt> du BTS si vous désirez garder le bogue comme rapporté sur
        votre paquet). Avant de faire cela, veuillez lire la <url
        id="&url-tech-ctte;" name="procédure recommandée">.
  </item>
  <item>
        Si le bogue est réel, mais est causé par un autre paquet,
        réattribuez simplement le bogue à l'autre paquet. Si vous ne savez pas à
        quel paquet il doit être réattribué, vous pouvez demander de l'aide sur
        &email-debian-devel; ou vous pouvez le réattribuer à
        <package>debian-policy</package> pour les laisser décider dans quel
        paquet est située l'erreur.
        <p>
        Parfois, vous devez également ajuster la gravité du bogue pour qu'elle
        corresponde à notre définition de gravité des bogues. C'est dû au
        fait que les gens tendent à augmenter la gravité des bogues pour
        s'assurer que leurs bogues seront corrigés rapidement. La gravité de
        certains bogues peut même être rétrogradée en <em>wishlist</em> (souhait)
        quand le changement demandé est seulement d'ordre cosmétique.
  </item>
  <item>
        Le rapporteur de bogue peut avoir oublié de fournir certaines
        informations. Dans ce cas, vous devez lui demander les informations
        nécessaires. Vous pouvez utiliser la marque <tt>moreinfo</tt> (plus
        d'information) sur le bogue. De plus, si vous ne pouvez pas reproduire le
        bogue, vous pouvez le marquer comme <tt>unreproducible</tt> (non
        reproductible). Une personne qui arriverait à reproduire le bogue est
        alors invitée à fournir plus d'informations sur la façon de le
        reproduire. Après quelques mois, si cette information n'a été envoyée
        par personne, le bogue peut être fermé.
  </item>
  <item>
        Si le bogue est lié à l'empaquetage, vous devez simplement le
        corriger. Si vous ne pouvez pas le corriger vous-même, marquez alors le
        bogue avec <tt>help</tt> (aide). Vous pouvez également demander de
        l'aide sur &email-debian-devel; ou &email-debian-qa;. S'il s'agit d'un
        problème amont, vous devez faire suivre le rapport à l'auteur amont.
        Faire suivre un bogue n'est pas suffisant, vous devez vérifier à chaque
        version si le bogue a été corrigé ou non. S'il a été corrigé, vous le
        fermez simplement, sinon vous devez le rappeler à l'auteur. Si vous avez
        les compétences nécessaires, vous pouvez préparer un correctif pour
        corriger le bogue et l'envoyer en même temps à l'auteur. Assurez-vous
        d'envoyer le correctif au BTS et marquez le bogue avec <tt>patch</tt>
        (correctif).
  </item>
  <item>
        Si vous avez corrigé un bogue sur votre copie locale ou si un correctif
        a été inclus dans le référentiel CVS, vous pouvez marquer le bogue avec
        <tt>pending</tt> (en attente) pour informer que le bogue est corrigé et
        qu'il sera fermé lors du prochain envoi (ajoutez le <tt>closes:</tt>
        dans le <file>changelog</file>). C'est particulièrement utile si
        plusieurs développeurs travaillent sur le même paquet.
  </item>
  <item>
        Une fois que le paquet corrigé est disponible dans la distribution
        <em>unstable</em>, vous pouvez fermer le bogue. Ceci peut être fait
        automatiquement, pour cela, reportez-vous à <ref id="upload-bugfix">.
  </item>
</enumlist>

      <sect1 id="upload-bugfix">Quand les rapports de bogue sont-ils fermés par
      une mise à jour&nbsp;?
<p>
Au fur et à mesure que les bogues et problèmes sont corrigés dans vos paquets,
 il est de votre responsabilité de fermer le rapport de bogue associé.
 Cependant, 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>
Cependant, il est possible d'éviter d'avoir à fermer manuellement les bogues
 après l'envoi &mdash; indiquez simplement les bogues corrigés dans le fichier
 <file>changelog</file> en suivant une syntaxe précise. Par exemple&nbsp;:

<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 man page. Closes: #98725.
</example>

Techniquement parlant, l'expression rationnelle Perl suivante décrit comment les
lignes de <em>changelogs</em> de fermeture de bogues sont identifiées&nbsp;:

<example>
  /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
</example>

Nous préfèrons la syntaxe <tt>closes: #<var>XXX</var></tt>, car c'est l'entrée
la plus concise et la plus facile à intégrer dans le texte du fichier
<file>changelog</file>.
<p>
Si vous entrez un numéro de bogue incorrect ou si vous oubliez un bogue dans les
 entrées du fichier <file>changelog</file>, n'hésitez pas à annuler tout dommage
 que l'erreur a entraîné. Pour réouvrir un bogue fermé par erreur, envoyez une
 commande <tt>reopen <var>XXX</var></tt> à l'adresse de contrôle du système de
 suivi des bogues, &email-bts-control;. Pour fermer tous les bogues restants qui
 ont été corrigés par votre envoi, envoyez le fichier <file>.changes</file> à
 <email>XXX-done@&bugs-host;</email> où <var>XXX</var> est le numéro du
 bogue.
<p>
Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en utilisant le
 <file>changelog</file> tel que décrit ci-dessus. Si vous désirez simplement
 fermer les bogues qui n'ont rien à voir avec l'un de vos envois, faites-le
 simplement en envoyant une explication à
 <email>XXX-done@&bugs-host;</email>. Vous <strong>ne devez pas</strong> pas
 fermer des bogues dans une entrée de changelog d'une version si les
 changements dans cette version n'ont rien à voir avec le bogue.
<p>
Pour une information plus générale sur ce qu'il faut mettre dans les entrées de
changelog, veuillez vous reporter aux <ref id="bpp-debian-changelog">.

      <sect1 id="bug-security">Gérer les bogues de sécurité
<p>
À cause de leur nature sensible, les bogues liés à la sécurité doivent être
 soigneusement traités. L'équipe de sécurité de Debian est là pour coordonner
 cette activité, pour faire le suivi des problèmes de sécurité en cours, pour
 aider les responsables ayant des problèmes de sécurité ou pour les corriger
 elle-même, pour envoyer les annonces de sécurité et pour maintenir le site
 security.debian.org.

        <sect2 id="bug-security-you">Que faire si vous apprenez l'existence d'un
        problème de sécurité&nbsp;?
<p>
Si vous prenez connaissance d'un bogue lié à un problème de sécurité sur un
   paquet Debian, que vous soyez ou non le responsable, regroupez les
   informations pertinentes sur le problème et contactez rapidement l'équipe de
   sécurité à &email-security-team;. Les informations utiles incluent, par
   exemple&nbsp;:

 <list compact>
      <item>
      les versions du paquet connues pour être affectées par le bogue. Vérifiez
      chaque version présente dans les distributions maintenues par Debian ainsi
      que dans <em>testing</em> et dans <em>unstable</em>,
      </item>
      <item>
      la nature d'une solution si elle est disponible (les correctifs sont
      particulièrement utiles),
      </item>
      <item>
      tout paquet corrigé que vous avez vous-même préparé (envoyez seulement les
      fichiers <file>.diff.gz</file> et <file>.dsc</file>),
      </item>
      <item>
      toute information nécessaire pour l'annonce de sécurité (voir <ref
      id="bug-security-advisories">).
      </item>
  </list>

        <sect2 id="bug-security-confidentiality">Confidentialité
<p>
À la différence de la plupart des autres activités au sein de Debian, les
   informations sur les problèmes de sécurité doivent parfois être gardées en
   privé pour un certain temps. Cette décision dépend de la nature du problème
   et de l'existence d'une solution correspondante et également s'il s'agit d'un
   fait connu publiquement.
<p>
Il existe plusieurs façons pour un développeur de prendre connaissance d'un
problème de sécurité&nbsp;:

<list compact>
      <item>
      il le remarque sur un forum public (liste de diffusion, site web, etc.),
      </item>
      <item>
      quelqu'un remplit un rapport de bogue,
      </item>
      <item>
      quelqu'un l'informe par courrier privé.
      </item>
</list>

Dans les deux premiers cas, l'information est publique et il est important
d'avoir une solution le plus vite possible. Dans le dernier cas, cependant, ce
n'est peut-être pas une information publique. Dans ce cas, il existe quelques
options possibles pour traiter le problème&nbsp;:

<list>
<item>
      si le problème est trivial (comme des fichiers temporaires non sécurisés),
      il n'y a pas besoin de garder le secret sur le problème et une correction
      devrait être effectuée et diffusée,
</item>
<item>
      si le problème est grave (exploitable à distance, possibilité d'accéder
      aux privilèges d'administratation), il est préférable de partager cette
      information avec d'autres vendeurs et de coordonner une diffusion.
      L'équipe de sécurité garde des contacts avec les différentes organisations
      et individus et peut prendre soin des actions à mener.
</item>
</list>

<p>
Dans tous les cas, si la personne qui indique le problème demande à ne pas
diffuser l'information, cela devrait être respecté avec l'évidente exception
d'informer l'équipe de sécurité (assurez-vous d'informer l'équipe de sécurité
que l'information ne doit pas être révélée).

<p>Veuillez noter que si le secret est nécessaire, vous ne pourrez pas envoyer
un correctif vers <em>unstable</em> (ou ailleurs) puisque les informations de
changelog et de diff sont publiques pour <em>unstable</em>.

<p>Il existe deux raisons pour diffuser l'information même si le secret est
demandé&nbsp;: le problème est connu depuis un certain temps ou le problème ou
son exploitation est devenu public.

        <sect2 id="bug-security-advisories">Annonces de sécurité
<p>
Les annonces de sécurité ne sont émises que pour la distribution actuelle
   diffusée <em>stable</em>, pas pour <em>testing</em> ou <em>unstable</em>.
   Quand elle est diffusée, l'annonce est envoyée à la liste de diffusion
   &email-debian-security-announce; et elle est postée sur <url
   id="&url-debian-security-advisories;" name="la page de sécurité">. Les
   annonces de sécurité sont écrites et postées par l'équipe de sécurité.
   Cependant, ils ne verront aucun inconvénient à ce qu'un responsable leur
   apporte des informations ou écrive une partie du texte. Les informations qui
   devraient être présentes dans une annonce incluent&nbsp;:
<list compact>
<item>
        une description du problème et de sa portée, y compris&nbsp;:
        <list>
        <item>
                le type du problème (escalade de privilège, déni de service,
                etc.),
        </item>
        <item>
                comment il peut être exploité,
        </item>
        <item>
                si le problème peut être exploité à distance ou localement,
        </item>
        <item>
                comment le problème a été corrigé,
        </item>
        </list>
</item>
<item>
        les numéros de version des paquets affectés,
</item>
<item>
        les numéros de version des paquets corrigés,
</item>
<item>
        une information sur la façon de récupérer les paquets mis à jour,
</item>
<item>
        des références à des annonces amont, des identifiants <url
        id="http://cve.mitre.org" name="CVE"> et toute autre information utile
        pour recouper les références de la vulnérabilité.
</item>
</list>

         <sect2 id="bug-security-building">
            <heading>Préparer les paquets pour corriger des problèmes de sécurité
<p>
Une façon d'aider l'équipe de sécurité dans ses travaux est de fournir des
  paquets corrigés convenables pour une annonce de sécurité pour la version
  <em>stable</em> de Debian
<p>
Quand une mise à jour de la version <em>stable</em> est effectuée, un soin
  particulier doit être apporté pour éviter de modifier le comportement du
  système ou d'introduire de nouveaux bogues. Pour cela, faites le moins de
  changements possibles pour corriger le bogue. Les utilisateurs et les
  administrateurs s'attendent à un comportement identique dans une version
  lorsque celle-ci est diffusée, donc tout changement qui est fait est
  susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour
  les bibliothèques&nbsp;: assurez-vous ne de jamais changer l'API ou l'ABI,
  quelque minimal que soit le changement.
<p>
Cela veut dire que passer à une version amont supérieure n'est pas une bonne
solution. À la place, les changements pertinents devraient être rétro-portés
vers la version présente dans la distribution <em>stable</em> de Debian.
Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de
sécurité Debian peut le faire.
<p>
Dans certains cas, il n'est pas possible de rétro-porter un correctif de
sécurité, par exemple, quand de grandes quantités de code source doivent être
modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à
une nouvelle version amont. Cependant, vous devez toujours coordonner cela avec
l'équipe de sécurité au préalable.
<p>
Il existe une autre règle de conduite liée à cela&nbsp;: testez toujours vos
changements. Si une exploitation du problème existe, essayez-la et
vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet
corrigé. Testez aussi les autres actions normales car parfois un correctif de
sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas
liées.
<p>
Examinez et testez autant que possible vos changements. Vérifiez les différences
avec la version précédente de manière répétée (<prgn>interdiff</prgn> du
paquet <package>patchutils</package> et <prgn>debdiff</prgn> du paquet
<package>devscripts</package> sont des outils utiles pour cela, voir <ref
id="debdiff">).
<p>
Lors de la construction de la correction, gardez les points suivants à
l'esprit&nbsp;:

<list>
<item>
      Assurez-vous que vous avez pour cible la bonne distribution dans votre
      fichier <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de
      <tt>stable-security</tt> et pour <em>testing</em>, c'est
      <tt>testing-security</tt> et pour l'ancienne distribution stable, c'est
      <tt>oldstable-security</tt>. Ne ciblez pas
      <var>distribution</var>-proposed-updates&nbsp;!
</item>
<item>
      Assurez-vous que le numéro de version est correct. Il doit être plus élevé
      que celui du paquet actuel, mais moins que ceux des paquets des versions
      des distributions suivantes. En cas de doute, testez-le avec <tt>dpkg
      --compare-versions</tt>. Pour <em>testing</em>, il doit y avoir un numéro
      de version supérieur dans <em>unstable</em>. S'il n'y en a pas encore (par
      exemple, si <em>testing</em> et <em>unstable</em> ont la même version),
      vous devez envoyer une nouvelle version vers <em>unstable</em> en premier.
</item>
<item>
      Ne faites pas d'envoi de source seul si votre paquet possède un ou
      plusieurs paquets binary-all (n'utilisez pas l'option <tt>-S</tt> de
      <prgn>dpkg-buildpackage</prgn>). L'infrastructure <prgn>buildd</prgn> ne
      construira pas ceux-ci. Ce point s'applique aux envois de paquets normaux
      également.
</item>
<item>
      Si la source amont a été envoyée auparavant à security.debian.org (par une
      précédente mise à jour de sécurité), construisez le paquet sans la source
      amont (<tt>dpkg-buildpackage -sd</tt>). Sinon, construisez-le avec le
      source complet (<tt>dpkg-buildpackage -sa</tt>).
</item>
<item>
      Assurez-vous d'utiliser exactement le même nom <file>*.orig.tar.gz</file>
      que celui utilisé dans l'archive normale, sinon il ne sera pas possible de
      déplacer plus tard le correctif de sécurité dans l'archive principale.
</item>
<item>
      Assurez-vous, lors de la compilation du paquet, de compiler sur un système
      propre, dont tous les paquets appartiennent à la distribution pour laquelle vous
      construisez le paquet. Si vous n'avez pas un tel système, vous pouvez
      utiliser l'une des machines de debian.org (voir <ref
      id="server-machines">) ou mettez en place un chroot (voir <ref id=
      "pbuilder"> et <ref id="debootstrap">).
</item>
</list>

      <sect2 id="bug-security-upload">Mettre à jour le paquet corrigé
<p>
Vous <em>NE DEVEZ PAS</em> envoyer un paquet dans la file d'attente des envois de sécurité
sans l'accord préalable de l'équipe de sécurité. Si le paquet ne remplit pas
exactement les exigences de l'équipe, il causera beaucoup de problèmes, ainsi
que des délais dans la gestion de l'envoi indésirable.
<p>
Vous <em>NE DEVEZ PAS</em> envoyer votre correction dans
<em>proposed-updates</em> sans vous coordonner avec l'équipe de sécurité. Les
paquets seront copiés de security.debian.org dans le répertoire
<file>proposed-updates</file> automatiquement. Si un paquet avec le même numéro
de version ou un numéro plus grand est déjà installé dans l'archive, la mise à
jour de sécurité sera rejetée par le système d'archive. Ainsi, la distribution
<em>stable</em> se retrouvera à la place sans la mise à jour de sécurité de ce
paquet.
<p>
Une fois que vous avez créé et testé le nouveau paquet et qu'il a été approuvé
par l'équipe de sécurité, il doit être envoyé pour être installé dans les
archives. Pour les envois de sécurité, l'adresse d'envoi est
<tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt>.

<p>
Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera
automatiquement recompilé pour toutes les architectures et stocké pour
vérification par l'équipe de sécurité.

<p>
Les envois en attente d'acceptation ou de vérification ne sont accessibles que
par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des
correctifs pour des problèmes de sécurité qui ne peuvent pas encore être
diffusés.

<p>
Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur
security.debian.org ainsi que dans le répertoire
<var>distribution</var>-proposed-updates qui convient sur ftp-master ou dans
l'archive non-US.

    <sect id="archive-manip">
      <heading>Déplacer, effacer, changer le nom, adopter et abandonner des paquets
<p>
Certaines manipulations de l'archive ne sont pas possibles 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.

      <sect1 id="moving-pkgs">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 GNU GPL&nbsp;; dans ce cas, le paquet doit être déplacé dans la section
 <tt>main</tt> ou <tt>contrib</tt><footnote><p>Reportez-vous à la <url
 id="&url-debian-policy;" name="charte Debian"> 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 à la <url
 id="&url-debian-policy;" name="charte Debian"> pour en savoir plus. Si votre
 nouvelle section est valide, il sera déplacé automatiquement. Si ce n'est pas
 le cas, contactez les responsables ftp pour comprendre ce qui s'est passé.
<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">.


      <sect1 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
 demander sa suppression. N'oubliez pas de préciser de quelle distribution le
 paquet doit être supprimé. Normalement, vous ne devriez avoir à supprimer que
 des paquets d'<em>unstable</em> ou de <em>experimental</em>. Les paquets de
 <em>testing</em> ne sont pas supprimés directement. Ils sont plutôt enlevés
 automatiquement après que le paquet a été supprimé d'<em>unstable</em> et
 si aucun paquet de <em>testing</em> n'en dépend.
<p>
Vous devez également détailler les raisons justifiant cette demande. Ceci a pour
 but d'éviter les suppressions non désirées et de garder une trace de la raison
 pour laquelle un paquet a été supprimé. Par exemple, vous pouvez fournir le nom
 du paquet qui remplace celui à supprimer.
<p>
Vous ne pouvez demander la suppression d'un paquet que si vous en
 êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez
 obtenir l'accord de son dernier responsable.
<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>paquet</var> </tt> vous
 indiquera, entre autres, les paquets qui dépendent de <var>paquet</var>.
<p>
Une fois que le paquet a été supprimé, les bogues du paquet doivent être gérés.
 Soit ils sont réattribués à un autre paquet dans le cas où le code actuel a
 évolué en un autre paquet (par exemple, <tt>libfoo12</tt> a été supprimé parce
 que <tt>libfoo13</tt> le remplace) ou ils sont fermés si le logiciel ne fait
 simplement plus partie de Debian.

        <sect2>Supprimer des paquets dans <tt>Incoming</tt>
<p>
Par le passé, il était possible de supprimer un paquet de <file>Incoming</file>.
   Cependant, 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 remplacée par la nouvelle. Toutefois, si vous testez
   correctement vos paquets, le besoin d'en remplacer un ne devrait pas être
   trop fréquent.

      <sect1>Remplacer un paquet ou changer son nom
<p>
Il peut vous arriver de vous tromper en nommant un paquet et de vouloir 
changer son nom. Dans ce cas, vous devrez intervenir en deux étapes. D'abord, modifiez
 votre fichier <file>debian/control</file> pour que votre nouveau paquet
 remplace et entre en conflit avec l'ancien paquet que vous voulez remplacer
 (reportez-vous à la <url id="&url-debian-policy;" name="charte Debian"> 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
 demandez la suppression du paquet mal nommé. N'oubliez pas de réattribuer
 correctement les bogues du paquet en même temps.
<p>
D'autres fois, vous pouvez commettre une erreur en construisant le paquet et
vous désirez le remplacer. La seule façon de faire est d'incrémenter le numéro de
 version et d'envoyer une nouvelle version. L'ancienne version expirera de la
 façon habituelle. Notez que ceci s'applique à chaque partie de votre paquet, y
 compris les sources&nbsp;: si vous désirez remplacer l'archive source amont de
 votre paquet, vous devez l'envoyer avec un numéro de version différent. Une
 possibilité simple est de remplacer <file>foo_1.00.orig.tar.gz</file> par
 <file>foo_1.00+0.orig.tar.gz</file>. Cette restriction donne à chaque fichier
 du site ftp un nom unique, ce qui aide à garantir la consistance dans le réseau
 des miroirs.

      <sect1 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 <package>wnpp</package>. Le
 titre de votre rapport de bogue devrait être
 «&nbsp;<tt>O<footnote><p><em>Orphaned</em>&nbsp;: abandonné.</footnote>:
 <var>paquet</var> &mdash; <var>courte description</var></tt>&nbsp;» pour
 indiquer que le paquet est abandonné. 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 <package>wnpp</package>,
 l'intituler «&nbsp;<tt>RFA<footnote><p><em>Request For Adoption</em>&nbsp;:
 offre d'adoption.</footnote>: <var>paquet</var> &mdash; <var>courte
 description</var></tt>&nbsp;» et lui affecter la gravité <em>importante</em>.
 Envoyez une copie de votre rapport de bogue à la liste debian-devel comme
 décrit ci-dessus.
<p>
Reportez-vous à la page WNPP<footnote><p><em>Work-needing and prospective
 packages</em>&nbsp;: paquets en souffrance et paquets souhaités.</footnote>
 <url id="&url-wnpp;"> pour en savoir plus.

      <sect1 id="adopting">Adopter un paquet
<p>
Une liste des paquets en attente de nouveau responsable est disponible à la page
 <url id="&url-wnpp;" name="paquets en souffrance et paquets souhaités">. Si
 vous voulez prendre en charge un paquet de cette liste, reportez-vous à la page
 mentionnée ci-dessus 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 &mdash; ce serait un détournement de paquet. Vous pouvez prendre
 contact avec le responsable actuel et lui demander si vous pouvez prendre en
 charge ce paquet. Si vous avez le sentiment qu'un responsable est parti sans
 prévenir depuis un moment, veuillez vous reporter à <ref id="mia-qa">).
<p>
Généralement, vous ne pouvez pas adopter un paquet sans l'accord du responsable
actuel. Même s'il vous ignore, ce n'est pas une raison pour le faire. Les
plaintes à propos des responsables devraient être portées sur la liste de
diffusion des développeurs. Si la discussion ne se termine pas par une
conclusion positive et que le problème est de nature technique, considérez de
porter le cas à l'attention du comité technique (voir la <url name="page web du
comité technique" id="&url-tech-ctte;"> pour plus d'information).
<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, vous pouvez utiliser le <ref
 id="pkg-tracking-system"> pour recevoir les rapports de bogue. Cependant,
 assurez-vous que cela ne pose aucun problème à l'ancien responsable de
 continuer à recevoir les bogues durant ce temps.

    <sect id="porting">Le portage
<p>
Debian accepte 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 paquets 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.


      <sect1 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 &mdash;
 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 bogue succincts ou peu
 clairs&nbsp;; 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 un
 pense-bête pour les choses auxquelles vous devez être attentif&nbsp;:
<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 de le vérifier est d'utiliser le paquet
        <package>debootstrap</package> pour créer un environnement
        <em>unstable</em> <em>chrooté</em> (voir <ref id="debootstrap">). 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 cet
        environnement. Ces étapes peuvent être automatisées en utilisant le
        programme <prgn>pbuilder</prgn> qui est fourni par le paquet de même
        nom (voir <ref id="pbuilder">).
        <p>
        Si vous n'arrivez pas à installer un environnement <em>chrooté</em>,
        <prgn>dpkg-depcheck</prgn> pourra peut-être vous aider (voir <ref
        id="dpkg-depcheck">).
        <p>
        Consultez la <url id="&url-debian-policy;" name="charte Debian"> pour en
        savoir plus sur les dépendances de fabrication.
  </item>
  <item>
        Ne choisissez pas d'autres valeurs 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 de la <url
        id="&url-debian-policy;" name="charte Debian">. Choisir la valeur
        «&nbsp;i386&nbsp;» est la plupart du temps incorrect.
  </item>
  <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écompresse correctement. En utilisant le résultat de ce test,
        construisez votre paquet binaire à l'aide de la commande
        <prgn>dpkg-buildpackage</prgn>.
  </item>
  <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>
  <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>
  <item>
        Ne vous appuyez pas sur une installation préexistante de votre paquet
        (un sous-cas de la remarque précédente).
  </item>
  <item>
        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.
  </item>
  <item>
        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>.
  </item>
</enumlist>


      <sect1 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&nbsp;; 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>
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>
La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante&nbsp;:
 <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>.

        <sect2 id="binary-only-nmu">
          Mises à jour indépendantes binaires ou recompilations
<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). Malgré les modifications nécessaires du changelog, ce type de mise
 à jour reste une mise à jour indépendante binaire &mdash; 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 «&nbsp;magiques&nbsp;»
 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
 «&nbsp;2.9-3&nbsp;», votre mise à jour portera le numéro
 «&nbsp;2.9-3.0.1&nbsp;». Si cette version était «&nbsp;3.4-2.1&nbsp;» votre
 mise à jour portera le numéro «&nbsp;3.4-2.1.1&nbsp;».


        <sect2 id="source-nmu-when-porter">
          Quand faire une mise à jour indépendante source pour un portage&nbsp;?
<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.
<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 &mdash; 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> &mdash; 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.


      <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&nbsp;; 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>
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 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&nbsp;; ce sont des machines
   «&nbsp;esclaves&nbsp;» 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&nbsp;;
   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>
Une partie des informations produites par <package>buildd</package> &mdash;
   utiles pour les porteurs &mdash; 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 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 &mdash; 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.
</sect2>

    <sect 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 «&nbsp;mise à jour indépendante&nbsp;».
<p>
Ces mises à jour indépendantes de binaires font de temps en temps partie du
       travail normal des porteurs qui compilent les paquets pour d'autres
       architectures (voir <ref id="porting">). Un développeur peut aussi faire
       des mises à jour indépendantes quand il corrige le paquet d'un autre
       développeur pour éliminer un problème de sécurité ou un bogue bloquant. 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.

      <sect1 id="nmu-terms">Terminologie
<p>
Deux nouvelles expressions sont introduites dans cette section&nbsp;:
 «&nbsp;mise à jour indépendante source&nbsp;» et «&nbsp;mise à jour
 indépendante binaire&nbsp;». Ces expressions ont une définition précise dans le
 monde Debian. Elles correspondent toutes deux au même type d'activité&nbsp;;
 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 tout comme un fichier
 <em>diff</em> modifié.
<p>
Une mise à jour indépendante binaire est constitué 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&nbsp;; 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 «&nbsp;mise à jour indépendante&nbsp;»
 (NMU<footnote><p>Non-maintainer upload</footnote>). Pourtant, cela conduit
 souvent à des confusions car beaucoup associent «&nbsp;mise à jour
 indépendante&nbsp;» et «&nbsp;mise à jour indépendante source&nbsp;». Il faut
 donc rester vigilant. Dans ce chapitre, si nous utilisons l'expression
 «&nbsp;mise à jour indépendante&nbsp;» seule, il s'agit des deux types de
 livraisons.


      <sect1 id="nmu-who">Qui peut faire une mise à jour indépendante&nbsp;?
<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&nbsp;; 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.


      <sect1 id="nmu-when">Quand faire une mise à jour indépendante
      source&nbsp;?
<p>
Les recommandations pour déterminer quand faire une mise à jour indépendante
 source dépendent de la distribution visée (i.e. <em>stable</em>,
 <em>unstable</em> ou <em>experimental</em>). 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 bogue de sécurité est détecté, l'équipe de sécurité peut faire une
 mise à jour indépendante. Veuillez vous reporter à <ref id="bug-security"> pour
 plus d'informations.
<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 devriez tenter d'entrer en contact
 avec le responsable du paquet&nbsp;; 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. Des exceptions spéciales sont
 effectuées pour <ref id="qa-bsp">.
<p>
Envoyer des corrections de bogues vers <em>unstable</em> par une autre personne
 que le responsable ne devrait être fait qu'en suivant ce protocole&nbsp;:
<p>
<list>
<item>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.
<item>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é
      «&nbsp;patch&nbsp;».
<item>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 <ref id="nmu-guidelines">, 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.
<item>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.
<item>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.
</list>
<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 «&nbsp;chasses aux bogues&nbsp;», la personne
 désirant faire la mise à jour indépendante doit remplir des bogues et
 contacter en premier le développeur, et ensuite seulement passer à
 l'action.

      <sect1 id="nmu-guidelines">Comment faire une mise à jour indépendante
      source&nbsp;?
<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&nbsp;; plus
 généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi
 petit que possible. Si certaines choses froissent votre sens de l'esthétique,
 parlez-en au responsable du paquet, au responsable amont ou soumettez un
 rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
 pas</em> être effectués lors d'une mise à jour indépendante.


        <sect2 id="nmu-version">Numéro de version pour les mises à jour
        indépendantes sources
<p>
Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
   changer, même pour la plus triviale des modifications. Notre système de
   gestion de paquets s'appuie sur ces numéros de version.
<p>
Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
   un numéro de version mineur à la partie <var>debian-revision</var> du numéro
   de version (la partie qui suit le dernier trait d'union). Ce numéro
   supplémentaire débutera à «&nbsp;1&nbsp;». Prenons pour exemple le paquet
   «&nbsp;foo&nbsp;» 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 «&nbsp;1.1&nbsp;» et la révision Debian est
   «&nbsp;3&nbsp;». La mise à jour indépendante suivante ajouterait le numéro de
   version mineur «&nbsp;.1&nbsp;» 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 à «&nbsp;0.1&nbsp;». 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 «&nbsp;0.1&nbsp;» comme numéro de révision Debian. Le mainteneur du
   paquet doit, lui, démarrer sa numérotation à «&nbsp;1&nbsp;».
 

        <sect2 id="nmu-changelog">
            <heading>Les mises à jour indépendantes sources doivent être
            mentionnées dans le fichier changelog</heading>
<p>
Une personne qui fait une mise à jour indépendante source doit ajouter une
   entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
   et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
   comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
   version livrée.
<p>
Par convention, dans le cas d'une mise à jour indépendante source
   <em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne

<example>
  * Non-maintainer upload
</example>


        <sect2 id="nmu-patch">Mise à jour indépendante source et système de
        suivi des bogues
<p>
Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
   modifications que possible et doit toujours envoyer ses modifications au
   système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).
<p>
Et si vous recompilez simplement le paquet&nbsp;? Si vous avez simplement besoin
   de recompiler le paquet pour une seule architecture, vous pouvez faire une
   NMU binaire seulement comme décrit dans <ref id="binary-only-nmu"> qui ne
   nécessite pas qu'un correctif soit envoyé. Si vous désirez que le paquet soit
   recompilé pour toutes les architectures, vous devez alors faire une NMU
   source et vous devrez envoyer un correctif.
<p>
Si la mise à jour indépendante source (<em>source NMU</em>) corrige des bogues,
   ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système de
   suivi des bogues plutôt que clos. Par convention, seul le responsable du
   paquet et la personne qui a ouvert le rapport de bogue peuvent clore ce
   rapport. Heureusement, le système d'archivage Debian reconnaît les mises à
   jours indépendantes et positionne correctement le statut des bogues à
   <em>fixed</em> si la personne qui fait la mise à jour a listé tous les bogues
   dans le fichier changelog en utilisant la syntaxe <tt>Closes:
   bug#<var>nnnnn</var></tt> (voir <ref id="upload-bugfix"> pour en savoir plus
   sur la fermeture de bogue par le fichier <file>changelog</file>). Ce passage
   au statut <em>fixed</em> assure que chacun sait que le bogue est corrigé par
   une mise à jour indépendante tout en laissant le rapport de bogue ouvert
   jusqu'à ce que le responsable du paquet incorpore les modifications de cette
   mise à jour dans la version officielle du paquet.
<p>
Après avoir fait une mise à jour indépendante, il vous faudra aussi ouvrir un
   nouveau rapport de bogue qui inclura un correctif contenant toutes les
   modifications que vous avez faites. Sinon, vous pouvez envoyer cette
   information aux bogues qui sont fixés par votre NMU. Le responsable officiel
   pourra choisir d'appliquer le correctif, il pourra aussi employer une autre
   méthode pour régler le problème. Certains bogues sont corrigés dans la
   version amont, ce qui est une bonne raison pour annuler les modifications
   d'une mise à jour indépendante. Si le responsable choisit de mettre à jour le
   paquet plutôt que d'utiliser les correctifs de la mise à jour indépendante,
   il devra s'assurer que cette nouvelle version corrige effectivement chacun
   des bogues corrigés dans la mise à jour indépendante.
<p>
De plus, le responsable officiel devrait <em>toujours</em> conserver les entrées
   documentant une mise à jour indépendante dans le fichier
   <file>changelog</file>.


        <sect2 id="nmu-build">Fabriquer une mise à jour indépendante source
<p>
Les paquets faisant l'objet d'une mise à jour indépendante source sont
   construits comme les autres. Sélectionnez une distribution en utilisant les
   règles décrites dans la section <ref id="distribution"> en suivant toutes les
   prescriptions de la section <ref id="upload">.
<p>
Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt> dans
   le fichier <file>debian/control</file>. Votre nom, mentionné dans l'entrée du
   fichier <file>debian/changelog</file> concernant la mise à jour, sera utilisé
   pour signer le fichier <file>.changes</file>.

      <sect1 id="ack-nmu">Valider une mise à jour indépendante
<p>
Si l'un de vos paquets a subi une mise à jour indépendante, vous devez récupérer
 les changements dans votre copie des sources. Ceci est aisé, vous avez
 simplement à appliquer le correctif qui vous a été envoyé. Une fois ceci fait,
 vous devez fermer les bogues qui ont été marqués comme fixés par la mise à
 jour. Vous pouvez soit les fermer manuellement en envoyant les courriers
 nécessaires au BTS soit ajouter les <tt>closes: #nnnn</tt> nécessaires dans
 l'entrée du changelog de votre prochain envoi.
<p>
Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une NMU n'est
 pas une attaque personnelle contre le responsable. C'est une preuve que le
 paquet est important pour quelqu'un et qu'il est désireux de vous aider dans
 votre travail, vous devriez donc lui être reconnaissant. Vous pouvez également
 lui demander s'il serait intéressé pour vous aider sur une base plus régulière
 comme co-responsable ou responsable de secours (cf. <ref
 id="collaborative-maint">).



    <sect id="collaborative-maint">
       <heading>Maintenance collective</heading>
<p>
«&nbsp;Maintenance collective&nbsp;» est un terme décrivant le partage des
 devoirs de la maintenance d'un paquet Debian par plusieurs personnes. Cette
 collaboration est presque toujours une bonne idée car il en résulte
 généralement une meilleure qualité et un temps de correction de bogues plus
 petit. Il est fortement recommandé que les paquets de priorité
 <tt>Standard</tt> ou qui font partie de la base aient des co-responsables.
<p>
Habituellement, il y a un responsable principal et un ou plusieurs
 co-responsables. Le responsable principal est celui dont le nom est indiqué
 dans le champ <tt>Maintainer</tt> du fichier <file>debian/control</file>. Les
 co-responsables sont tous les autres responsables.
<p>
Dans sa forme la plus simple, ajouter un nouveau co-responsable est assez
 simple&nbsp;:
<list>
<item><p> Donner au co-responsable un accès aux sources à partir desquelles vous
      construisez le paquet. Habituellement, cela implique que vous utilisiez un
      système de contrôle de version comme <prgn>CVS</prgn> ou
      <prgn>Subversion</prgn>.
</item>
<item><p> Ajouter les nom et adresse correctes du co-responsable au champ
      <tt>Uploaders</tt> dans la partie globale du fichier
      <file>debian/control</file>.
<example>
Uploaders: John Buzz &lt;jbuzz@debian.org&gt;, Adam Rex &lt;arex@debian.org&gt;
</example>
</item>
<item><p>
      En utilisant le PTS (<ref id="pkg-tracking-system">), les
      co-responsables devraient s'inscrire eux-mêmes aux paquets sources
      appropriés.
</item>
</list>

  <chapt id="best-pkging-practices">
    <heading>Les meilleurs pratiques pour la construction des paquets
<p>
La qualité de Debian est principalement due à la <url id="&url-debian-policy;"
name="charte Debian"> qui définit explicitement les obligations que tous les
paquets doivent suivre. Mais c'est également grâce à une histoire partagée
d'expériences qui va au-delà de la charte Debian, une accumulation d'années
d'expérience pour la construction des paquets&nbsp;; 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&nbsp;: 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&nbsp;?
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
«&nbsp;monolithiques&nbsp;»&nbsp;: vous ne pouviez pas choisir quelles parties
intéressantes vous pouviez utiliser, mais vous étiez obligé de choisir le
système pour tout faire. <package>debhelper</package>, à l'inverse, consiste en
un certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple,
<prgn>dh_installman</prgn> installe et compresse les pages de manuel,
<prgn>dh_installmenu</prgn> installe les fichiers de menu et ainsi de suite.
Ainsi, il offre une flexibilité suffisante pour pouvoir utiliser les scripts
d'aide quand ils sont utiles, en complément de commandes définies manuellement
dans le fichier <file>debian/rules</file>.
<p>
Vous pouvez débuter avec <package>debhelper</package> par lire <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
«&nbsp;vierge&nbsp;» 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&nbsp;: les fichiers
correctifs sont livrés dans le fichier correctif Debian
(<file>.diff.gz</file>), habituellement dans le répertoire <file>debian/</file>.
La seule différence est qu'ils ne sont pas appliqués immédiatement par
dpkg-source, mais par la règle <tt>build</tt> du fichier
<file>debian/rules</file>. Inversement, ils sont annulés par la règle
<tt>clean</tt>.
<p>
<prgn>dbs</prgn> est l'une des approches les plus populaires pour cela. Il fait
ce qui est décrit ci-dessus et fournit la possibilité de créer de nouveaux
correctifs et de mettre à jour d'anciens correctifs. Veuillez vous reporter au
paquet <package>dbs</package> pour plus d'informations et au paquet
<package>hello-dbs</package> pour un exemple.
<p>
<prgn>dpatch</prgn> fournit également ces fonctions, mais il est prévu pour être
encore plus facile d'utilisation. Veuillez voir le paquet
<package>dpatch</package> pour la documentation et des exemples (dans
<file>/usr/share/doc/dpatch</file>).
<p>

        <sect1 id="multiple-binary">Paquets binaires multiples
<p>
Un simple paquet source va souvent permettre de construire plusieurs paquets
 binaires différents, que ce soit pour fournir plusieurs saveurs du même
 paquet (par exemple, le paquet source <package>vim</package>) ou pour créer
 plusieurs petits paquets au lieu d'un seul gros (par exemple, si
 l'utilisateur peut n'installer que la partie dont il a besoin et ainsi
 économiser de l'espace disque).
<p>
Le second cas peut facilement être géré dans le fichier
 <file>debian/rules</file>. Vous avez simplement besoin de déplacer les fichiers
 appropriés du répertoire de construction dans les arborescence temporaires du
 paquet. Vous pouvez le faire en utilisant <prgn>install</prgn>
 ou <prgn>dh_install</prgn> du paquet <package>debhelper</package>.
 Assurez-vous de vérifier les différentes permutations de paquets, en
 garantissant que vous avez bien défini les dépendances entre les paquets dans
 le fichier <file>debian/control</file>.
<p>
Le premier cas est un peu plus diffile car il implique de multiples
 recompilations du même logiciel, mais avec différentes options de
 configuration. Le paquet source <package>vim</package> est un exemple de la
 façon de gérer cela avec un fichier <file>rules</file> écrit à la main.

<!-- &FIXME; Find a good debhelper example with multiple configure/make cycles
     -->
</sect1>


    <sect id="bpp-debian-control">
        <heading>Les meilleures pratiques pour le fichier
        <file>debian/control</file></heading>
        <p>
Les pratiques suivantes sont relatives au fichier <file>debian/control</file>.
Elles viennent en complément des <url
id="&url-debian-policy;ch-miscellaneous.html#s-descriptions" name="règles pour
les descriptions de paquet">.
<p>
La description du paquet, telle qu'elle est définie par le champ correspondant
dans le fichier <file>control</file>, contient à la fois le résumé du paquet et
la description longue pour le paquet. <ref id="bpp-desc-basics"> décrit des
lignes générales pour les deux parties de la description. Ensuite, <ref
id="bpp-pkg-synopsis"> fournit des principes spécifiques pour le résumé et <ref
id="bpp-pkg-desc"> contient des principes spécifiques pour la description
longue.

        <sect1 id="bpp-desc-basics">
          <heading>Les règles générales pour les descriptions des paquets</heading>
<p>
La description du paquet devrait être écrite pour l'utilisateur moyen,
l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple, les paquets
de développement sont pour les développeurs et leur description peut utiliser un
langage technique. Pour les applications à but plus général comme un éditeur, la
description devrait être écrite pour un non-spécialiste.
<p>
Notre critique des descriptions des paquets nous amène à conclure que la plupart
des descriptions des paquets sont techniques, c'est-à-dire, qu'elles ne sont pas
écrites pour être comprises par les non-spécialistes. À moins que
votre paquet ne soit que pour les techniciens, c'est un problème.
<p>
Comment écrire pour les non-spécialistes&nbsp;? É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 &mdash; «&nbsp;GNOME&nbsp;»
ou «&nbsp;KDE&nbsp;» sont corrects car les utilisateurs sont probablement
familiers avec ces termes, mais «&nbsp;GTK+&nbsp;» 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 «&nbsp;X Window System&nbsp;», «&nbsp;X11&nbsp;»
ou «&nbsp;X&nbsp;» et non «&nbsp;X Windows&nbsp;», «&nbsp;X-Windows&nbsp;» ou
«&nbsp;X Window&nbsp;». Utilisez «&nbsp;GTK+&nbsp;» et non «&nbsp;GTK&nbsp;» ou
«&nbsp;gtk&nbsp;». Utilisez «&nbsp;GNOME&nbsp;» et non «&nbsp;Gnome&nbsp;».
Utilisez «&nbsp;PostScript&nbsp;» et non «&nbsp;Postscript&nbsp;» ou
«&nbsp;postscript&nbsp;».
<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
«&nbsp;Rudolph, le renne au nez rouge&nbsp;». La clause apposée ici est
«&nbsp;le renne au nez rouge&nbsp;». 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 («&nbsp;le&nbsp;») ou indéfini («&nbsp;un&nbsp;»).
<p>
Cela peut vous aider d'imaginer le résumé combiné avec le nom du paquet de
la façon suivante&nbsp;:

<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
«&nbsp;developer-tools&nbsp;»)

<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&nbsp;: qu'est-ce que fait le paquet&nbsp;? Quelle tâche aide-t-il
l'utilisateur à accomplir&nbsp;? 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&nbsp;:
Pourquoi, en tant qu'utilisateur, ai-je besoin de ce paquet&nbsp;? Quelles
sont les autres fonctionnalités dont dispose le paquet&nbsp;? Quelles
sont les fonctionnalités marquantes et les déficiences de ce paquet comparé à
d'autres paquets (par exemple, «&nbsp;si vous avez besoin de X, utilisez Y à la
place&nbsp;»)&nbsp;? 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,
«&nbsp;il s'agit d'un client pour le serveur foo&nbsp;»)&nbsp;?
<p>
Soyez attentif à éviter les fautes d'orthographe et de grammaire. N'oubliez
pas votre vérificateur orthographique. <prgn>ispell</prgn> possède une option
spéciale (<tt>-g</tt>) pour cela&nbsp;:

<example>ispell -d american -g debian/control</example>

        </sect1>

        <sect1 id="bpp-upstream-info">
          <heading>Page d'accueil amont</heading>
          <p>
Nous vous recommandons d'ajouter l'adresse de la page d'accueil du paquet à la
description du paquet dans le fichier <file>debian/control</file>. Cette
information devrait être ajoutée à la fin de la description en utilisant le
format suivant&nbsp;:

<example> .
  Homepage: http://some-project.some-place.org/</example>

Veuillez noter les espaces au début de la ligne, ils servent à séparer les
lignes correctement. Pour voir un exemple de ce que cela affiche, veuillez vous
reporter à <url id="&url-eg-desc-upstream-info;">.
          <p>
Ne mettez rien s'il n'existe pas de page pour le logiciel.

          <p>
Veuillez noter que nous espérons que ce champ sera remplacé par un
vrai champ de <file>debian/control</file> que comprendraient <prgn>dpkg</prgn>
et <tt>&packages-host;</tt>. Si vous ne voulez pas vous embêter à déplacer la
page d'accueil depuis la description vers ce nouveau champ, vous devriez
probablement attendre qu'il soit disponible.</p>
        </sect1>
      </sect>


    <sect id="bpp-debian-changelog">
        <heading>Les meilleures pratiques pour le fichier <file>debian/changelog</file></heading>
        <p>
Les pratiques suivantes viennent en complément de la <url name="directive sur
les fichiers changelog" id="&url-debian-policy;ch-docs.html#s-changelogs">.</p>

        <sect1 id="bpp-changelog-do">
            <heading>Écrire des entrées de changelog utiles</heading>
        <p>
L'entrée de changelog pour une révision de paquet documente les changements dans
cette révision et seulement ceux-ci. Concentrez-vous sur la description des
changements significatifs et visibles de l'utilisateur qui ont été effectués
depuis la dernière version.
        <p>
Ciblez <em>ce</em> qui a été changé &mdash; qui, comment et quand cela a été fait
est généralement de moindre importance. Ceci dit, rappelez-vous de nommer
poliment les personnes qui ont fourni une aide notable pour réaliser le
paquet (par exemple, ceux qui ont envoyé des correctifs).
        <p>
Vous n'avez pas besoin de détailler les changements triviaux et évidents. Vous
pouvez également regrouper plusieurs de ces changements dans une seule entrée.
D'un autre côté, ne soyez pas trop concis si vous avez entrepris un changement
majeur. Soyez tout spécialement clair s'il y a des changements qui modifient le
comportement du programme. Pour plus d'explications, utilisez le fichier
<file>README.Debian</file>.
        <p>
Utilisez un langage anglais commun pour que la majorité des lecteur puissent le
comprendre. Évitez les abbréviations, le parler technique et le jargon quand
vous expliquez des changements fermant un bogue, spécialement pour les rapports
de bogue créés par des utilisateurs qui ne vous paraissent pas particulièrement
à l'aise techniquement. Vous devez être poli et ne pas jurer.
        <p>
Il est parfois désirable de préfixer les entrées de changelog avec le nom des
fichiers qui ont été modifiés. Cependant, il n'est pas besoin de lister
explicitement tous les fichiers modifiés, particulièrement si la modification
est petite ou répétitive. Vous pouvez utiliser les caractères génériques.
        <p>
Quand vous faites référence aux bogues, ne supposez rien a priori. Dites ce
qu'était le problème, comment il a été résolu et ajoutez la chaîne de caractères
«&nbsp;closes: #nnnnn&nbsp;». Veuillez voir <ref id="upload-bugfix"> pour plus
d'informations.

        <sect1 id="bpp-changelog-misconceptions">
            <heading>Communes idées fausses sur les entrées de changelog</heading>
        <p>
Les entrées de changelog <strong>ne devraient pas</strong> documenter des
problèmes génériques d'empaquetage («&nbsp;Hé, si vous cherchez foo.conf, il
est dans /etc/blah/.&nbsp;») car les administrateurs et utilisateurs sont
supposés être au moins vaguement rompus à la façon dont les choses sont
arrangées sur un système Debian. Mentionnez cependant tout changement
d'emplacement d'un fichier de configuration.
        <p>
Les seuls bogues fermés par une entrée de changelog devraient être ceux qui sont
vraiment corrigés dans la même révision du paquet. Fermer des bogues non liés
par le fichier changelog est considéré comme une très mauvaise pratique.
Veuillez voir <ref id="upload-bugfix">.
        <p>
Les entrées de changelog <strong>ne devraient pas</strong> être le lieu de
discussions avec les émetteurs de bogues («&nbsp;Je ne vois pas de segfaults
lors du lancement de foo avec l'option bar&nbsp;; envoyez-moi plus
d'informations.&nbsp;»), ni celui de phrases génériques sur la vie, l'univers et
tout le reste («&nbsp;Désolé, cet envoi m'a pris du temps, mais j'avais attrapé
la grippe.&nbsp;») ou celui de demandes d'aide ("&nbsp;La liste des bogues sur
ce paquet est énorme, donnez-moi un coup de main.&nbsp;»). Ceci ne sera
généralement pas remarqué par les personnes ciblées, mais peut ennuyer les
personnes qui désirent lire des informations sur les changements réels du
paquet. Veuillez vous reporter à <ref id="bug-answering"> pour plus
d'informations sur la façon d'utiliser le système de suivi des bogues.
        <p>
C'est une vieille tradition de valider les bogues fixés par une mise à jour
indépendante dans la première entrée du changelog de l'envoi du vrai
responsable, par exemple, dans une entrée de changelog comme ceci&nbsp:
<example>
  * Maintainer upload, closes: #42345, #44484, #42444.
</example>
Ceci fermera les bogues NMU marqués comme corrigé («&nbsp;fixed&nbsp;») quand le
paquet arrivera dans l'archive. Le bogue pour le fait qu'une NMU a été faite
peut être fermé de la même façon. Bien sûr, il est également parfaitement
acceptable de fermer les bogues corrigés par NMU par d'autres moyens&nbsp;; voir
<ref id="bug-answering">.
</sect1>

        <sect1 id="bpp-changelog-errors">
            <heading>Erreurs communes dans les entrées de changelogs</heading>
<p>
Les exemples suivants montrent des erreurs communes ou des exemples de mauvais
style dans les entrées de changelog<footnote>NdT&nbsp;: Les entrées de
changelog sont ici affichées en français pour faciliter la compréhension, mais
vos entrées devront naturellement être rédigées en anglais.</footnote>.

<p>
<example>
  * Corrige tous les bogues restants.
</example>
<p>
Ceci n'indique visiblement rien d'utile au lecteur.
<p>
<example>
  * Correctif de Jane Random appliqué.
</example>
Sur quoi portait le correctif&nbsp;?

<p>
<example>
  * Révision de cible d'installation la nuit dernière.
</example>
Révision qui a accompli quoi&nbsp;? Est-ce que la mention de la nuit dernière
est supposée nous rappeler que nous ne devons pas faire confiance à ce
code&nbsp;?

<p>
<example>
  * Corrige MRD vsync av. anciens CRTs.
</example>
Trop d'acronymes et il n'est pas très clair de ce qu'était vraiment cette...
 euh..., merde (oups, un mot interdit !) ou comment cela a été corrigé.

<p>
<example>
  * Ceci n'est pas un bogue. Closes: #nnnnnn.
</example>
Premièrement, il n'y a absolument pas besoin d'envoyer un paquet pour
communiquer cette information&nbsp;; à la place, utilisez le système de suivi des
bogues. Deuxièmement, il n'y a aucune explication concernant la raison
pour laquelle le rapport n'était pas un bogue.

<p>
<example>
  * A été fixé il y a longtemps, mais j'ai oublié de le fermer. Closes: #54321.
</example>
Si, pour toute raison, vous n'aviez pas indiqué le numéro du bogue dans une
précédente entrée de changelog, ceci n'est pas un problème, fermez simplement le
bogue normalement dans le BTS. Il n'y a pas besoin de modifier le fichier
changelog, en supposant que la description de la correction est déjà intégrée
(ceci s'applique aux correctifs par les auteurs/responsables amonts également,
vous n'avez pas à suivre les bogues qui ont été corrigés il y a longtemps dans
votre changelog).

<p> <!-- MANQUE UN . final -->
<example>
  * Closes: #12345, #12346, #15432
</example>
Où est la description&nbsp;?! Si vous n'arrivez pas à trouver un message
descriptif, commencez par insérer le titre de chacun des différents bogues.
<p>
</sect1>
</sect>

<!-- <sect1 id="pkg-mgmt-cvs">Managing a package with CVS
        <p>
        &FIXME; presentation of cvs-buildpackage, updating sources
        via CVS (debian/rules refresh).
      <url id="http://www.debian.org/devel/cvs_packages">
-->

    <sect id="bpp-debian-maint-scripts">
        <heading>Les meilleures pratiques pour les scripts de
        maintenance</heading>
        <p>
Les scripts de maintenance incluent les fichiers <file>debian/postinst</file>,
<file>debian/preinst</file>, <file>debian/prerm</file> et
<file>debian/postrm</file>. Ces scripts prennent soin de la configuration
d'installation ou de désinstallation des paquets, ce qui n'est pas simplement créer ou 
supprimer des fichiers et des répertoires. Les instructions suivantes
complètent la <url id="&url-debian-policy;" name="charte Debian">.
        <p>
Les scripts de maintenance doivent être idempotents. Cela veut dire que vous
devez vous assurer que rien de grave ne se produit si un script est appelé deux
fois là où il ne devrait habituellement être appelé qu'une fois.
        <p>
Les entrée et sortie standard peuvent être redirigées (par exemple, dans des
tubes<footnote><p>pipes</p></footnote>) pour des besoins d'enregistrement
d'activité, donc vous ne devez pas supposer que ce sont des tty.
        <p>
Tous les affichages et les configurations interactives devraient être
minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet
<package>debconf</package> pour l'interface. Rappelez-vous que, dans tous les
cas, l'affichage ne doit se faire que dans l'étape de configuration,
<tt>configure</tt> du script de post-installation, <file>postinst</file>.
        <p>
Gardez les scripts de maintenance aussi simples que possible. Nous vous
suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que si vous
avez besoin d'une fonctionnalité de Bash, le script de maintenance doit
l'indiquer dans sa première ligne. Un shell POSIX ou Bash sont préférés à
Perl car ils permettent à <package>debhelper</package> d'ajouter facilement des
parties aux scripts.
        <p>
Si vous modifiez les scripts de maintenance, assurez-vous de tester la
suppression du paquet, la double installation et la purge complète. Assurez-vous
qu'il ne reste rien d'un paquet purgé, c'est-à-dire, que la purge doit enlever
tout fichier créé, directement ou indirectement, par les scripts de
maintenance.
        <p>
Si vous avez besoin de vérifier l'existence d'une commande, vous devriez
utiliser quelque chose comme&nbsp;:
<example>if [ -x /usr/sbin/install-docs ]; then ...</example>

Si vous ne désirez pas mettre en dur le chemin de la commande dans le script de
maintenance, la fonction de shell suivante conforme à POSIX peut vous
aider&nbsp;:

&example-pathfind;

Vous pouvez utiliser cette fonction pour rechercher le <tt>$PATH</tt> pour un
nom de commande passé en argument. Il renvoie vrai (zéro) si la commande a été
trouvée et faux sinon. Il s'agit réellement de la façon la plus portable de faire
car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn> ne sont pas
POSIX.
<p>
Bien que <prgn>which</prgn> soit une alternative acceptable car il est
présent dans le paquet classé <em>required</em> <package>debianutils</package>, il n'est pas
présent dans la partition racine. Autrement dit, il est placé dans
<file>/usr/bin</file> au lieu de <file>/bin</file>, il n'est donc pas possible
de l'utiliser dans les scripts qui sont exécutés avant que la partition
<file>/usr</file> soit montée. Cependant, la plupart des scripts n'auront pas ce
problème.
      </sect>

      <sect id="bpp-config-mgmt">
        <heading>Gestion de la configuration avec <package>debconf</package></heading>
        
        <p>
<p>
<package>Debconf</package> est un système de gestion de configuration qui
 peut être utilisé par les divers scripts de maintenance (principalement
 en post-installation dans le fichier <file>postinst</file>) pour demander à
l'utilisateur des informations concernant la configuration du paquet. Il 
faut maintenant éviter les interactions directes avec l'utilisateur et 
préférer les interactions utilisant <package>debconf</package>. Ceci permettra
 à l'avenir des installations non interactives. <!-- pas de trait d'union
entre non et adjectif -->
        <p>
Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs erreurs
 communes sont référencées dans la page de manuel <manref section="8"
 name="debconf-devel">. Vous devriez vraiment lire cette page si vous décidez
 d'utiliser debconf.
      </sect>


      <sect id="bpp-i18n">
        <heading>Internationalisation</heading>



        <sect1 id="bpp-i18n-debconf">Gestion des traductions de
        debconf
<p>
Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur
 un grand nombre de paquets et doivent donc collaborer avec plusieurs
 responsables différents. De plus, la plupart du temps, l'anglais n'est pas leur
 langue maternelle, il se peut que vous deviez être particulièrement patient
 avec eux.
<p>
Le but de <package>debconf</package> était de faciliter la configuration des
paquets aux responsables et aux utilisateurs. À l'origine, les
traductions des questionnaires debconf étaient gérées avec
<prgn>debconf-mergetemplate</prgn>. Cependant, cette technique est maintenant
déconseillée&nbsp;; la meilleure façon pour l'internationalisation de
<package>debconf</package> est d'utiliser le paquet
<package>po-debconf</package>. Cette méthode est plus facile et pour le
responsable et pour les traducteurs&nbsp;; des scripts de transition sont
fournis.
<p>
Lors de l'utilisation de <package>po-debconf</package>, la traduction est
stockée dans des fichiers <file>po</file> (à l'instar des techniques de
traduction de <prgn>gettext</prgn>). Des fichiers modèles contiennent les
messages d'origine et indiquent quels sont les champs traduisibles. Quand vous
modifiez l'état d'un champ traduisible en appelant
<prgn>debconf-updatepo</prgn>, la traduction est marquée comme ayant besoin de
l'attention des traducteurs. Puis, lors de la construction du paquet, le
programme <prgn>dh_installdebconf</prgn> prendra soin de toute la magie
nécessaire à l'ajout du modèle avec les traductions à jour dans les paquets
binaires. Veuillez vous reporter à la page de manuel <manref name="po-debconf"
section="7"> pour les détails.
        </sect1>

        <sect1 id="bpp-i18n-docs">
          <heading>Documentation traduite</heading>
          <p>
La traduction de la documentation est cruciale pour les utilisateurs, mais elle
représente un important travail. Il n'existe aucun moyen d'éliminer ce travail,
mais vous pouvez faciliter les choses pour les traducteurs.
          <p>
Si vous êtes responsable d'une documentation quelle que soit sa taille, il est
plus facile pour les traducteurs d'avoir accès à un système de contrôle de
source. Ceci permet aux traducteurs de voir les différences entre deux versions
de la documentation, pour, par exemple, qu'ils puissent voir ce qui a besoin
d'être retraduit. Il est recommandé que le document traduit inclue une note à
propos de la révision de contrôle du source sur laquelle la traduction est
basée. Un système intéressant est fourni par <url id="&url-i18n-doc-check;"
name="doc-check"> dans le paquet <package>boot-floppies</package> qui donne un
aperçu de l'état de la traduction pour une langue donnée, en utilisant les
commentaires structurés pour une révision donnée du fichier à traduire et, pour
un fichier traduit, la révision du fichier d'origine sur laquelle la traduction
est basée. Vous pouvez vouloir adapter et fournir ceci dans votre référentiel CVS.
          <p>
Si vous maintenez de la documentation au format XML ou SGML, nous vous suggérons
d'isoler les informations indépendantes de la langue et de les définir
comme des entités dans un fichier séparé qui sera inclus par les différentes
traductions. Ceci aide, par exemple, à garder à jour les adresses pour
plusieurs fichiers.
        </sect1>
      </sect>


    <sect id="bpp-common-situations">
        <heading>Pratiques d'empaquetage communes</heading>

<!--
        <sect1 id="bpp-kernel">Kernel modules/patches
<p>

        &FIXME; Heavy use of kernel-package. provide files in
        /etc/modutils/ for module configuration.
-->

        <sect1 id="bpp-autotools">
          <heading>Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
<p>
Conserver à jour les fichiers d'<prgn>autoconf</prgn>, <file>config.sub</file>
et <file>config.guess</file>, est critique pour les porteurs, spécialement pour
les architectures plus changeantes. De très bonnes pratiques d'empaquetage
utilisant <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été regroupées
dans &file-bpp-autotools; du paquet <package>autotools-dev</package>. Vous êtes
vivement encouragé à lire ce fichier et à suivre les recommandations indiquées.


        <sect1 id="bpp-libraries">Bibliothèques
<p>
Pour diverses raisons, il a toujours été difficile d'empaqueter les 
bibliothèques. La charte impose plusieurs contraintes pour faciliter la maintenance
 et pour garantir que les mises à jour sont aussi simples que possible quand une
 nouvelle version amont est disponible. Une erreur dans une bibliothèque peut
 rendre défectueux une douzaine de paquets qui en dépendent.
<p>
Les bonnes pratiques d'empaquetage des bibliothèques ont été regroupées dans
 <url id="&url-libpkg-guide;" name="le guide d'empaquetage des
 bibliothèques">.

        <sect1 id="bpp-docs">Documentation
           <p>
Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html"
name="règles sur la documentation">.</p>
          <p>
Si votre paquet contient de la documentation construite à partir de XML ou SGML,
nous vous recommandons de ne pas fournir le source XML ou SGML dans le(s)
paquet(s) binaire(s). Si les utilisateurs désirent avoir le source de la
documentation, ils peuvent récupérer le paquet source.</p>
          <p>
La charte spécifie que la documentation doit être fournie au format HTML.
Nous vous recommandons également de la fournir au format PDF et texte simple si
c'est adapté et qu'une sortie de qualité est possible. Cependant, il n'est
généralement pas approprié de fournir des versions en texte simple pour la
documentation dont le format source est du HTML.</p>
          <p>
Les principaux manuels fournis devraient être enregistrés par le paquet
<package>doc-base</package> à l'installation. Reportez-vous à la documentation
du paquet <package>doc-base</package> pour plus d'information.</p>


        
        <sect1 id="bpp-other">Types spécifiques de paquets
<p>
Plusieurs types spécifiques de paquets ont des sous-chartes spéciales et des
 règles et pratiques d'empaquetage correspondantes&nbsp;:
<list>
<item>
      Les paquets liés à Perl ont leur <url id="&url-perl-policy;" name="charte
      Perl">, quelques exemples de paquets qui suivent cette charte sont
      <package>libdbd-pg-perl</package> (module perl binaire) ou
      <package>libmldbm-perl</package> (module perl indépendant de
      l'architecture).
</item>
<item>
      Les paquets liés à Python ont leur charte Python&nbsp;; voir
      &file-python-policy; dans le paquet <package>python</package>.
</item>
<item>
      Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;"
      name="charte Emacs">.
</item>
<item>
      Les paquets liés à Java ont leur <url id="&url-java-policy;" name="charte
      Java">.
</item>
<item>
      Les paquets liés à Ocaml ont leur propre charte que l'on trouve dans
      &file-ocaml-policy; du paquet <package>ocaml</package>. Un bon exemple est
      le paquet source <package>camlzip</package>.
</item>
<item>
      Les paquets fournissant des DTDs XML ou SGML devraient se conformer aux
      recommandations que l'on peut trouver dans le paquet
      <package>sgml-base-doc</package>
<item>
      Les paquets Lisp devraient s'enregistrer avec le paquet
      <package>common-lisp-controller</package> pour lequel vous pouvez vous
      reporter au fichier &file-lisp-controller;.
</list>

  </sect1>

        <sect1 id="bpp-archindepdata">Données indépendantes de l'architecture
        <p>
        Il n'est pas rare d'avoir une grande quantité de données indépendantes de
        l'architecture fournie avec un programme. Par exemple, des fichiers
        audio, une collection d'icônes, des motifs de papiers peints ou autres
        fichiers graphiques. Si la taille des données est négligeable par
        rapport à la taille du reste du paquet, il est probablement mieux de
        tout garder dans le même paquet.

        <p>
        Cependant, si la taille des données est considérable, vous devez
        envisager de les partager dans un paquet séparé et indépendant de
        l'architecture («&nbsp;_all.deb&nbsp;»). Ainsi, en faisant cela, vous
        évitez une duplication inutile des mêmes données dans onze fichiers
        .debs pour chaque architecture. Bien que ceci ajoute une surcharge
        supplémentaire aux fichiers <file>Packages</file>, ceci sauve beaucoup
        d'espace disque sur les miroirs Debian. Séparer les données
        indépendantes de l'architecture réduit également le temps de traitement
        de <prgn>lintian</prgn> ou de <prgn>linda</prgn> (voir <ref
        id="tools-lint">) quand ils sont exécutés sur l'ensemble de l'archive
        Debian.
        </sect1>

</sect>

</chapt>

  <chapt id="beyond-pkging">
    <heading>Au-delà de l'empaquetage
<p>
Debian, c'est beaucoup plus que de l'empaquetage de logiciels et de
    la maintenance de paquets. Ce chapitre contient des informations sur les
    façons, souvent vraiment importantes, de contribuer à Debian au-delà de la
    simple création et maintenance de paquets.
<p>
En tant qu'organisation de volontaires, Debian repose sur la liberté de 
    choisir ce sur quoi l'on désire travailler et de choisir la
    partie la plus importante à laquelle on veut consacrer son temps.

    <sect id="submit-bug">
        <heading>Rapporter des bogues
<p>
Nous vous encourageons à remplir des rapports de bogue quand vous trouvez des
 bogues dans les paquets Debian. En fait, les développeurs Debian sont souvent
 les testeurs de première ligne. Trouver et rapporter les bogues dans les
 paquets d'autres développeurs améliore la qualité de Debian.
<p>
Lisez les <url name="instructions pour créer un rapport de bogue"
id="&url-bts-report;"> dans le <url name="système de suivi des bogues"
id="&url-bts;"> Debian.
<p>
Essayez de soumettre le bogue à partir d'un compte utilisateur normal sur lequel
 vous pouvez recevoir des courriers, pour que les personnes puissent vous
 joindre s'ils ont besoin de plus d'informations à propos du bogue. Ne soumettez
 pas de bogues en tant que root.
<p>
Vous pouvez utiliser un outil comme <manref name="reportbug" section="1"> pour
soumettre des bogues. Il peut automatiser et dans l'ensemble faciliter le
processus.
<p>
Assurez-vous que le bogue n'a pas déjà été rapporté. Chaque paquet dispose d'une
liste de bogues facilement accessible à
<tt>http://&bugs-host;/<var>packagename</var></tt>. Des outils comme <manref
name="querybts" section="1"> peuvent également vous fournir ces informations (et
<prgn>reportbug</prgn> invoquera également habituellement <prgn>querybts</prgn>
avant l'envoi).
<p>
Essayer d'envoyer vos bogues au bon emplacement. Quand, par exemple, votre bogue
concerne un paquet qui réécrit des fichiers d'un autre paquet, vérifiez les
listes des bogues pour les <em>deux</em> paquets pour éviter de créer des
rapports de bogues dupliqués.
<p>
Vous pouvez également parcourir les bogues d'autres paquets, en les regroupant
 s'ils sont indiqués plus d'une fois, ou en les marquant avec
 «&nbsp;fixed&nbsp;» quand ils ont déjà été corrigés. Notez cependant que si
 vous n'êtes ni le rapporteur du bogue, ni le responsable du paquet, vous ne
 devriez pas fermer réellement le bogue (à moins que vous n'ayez obtenu la
 permission du responsable).
<p>
De temps en temps, vous pourrez vouloir vérifier ce qui s'est passé à propos des
 bogues que vous avez rapportés. Saisissez cette occasion pour fermer les bogues
 que vous ne pouvez plus reproduire. Pour trouver tous les bogues que vous avez
 rapportés, vous avez simplement besoin d'aller à
 <tt>http://&bugs-host;/from:<var>&lt;your-email-addr&gt;</var></tt>.

      <sect1 id="submit-many-bugs">Ouvrir un grand nombre de rapports d'un seul
      coup
<p>
Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
 paquets &mdash; plus de dix &mdash; est une pratique que nous déconseillons.
 Prenez toutes les mesures possibles pour éviter cette situation. Si le problème
 peut être détecté automatiquement par exemple, ajoutez un nouveau test dans le
 paquet <package>lintian</package> pour générer une erreur ou un avertissement.
<p>
Si vous ouvrez plus de dix rapports sur le même sujet, il est préférable
 d'indiquer votre intention sur la liste &email-debian-devel;. Cela donnera à
 d'autres développeurs la possibilité de vérifier que le problème existe
 vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent
 les mêmes rapports de bogue simultanément.
<p>
Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez
 les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils ne soient
 pas redirigés vers les listes de diffusion.


      <sect id="qa-effort">Effort d'assurance qualité
        
        <sect1 id="qa-daily-work">Travail journalier
<p>
Bien qu'il y ait un groupe de personnes dédiées à l'assurance qualité, les
 devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez participer à
 cet effort en conservant vos paquets aussi exempts de bogues que possible et
 aussi corrects que possible selon <prgn>lintian</prgn> (reportez-vous à <ref
 id="lintian">). Si cela vous paraît impossible, vous devriez alors envisager
 d'abandonner certains de vos paquets (reportez-vous à <ref id="orphaning">).
 Sinon, vous pouvez demander de l'aide à d'autres personnes pour qu'elles
 puissent rattraper votre retard dans la correction des bogues (vous pouvez
 demander de l'aide sur &email-debian-qa; ou &email-debian-devel;). En même
 temps, vous pouvez rechercher des co-responsables (reportez-vous à <ref
 id="collaborative-maint">).
        
        <sect1 id="qa-bsp">Les chasses aux bogues
<p>
De temps en temps, le groupe d'assurance qualité organise des chasses aux
 bogues<footnote><em>Bug Squashing Party</em></footnote> pour essayer de
 supprimer le plus de problèmes possible. Elles sont annoncées sur
 &email-debian-devel-announce; et l'annonce explique quel domaine sera visé
 pendant la chasse&nbsp;: habituellement, il s'agit des bogues empêchant
 l'intégration du paquet dans la distribution («&nbsp;Release Critical&nbsp;»),
 mais il peut arriver qu'ils décident d'aider à finir une transition majeure
 (comme une nouvelle version de Perl qui demande la recompilation de tous les
 modules binaires).
<p>
Les règles pour les mises à jour indépendantes sont différentes au cours de la
 chasse parce que l'annonce de la chasse est considérée comme une annonce
 préalable pour les mises à jour indépendantes. Si vous avez des paquets qui
 peuvent être affectées par la chasse (parce qu'ils ont des bogues critiques par
 exemple), vous devriez envoyer une mise à jour pour chaque bogue correspondant
 pour expliquer leur état actuel et ce que vous attendez de la chasse. Si vous
 ne voulez pas d'une mise à jour indépendante ou si vous n'êtes intéressé que
 par un correctif ou si vous voulez gérer vous-même le bogue, veuillez l'expliquer
 dans le BTS.
<p>
Les personnes qui participent à la chasse ont des règles spécifiques pour les
 mises à jour indépendantes, ils peuvent en faire une sans avertissement
 préalable s'ils envoient leur paquet avec un délai d'au moins 3 jours dans
 DELAYED/3-day. Toutes les autres règles de mise à jour indépendante
 s'appliquent comme d'habitude, ils devraient envoyer le correctif de la
 mise à jour dans le BTS (pour l'un des bogues ouverts corrigé par la mise à
 jour ou pour un nouveau bogue marqué comme fixé). Ils devraient également
 respecter les souhaits du responsable s'il en a exprimés.
<p>
Si une personne ne se sent pas à l'aise avec une mise à jour indépendante, elle
 devrait simplement envoyer un correctif au BTS. C'est de loin meilleur qu'une
 mise à jour défectueuse.

    <sect id="contacting-maintainers">Contacter d'autres responsables
<p>
Pendant vos activités dans Debian, vous aurez à contacter d'autres responsables
      pour différentes raisons. Vous pourrez vouloir discuter d'une nouvelle
      façon de coopérer au sein d'un ensemble de paquets liés, ou vous pouvez
      simplement rappeler à quelqu'un qu'une nouvelle version est disponible et
      que vous en avez besoin.
<p>
Chercher l'adresse d'un responsable d'un paquet peut être fastidieux.
      Heureusement, il existe un alias de courrier simple,
      <tt>&lt;package&gt;@&packages-host;</tt>, qui fournit un moyen d'envoyer
      un courrier à un responsable, quelle que soit son adresse (ou ses
      adresses). Remplacez <tt>&lt;package&gt;</tt> par le nom du paquet source
      ou binaire.
<p>
Vous pouvez également vouloir contacter les personnes qui sont inscrites à un
      paquet de source donné par le <ref id="pkg-tracking-system">. Vous pouvez le
      faire en utilisant l'adresse <tt>&lt;package-name&gt;@&pts-host;</tt>.


    <sect id="mia-qa">Gérer les responsables non joignables
<p>
Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer
      que le responsable est toujours actif et qu'il continue à travailler sur
      ses paquets. Il est possible qu'il ne soit plus actif, mais qu'il ne se
      soit pas désenregistré du système. D'un autre côté, il est possible qu'il
      ait simplement besoin d'un rappel.
<p>
La première étape est de contacter poliment le responsable et d'attendre une
réponse pendant un temps raisonnable. Il est assez difficile de définir le
«&nbsp;temps raisonnable&nbsp;», mais il est important de prendre en compte que
la vraie vie est parfois assez mouvementée. Une façon de gérer cela pourrait
être d'envoyer un rappel après deux semaines.
<p>
Si le responsable ne répond pas après quatre semaines (un mois), on peut
supposer qu'il n'y aura probablement pas de réponse. Si ceci se produit, vous
devriez poursuivre vos investigations et essayer de réunir toutes les
informations utiles sur ce responsable. Ceci inclut&nbsp;:
      <p>
      <list>
        <item>Les informations «&nbsp;echelon&nbsp;» disponibles dans la <url
              id="&url-debian-db;" name="base de données LDAP des
              développeurs">, qui indiquent quand le développeur a envoyé un
              message pour la dernière fois sur une liste de diffusion Debian.
              (Ceci inclut les envois via les listes debian-*-changes.)
              Rappelez-vous également de vérifier si le responsable est indiqué
              comme en vacances dans la base de données.

        <item>Le nombre de paquets de ce responsable et les conditions de ces
              paquets. En particulier, restent-ils des bogues empêchant
              l'intégration du paquet dans la distribution qui sont ouverts
              depuis des lustres&nbsp;? De plus, combien de bogues y a-t-il en
              général&nbsp;? Un autre point d'information important est si les
              paquets ont subi des mises à jour indépendantes et si oui, par
              qui&nbsp;?

        <item>Est-ce que le responsable est actif en dehors de Debian&nbsp;? Par
              exemple, il peut avoir envoyé des messages récemment à des
              listes de diffusion non-Debian ou des groupes de discussion.
      </list>
      <p>
Un gros problème est représenté par les paquets parrainés &mdash; le responsable
n'est pas un développeur Debian officiel. Les informations «&nbsp;echelon&nbsp;»
ne sont pas disponibles pour les personnes parrainés, par exemple, vous devez
donc trouver et contacter le responsable Debian qui a réellement envoyé le
paquet. Étant donné qu'il a signé le paquet, il est responsable de l'envoi de
toute façon et il devrait savoir ce qui s'est passé avec la personne qu'il
parraine.
<p>
Il est également permis d'envoyer une demande à &email-debian-devel; demandant
si quelqu'un est au courant d'information sur le responsable manquant.
<p>
Une fois que vous avez réuni toutes ces informations, vous pouvez contacter
&email-debian-qa;. Les personnes de cet alias utiliseront les informations que
vous aurez fournies pour décider comment procéder. Par exemple, ils peuvent
abandonner un ou tous les paquets du responsable. Si un paquet a subi une mise à
jour indépendante, ils peuvent préférer contacter le responsable ayant fait cette
mise à jour &mdash; il est peut-être intéressé par le paquet.
<p>
Un dernier mot&nbsp;: veuillez vous souvenir d'être poli. Nous sommes tous des
volontaires et nous ne pouvons dédier l'intégralité de notre temps à Debian.
Vous n'êtes pas non plus au courant des circonstances de la personne impliquée.
Elle est peut-être sérieusement malade ou pourrait même nous avoir quitté
&mdash; vous ne savez pas qui recevra vos courriers &mdash; imaginez comme un
proche se sentira s'il lit un courrier pour la personne décédée et trouve un
message très impoli, en colère et accusateur&nbsp;!)
<p>
D'un autre côté, bien que nous soyons tous volontaires, nous avons une
responsabilité. Vous pouvez donc insister sur l'importance du plus grand intérêt
&mdash; si un responsable n'a plus le temps ou l'envie, il devrait
«&nbsp;laisser filer&nbsp;» et donner le paquet à quelqu'un ayant plus de temps.

    <sect id="newmaint">
      <heading>Interagir avec de futurs développeurs Debian
<p>
Le succès de Debian dépend de sa capacité à attirer et retenir de nouveaux et
      talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous
      recommandons de vous impliquer dans le processus d'apport des nouveaux
      responsables. Cette section décrit comment aider les futurs développeurs.


      <sect1 id="sponsoring">Parrainer des paquets
<p>
Parrainer un paquet veut dire envoyer un paquet pour un responsable qui n'est
 pas encore autorisé à le faire lui-même, un candidat nouveau responsable.
 Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité.
<p>
Si vous désirez être volontaire pour être parrain, vous pouvez vous inscrire à
 <url id="&url-sponsors;">.
<p>
Les nouveaux responsables ont habituellement certaines difficultés à créer des
 paquets Debian &mdash; ceci est bien compréhensible. C'est pourquoi le parrain
 est là pour vérifier que le paquet parrainé est assez bon pour être inclus
 dans Debian. (Notez que si le paquet parrainé est nouveau, les ftpmasters
 devront également l'inspecter avant de l'intégrer)
<p>
Effectuer un parrainage en signant simplement l'envoi ou en recompilant le
 paquet <strong>n'est définitivement pas recommandé</strong>. Vous devez
 construire le paquet source comme si vous vouliez construire l'un de vos
 paquets. Rappelez-vous que cela ne change rien si vous avez laissé le nom du
 candidat développeur dans le changelog et dans le fichier de
 contrôle, il est toujours possible de savoir que c'est vous qui avez fait l'envoi.
<p>
Si vous êtes un gestionnaire de candidature pour un futur développeur, vous
 pouvez également être son parrain. Ainsi, vous pourrez vérifier comment le
 candidat gère la partie «&nbsp;Tâches et Capacités&nbsp;»<footnote>Tasks and
 Skills</footnote> de sa candidature.

      <sect1>Gérer les paquets parrainés
<p>
En envoyant un paquet sponsorisé vers Debian, vous certifiez que le paquet
 atteint les standards minimum de Debian. Ceci implique que vous devez
 construire et tester le paquet sur votre propre système avant l'envoi.
<p>
Vous ne pouvez pas simplement envoyer un fichier <file>.deb</file> binaire d'un
 filleul. En théorie, vous devriez seulement demander le fichier diff et
 l'emplacement de l'archive source d'origine et ensuite vous devriez récupérer
 le source et appliquer le diff vous-même. En pratique, vous pouvez vouloir
 utiliser le paquet source construit par votre filleul. Dans ce cas, vous devez
 vérifier qu'il n'a pas modifié les fichiers sources du fichier
 <file>.orig.tar.gz</file> qu'il fournit.
<p>
N'ayez pas peur de répondre au filleul et de lui indiquer les changements qu'il
 doit faire. Cela prend souvent plusieurs échanges de courriers avant que le
 paquet ne soit dans un état acceptable. Être un parrain veut dire être un
 mentor.
<p>
Une fois que le paquet a atteint les standards Debian, construisez le paquet
 avec
<example>
 dpkg-buildpackage -us -uc
</example>
 et signez-le avec
<example>
 debsign -m <var>"Nom complet</var> <var>votre-adresse-courrier</var> <var>changes-file</var>
</example>
 avant de l'envoyer dans le répertoire Incoming.
<p>
Le champ Maintainer du fichier <file>control</file> et le fichier
 <file>changelog</file> devraient lister la personne qui a fait l'empaquetage,
 c'est-à-dire, le filleul. Celui-ci recevra donc tous les courriers du système
 de suivi des bogues (BTS) à propos de son paquet.
<p>
Si vous préférez laisser une trace plus visible de votre travail de parrainage,
  vous pouvez ajouter une ligne l'indiquant dans la plus récente entrée du
  changelog.
<p>
Vous êtes encouragé à garder un ½il sur le suivi des paquets que vous parrainez
  en utilisant le <ref id="pkg-tracking-system">.

      <sect1>Recommander un nouveau développeur
<p>
Reportez-vous à la page sur les <url id="&url-newmaint-advocate;"
 name="recommandations pour un développeur prospectif"> sur le site web Debian.

      <sect1>Gérer les candidatures des nouveaux candidats
<p>
Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;" name="liste à
 vérifier pour les responsables de candidatures"> sur le site web Debian.



    <appendix id="tools">Aperçu des outils du responsable Debian
<p>
Cette section contient un aperçu rapide des outils dont dispose le responsable.
      Cette liste n'est ni complète, ni définitive, il s'agit juste d'un guide
      des outils les plus utilisés.
<p>
Les outils du responsable Debian sont destinés à améliorer le confort des
      responsables et libérer leur temps des tâches plus cruciales. Comme le dit
      Larry Wall, il y a plus d'une manière de le faire.
<p>
Certaines personnes préfèrent utiliser des outils de haut niveau, d'autres pas.
      Debian n'a pas de position officielle sur la question&nbsp;; tout outil
      conviendra du moment qu'il fait le boulot. C'est pourquoi cette section
      n'a pas été conçue pour indiquer à chacun quel outil il doit utiliser ou
      comment il devrait faire pour gérer sa charge de responsable Debian. Elle
      n'est pas non plus destinée à favoriser l'utilisation d'un outil aux
      dépens d'un autre.
<p>
La plupart des descriptions de ces outils proviennent des descriptions de leurs
      paquets. Vous trouverez plus d'informations dans les documentations de ces
      paquets. Vous pouvez aussi obtenir plus d'informations avec la commande
      <tt>apt-cache show &lt;package_name&gt;</tt>.</p>


      <sect id="tools-core">
        <heading>Outils de base</heading>
        <p>
Les outils suivants sont pratiquement nécessaires à tout responsable.</p>


      <sect1 id="dpkg-dev">
          <heading><package>dpkg-dev</package></heading>
<p>
Le paquet <package>dpkg-dev</package> contient les outils (y compris
 <prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des
 paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas
 niveau indispensables pour créer et manipuler les paquets&nbsp;; en tant que
 tels, ils sont indispensables à tout responsable Debian.

      <sect1 id="debconf">
          <heading><package>debconf</package></heading>
<p>
Le paquet <package>debconf</package> fournit une interface unifiée pour
 configurer les paquets interactivement. Il est indépendant de l'interface et
 permet une configuration en mode texte, par une interface HTML ou par boîtes de
 dialogue. D'autres types d'interface peuvent être ajoutés sous forme de
 modules.
<p>
Vous trouverez la documentation de ce paquet dans le paquet
 <package>debconf-doc</package>.
<p>
Beaucoup pensent que ce système devrait être utilisé pour tout paquet
 nécessitant une configuration interactive&nbsp;; reportez-vous à la <ref
 id="bpp-config-mgmt">. <package>debconf</package> n'est pas requis par la
 <em>charte Debian</em> pour le moment&nbsp;; cependant, cela pourra changer.
</sect1>

      <sect1 id="fakeroot">
        <package>fakeroot</package>
<p>
<package>fakeroot</package> simule les privilèges <em>root</em>. Cela permet de
 fabriquer un paquet sans être root (en général, les paquets installent des
 fichiers appartenant à <em>root</em>). Si vous avez installé
 <package>fakeroot</package>, vous pouvez construire un paquet en tant que
 simple utilisateur avec&nbsp;: <tt>dpkg-buildpackage -rfakeroot</tt>.


      <sect id="tools-lint">
        <heading>Outils du paquet lint</heading>
        <p>
Selon le «&nbsp;Free On-line Dictionary of Computing&nbsp;» (FOLDOC),
«&nbsp;lint&nbsp;» est «&nbsp;un outil de traitement de langage C qui contient
beaucoup plus de tests complets sur le code que n'en font habituellement les
compilateurs C.&nbsp;». Les outils du paquet lint aide les responsables de
paquet à trouver automatiquement des problèmes habituels et des violations de
charte dans leurs paquets</p>

      <sect1 id="lintian">
          <heading><package>lintian</package></heading>
<p>
<package>lintian</package> dissèque les paquets pour y repérer des bogues et des
 manquements aux règles de développement. Il contient des tests automatisés pour
 vérifier de nombreuses règles et quelques erreurs courantes.
<p>
Vous devriez récupérer la dernière version de <package>lintian</package> depuis
 <em>unstable</em> régulièrement et vérifier tous vos paquets. Notez que
 l'option <tt>-i</tt> donne des explications détaillées sur la signication de
 chaque erreur, la partie concernée dans la charte et le moyen habituel de
 régler le problème.
<p>
Veuillez vous reporter à <ref id="sanitycheck"> pour plus d'informations sur
comment et quand utiliser Lintian.
<p>
 Vous pouvez aussi obtenir un résumé de tous les problèmes reportés par Lintian
 sur vos paquets à <url id="&url-lintian;">. Ces rapports contiennent la sortie
 de la dernière version de <prgn>lintian</prgn> sur l'ensemble de la
 distribution de développement (<em>unstable</em>).
</sect1>

        <sect1 id="linda">
          <heading><package>linda</package></heading>
          <p>
<package>linda</package> est un autre vérificateur de paquet. Il est sembable à
<package>lintian</package>, mais il a un ensemble de tests différents. Il est écrit
en Python plutôt qu'en Perl.</p>
        </sect1>


        <sect1 id="debdiff">
          <heading><package>debdiff</package></heading>
          <p>
<prgn>debdiff</prgn> (du paquet <package>devscripts</package>, <ref
id="devscripts">) compare des listes de fichiers et des fichiers de contrôle de
deux paquets. C'est un simple test de régression qui peut vous aider à remarquer
si le nombre de paquets binaires à changer depuis le dernier envoi ou si autre
chose a changé dans le fichier de contrôle. Bien sûr, certains des changements
qu'il indique sont normaux, mais il peut aider à empêcher différents accidents
          <p>
Vous pouvez l'exécuter sur un couple de paquets binaires&nbsp;:
<example>
debdiff package_1-1_arch.deb package_2-1_arch.deb
</example>
          <p>
Ou même sur un couple de fichiers de changements&nbsp;:
<example>
debdiff package_1-1_arch.changes package_2-1_arch.changes
</example>
          <p>
Pour plus d'informations, veuillez voir <manref name="debdiff" section="1">.
        </sect1>


      </sect>

      <sect id="tools-helpers">
        <heading>Aides pour le fichier <file>debian/rules</file></heading>
        <p>
Des outils de construction de paquets rendent le processus d'écriture du fichier
<file>debian/rules</file> plus facile. Veuillez voir les <ref
id="helper-scripts"> pour plus d'informations sur les raisons pour lesquelles
ils peuvent être désirables ou non.

      <sect1 id="debhelper">
        <heading><package>debhelper</package></heading>
<p>
Le paquet <package>debhelper</package> regroupe un ensemble de programmes qui
 peuvent être utilisés dans <file>debian/rules</file> pour automatiser les
 tâches courantes relatives à la fabrication des paquets Debian binaires. Ce
 paquet contient des utilitaires pour installer différents fichiers, les
 compresser, ajuster leurs droits et intégrer votre paquet dans le système de
 menu Debian.
<p>
À la différence des autres approches, <package>debhelper</package> est divisé en
 plusieurs petits utilitaires qui agissent de manière cohérente. Ce découpage
 permet un contrôle des opérations plus fin que d'autres «&nbsp;<em>outils
 debian/rules</em>&nbsp;».
<p>
Il existe aussi un certain nombre de petites extensions
 <package>debhelper</package> trop éphémères pour être documentées. Vous en
 listerez la plupart en faisant <tt>apt-cache search ^dh-</tt>.
</sect1>


      <sect1 id="debmake">
          <heading><package>debmake</package></heading>
<p>
<package>debmake</package> &mdash; un précurseur de <package>debhelper</package>
 &mdash; est un assistant moins modulaire pour manipuler le fichier
 <file>debian/rules</file>. Il inclut deux programmes principaux&nbsp;:
 <prgn>deb-make</prgn>, utile au développeur Debian pour convertir un paquet
 source normal (non-Debian) en paquet source Debian, et <prgn>debstd</prgn> qui
 regroupe le type de fonction que l'on trouve dans <package>debhelper</package>.
<p>
Le consensus actuel est que l'usage de <package>debmake</package> est
 déconseillé au profit de <package>debhelper</package>, mais ce n'est pas une
 erreur d'utiliser <package>debmake</package>.
</sect1>

        <sect1 id="dh-make">
          <heading><package>dh-make</package>
        <p>
Le paquet <package/dh-make/ contient <prgn/dh_make/, un programme qui crée un
squelette de fichiers nécessaires à la construction d'un paquet Debian à partir
d'une arborescence source. Comme le nom le suggère, <prgn/dh_make/ est une
ré-écriture de <package/debmake/ et ses fichiers modèles utilisent les
programmes dh_* de <package/debhelper/.
        <p>
Quoique les fichiers de règles générés par <prgn/dh_make/ constituent en général
une base suffisante pour un paquet fonctionnel, ce ne sont que les
fondations&nbsp;: la charge incombe toujours au responsable d'affiner 
les fichiers générés et de rendre le paquet complètement fonctionnel et
en conformité avec la charte.
        </sect1>

      <sect1 id="yada">
          <heading><package>yada</package></heading>
<p>
Le paquet <package>yada</package> est un autre assistant pour la création de
 paquets. Il utilise un fichier <file>debian/packages</file> pour générer
 <file>debian/rules</file> et d'autres fichiers nécessaires dans le
 sous-répertoire <file>debian/</file>.
<p>
Remarque&nbsp;: <package>yada</package> est qualifié de «&nbsp;quasiment non
 maintenu&nbsp;» par son responsable, Charles Briscoe-Smith. Son usage est donc
 déconseillé.
</sect1>


      <sect1 id="equivs">
          <heading><package>equivs</package></heading>
<p>
<package>equivs</package> est un autre paquet pour faire des paquets. Il est
 souvent conseillé pour un usage local, si vous avez besoin de faire un paquet
 pour satisfaire des dépendances. Il est aussi parfois utilisé pour faire des
 «&nbsp;méta-paquets&nbsp;» qui sont des paquets dont l'unique objet est de
 dépendre d'autres paquets.</p>
 </sect1>
</sect>


      <sect id="tools-builders">
        <heading>Constructeurs de paquets</heading>
        <p>
Les paquets suivants aident le processus de construction des paquets, en général
en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que la gestion du support de
tâches.

      <sect1 id="cvs-buildpackage">
          <heading><package>cvs-buildpackage</package></heading>
<p>
Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou de
 récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer
 un paquet Debian depuis le référentiel CVS et il assiste le développeur lors de
 l'intégration de modifications amonts dans le référentiel.
<p>
Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS pour le
 responsable Debian. Il permet de conserver des branches CVS distinctes pour les
 distributions <em>stable</em>, <em>unstable</em> et probablement
 <em>experimental</em> et de bénéficier des avantages d'un système de contrôle
 de version.
 </sect1>

      <sect1 id="debootstrap">
          <heading><package>debootstrap</package></heading>
<p>
Le paquet <package>debootstrap</package> vous permet d'amorcer un système Debian
 de base à n'importe quel endroit dans votre système de fichier. Par
 «&nbsp;système de base&nbsp;», nous entendons le strict minimum nécessaire pour
 fonctionner et installer le reste du système.
<p>
Avoir un système comme celui-ci peut vous servir de différentes manières. Vous
 pouvez, par exemple, déplacer votre racine dans ce système avec
 <prgn>chroot</prgn> pour tester vos dépendances de fabrication. Vous pouvez
 aussi l'utiliser pour voir comment se comporte votre paquet quand il est
 installé dans un environnement minimum.
        </sect1>

      <sect1 id="pbuilder">
          <heading><package>pbuilder</package></heading>
<p>
<package>pbuilder</package> construit un système «&nbsp;chrooté&nbsp;» et
 compile des paquets dans ce système. Ceci est très utile pour vérifier que les
 dépendances de compilation de votre paquet sont correctes et pour vous assurer
 qu'aucune dépendance de construction inutile ou incorrecte n'existe dans le
 paquet résultant. </sect1>

      <sect1 id="sbuild">
          <heading><package>sbuild</package></heading>
<p>
<package>sbuild</package> est un autre compilateur automatique. Il peut aussi
 être utilisé dans un environnement «&nbsp;chrooté&nbsp;». Il peut être utilisé
 seul ou comme partie d'un environnement de compilation distribué en réseau.
 Comme le précédent, c'est une partie du système utilisé par les porteurs pour
 construire des paquets binaires pour toutes les architectures disponibles.
 Veuillez vous reporter à <ref id="buildd"> pour plus d'informations et à <url
 id="&url-buildd;"> pour voir le système en fonctionnement.</p>
        </sect1>
      </sect>

      <sect id="uploaders">
        <heading>Téléchargeurs de paquets</heading>
        <p>
Les paquets suivants aident à automatiser ou à simplifier le processus d'envoi
de paquets dans l'archive officielle.</p>

      <sect1 id="dupload">
          <heading><package>dupload</package></heading>
<p>
Le paquet <package>dupload</package> contient un script du même nom pour mettre
 à jour des paquets dans l'archive Debian, tracer les mises à jour et les
 annoncer par courrier électronique automatiquement. Vous pouvez le configurer
 pour faire des mises à jour à d'autres endroits et avec d'autres méthodes.
        </sect1>

      <sect1 id="dput">
          <heading><package>dput</package></heading>
<p>
Le script <package>dput</package> fait à peu près la même chose que
 <package>dupload</package>, mais il le fait différemment. Il a aussi quelques
 fonctions supplémentaires telles que la possibilité de vérifier la signature
 GnuPG et les sommes de contrôles avant le téléchargement et la possibilité de
 démarrer <prgn>dinstall</prgn> en mode simulation (<em>dry-run</em>) après le
 téléchargement.
        </sect1>
      </sect>


      <sect id="tools-maint-automate">
        <heading>Automatisation de la maintenance</heading>
        <p>
Les outils suivants aident à automatiser les différentes tâches de maintenance
par l'ajout des entrées de changelog ou de lignes de signatures, par la
recherche de bogues à partir d'Emacs ou par l'utilisation du plus récent fichier
officiel <file>config.sub</file>.</p>


        <sect1 id="devscripts">
          <heading><package>devscripts</package></heading>
<p>
Le paquet <package>devscripts</package> contient des scripts et outils qui sont
 très utiles pour maintenir vos paquets Debian. Parmi ces scripts, vous
 trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui manipulent votre
 fichier <file>debian/changelog</file> depuis la ligne de commande et
 <prgn>debuild</prgn> qui est construit au-dessus de
 <prgn>dpkg-buildpackage</prgn>. L'outil <prgn>bts</prgn> est également très
 utile pour mettre à jour l'état des rapports de bogue depuis la ligne de
 commande. Le programme <prgn>uscan</prgn> peut être utilisé pour suivre les
 nouvelles versions amonts de vos paquets. Le programme <prgn>debrsign</prgn>
 peut être utilisé pour signer à distance un paquet avant de l'envoyer, ce qui
 est agréable quand la machine sur laquelle vous construisez le paquet est
 différente de celle où résident vos clés GPG.</p>
<p>
Vérifiez la page de manuel <manref section="1" name="devscripts"> pour une liste
 complète des scripts disponibles.

        <sect1 id="autotools-dev">
          <heading><package>autotools-dev</package></heading>
          <p>
Contient les meilleurs pratiques pour des personnes assurant la maintenance de
paquets qui utilisent <prgn>autoconf</prgn> et/ou <prgn>automake</prgn>.
Contient également des fichiers canoniques <file>config.sub</file> et
<file>config.guess</file> qui sont connus pour fonctionner avec tous les
portages Debian.</p>
        </sect1>

        <sect1 id="dpkg-repack">
          <heading><package>dpkg-repack</package></heading>
          <p>
<prgn>dpkg-repack</prgn> crée un paquet Debian à partir d'un paquet qui
a déjà été installé. Si des changements ont été effectués sur le paquet quand il
a été décompressé (par exemple, des fichiers dans <file>/etc</file> ont été
modifés), le nouveau paquet héritera de ces changements.</p>
          <p>
Cet utilitaire peut faciliter la copie de paquet d'un ordinateur vers un autre
ou la re-création de paquets installés sur un système, mais qui ne sont plus
disponibles ailleurs ou pour stocker l'état actuel d'un paquet avant de le
mettre à jour.</p>
        </sect1>

        <sect1 id="alien">
          <heading><package>alien</package></heading>
          <p>
<prgn>alien</prgn> convertit des paquets binaires entre différents formats de
paquets, y compris des paquets Debian, RPM (RedHat), LSB (Linux Standard Base),
Solaris et Slackware.</p>
        </sect1>

        <sect1 id="debsums">
          <heading><package>debsums</package></heading>
          <p>
<prgn>debsums</prgn> vérifie des paquets installés par rapport à leur somme de
hachage MD5. Veuillez noter que tous les paquets n'ont pas de sommes MD5 car
elles ne sont pas requises par la charte.</p>
        </sect1>

      <sect1 id="dpkg-dev-el">
          <heading><package>dpkg-dev-el</package></heading>
<p>
<package>dpkg-dev-el</package> fournit des macros Emacs Lisp qui apportent une
 aide lors de l'édition des fichiers du répertoire <file>debian</file> de votre
 paquet. À l'édition de <file>debian/changelog</file>, par exemple, vous
 disposez de fonctions pour finaliser une version et consulter la liste des
 rapports de bogue ouverts.</p>
</sect1>


        <sect1 id="dpkg-depcheck">
          <heading><package>dpkg-depcheck</package></heading>
          <p>
<prgn>dpkg-depcheck</prgn> (du paquet <package>devscripts</package>, <ref
id="devscripts">) exécute une commande sous <prgn>strace</prgn> pour déterminer
tous les paquets utilisés par la commande.
          <p>
Pour les paquets Debian, c'est utile quand vous devez créer une ligne
<tt>Build-Depends</tt> pour votre nouveau paquet&nbsp;: exécuter le processus de
compilation avec <prgn>dpkg-depcheck</prgn> vous fournira une bonne première
approximation des dépendances de compilation. Par exemple&nbsp;:
<example>
dpkg-depcheck -b debian/rules build
</example>
          <p>
<prgn>dpkg-depcheck</prgn> peut aussi être utilisé pour vérifier les dépendances
d'exécution, particulièrement si votre paquet utilise exec(2) pour exécuter
d'autres programmes.
          <p>
Pour plus d'informations, veuillez voir <manref name="dpkg-depcheck" section="1">.
        </sect1>


      <sect id="tools-porting">
        <heading>Outils de portage</heading>
        <p>
Les outils suivants facilitent le travail des porteurs et la compilation
croisée.</p>

        <sect1 id="quinn-diff">
          <heading><package>quinn-diff</package></heading>
<p>
<package>quinn-diff</package> est utilisé pour localiser les différences d'une
   architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de
   l'architecture <var>X</var> doivent être portés sur l'architecture
   <var>Y</var>.

        <sect1 id="dpkg-cross">
            <heading><package>dpkg-cross</package></heading>
<p>
<package>dpkg-cross</package> est un outil qui installe les bibliothèques et les
   en-têtes nécessaires à une compilation
   croisée<footnote><p><em>cross-compilation</em></footnote> d'une manière
   similaire à <package>dpkg</package>. De plus, les paquets
   <prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
   améliorés pour accepter les compilations croisées.

      <sect id="tools-doc">
        <heading>Documentation et information</heading>
        <p>
Les paquets suivants fournissent des informations pour les responsables ou de
l'aide pour construire de la documentation

        <sect1 id="debiandoc-sgml">
          <heading><package>debiandoc-sgml</package></heading>
          <p>
<package>debiandoc-sgml</package> fournit la DTD DebianDoc SGML qui est
habituellement utilisée pour la documentation Debian. Ce manuel, par exemple,
est écrit en DebianDoc. Il fournit également des scripts pour construire et
décliner le source en de multiples formats de sortie.</p>
          <p>
La documentation sur la DTD peut être trouvée dans le paquet
<package>debiandoc-sgml-doc</package>.</p>
        </sect1>

        <sect1 id="debian-keyring">
          <heading><package>debian-keyring</package></heading>
          <p>
Contient les clés publiques GPG et PGP des développeurs Debian. Voir <ref
id="key-maint"> et la documentation du paquet pour plus d'informations.</p>
        </sect1>

        <sect1 id="debview">
          <heading><package>debview</package></heading>
          <p>
<package>debview</package> fournit un mode Emacs pour voir les paquets binaires
Debian. Il vous permet d'examiner un paquet sans le décompresser.</p>
        </sect1>
      </sect>


<!-- FIXME: add the following

questionable:
  dbs (referred to above)
  dpatch (referred to above)
  debarchiver
  ucf
  dpkg-awk
  grep-dctrl
  d-shlibs
  wajig
  magpie
  apt-dpkg-ref
  apt-show-source
  apt-show-versions
  pdbv
  epm
  apt-src
  apt-build

rejected:
  debaux: too new, unmaintained?
  dh-make-perl: too new, unmaintained?
-->

    </appendix>
  </book>
</debiandoc>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-indent-data:nil
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-declaration:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->