[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.17 $">

  <!-- if you are translating this document, please notate the RCS
       revision of the developers reference here -->
  <!--
    <!entity cvs-en-rev "1.70">
    -->
]>
<debiandoc>
<!--
 TODO:
  - bugs in upstream versions should be reported upstream!
  - add information on how to get accounts on different architectures
  - talk about CVS access, other ways to submit problems
  - add information on how you can contribute w/o being an official
    developer
  - "official port maintainer" ? (cf. glibc-pre2.1)
 -->


<book>
<title>Manuel de référence du développeur Debian

<author>Adam Di Carlo, responsable actuel <email>aph@debian.org</email>
<author>Christian Schwarz <email>schwarz@debian.org</email>
<author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
<author>&nbsp;
<author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.fr</email>
<author>avec la participation de Alain Meessen
<author>et des membres de la liste
<email>debian-l10n-french@lists.debian.org</email>
<version>version &version;, &date-fr;

<copyright>

<copyrightsummary>
 Copyright &copy;1998 &ndash; 2001 Adam Di Carlo</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 grand public du projet GNU (GNU GPL), telle que
publiée par la «&nbsp;Free Software Foundation&nbsp;» (version 2 ou toute
version supé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 grand public
du projet GNU pour plus de détails.

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




        <toc detail="sect2">




        <chapt id="scope">Introduction
        
        <sect>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.

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

<p>
Les ressources présentées dans ce manuel incluent les listes de diffusion et
les serveurs (<ref id="servers">), 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. Il ne décrit pas non plus 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 le <url id="&url-debian-policy;" name="Debian
Policy Manual">.

<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...

<p>
En conséquence la langue utilisée dans toutes les listes de diffusion
destinées aux développeurs 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 quelque 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>NMU source</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>NMU binaire</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 remettant en cause 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-bug">). 

        <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="life-cycle">).

        <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 sensée être plus stable que
        <em>unstable</em> (<ref id="life-cycle">).

        <item><em>Frozen</em>&nbsp;: Nom de la distribution gelée. Cette
        distribution apparaît pendant quelques mois avant la sortie d'une
        nouvelle distribution stable. Elle est destinée à être testée en
        profondeur et ne reçoit que des corrections de bogues (<ref
        id="life-cycle">).

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

        <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; au sens large &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 documentation,
        site web, création des cédéroms, administration des serveurs...

        <item><em>Upstream version</em>&nbsp;: version amont. Il s'agit du
        logiciel tel qu'il est fournit 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(s) responsable(s) 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>Pour commencer

<p>
Vous avez lu toute la documentation, vous comprenez l'intérêt de tout ce qui
se trouve dans le paquet 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 vous pouvez commencer par vous inscrire à la
liste &email-debian-devel;.

<p>
Pour cela, envoyez un courrier à l'adresse
&email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne
<em>Objet</em><footnote><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'information dans la section <ref
id="mailing-lists">.

<p>
Vous suivrez les discussions de cette liste (sans poster) pendant quelques
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> sur le réseau
<em>Linux People IRC</em> (c.-à-d. <tt>irc.debian.org</tt>) pourra aussi être
utile.




        <sect id="registering">Devenir responsable Debian

<p>
Avant de décider de devenir responsable Debian, il vous faudra lire le <url
id="&url-social-contract;" name="Contrat social Debian">. Vous faire
enregistrer comme responsable 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 GNU-Linux. 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é et vos
intentions. Le nombre de personnes travaillant pour Debian GNU-Linux a atteint
&number-of-maintainers; et notre système est utilisé dans un certain nombre
d'endroits très importants : nous devons rester attentifs pour éviter un acte
malveillant. C'est pourquoi nous contrôlons les nouveaux responsables avant de
leur donner un compte sur nos serveurs et les autoriser à ajouter des paquets
dans l'archive.

<p>
Pour votre enregistrement il sera nécessaire d'envoyer les informations
suivantes<footnote>Voir la page  <url id="&url-newmaint-checklist;"
name="Checklist for applicants">.</footnote> après une
première prise de contact à l'adresse &email-new-maintainer;&nbsp;:

        <list compact>
        <item>
        Votre nom.

        <item>
        Le <em>login</em> que vous voudriez avoir sur <tt>master</tt> (maximum
        huit caractères) ainsi que l'adresse qui sera utilisée pour votre
        inscription à la liste &email-debian-private; (il s'agira soit de
        votre adresse personnelle soit de votre adresse <tt>debian.org</tt>
        fraîchement acquise).

        <item>
        Un numéro de téléphone où nous pouvons vous joindre. Souvenez-vous que
        l'équipe <em>New maintainer</em> appelle généralement le soir pour
        limiter les coûts de communication longue distance. Ne donnez pas de
        numéro professionnel à moins d'y être souvent le soir.

        <item>
        Une déclaration de vos intentions. C'est à dire, sur quel paquet vous
        pensez travailler, à quel portage vous comptez participer ou comment
        vous comptez contribuer au projet.

        <item>
        Une déclaration indiquant que vous avez lu et acceptez de soutenir le
        <url id="&url-social-contract;" name="Contrat social Debian">.

        <item>
        Un moyen de vérifier votre identité réelle. Les moyens suivants feront
        l'affaire&nbsp;:

                <list compact>
                <item>
                une clé OpenPGP signée par une signature connue telle qu'un
                responsable Debian que vous aurez rencontré
                <em>physiquement</em> ou un service d'authentification qui
                vérifie votre identité (Verisign par exemple)<footnote>Un
                service d'authentification qui vérifie votre adresse
                électronique mais pas votre identité ne conviendra pas.
                </footnote>,

                <item>
                une copie (numérisée ou photocopiée) de n'importe quel
                document officiel prouvant votre identité (certificat de
                naissance, carte d'identité, permis de conduire, etc...). Pour
                un envoi électronique, signez avec votre clé OpenPGP. 

                </list>
        </list>

<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'information 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>
Souvenez-vous que l'un des noms de votre clé doit correspondre à l'adresse de
mainteneur officiel que vous indiquez dans vos paquets. Par exemple, j'affecte
le responsable du paquet <package>developers-reference</package> à «&nbsp;Adam
Di Carlo &lt;aph@debian.org&gt;&nbsp;»&nbsp;; alors l'un des identifiants de ma clé
doit être cette même valeur «&nbsp;Adam Di Carlo
&lt;aph@debian.org&gt;&nbsp;».

<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>
Pour cause de restriction sur le droit à l'exportation aux États-Unis,
certains paquets, dont <package>gnupg</package>, sont hébergés sur
des serveurs FTP en dehors des États-Unis. Vous trouverez les adresses
de ces serveurs dans le fichier <url id="&url-readme-non-us;">.  

<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 cryptage (comme c'est le cas en
France). Le projet Debian ne nécessite en aucune manière de cryptographie en
tant que cryptage. Si vous vivez dans un pays où l'usage de la cryptographie
pour authentification est interdit, contactez-nous pour que nous prenions des
dispositions particulières.

<p>
Une fois que votre dossier est prêt et que votre clé publique est accessible sur
les serveurs de clés publiques, envoyez votre candidature sur la liste
&email-new-maintainer; pour être enregistré comme responsable Debian et
pouvoir ajouter vos paquets dans l'archive. Ce message doit contenir votre nom
et votre adresse électronique. Toutes les informations présentées plus tôt
seront requises une fois que votre responsable de canditature aura été
désigné.  Le responsable de candidature<footnote>Application manager</footnote> est votre accompagnateur dans le
processus d'enregistrement et vous pouvez toujours lui demander où en est
votre candidature. Vous pouvez aussi consulter le <url id="&url-newmaint-db;"
name="tableau de bord des candidatures"> sur le site Debian.

<p>
Pour en savoir plus, consultez le <url id="&url-newmaint;" name="coin des
nouveaux responsables"> sur le site Debian.

<p>
Une fois que votre dossier aura été reçu et traité, vous devriez 
recevoir les informations concernant votre compte Debian.  Si vous
ne recevez rien pendant un mois, envoyez un message de relance demandant si
votre candidature initiale a bien été reçue. Ne renvoyez <em>pas</em> votre
candidature initiale, cela embrouillerait l'équipe <em>New maintainer</em>.
Soyez patient, en particulier à l'approche de la sortie d'une
distribution&nbsp;; des erreurs ont parfois lieu et les gens peuvent manquer
de temps pour cette activité bénévole.


        <sect id="mentors">Mentors 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.






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


        <sect>Mise à jour de vos références Debian

<p>
Une base de données LDAP contient de nombreuses informations concernant
les développeurs, vous pouvez y accéder à l'adresse <url
id="&url-debian-db;">.  Vous pouvez modifier votre mot de passe (ce mot de
passe est diffusé sur la plupart des machines auxquelles vous avez accès),
votre adresse, votre pays, la latitude et la longitude de l'endroit où vous
résidez, vos numéros de téléphone et de fax, votre interpréteur de commande
préféré, votre surnom IRC, votre page web, votre adresse de courrier
électronique ainsi que l'alias que vous utilisez pour votre courrier
électronique chez debian.org. La plupart de ces informations ne sont pas
accessibles au public. Pour plus de détails au sujet de cette base de données
reportez-vous à sa documentation en ligne disponible à l'adresse <url
id="&url-debian-db-doc;">.

<p>
Vous y tiendrez à jour les informations vous concernant.




        <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
<tt>master.debian.org</tt>.  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="inform-vacation">Prendre des vacances courtoisement

<p>
La plupart des développeurs prennent des vacances&nbsp;; généralement, cela signifie
qu'ils ne peuvent ni travailler pour Debian ni être joints par
courrier électronique si un problème se présentait. Les autres développeurs
ont besoin de savoir que vous êtes en vacances&nbsp;; ainsi ils sauront comment
réagir en cas de problème. En général, cela signifie que les autres
développeurs sont autorisés à modifier votre paquet (voir <ref id="nmu">) en
cas de gros problème (bogues bloquants pour la distribution, mise à jour de
sécurité...) durant vos vacances.

<p>
Il y a deux choses à faire pour informer les autres développeurs.
Premièrement, envoyer un courrier électronique indiquant vos dates de vacances
à &email-debian-private;, vous pouvez aussi donner quelques instructions pour
indiquer comment agir si un problème survenait.  Deuxièmement, il faut mettre
à jour la base de données Debian LDAP et vous signaler «&nbsp;en
vacances&nbsp;» (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.




        <sect id="upstream-coordination">Coordination avec les développeurs
        amonts

<p>
Une grosse 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 <em>patch</em> qui corrige ce bogue.
Les utilisateurs et responsables Debian proposent souvent des <em>patches</em>
pour corriger des bogues amonts, il vous faudra alors évaluer ce
<em>patch</em> 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
<em>patch</em> 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-bug">Gestion des bogues bloquants pour la distribution

<p>
Les bogues bloquants pour la distribution<footnote>Traduction de l'anglais
<em>Release critical bug (RCB)</em></footnote> sont les bogues 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>.
Ces bogues peuvent retarder la diffusion d'une distribution Debian et/ou
peuvent justifier la suppression d'un paquet d'une distribution gelée. C'est
pourquoi ces bogues ont besoin d'être corrigés au plus vite.  Vous devez être
conscient que certains 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 id="qa-effort">L'effort d'assurance qualité

<p>
Même s'il y a un groupe de personnes dédié à l'assurance qualité, cette
activité ne leur est pas réservée. Vous pouvez participer à cet effort en
éliminant, autant que faire se peut, tout bogue de vos paquets et en observant
les remarques émises par <prgn>lintian</prgn> (voir <ref id="lintian-reports">).  Si cela
ne vous semble pas possible, il faudrait songer à abandonner certains
de vos paquets (voir <ref id="orphaning">). Vous pouvez aussi
demander l'aide d'autres personnes pour rattraper votre retard dans la liste
des bogues (vous pouvez demander de l'aide sur les listes  &email-debian-qa;
et &email-debian-devel;).  


        <sect>Démissionner courtoisement
<p>
Si vous choisissez de quitter le projet Debian, procédez comme suit&nbsp;: 

        <enumlist>
        <item>
        Abandonnez tous vos paquets comme décrit dans <ref id="orphaning">.
        
        <item>
        Envoyez un courrier électronique à &email-debian-private; indiquant
        comment vous quittez le projet.

        <item>
        Signalez aux responsables du porte-clés Debian que vous quittez le
        projet en écrivant à &email-debian-keyring;.

        </enumlist>





        <chapt id="servers">Listes de diffusion, serveurs et autres machines

<p>
Dans ce chapitre vous trouverez une très brève description des listes de 
diffusion Debian, des principaux serveurs Debian et des autres machines 
auxquelles vous aurez accès en tant que développeur.



        <sect id="mailing-lists">Les listes de diffusion

<p>
Le serveur de liste de diffusion est <tt>&lists-host;</tt>.  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, avec le mot
<tt>subscribe</tt> dans le champ <em>Objet</em><footnote><em>Subject</em> en
anglais</footnote> pour vous abonner à la liste ou <tt>unsubscribe</tt> pour
vous désabonner.  Vous trouverez des instructions plus détaillées pour vous
abonner et vous désabonner aux adresses <url
id="&url-debian-lists-subscribe;">, <url id="&url-debian-lists;"> ou
localement dans le fichier &file-mail-lists; si vous avez installé le paquet
<package>doc-debian</package>.

<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. Quelqu'un qui envoie un message à une
liste de diffusion se doit d'y lire les réponses.

<p>
Les principales listes de diffusion Debian sont&nbsp;:
        <list compact>
        <item> &email-debian-devel;, 
        <item> &email-debian-policy;, 
        <item> &email-debian-user;,
        <item> &email-debian-private;,
        <item> &email-debian-announce; et
        <item> &email-debian-devel-announce;.
        </list>

Un développeur devrait, au minimum, être inscrit aux listes
&email-debian-private; et &email-debian-devel-announce;.

<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.  Nous déconseillons l'usage des correspondances
croisées (envoyer le même message à plusieurs listes).

<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é, quelqu'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.

<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.

<p>
Comme toujours sur internet, éliminez les lignes inutiles quand vous citez
le message auquel vous répondez. Plus généralement, respectez
les conventions habituelles lorsque vous envoyez des messages.

<p>
Les archives des listes de diffusion sont disponibles en ligne à l'adresse
<url id="&url-lists-archives;">.




        <sect id="server-machines">Les serveurs Debian

<p>
Les serveurs Debian sont bien connus et hébergent les fonctions
critiques du projet Debian.  Tout développeur se doit de savoir ce qu'ils sont
et à quoi ils servent.

<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, vous trouverez
l'adresse d'un responsable pour cette machine à la page <url
id="&url-devel-machines;">.  Si votre problème n'est pas lié au système
(paquet à supprimer 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-master">Le serveur maître

<p>
<tt>master.debian.org</tt> est le serveur maître du système de suivi des
bogues (BTS<footnote>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 le gaspillage de temps machine.

<p>
Tous les développeurs Debian ont un compte sur <tt>master.debian.org</tt>.
Prenez grand soin de votre mot de passe. Évitez les méthodes de connexion et
de téléchargement qui envoient votre mot de passe en clair sur internet.

<p>
Si vous rencontrez un problème avec <tt>master.debian.org</tt> tel qu'un
disque plein, une activité suspecte ou autre, envoyez un courrier
électronique à &email-debian-admin;.




        <sect1 id="servers-ftp-master">Le serveur ftp-master

<p>
Le serveur ftp-master (<tt>ftp-master.debian.org</tt> ou <tt>
auric.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 bogue contre 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-www">Le serveur WWW

<p>
Le serveur web principal, <tt>www.debian.org</tt>, est aussi connu sous le nom
<tt>klecker.debian.org</tt>. Tous les développeurs ont un compte sur cette
machine.

<p>
Si vous désirez publier quelques informations spécifiques à Debian sur la
toile,
vous pouvez le faire en les déposant dans le sous-répertoire
<file>public_html</file> de votre répertoire personnel sur
<tt>klecker.debian.org</tt>. Toute information déposée à cet endroit est
accessible à l'adresse <tt>http://people.debian.org/~<var>user-id</var>/</tt>.
Vous devriez préférer ce serveur aux autres car les répertoires
<file>public_html</file> du serveur <tt>klecker.debian.org</tt> sont
sauvegardés. Ce n'est pas le cas sur les autres serveurs. N'utilisez pas ces
serveurs pour publier des informations sans rapport avec le projet Debian
avant d'en avoir obtenu la permission. Pour toute question supplémentaire,
adressez-vous à la liste &email-debian-devel;.  

<p>
Si vous rencontrez un problème avec un serveur web Debian, vous devez
généralement envoyer un rapport de bogue contre le pseudo-paquet
<package>www.debian.org</package>.  Vérifiez d'abord sur le <url
id="http://bugs.debian.org/www.debian.org" name="système de suivi des bogues">
que personne ne l'a déjà rapporté avant vous.




        <sect1 id="servers-cvs">Le serveur CVS
        
<p>
Le serveur <tt>cvs.debian.org</tt> est aussi connu sous le nom
<tt>klecker.debian.org</tt> (déjà présenté plus haut). 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 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 propriétaire du
répertoire racine et pourquoi vous en avez besoin.




        <sect1 id="servers-mirrors">Les miroirs des serveurs Debian

<p>
Les serveurs web et FTP Debian sont dupliqués sur d'autres serveurs. Évitez de
charger les serveurs originaux. Idéalement, les serveurs originaux se
contentent de copier leur contenu sur les miroirs de premier niveau et
tous les utilisateurs consultent les miroirs. Ainsi le projet Debian étale
ces besoins en bande passante sur plusieurs serveurs et plusieurs réseaux.
Notez que la duplication des données sur les miroirs est déclenchée par le
serveur maître. Ceci nous garantit que les miroirs sont aussi à jour que
possible.

<p>
La liste des miroirs FTP (et en général HTTP) se trouve à l'adresse <url
id="&url-debian-mirrors;">. Vous trouverez plus d'information sur les miroirs
Debian à l'adresse <url id="&url-debian-mirroring;">. Cette page contient des
informations et des outils qui pourront vous aider si vous avez l'intention de
mettre en place votre propre miroir, que ce soit pour un usage interne ou
pour un accès public.

<p>
Les miroirs sont en général mis en oeuvre 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="other-machines">Les autres machines Debian

<p>
Vous aurez peut-être accès à d'autres machines Debian. Vous pouvez utiliser
ces machines pour des tâches en rapport avec le projet Debian. Soyez gentils
avec les administrateurs et ne consommez pas des montagnes d'espace disque, de
bande passante ou de temps machine sans en avoir d'abord reçu l'autorisation.
En général, ces machines sont gérés par des volontaires et sont utilisées pour
des activités de portage.

<p>
Vous trouverez une liste des autres machines mises à la disposition des
développeurs Debian à l'adresse <url id="&url-devel-machines;">.





        <chapt id="archive">L'archive Debian

        <sect>Aperçu

<p>
La distribution Debian est composée d'un grand nombre de paquets Debian
(fichiers <tt>.deb</tt>&nbsp;: à peu près &number-of-pkgs;) et de quelques
autres fichiers (documentation, images des disquettes d'installation,
etc.).

<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,
<tt>dists/</tt> et <tt>pool/</tt>. 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>. Le
découpage en sous-répertoires est identique d'un répertoire de distribution à
l'autre&nbsp;; nous nous contenterons donc d'exposer ce découpage pour la
distribution <em>stable</em>. Les fichiers <tt>Packages</tt> et
<tt>Sources</tt> qui se trouvent dans les répertoires de distribution peuvent
faire référence à des fichiers du répertoire <tt>pool/</tt>.


<p>
Le répertoire <tt>dists/stable</tt> contient trois répertoires nommés
<tt>main</tt>, <tt>contrib</tt> et <tt>non-free</tt>.

<p>
Dans chacune de ces sections se trouve un répertoire contenant les paquets
sources (<tt>source/</tt>), un répertoire pour chaque architecture supportée
(<tt>binary-i386/</tt>, <tt>binary-m68k/</tt>, etc) et un répertoire pour les
paquets indépendants de l'architecture (<tt>binary-all/</tt>).

<p>
La section <em>main</em> contient d'autres répertoires destinés aux images de
disquettes et à quelques documentations essentielles pour installer la
distribution Debian sur une architecture particulière (<tt>disk-i386/</tt>,
<tt>disk-m68k/</tt>, etc).

<p>
Les répertoires  <tt>binary-*/</tt> et <tt>source/</tt> sont à nouveau
divisés en <em>sous-sections</em>.



        <sect>Les sections

<p>
La section <em>main</em> constitue la <strong>distribution Debian GNU-Linux
officielle</strong>.  Elle est officielle parce qu'elle est conforme à toutes
nos recommandations. Les deux autres sections divergent de ces recommandations
à différents degrés, elles ne font donc pas officiellement partie de Debian.

<p>
Chaque paquet de la section <em>main</em> doit être conforme aux <url
id="&url-dfsg;" name="Debian Free Software Guidelines"> et à toutes les autres
recommandations décrites dans <url id="&url-debian-policy;" name="le Debian
Policy Manual">. Les DFSG<footnote><em>Debian Free Software
Guidelines</em></footnote> constituent notre définition de <em>logiciel
libre</em>. Reportez-vous au <em>Debian Policy Manual</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>
Le <em>Debian Policy Manual</em> donne des définitions plus précises pour ces trois sections.
Les paragraphes précédants 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 coté, un distributeur de cédérom pourra facilement vérifier
individuellement les licences des paquets de la section <em>non-free</em> et
ajouter autant de paquets qu'il est autorisé à le faire sur ses cédéroms (dans
la mesure où cela varie énormément d'un distributeur à l'autre ce travail ne
peut être fait par les développeurs Debian).



        <sect>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 supporte encore
plus d'architectures dont ARM et UltraSPARC.  Puisque Linux supporte ces
architectures, Debian a décidé qu'il devait les supporter aussi. C'est
pourquoi plusieurs portages sont en cours&nbsp;; en fait il y a aussi des portages
vers d'autres noyaux. À coté 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>, et <em>arm</em>.

<p>
Debian GNU-Linux 1.3 est disponible uniquement pour <em>i386</em>.  Debian 2.0
supporte les architectures <em>i386</em> et <em>m68k</em>.  Debian 2.1
supporte les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et
<em>sparc</em>. Debian 2.2 ajoute le support de l'architecture
<em>powerpc</em>.

<p>
Vous trouverez des informations destinées aux développeurs à propos d'un
portage particulier sur la page <url id="&url-debian-ports;" name="Portage
Debian">.




        <sect>Les sous-sections

<p>
Les sections <em>main</em>, <em>contrib</em> et <em>non-free</em> sont
divisées en sous-sections  pour simplifier le processus d'installation et la
maintenance de l'archive Debian. Ces sous-sections ne sont pas définies
formellement, à l'exception peut-être de la sous-section <em>base</em>.
Elles existent pour simplifier l'organisation des paquets et la navigation
dans la liste des paquets disponibles. Reportez-vous à la distribution
courante pour connaître la liste des sous-sections disponibles.

<p>
Notez qu'avec l'introduction de la nouvelle organisation de l'archive (voir le
répertoire racine <em>pool/</em>), les sous-sections matérialisées par des
répertoires pourraient disparaître à l'avenir. Elles seront cependant
conservées dans le champ <tt>Section</tt> de l'en-tête des paquets.




        <sect>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;: 

        <list compact>
        <item>
        un fichier <tt>.dsc</tt> et un fichier <tt>.tar.gz</tt> ou,

        <item>
        un fichier <tt>.dsc</tt>, un fichier <tt>.orig.tar.gz</tt> et un
        fichier <tt>.diff.gz</tt>.

        </list>
        
<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 <tt>.tar.gz</tt> qui
contient les sources du programme. Si un paquet est distribué ailleurs, le
fichier <tt>.orig.tar.gz</tt> 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 <tt>.diff.gz</tt> contient les modifications faites par le responsable
Debian.

<p>
Le fichier <tt>.dsc</tt> 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).




        <sect>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 <tt>pool</tt> à 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 <tt>/pub/debian</tt>.

<p>
Une distribution est composée de paquets Debian sources et binaires et des
fichiers <tt>Sources</tt> et <tt>Packages</tt> correspondants. Ces derniers
contiennent la description de tous les paquets. Les premiers sont
conservés dans le répertoire <tt>pool/</tt> tandis que les seconds sont
conservés dans le répertoire <tt>dists/</tt> de l'archive (pour des questions
de compatibilité descendante)




        <sect1 id="life-cycle"><em>Stable</em>, <em>testing</em>,
                               <em>unstable</em> et parfois <em>frozen</em>

<p>
Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire
<tt>dists/stable</tt>), une distribution appelée <em>testing</em> (dans le
répertoire <tt>dists/testing</tt>) et une distribution appelée
<em>unstable</em> (dans le répertoire <tt>dists/unstable</tt>). Ceci reflète
le processus de développement du projet Debian.
        
<p>
Les développements se font sur la distribution <em>unstable</em><footnote>
<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 <em>instable</em>. 

<p>
Les paquets sont copiés de <em>unstable</em> vers <em>testing</em> s'ils
satisfont certains critères. Pour entrer dans la distribution <em>testing</em>
un paquet doit faire partie de l'archive depuis deux semaines et ne doit pas
avoir de bogue bloquant pour la distribution<footnote><em>Release critical
bug</em></footnote>. Passée cette période, le paquet sera installé dans
<em>testing</em> dès que les paquets dont il dépend y seront. Ce processus est
automatique.

<p>
Après une période de développement, quand le responsable de
distribution<footnote><em>Release manager</em></footnote> le juge opportun, la
distribution <em>testing</em> est renommée <em>frozen</em>.  Une fois que cela
est fait, aucun changement n'est autorisé sur cette distribution en dehors des
corrections de bogues&nbsp;; c'est pourquoi nous l'appelons <em>frozen<footnote>
<em>frozen</em> signifie «&nbsp;gelée&nbsp;»</footnote></em>.  Après un mois
ou un peu plus 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>
est renommée <em>stable</em>, remplaçant l'ancienne distribution <em>stable</em> qui
est enlevée à cette occasion.

<p>
Ce cycle de développement est basé sur l'idée que la distribution
<em>instable</em> devient <em>stable</em> après une période de test en tant
que distribution <em>gelée</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 ajoutées individuellement à 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 <tt>proposed-updates</tt>. 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;1.3&nbsp;» devient «&nbsp;1.3r1&nbsp;»,
«&nbsp;2.0r2&nbsp;» devient «&nbsp;2.0r3&nbsp;» et ainsi de suite).

<p>
Notez que pendant la période de gel les développements continuent sur la
distribution instable car cette distribution reste en place quand
<em>testing</em> devient <em>frozen</em>. Quand la distribution
<em>frozen</em> devient officiellement <em>stable</em>, l'ancienne distribution
stable est entièrement supprimée de l'archive Debian (elle reste cependant
disponible à l'adresse <tt>&archive-host;</tt>).

<p>
En résumé, les distributions <em>stable</em>, <em>testing</em> et
<em>unstable</em> sont disponibles en permanence et de temps en temps, une
distribution <em>frozen</em> apparaît pour quelques mois.





        <sect1>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 ont de grandes chances 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 qui ont néanmoins une
bonne raison pour être mis en paquet). 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>
S'il y a des chances pour qu'un logiciel cause des dégats importants, il sera
sûrement préférable de le mettre dans la distribution <em>experimental</em>.
Un système de fichier compressé, par exemple, devrait probablement aller dans
<em>experimental</em>.

<p>
Une nouvelle version amont qui ajoute des nouvelles fonctions et en supprime
beaucoup de plus anciennes 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> à la discrétion 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 aller dans <em>unstable</em>, avec un
avertissement dans la description mais ce n'est pas recommandé car les paquets
de <em>unstable</em> se propagent dans <em>testing</em> et aboutissent dans
<em>stable</em>.

<p>
Un nouveau logiciel qui a peu de chance 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>
(<tt>klecker.debian.org</tt>).

        <sect id="codenames">Les noms de distribution

<p>
Chaque distribution Debian diffusée a un nom&nbsp;: Debian 1.1 s'appelle
«&nbsp;buz&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 de <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
supportées ou pour lesquelles la distribution n'a pas encore été diffusée. Ces
architectures doivent rejoindre les architectures supportées à une date
future.

<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.

<p>
Si nous avions nommé le répertoire qui contient la prochaine version àc
diffuser «&nbsp;testing&nbsp;», il aurait fallu le renommer
«&nbsp;stable&nbsp;» au moment de la diffusion, ce qui aurait forcé les
miroirs FTP à re-télécharger la distribution complète (qui est plutôt
volumineuse).

<p>
D'un autre coté, si une distribution s'appelle <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 leurs noms 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. 

<p>
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>, <em>unstable</em> et <em>frozen</em> sont des liens
symboliques qui pointent vers les répertoires appropriés.





        <chapt id="upload">La mise à jour d'un paquet


        <sect>Annoncer un nouveau paquet

<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 <tt>wnpp</tt>. 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><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>whishlist</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>
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>
Il y a plusieurs raisons qui nous poussent à demander aux responsables d'annoncer
leurs intentions&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>
        Cela permet aux autres responsables d'en savoir plus sur le nouveau
        paquet que ne le permettent la description d'une ligne et l'habituelle
        entrée «&nbsp;<em>Initial release</em>&nbsp;» que l'on trouve dans les
        fichiers <em>changelog</em> qui sont postés sur
        <tt>debian-devel-changes</tt>.

        <p>
        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.

        <p>
        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 nouveautés du
        projet.

        </list>


        <sect1 id="upload-checking">Vérifier le paquet avant la mise à jour

<p>
Avant de mettre à jour votre paquet vous ferez quelques tests de base. Vous
devrez au moins faire les tests suivants (il vous faut une ancienne version
du paquet pour cela)&nbsp;:
        <list compact>
        <item>
        Installez le paquet et vérifiez que le logiciel fonctionne. Si le
        paquet existait déjà dans une version plus ancienne, faites une mise à
        jour.

        <item>
        Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
        <prgn>lintian</prgn> comme suit&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
        par les messages générés par <prgn>lintian</prgn> essayez l'option
        <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
        bavard dans sa description du problème.
        <p>
        En principe, un paquet pour lequel
        <prgn>lintian</prgn> génère des erreurs (elles commencent par
        <tt>E</tt>) <em>ne doit pas</em> être installé dans l'archive.
        <p>
        Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la
        section lintian <ref id="lintian">.
        
        <item>
        Faites régresser le paquet
        vers sa version précédente si elle existe &mdash; cela permet de tester les
        scripts <tt>postrm</tt> et <tt>prerm</tt>.

        <item>
        Désinstallez le paquet et réinstallez-le.

        </list>



        <sect>Générer le fichier « changes »
<p>
Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit
être accompagnée d'un fichier <tt>.changes</tt>. Ce fichier explique à
l'administrateur de l'archive Debian ce qu'il doit faire du paquet. Il est en
général créé par <prgn>dpkg-genchanges</prgn> au cours du processus de
fabrication du paquet.

<p>
Le fichier <tt>changes</tt> est un fichier de contrôle qui contient les champs
suivants&nbsp;:

<p>
&control-file-fields;

<p>
Tous ces champs sont obligatoires pour une installation sur les serveurs
Debian.  Vous pouvez consulter la liste des champs de contrôle dans le
<url id="&url-debian-policy;" name="Debian Policy Manual"> pour connaître
les valeurs que prennent ces champs. Vous pouvez fermer un rapport de bogue
automatiquement avec le champ <tt>Description</tt> (voir <ref
id="upload-bugfix">).


        <sect1>L'archive des sources amonts
<p>
La première fois qu'un paquet est installé dans l'archive pour une version
amont donnée, le fichier <tt>tar</tt> de cette version amont doit être
téléchargé et mentionné dans le fichier <tt>.changes</tt>. Par la suite, ce
fichier <tt>tar</tt> sera utilisé pour générer les fichiers <tt>diff</tt> et
<tt>.dsc</tt> et il ne sera pas nécessaire de le re-télécharger.

<p>
Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn>
incluront le fichier <tt>tar</tt> amont si et seulement si le numéro de
révision du paquet source est 0 ou 1, ce qui indique une nouvelle version
amont. Ce comportement peut être modifié en utilisant <tt>-sa</tt> pour
l'inclure systématiquement ou <tt>-sd</tt> pour ne jamais l'inclure.

<p>
Si la mise à jour ne contient pas le fichier <tt>tar</tt> des sources
originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
fichiers <tt>.dsc</tt> et <tt>diff</tt> de la mise à jour, utiliser un fichier
<tt>tar</tt> identique à l'octet près à celui sur le serveur. Si pour une
raison ou pour une autre il y a une différence, la nouvelle version de ce
fichier doit à nouveau être incluse dans la mise à jour (en utilisant l'option
<tt>-sa</tt> par exemple).




        <sect1 id="upload-dist">Choisir une distribution

<p>
Le champ <tt>Distribution</tt>, qui provient de la première ligne du fichier
<file>debian/changelog</file>, indique à quelle distribution le paquet est
destiné.

<p>
Il y a quatre valeurs possibles pour ce champ&nbsp;: <em>stable</em>,
<em>unstable</em>, <em>frozen</em> et <em>experimental</em>&nbsp;. En temps
normal, les paquets sont téléchargés dans <em>unstable</em>.

<p>
Ces valeurs peuvent être combinées mais seules quelques combinaisons ont
un sens. Si la distribution a été gelée et si vous voulez livrer une correction
de bogue sur <em>frozen</em>, il faudra indiquer <em>frozen unstable</em> dans
le champ distribution. Se reporter à <ref id="upload-frozen"> pour en savoir
plus sur les mises à jour de <em>frozen</em>).

<p>
Vous devriez éviter de combiner <em>stable</em> avec d'autres cibles à cause
des problèmes potentiels de dépendance de bibliothèque (pour votre paquet et
pour les paquets fabriqués par le démon de compilation pour les autres
architectures). Se reporter à <ref id="upload-stable"> pour savoir quand et
comment faire une mise à jour de <em>stable</em>.

<p>
Notez bien que combiner <em>experimental</em> avec quelque distribution
que ce soit n'a pas de sens.


        <sect2 id="upload-frozen">Mettre à jour un paquet de la distribution <em>frozen</em>

<p>
Le gel de la distribution est un moment crucial pour Debian. C'est l'occasion
de synchroniser et de stabiliser notre distribution en un tout
cohérent. Il faut donc être très vigilant quand on fait une mise à jour
pour <em>frozen</em>.

<p>
Il est tentant de toujours mettre en paquet la dernière version d'un logiciel
pour Debian&nbsp;; mais il est bien plus important que le système soit stable et
qu'il fonctionne de la manière attendue.

<p>
Le mot d'ordre pour télécharger vers <em>frozen</em> est&nbsp;: <strong>pas de code
nouveau</strong>. C'est une chose difficile à quantifier, voici quelques
conseils&nbsp;:

<p>
        <list compact>
        <item>
        Les corrections de bogues de gravité <em>critique</em>,
        <em>grave</em> ou <em>sérieuse</em><footnote>respectivement
        <em>critical</em>, <em>grave</em> ou <em>serious</em></footnote> sont
        toujours autorisées pour les paquets qui doivent exister dans la
        distribution.

        <item>
        Les corrections pour les bogues de gravité <em>critique</em>,
        <em>grave</em> ou <em>sérieuse</em><footnote>respectivement
        <em>critical</em>, <em>grave</em> ou <em>serious</em></footnote> sont
        autorisées pour les paquets non indispensables uniquement si elles
        n'ajoutent pas de nouvelle fonctionnalité.

        <item>
        Les corrections pour les bogues de gravité <em>importante</em>,
        <em>normale</em> et <em>mineure</em><footnote>respectivement
        <em>important</em>, <em>normal</em> et <em>minor</em></footnote> sont
        autorisées, bien que découragées, sur tous les paquets si et seulement
        s'elles n'ajoutent pas de nouvelle fonctionnalité. 

        <item>
        Les corrections de gravité <em>wishlist</em> ne sont pas autorisées (ce
        ne sont pas vraiment des bogues après tout).

        <item>
        Les corrections liées à la documentation sont autorisés car il est
        important d'avoir une bonne documentation.

        </list> 

<p> 
L'expérience montre qu'il y a 15% de chance d'introduire un nouveau bogue en
corrigeant un autre bogue. L'introduction et la découverte d'un nouveau bogue
retarde la mise à disposition de la distribution ou affaiblit le produit
final.  Il y a très peu de corrélation entre la gravité du bogue corrigé et
la gravité du bogue introduit par la correction.


        <sect2 id="upload-stable">Mettre à jour un paquet de la distribution <em>stable</em>

<p>
Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
sera dirigé vers le répertoire <tt>proposed-updates</tt> des archives Debian
pour y être testé avant d'être effectivement inclus dans <em>stable</em>.

<p>
Une livraison pour la distribution <em>stable</em> requière des soins
supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
que dans les cas suivants&nbsp;:

        <list>
        <item>un problème de sécurité (un avis de sécurité
        Debian<footnote>Debian security advisory.</footnote>),
        <item>un probleme fonctionnel vraiment critique,
        <item>un paquet devenu ininstallable,
        <item>un paquet indisponible pour une architecture.
        </list>

<p>
Il est fortement déconseillé de changer quoi que ce soit si ce n'est pas
important car même une modification triviale peut causer un bogue plus 
tard. Livrer une nouvelle version amont d'un logiciel pour corriger un 
problème de sécurité est désapprouvé&nbsp;; dans la plupart des cas la
bonne solution consiste à prendre le <em>patch</em> correspondant de la
nouvelle version amont et à l'appliquer à l'ancienne (faire un
<em>backport</em> du <em>patch</em>).

<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
librairie qui n'est disponible que dans <em>unstable</em> sera rejeté.
Modifier les dépendances d'autres paquets (en manipulant le champ
<tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
ininstallables, est fortement déconseillé.

<p>
L'équipe responsable de la distribution<footnote><em>the Release
team</em></footnote> (joignable à l'adresse &email-debian-release;) évaluera
régulièrement le contenu de <em>proposed-updates</em> et décidera si votre
paquet peut être inclus dans la distribution <em>stable</em>. Soyez précis
(et, si nécéssaire, généreux) quand vous décrivez, dans le fichier changelog,
vos changements pour une livraison vers <em>stable</em> sinon le paquet ne
sera pas considéré.



        <sect id="uploading">Mettre à jour un paquet


        <sect1 id="upload-ftp-master">Installer un paquet sur
        <tt>ftp-master</tt> 

<p>
Pour installer un paquet vous avez besoin d'un compte sur
<ftpsite>ftp-master</ftpsite>, ce que vous devez avoir en tant que
développeur Debian. Si vous utilisez <prgn>scp</prgn> ou <prgn>rsync</prgn>
pour télécharger vos paquets, placez-les dans
<tt>&us-upload-dir;</tt>.  Si vous utilisez un FTP anonyme,
placez-les dans <ftppath>/pub/UploadQueue/</ftppath>.

<p>
<em>Note&nbsp;:</em> ne téléchargez pas de paquet soumis aux lois de contrôle des
exportations américaines sur le serveur <tt>ftp-master</tt>, ni sur les serveurs
<tt>chiark</tt> et <tt>erlangen</tt>. Cet interdit couvre à peu près tous les
logiciels de cryptographie ainsi que quelques logiciels liés aux logiciels de
cryptographie comme les clients de courrier électronique qui utilisent le
cryptage et l'authentification PGP. Ces logiciels doivent être téléchargés sur
le serveur <tt>non-us</tt>. Reportez-vous à la section <ref
id="upload-non-us"> pour en savoir plus. Si vous ne savez pas si votre paquet
est soumis aux lois de contrôle des exportations américaines posez la question sur la
liste &email-debian-devel;.

<p>
Le paquet <package>dupload</package> pourra vous faciliter le travail lors du
téléchargement. Ce programme, bien pratique, est configuré par défaut pour
se connecter par FTP sur les serveurs <tt>ftp-master</tt>,
<tt>chiark</tt> et <tt>erlangen</tt>. Il peut aussi être configuré pour
utiliser <prgn>ssh</prgn> ou <prgn>rsync</prgn>. Se reporter à <manref
name="dupload" section="1"> et <manref name="dupload" section="5"> pour en
savoir plus.

<p>
Après avoir téléchargé votre paquet, vous pouvez vérifier ce qu'en fera le 
logiciel de maintenance de l'archive en exécutant <prgn>dinstall</prgn>
sur votre fichier <file>.changes</file>&nbsp;:

<example>dinstall -n foo.changes</example>





        <sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
        (pandora) 

<p>
Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
exportations américain ne doivent pas être installés sur <tt>ftp-master</tt>.
Utilisez <prgn>scp</prgn> ou <prgn>rsync</prgn> pour copier votre paquet sur
<ftpsite>non-us.debian.org</ftpsite>. Placer les fichiers dans le répertoire
<tt>&non-us-upload-dir;</tt>.  Par défaut, vous pouvez utiliser le même
<em>login/mot de passe</em> que pour <tt>ftp-master</tt>.  Si vous utilisez
une connexion FTP anonyme pour le téléchargement, placez vos fichiers dans le
répertoire <ftppath>/pub/UploadQueue/</ftppath>.

<p>
Le programme <prgn>dupload</prgn> est, lui aussi, capable de télécharger sur
<tt>non-us</tt>&nbsp;; consultez la documentation de ce programme pour en savoir
plus.

<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.

<p>
Le <em>Debian Policy Manual</em> n'empêche pas les résidents et citoyens
américains de livrer des paquets sur <tt>non-US</tt> mais ils devront être
vigilants en le faisant.  Nous recommandons aux responsables concernés de
prendre toutes les précautions nécessaires, <em>y compris la consultation d'un
juriste</em>, pour s'assurer qu'ils n'enfreignent pas une loi américaine en
livrant un paquet sur <tt>non-US</tt>.

<p>
Pour les paquets des sections <em>non-US/main</em> et <em>non-US/contrib</em>
les responsables devraient au moins suivre la <url id="&url-u.s.-export;"
name="procédure décrite par le gouvernement américain">. Les responsables de
paquets <em>non-US/non-free</em> devront en plus consulter les <url
id="&url-notification-of-export;" name="règles de déclaration d'exportation
pour les logiciels commerciaux">.

<p>
Cette section a pour seul but d'informer, elle n'a pas valeur de conseil
juridique. Une fois encore, nous recommandons aux résidents et citoyens
américains de consulter un juriste avant de livrer un paquet sur
<tt>non-US</tt>.


        <sect1>Installer un paquet via <tt>chiark</tt>

<p>
Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs
possibilités. L'une d'elles consiste à télécharger vos fichiers dans
<tt>Incoming</tt> en passant par le serveur <tt>chiark</tt> en Europe. Comme
cette file d'attente des mises à jour est redirigée 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&nbsp;:

<p>
        <url id="&url-upload-erlangen;">.

<p>
Le téléchargement fait sur ce serveur doit être aussi complet que s'il
était fait dans le répertoire <tt>Incoming</tt> sur <tt>ftp-master</tt> :
il doit comporter le fichier <file>.changes</file> et tous les fichiers 
mentionnés dans ce dernier. Le serveur vérifie que le fichier 
<tt>.changes</tt> est bien signé avec la clé PGP d'un développeur Debian pour 
éviter que des faux paquets n'atteignent <tt>ftp-master</tt>. Vérifiez bien 
que le champ <tt>Maintainer</tt> du fichier <tt>.changes</tt> contient 
<em>votre</em> adresse électronique. De même que sur <tt>ftp-master</tt>, 
cette adresse est ensuite utilisée pour toutes les réponses.

<p>
Il n'est pas nécessaire de déplacer votre fichier dans un autre répertoire
après le téléchargement, contrairement au serveur <tt>chiark</tt>. Vous
devriez ensuite recevoir un courrier du serveur expliquant ce qu'il a fait de
votre paquet. Normalement, il devrait avoir été déplacé vers
<tt>ftp-master</tt>&nbsp;;
vous serez informé par le même biais si une erreur s'est produite au cours du
processus.

<p>
<em>Note&nbsp;:</em> ne téléchargez pas de paquets contenant des logiciels tombant
sous le coup de la loi de contrôle des exportations américaine sur
<tt>erlangen</tt>. Comme les paquets téléchargés ici vont vers
<tt>ftp-master</tt>, les règles décrites dans 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;">.




        <sect id="upload-announce">Annoncer une mise à jour

<p>
Quand un paquet est mis à jour, une annonce doit être envoyée sur l'une des
listes «&nbsp;debian-changes&nbsp;». Ceci est maintenant géré automatiquement
par le logiciel de gestion de l'archive quand il est exécuté (en principe une
fois par jour). Vous devez juste utiliser une version récente de
<package>dpkg-dev</package> (&gt;= 1.4.1.2). Le courrier généré par le
logiciel de maintenance de l'archive contiendra le fichier <tt>.changes</tt>
signé que vous avez livré avec votre paquet. Précédemment, cette charge
revenait à <prgn>dupload</prgn>&nbsp;; vérifiez que vous avez bien configuré
<prgn>dupload</prgn> pour qu'il n'envoie pas ces annonces (cherchez
<tt>dinstall_runs</tt> dans la documentation de <prgn>dupload</prgn>).

<p>
Si un paquet est mis à jour pour la distribution <em>stable</em>, l'annonce
est envoyée sur la liste&nbsp;:

<p>
<tt>   &email-debian-changes;.</tt>

<p>
S'il est mis à jour pour les distributions <em>unstable</em>,
<em>experimental</em> ou <em>frozen</em>, l'annonce est envoyée sur la liste
&email-debian-devel-changes;.

<p>
Le programme <prgn>dupload</prgn> est suffisamment intelligent pour déterminer
où devra aller l'annonce et pour envoyer le courrier sur la bonne liste. Voir <ref
id="dupload">.




        <sect id="upload-notification">
        <heading>Notification de l'installation d'un nouveau paquet</heading>

<p>
Les administrateurs de l'archive Debian sont responsables de l'installation
des mises à jour. La plupart des mises à jour sont gérées
quotidiennement par le logiciel de gestion de l'archive <prgn>katie</prgn>.
Les mises à jour
de paquets sur la distribution <em>unstable</em>, en particulier, sont
installés ainsi. Dans les autres cas et notamment dans le cas d'un nouveau
paquet, celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois
entre le téléchargement d'un paquet vers un serveur et son installation
effective. Soyez patients.

<p>
Dans tous les cas vous recevrez un accusé de réception par courrier
électronique indiquant que votre paquet a été installé et quels rapports
de bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous
les rapports de bogues que vous vouliez clore sont bien dans cette liste. 

<p>
L'accusé de réception indique aussi la section dans laquelle le paquet a
été installé. S'il ne s'agit pas de votre choix, vous recevrez un second
courrier qui vous informera de cette différence (voir plus loin).




        <sect1 id="override-file">Le fichier <em>override</em>

<p>
Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
<file>debian/control</file> n'indiquent ni où le paquet sera installé dans
l'archive Debian ni sa priorité. Afin de conserver la
cohérence de l'archive, ce sont les administrateurs qui contrôlent ces
champs. Les valeurs du fichier <file>debian/control</file> sont juste des
indications.

<p>
Les administrateurs de l'archive indiquent les sections et priorités des paquets
dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le
fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez
informé par courrier électronique quand votre paquet sera installé dans
l'archive. Vous pourrez corriger votre fichier <em>debian/control</em>
avant votre prochain téléchargement ou alors vous aurez envie de modifier le
fichier <em>override</em>.

<p>
Pour modifier la section dans laquelle un paquet est archivé, vous devez
d'abord vérifier que fichier <file>debian/control</file> est correct. Ensuite,
envoyez un courrier à &email-override; ou un rapport de bogue sur le pseudo
paquet <package>ftp.debian.org</package> demandant la modification de la
section ou de la priorité de votre paquet. Exposez bien les raisons qui vous
amènent à demander ces changements.

<p>
Pour en savoir plus sur le fichier <em>override</em>, reportez-vous à <manref
name="dpkg-scanpackages" section="8">, &file-bts-mailing; et &file-bts-info;.




        <chapt id="nmu">Mise à jour indépendante

<p>
Dans certaines circonstances il est nécessaire qu'une personne autre que le
responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de mise à
jour est désigné en anglais par l'expression <em>non-maintainer upload
(NMU)</em>.  Dans le présent document, nous traduisons librement cette
expression par «&nbsp;mise à jour indépendante&nbsp;».

<p>
Ces mises à jour indépendantes font partie du travail normal des porteurs qui
compilent les paquets pour d'autres architectures (voir <ref id="porting">).
Nous faisons aussi des mises à jour indépendantes quand un développeur Debian 
corrige le paquet d'un autre développeur pour éliminer un trou de sécurité
ou un bogue paralysant. Cela se produit plus particulièrement en période de
gel de la distribution de développement ou quand le responsable officiel du
paquet ne peut pas fournir une correction dans un délai raisonnable.

<p>
Ce chapitre contient des informations qui vous expliqueront quand et comment
faire des mises à jour indépendantes. Une distinction fondamentale doit être
faite entre les mises à jour indépendantes sources et les mises à jour 
indépendantes binaires. Elle est explicitée dans la section suivante.


        <sect id="nmu-terms">Terminologie

<p>
Deux nouvelles expressions sont introduites dans cette section&nbsp;: 
«&nbsp;mise à jour indépendante source&nbsp;» et «&nbsp;mise à 
jour indépendante binaire&nbsp;». Ces expressions ont une définition
précie 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, un fichier <em>diff</em>
modifié ou, plus rarement, des nouveaux sources amonts.

<p>
Une mise à jour indépendante binaire est la recompilation et l'archivage
d'un paquet pour une architecture donnée. Il s'agit souvent du résultat d'un
effort de portage. Une mise à jour indépendante binaire est la livraison d'un
paquet compilé (souvent pour une autre architecture) à condition que cette
compilation n'ait pas nécessité de modifications des sources. Dans de 
nombreux cas, les porteurs
sont obligés de modifier les sources pour les rendre compilables sur leur
architecture cible&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>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 «&nbsp;mise à jour
indépendante&nbsp;» seul, il s'agit des deux types de livraisons.





        <sect 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 <em>patch</em> qui le méritent au
système de suivi des bogues. Les responsables apprécient presque toujours les
<em>patch</em> et les rapports de bogue soignés.


        <sect 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. stable, instable ou
gelée). Les porteurs, ayant une activité particulière, obéissent à des règles
légèrement différentes (voir <ref id="source-nmu-when-porter">).

<p>
Quand une faille de sécurité est détectée, un
paquet corrigé doit être livré le plus tôt possible. Dans ce cas, un membre de
l'équipe de sécurité Debian<footnote>Debian Security officer</footnote>
entrera en contact
avec le responsable du paquet pour s'assurer qu'un paquet corrigé sera livré dans
un délai raisonnable (moins de 48&nbsp;heures). Si le mainteneur ne peut
fournir une mise à jour suffisamment vite ou s'il ne peut être joint à temps,
l'équipe de sécurité pourra corriger le paquet (i.e. faire une mise à jour
indépendante source).

<p>
Pendant la phase de gel (voir <ref id="upload-frozen">), les livraisons qui
corrigent les bogues de gravité <em>sérieuse</em> (i.e. <em>serious</em>) et
supérieures sont encouragées et acceptées. Même pendant cette période, vous
devrez tenter d'entrer en contact avec le responsable du paquet&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.

<p>
Les mises à jour indépendantes sont aussi acceptable pour la distribution
instable mais seulement en dernier ressort
ou avec une autorisation. Essayez d'abord ce qui suit et si cela ne fonctionne
pas il est probablement correct de faire une mise à jour indépendante 
<em>(NMU)</em>&nbsp;:

<p>
        <list compact>
        <item>
        Vérifiez que le bogue est bien référencé dans le système de suivi des
        bogues.  S'il n'y est pas, faites un rapport de bogue.

        <item>
        Envoyez un courrier au responsable du paquet et proposez votre aide
        pour corriger le bogue. Donnez-lui quelques jours.

        <item>
        Lancez-vous. Corrigez le bogue et envoyez votre <em>patch</em> au système de
        suivi des bogues. Construisez le paquet et testez-le comme décrit dans
        la section <ref id="upload-checking">. Utilisez le paquet chez vous.

        <item>
        Attendez une réponse pendant quelques semaines.

        <item>
        Envoyez un courrier au responsable lui demandant son accord pour faire
        une mise à jour indépendante <em>(NMU)</em>.

        <item>
        Vérifiez une nouvelle fois que votre modification n'a pas d'effet de
        bord inattendu et qu'elle est aussi minimaliste et peu intrusive que
        possible.

        <item>
        Attendez une réponse une semaine encore.

        <item>
        Faites votre mise à jour indépendante comme décrit dans la section
        <ref id="nmu-guidelines">.  

        </list>






        <sect id="nmu-guidelines">Comment faire une mise à jour indépendante
        source&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 <em>patch</em> 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 faits lors d'une mise à jour indépendante.





        <sect1 id="nmu-version">Numéro de version pour les mises à jour
        indépendantes sources

<p>
Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
changer, même pour la plus triviale des modifications. Notre système de
gestion de paquets s'appuie sur ces numéros de version.

<p>
Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
un numéro de version mineur à la partie <var>debian-revision</var> du numéro
de version (la partie qui suit le dernier trait d'union). Ce numéro
supplémentaire débutera à «&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;». Notez que pour
faire cela vous devrez utiliser <prgn>dpkg-buildpackage</prgn> avec l'option
<tt>-sa</tt> pour le forcer à utiliser le nouveau paquet source (par défaut il
reconnaît les numéros de révisions «&nbsp;0&nbsp;» ou «&nbsp;1&nbsp;» &mdash; il
n'est pas suffisamment intelligent pour reconnaître «&nbsp;0.1&nbsp;»).

<p>
Attention, les porteurs qui ne font que recompiler les paquets pour d'autres
architectures n'ont pas besoin de renuméroter les paquets. Les porteurs ne
doivent utiliser de nouveaux numéros de version que s'ils modifient les
paquets sources qu'ils recompilent, c'est-à-dire s'ils font une mise à jour
indépendante source et non une mise à jour indépendante binaire.





        <sect1 id="nmu-changelog">
          <heading>Les mises à jour indépendantes sources doivent être
          mentionnées dans le fichier changelog</heading>

<p>
Une personne qui fait une mise à jour indépendante source doit ajouter une
entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
version livrée.

<p>
Par convention, dans le cas d'une mise à jour indépendante source
<em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne

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





        <sect1 id="nmu-patch">Mise à jour indépendante source et système
        de suivi des bogues 

<p>
Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
modifications que possible et doit toujours envoyer ses modifications au
système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).

<p>
En cas de simple recompilation du paquet, le processus diffère
suivant que vous agissez en tant que porteur ou pas. Si vous faites une mise
à jour indépendante qui ne nécessite rien de plus qu'une recompilation et
n'agissez pas en temps que porteur (i.e. une nouvelle bibliothèque partagée
est disponible, un bogue a été corrigé dans <package>debhelper</package>),
vous devez tout de même ajouter une entrée dans le fichier <em>changelog</em>;
il y aura donc une modification. Si vous êtes porteur, vous êtes probablement
en train de faire une mise à jour indépendante binaire. (Note&nbsp;: ce système ne
tient pas compte des porteurs qui font des recompilations &mdash; tenez cela pour
une faiblesse de notre système de gestion des paquets.)

<p>
Si la mise à jour indépendante source corrige des bogues, vous devez le
<em>notifier</em> au système de suivi des bogues mais vous ne devez pas
<em>clore</em> les rapports de bogue. Seul le responsable officiel d'un paquet
et le rapporteur du bogue sont autorisés à fermer un rapport de bogue.
Cependant, la personne qui fait une mise à jour indépendante doit envoyer une
note à chaque bogue concerné expliquant qu'il est corrigé par cette mise à
jour indépendante.  Cette personne doit ensuite utiliser l'adresse
<email>control@bugs.debian.org</email> pour modifier la gravité des bogues
corrigés et leur donner la valeur <em>corrigé</em> (i.e. <em>fixed</em>).
Cela permet de s'assurer 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. Si nécessaire, ouvrez des rapports de bogue
avec les <em>patch</em> correspondants ou assurez-vous que l'un des rapports de
bogue déjà ouverts comporte ces <em>patch</em>.

<p>
Le responsable officiel pourra choisir d'appliquer le <em>patch</em>, 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 sans utiliser les <em>patch</em> de la mise à jour
indépendante, il devra s'assurer que cette nouvelle version corrige
effectivement chacun des bogues corrigés dans la mise à jour indépendante.

<p>
De plus, le responsable officiel devrait <em>toujours</em> conserver les
entrées documentant une mise à jour indépendante dans le fichier
<file>changelog</file>.






        <sect1 id="nmu-build">Fabriquer une mise à jour indépendante source

<p>
Les paquets faisant l'objet d'une mise à jour indépendante source sont 
construits comme les
autres. Sélectionnez une distribution en utilisant les règles décrites dans
la section <ref id="upload-dist"> et construisez un fichier <tt>.changes</tt>
classique avec tout ce qui l'accompagne conformément à la description <ref
id="upload">.

<p>
En fait, toutes les prescriptions de la section <ref id="upload"> sont
applicables ici, y compris l'obligation d'annoncer la mise à jour sur la liste
idoine.

<p>
Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt>
dans le fichier <file>debian/control</file>. Votre nom, mentionné dans
l'entrée du fichier <file>debian/changelog</file> concernant la mise à jour, 
sera utilisé pour signer le fichier <tt>.changes</tt>.




        <chapt id="porting">Le portage

<p>
Debian supporte un nombre croissant d'architectures. Même si vous n'êtes pas
un porteur et même si vous n'utilisez qu'une architecture, il est de votre
responsabilité de développeur d'être attentif aux questions de portabilité.
C'est pourquoi il est important que vous lisiez ce chapitre même si vous
n'êtes pas un porteur.
        
<p>
Porter un paquet consiste à faire un paquet binaire pour une architecture
différente de celle du paquet binaire fait par le responsable du paquet. 
C'est une
activité remarquable et essentielle. En fait, les porteurs sont à l'origine
de la plupart des compilations de paquet Debian. Pour un paquet binaire
<em>i386</em>, par exemple, il faut compter une recompilation pour chaque
autre architecture, soit un total de &number-of-arches; recompilations.




        <sect id="kind-to-porters">Être gentil avec les porteurs

<p>
Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un 
grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
modification. Malheureusement, c'est rarement le cas. Cette section contient
une liste d'erreurs commises régulièrement par les responsables Debian &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 bogues 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 une
<em>checklist</em> de choses auxquelles vous devez être attentif :

        <enumlist>
        <item>
        Vérifiez que les champs <tt>Build-Depends</tt> et
        <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
        corrects. Le meilleur moyen pour vérifier cela est d'utiliser le
        paquet <package>debootstrap</package> pour créer un environnement
        <em>unstable</em> <em>chrooté</em>. Dans cet environnement
        <em>chrooté</em> il faudra installer le paquet
        <package>build-essential</package> et tous les paquets mentionnés dans
        les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
        Ensuite, vous essayerez de fabriquer votre paquet dans cette
        environnement.
        <p>
        Consultez le <url id="&url-debian-policy;" name="Debian Policy
        Manual"> pour en savoir plus sur les dépendances de fabrication.
        <item>
        Ne choisissez pas d'autre valeur que <em>all</em> ou <em>any</em> pour
        le champ architecture sans avoir de bonnes raisons pour le faire. Trop
        souvent, les développeurs ne respectent pas les instructions du
        <url id="&url-debian-policy;" name="Debian Policy Manual">. Choisir
        la valeur «&nbsp;i386&nbsp;» est la plupart du temps incorrect.

        <item>
        Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
        <var>package</var>.dsc</tt> pour vous assurer que le paquet se
        désarchive correctement. En utilisant le résultat de ce test,
        construisez votre paquet binaire à l'aide de la commande
        <tt>dpkg-buildpackage</tt>.

        <item>
        Vérifiez que les fichiers <file>debian/files</file> et
        <file>debian/substvars</file> ne sont pas dans votre paquet source.
        Ils doivent être effacés par la cible <em>clean</em> de
        <file>debian/rules</file>.

        <item>
        Assurez-vous que vous ne vous appuyez pas sur des éléments de
        configuration ou des logiciels installés ou modifiés localement. Par
        exemple, vous ne devriez jamais appeler des programmes du répertoire
        <file>/usr/local/bin</file> ou de répertoires équivalents.  Essayez de ne pas vous
        appuyer sur des logiciels configurés de manière spéciale. Essayez de
        construire votre paquet sur une autre machine, même s'il s'agit de la
        même architecture.

        <item>
        Ne vous appuyez pas sur une installation préexistante de votre paquet
        (un sous-cas de la remarque précédente).

        <item>
        Si possible, ne vous appuyez pas sur une particularité présente dans
        un compilateur précis ou dans certaine version d'un compilateur. Si
        vous ne pouvez pas faire autrement, assurez-vous que les dépendances
        de fabrication reflètent bien cette restriction. Dans ce cas, vous
        cherchez sûrement les problèmes car quelques architectures pourraient
        choisir un compilateur différent.

        <item>
        Vérifiez que votre <file>debian/rules</file> distingue les cibles
        <em>binary-arch</em> et <em>binary-indep</em> comme l'exige le
        <em>Debian packaging manual</em>. Vérifiez que ces cibles sont
        indépendantes l'une de l'autre, c'est à dire qu'il n'est pas
        nécessaire d'invoquer l'une de ces cibles avant d'invoquer l'autre.
        Pour vérifier cela, essayez d'exécuter <tt>dpkg-buildpackage -b</tt>.

        </enumlist>




        <sect id="porter-guidelines">Instructions pour les mises à jour des
        porteurs

<p>
Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez
de la chance et votre travail est facile. Cette section s'applique dans ce
cas&nbsp;; elle décrit comment construire et installer correctement votre mise à
jour indépendante binaire dans l'archive Debian. Si vous devez modifier le
paquet pour le rendre compilable sur votre architecture cible vous devez faire
une mise à jour des sources, consultez la section <ref id="nmu-guidelines">.

<p>
Pour une mise à jour indépendante binaire, ne faites pas de changement
dans les sources. Vous n'avez pas besoin de modifier les fichiers du paquet
source (cela inclut <file>debian/changelog</file>).

<p>
La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante :
<tt>dpkg-buildpackage -B -e<var>adresse-porteur</var></tt>. Bien sûr,
remplacez <var>adresse-porteur</var> par votre adresse électronique. Cette
commande construira les portions du paquet qui dépendent de l'architecture, en
utilisant la cible <em>binary-arch</em> de <file>debian/rules</file>.


        <sect1 id="recompile-nmu-versioning">
        <heading>Numéro de version des mises à jour indépendantes
        binaires</heading>

<p>
Parfois il est nécessaire de recompiler des paquets quand d'autres paquets,
tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez
changer le numéro de version pour que le système de comparaison des numéros de
version fonctionne correctement. Ce type de mise à jour reste une mise à jour
indépendante binaire &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 « magiques » pour que le
système de maintenance de l'archive comprennent que, bien qu'il y ait une
nouvelle version, il n'y a pas eu de modification des sources. Si vous ne
faites pas cela correctement, les administrateurs de l'archive rejetteront
votre mise à jour (car il n'y aura pas de code source associé).

<p>
Cette magie associée à une mise à jour par recompilation est déclenchée en
utilisant un troisième nombre dans la partie debian du numéro de version.  Si,
par exemple, la dernière version du paquet que vous recompilez était
«&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;».



        
        <sect1 id="source-nmu-when-porter"> <heading>Quand faire une mise à
        jour indépendante source pour un portage&nbsp;?</heading>

<p>
Les porteurs qui font des mises à jour indépendantes sources suivent
généralement les instructions de la section <ref id="nmu"> tout comme les
non-porteurs. Les délais d'attente sont cependant plus courts car les porteurs
doivent manipuler un grand nombre de paquets.

<p>
À nouveau, la situation diffère selon la distribution visée. Une correction
cruciale (i.e. rendre un paquet compilable sur une architecture supportée par
la prochaine distribution) peut être installée <em>sans</em> délai pour la
distribution gelée.

<p>
Si vous êtes porteur et faites une mise à jour pour <em>unstable</em>, les
instructions précédentes sont applicables à deux différences près. Tout
d'abord, le temps d'attente raisonnable &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.




        <sect>Outils pour les porteurs

<p>
Il y a plusieurs outils pour le travail de portage. Cette section contient
une courte description de ces outils&nbsp;; reportez-vous à la documentation de
leurs paquets ou aux références citées ci-après pour une description complète.




        <sect1 id="quinn-diff">
        <heading><package>quinn-diff</package>

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





        <sect1 id="buildd">
        <heading><package>buildd</package>

<p>
Le système <package>buildd</package> est un système distribué pour la
compilation d'une distribution. Il est habituellement utilisé en conjonction
avec des automates de compilation&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. Il regroupe un ensemble de composants très utiles,
continuellement utilisés mais non encore mis en paquet, tels que
<prgn>andrea</prgn>, <prgn>sbuild</prgn> et <prgn>wanna-build</prgn>.

<p>
Une partie des informations produites par <package>buildd</package> &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
enthousiasmés par ce système car il a de nombreux usages potentiels. Des
groupes de développeurs indépendants peuvent utiliser ce système pour créer
différentes saveurs de la Debian &mdash; qui peuvent être ou ne pas être
intéressantes pour tous (une version de Debian compilée avec des vérifications
relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi de recompiler
rapidement toute une distribution.




        <sect1 id="dpkg-cross">
        <heading><package>dpkg-cross</package>

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





        <chapt id="archive-manip">
        <heading>Déplacer, effacer, renommer, adopter et abandonner des
        paquets</heading>

<p>
Certaines manipulations de l'archive ne sont pas accessibles avec le processus
de mise à jour automatisé. Elles sont appliquées manuellement par les
développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.




        <sect>Déplacer des paquets

<p>
Parfois un paquet pourra changer de section. Une nouvelle version d'un paquet
de la section <tt>non-free</tt> pourrait par exemple être distribuée sous
licence LGP GNU&nbsp;; dans ce cas le paquet doit être déplacé dans la section
<tt>main</tt> ou <tt>contrib</tt><footnote> Reportez-vous  au <url
id="&url-debian-policy;" name="Debian Policy Manual"> pour savoir dans quelle
section un paquet doit être classé.</footnote>.

<p>
Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez
les informations de contrôle du paquet pour le placer dans la section désirée
et téléchargez à nouveau votre paquet dans l'archive. Reportez-vous au
<url id="&url-debian-policy;" name="Debian Policy Manual"> pour en savoir
plus.  Lisez attentivement le rapport d'installation qui vous sera envoyé lors
de l'archivage de votre paquet. Si pour une raison ou une autre le paquet
est toujours à son ancien emplacement, envoyez un rapport de bogue sur le
pseudo-paquet <tt>ftp.debian.org</tt> demandant la suppression dudit paquet.
Décrivez précisément vos manipulations car il pourrait s'agir d'un bogue dans
le logiciel de gestion de l'archive.

<p>
Si vous avez besoin de modifier la sous-section de l'un de vos paquets
(<tt>devel</tt> ou <tt>admin</tt> par exemple) la procédure est légèrement
différente. Modifiez la sous-section dans le fichier de contrôle de votre
paquet et téléchargez-le. Il vous faudra ensuite demander la modification du
fichier <em>override</em> comme décrit dans la section <ref
id="override-file">.




        <sect id="removing-pkgs">Supprimer des paquets

<p>
Si pour une raison ou une autre vous avez besoin de supprimer un paquet
de l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile,
que l'on conservait pour des raisons de compatibilité), il vous faudra 
envoyer un rapport de bogue concernant le pseudo-paquet
<tt>ftp.debian.org</tt> et demandant sa suppression. N'oubliez pas de
préciser de quelle distribution le paquet doit être supprimé.

<p>
Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
autres développeurs sur la liste &email-debian-devel;.  Le programme
<prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
utile. La commande <tt>apt-cache showpkg <var>package</var> </tt> vous
indiquera, entre autres, les paquets qui dépendent de <var>package </var>.

        <sect1>Supprimer des paquets dans <tt>Incoming</tt>
<p>
Si vous décidez de supprimer un paquet de la section <tt>Incoming</tt>, il
serait gentil de l'annoncer sur la liste de diffusion appropriée
(&email-debian-changes; ou &email-debian-devel-changes;). Ce n'est pas
obligatoire.



        <sect>Remplacer ou renommer un paquet

<p>
Il peut vous arriver de vous tromper en nommant un paquet et avoir besoin de le
renommer. Dans ce cas, vous devrez intervenir en deux étapes. D'abord,
modifiez votre fichier <file>debian/control</file> pour que votre paquet
renommé remplace et entre en conflit avec le nom de paquet que vous voulez
remplacer. Reportez-vous au <url id="&url-debian-policy;" name="Debian Policy
Manual"> pour les détails. Une fois que votre paquet est installé dans
l'archive, faites un rapport de bogue concernant le pseudo-paquet
<tt>ftp.debian.org</tt> et demandant la suppression du paquet mal nommé.
l'archive, faites un rapport de bogue concernant le pseudo-paquet
<tt>ftp.debian.org</tt> et demandant la suppression du paquet mal nommé.





        <sect id="orphaning">Abandonner un paquet

<p>
Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres
et faire le nécessaire pour qu'il soit marqué <em>abandonné</em>(i.e.
<em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
Group &orphan-address;</tt> dans le champ
<tt>maintainer</tt> du paquet et faire un rapport de bogue sur le
pseudo-paquet <tt>wnpp</tt>. Le titre de votre rapport de bogue devra être
«&nbsp;<tt>O<footnote><em>Orphaned</em>&nbsp;: abandonné.</footnote>:
<var>paquet</var> &mdash; <var>courte description</var></tt>&nbsp;» pour indiquer
que le paquet est orphelin. La gravité du bogue sera <em>normale</em>.
Si vous le jugez nécessaire, envoyez une copie à
&email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le
sujet du message ne contiendra pas le numéro du bogue.

<p>
Si le paquet est particulièrement important pour la distribution il vous
faudra faire un rapport de bogue sur le pseudo-paquet <tt>wnpp</tt>, titrer
«&nbsp;<tt>RFA<footnote><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 précédemment.

<p>
Reportez-vous à la page WNPP<footnote><em>Work-needing and prospective
packages</em>&nbsp;: paquets en souffrance et paquets souhaités.</footnote> <url
id="&url-wnpp;"> pour en savoir plus.





        <sect id="adopting">Adopter un paquet

<p>
Une liste des paquets en attente de nouveau responsable est disponible à la
page <url id="&url-wnpp;" name="Work-Needing and Prospective Packages">. Si
vous voulez prendre en charge un paquet de cette liste reportez-vous à la page
susmentionnée pour connaître la procédure à suivre.

<p>
Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
correct &mdash; ce serait une prise d'otage.  Vous pouvez prendre contact avec le
responsable actuel et lui demander si vous pouvez prendre en charge ce paquet.
Vous ne pouvez le faire sans son accord. Qu'il vous ignore n'est pas une
raison suffisante pour le faire. Si vous avez le sentiment qu'un responsable
est parti sans prévenir depuis un moment, demandez-le sur la liste
&email-debian-private;.

<p>
Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de
suivi des bogues indique que vous êtes le responsable du paquet. Cela se
produira automatiquement une fois que vous aurez installé une nouvelle version
du paquet dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut
prendre quelques heures après le téléchargement. Si vous pensez ne pas avoir
de mise à jour à faire pour un moment, envoyez un courrier électronique à
&email-override; pour pouvoir recevoir les rapports de bogue.





        <chapt id="bug-handling">Gérer les bogues



        <sect>Superviser les rapports de bogues

<p>
Si vous voulez être un bon responsable, vous devrez consulter régulièrement la
page du <url id="&url-bts;" name="système de suivi des bogues">. Cette page
contient tous les rapports de bogue qui concernent vos paquets.

<p>
Les responsables interagissent avec le système de suivi des bogues en
utilisant l'adresse électronique <tt>bugs.debian.org</tt>. Vous trouverez une
documentation sur les commandes disponibles à l'adresse <url id="&url-bts;">
ou, si vous avez installé le paquet <package>doc-debian</package>, dans les
fichiers locaux <file>/usr/share/doc/debian/bug-*</file>.

<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;:

<p>
<example>
# Synthèse hebdomadaire des rapports de bogue qui me concernent
0 17 * * fri echo "index maint <var>adresse</var>" | mail request@bugs.debian.org
</example>

<p>
Remplacez <var>adresse</var> par votre adresse officielle de responsable
Debian.




        <sect id="submit-bug">Ouvrir un rapport de bogue

<p>
En tant que responsable Debian, vous trouvez des bogues dans d'autres paquets
En tant que responsable Debian, vous trouvez des bogues dans d'autres paquets,
ou bien vous voulez réassigner à d'autres paquets des rapports de bogue 
concernant vos paquets. La page d'aide du <url id="&url-bts-control;"
name="système de suivi des bogues"> vous explique comment procéder.

<p>
Nous vous encourageons à ouvrir des rapports de bogue s'il y a des problèmes.
Essayez de soumettre ces rapports depuis un compte utilisateur où vous pouvez
recevoir du courrier. Ne les envoyez pas en tant que <em>root</em>.

<p>
Vérifiez que le bogue n'a pas encore été déclaré. Essayez de faire un travail
propre en déclarant le bogue et en l'envoyant à la bonne adresse.

<p>
Pour faire encore mieux, vous pouvez consulter d'autres paquets, grouper les
bogues qui ont été rapportés plusieurs fois ou affecter la gravité
<em>corrigé</em> (i.e. <em>fixed</em>) à un rapport dont le bogue a été
corrigé.  Attention, quand vous n'êtes ni le rapporteur d'un bogue ni le
responsable du paquet vous ne devez pas clore le rapport (à moins que vous
n'ayez l'autorisation du responsable).




        <sect>Répondre à des rapports de bogues

<p>
Assurez-vous que toutes vos discussions concernant les bogues sont envoyées au
rapporteur du bogue et au bogue lui-même (<email>123@bugs.debian.org</email>
par exemple).

<p>
Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la
commande <em>close</em> à l'adresse&nbsp;:

<p>
<tt>   &email-bts-control;</tt>

<p>
Si vous le faites, le rapporteur n'aura aucun retour sur la clôture de son
rapport.




        <sect id="upload-bugfix">Quand les rapports sont fermés par une
        mise à jour

<p>
Si vous corrigez un bogue dans vos paquets, il est de votre responsabilité de
fermer le rapport de bogue associé. Pourtant vous ne devez pas le fermer avant
que le paquet n'ait été accepté dans l'archive Debian.  C'est pourquoi, vous
pouvez et vous devez clore le rapport dans le système de suivi des bogues une
fois que vous avez reçu l'avis indiquant que votre nouveau paquet a été
installé dans l'archive.

<p>
Si vous utilisez une version récente de <package>dpkg-dev</package> et que
vous remplissez convenablement le fichier <file>changelog</file>, le logiciel de
maintenance de l'archive fermera les rapports de bogue automatiquement. Tout ce
que vous avez à faire est de respecter la syntaxe suivante dans votre fichier
<file>debian/changelog</file>&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 manpage. Closes: #98725.
</example>

Techniquement parlant, l'expression régulière suivante est utilisée :
<example>
  /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
</example>

L'auteur préfère la syntaxe <tt>(closes: Bug#<var>XXX</var>)</tt>, car elle
est facilement repérable dans le fichier <file>changelog</file>.

<p>
Si vous voulez fermer un rapport de bogue manuellement &mdash; à l'ancienne &mdash; il
suffit d'envoyer le fichier <tt>.changes</tt> à l'adresse
<email>XXX-done@bugs.debian.org</email> où <var>XXX</var> est le numéro du
bogue.




        <sect id="lintian-reports">Les rapports Lintian

<p>
Vous devriez récupérer la dernière version de <package>lintian</package>
depuis <em>unstable</em> régulièrement et vérifier tous vos paquets. Vous
pouvez aussi chercher votre adresse électronique dans la page de <url
id="&url-lintian;" name="rapport lintian">. Cette page, mise à jour
automatiquement, contient les rapports lintian concernant la
dernière version de la distribution (en général <em>unstable</em>) générés
avec la dernière version de <package>lintian</package>.





        <sect>Ouvrir un grand nombre de rapports d'un seul coup

<p>
Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
paquet &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.debian.org</email> pour qu'ils ne soient
pas redirigés vers les listes de diffusions.





        <chapt id="newmaint">
        <heading>Interaction avec les nouveaux responsables</heading>

<p>
Ce chapitre décrit les procédures que doivent suivre les responsables
Debian quand ils ont affaire à un futur responsable Debian.

        <sect>Parrainer un paquet
<p>
Parrainer un paquet signifie télécharger un paquet dans l'archive Debian pour
un responsable qui n'est pas capable de le faire lui-même : un futur
responsable. Parrainer un paquet signifie aussi assumer la responsabilité de
ce parrainage.

<p>
Les nouveaux responsables éprouvent souvent quelques difficultés pour créer
des paquets Debian &mdash; ce qui est bien compréhensible. C'est là que le parrain
intervient. Il doit vérifier que le paquet est suffisamment bon pour intégrer
la distribution. Notez que si le paquet est nouveau les administrateurs FTP
devront eux aussi inspecter ce paquet avant de le laisser entrer.

<p>
Parrainer un paquet en se contentant de recompiler le paquet ou de signer le
téléchargement <strong>n'est franchement pas recommandé</strong>. Vous devez
reconstruire le paquet source comme vous le feriez avec vos propres paquets.
N'oubliez pas qu'il sera possible de voir que vous avez téléchargé un paquet
même si vous avez laissé le nom du futur responsable dans les fichiers de
contrôle et changelog.

<p>
Si vous êtes responsable de candidature<footnote>Application
manager</footnote> pour un développeur, vous pouvez aussi être son parrain. De
cette manière, vous aurez la possibilité de vérifier vous-même comment ce
candidat accomplit la partie «&nbsp;Tâches et compétences&nbsp;»<footnote>`Tasks and
Skills'</footnote> de sa candidature.



        <sect>Aider un nouveau responsable

<p>
Consultez la page <url id="&url-newmaint-advocate;" name="Aider un futur
responsable"> sur le site du projet Debian.



        <sect>Suivre la candidature d'un nouveau responsable

<p>
Consultez la page <url id="&url-newmaint-amchecklist;" name="Aide mémoire du
responsable de candidature"> sur le site du projet Debian.






        <chapt id="tools">Aperçu des outils du responsable Debian

<p>
Cette section contient un aperçu rapide des outils dont dispose le responsable.
Ces outils sont faits pour améliorer le confort des responsables et pour 
libérer leur temps pour des tâches cruciales.

<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 devrait utiliser ou comment il devrait faire pour gérer sa
charge de responsable Debian. Elle n'est pas non plus destinée à
favoriser l'usage d'un outil aux dépens d'un autre.

<p>
La plupart des descriptions de ces outils proviennent des descriptions de
leurs paquets. Vous trouverez plus d'information dans les
documentations de ces paquets.



        <sect id="dpkg-dev">
        <heading><package>dpkg-dev</package> 

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




        <sect id="lintian">
        <heading><package>lintian</package> 

<p>
<package>lintian</package> dissèque les paquets pour y repérer des bogues et
des manquements aux règles de développement. Il contient des tests automatisés pour
vérifier de nombreuses règles et quelques erreurs courantes.  L'utilisation de
<package>lintian</package> a déjà été discutée dans <ref id="upload-checking">
et <ref id="lintian-reports">.

        <sect id="debconf">
        <heading><package>debconf</package></heading>

<p>
Le paquet <package>debconf</package> fournit une interface consistante pour
configurer les paquets interactivement. Il est indépendant de l'interface et
permet une configuration en mode texte, par une interface HTML ou par boîtes
de dialogues. D'autres types d'interface peuvent être ajoutés sous forme
de modules.

<p>
Beaucoup pensent que ce système devrait être utilisé pour tout paquet
nécessitant une configuration interactive. <package>debconf</package> n'est
pas requis par le <em>Debian Policy Manual</em> pour le moment&nbsp;; cela
pourra changer dans le futur.

        
        <sect id="debhelper">
        <heading><package>debhelper</package> 

<p>
Le paquet <package>debhelper</package> regroupe un ensemble de programmes qui
peuvent être utilisés dans <file>debian/rules</file> pour automatiser les
tâches courantes relatives à la fabrication des paquets Debian binaires. Ce
paquet contient des utilitaires pour installer différents fichiers, les
compresser, ajuster leurs droits et intégrer votre paquet dans le
système de menu Debian.

<p>
Au contraire de <package>debmake</package>, <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
<package>debmake</package>.




        <sect id="debmake">
        <heading><package>debmake</package> 

<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>.



        <sect id="yada">
        <heading><package>yada</package> 

<p>
Le paquet <package>yada</package> est un nouvel assistant pour la création de
paquets qui a une approche légèrement différente. Il utilise un fichier
<file>debian/packages</file> pour générer d'autres fichiers nécessaires dans
le sous-répertoire <file>debian/</file>.

<p>
Remarque&nbsp;: <package>yada</package> est encore jeune et probablement moins
robuste que ses aînés.



        <sect id="equivs">
        <heading><package>equivs</package> 

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



        <sect id="cvs-buildpackage">
        <heading><package>cvs-buildpackage</package> 

<p>
Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou
récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer
un paquet Debian depuis le référentiel CVS et il assiste le développeur lors
de l'intégration de modifications amont dans le référentiel.

<p>
Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS
pour le responsable. Il permet de conserver des branches CVS distinctes
pour les distributions <em>stable</em>, <em>unstable</em> et probablement
<em>experimental</em>. 


        <sect id="dupload">
        <heading><package>dupload</package> 

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

<p>
Note&nbsp;: l'annonce d'une mise à jour est maintenant prise en charge par le logiciel
de gestion de l'archive. <package>dupload</package> doit être configuré
pour ne plus envoyer de courrier (voir <ref id="upload-announce">).

        <sect id="fakeroot">
        <heading><package>fakeroot</package> 

<p>
<package>fakeroot</package> simule les privilèges <em>root</em>. Cela permet
de fabriquer un paquet sans être root (en général les paquets installent des
fichiers appartenant à <em>root</em>). Si vous avez installé
<package>fakeroot</package> vous pouvez par exemple écrire
<tt>dpkg-buildpackage -rfakeroot</tt> en tant qu'utilisateur.



        <sect id="devscripts">
        <heading><package>devscripts</package> 

<p>
Le paquet <package>devscripts</package> contient quelques scripts et outils
que vous trouverez peut-être utiles pour maintenir vos paquets Debian. Parmi
ces scripts, vous trouverez <prgn>debchange</prgn> qui manipule votre fichier
<file>debian/changelog</file> depuis la ligne de commande et
<prgn>debuild</prgn> qui est construit au-dessus de
<prgn>dpkg-buildpackage</prgn>.




        <sect id="debget">
        <heading><package>debget</package>

<p>
Le paquet <package>debget</package> contient un script qui peut être utile
pour télécharger des paquets depuis l'archive Debian. Vous pouvez par exemple
l'utiliser pour télécharger des paquets sources.









</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:
-->
<!-- vim:set tw=78:ts=8: -->