-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 : les paquets sources et les
-paquets binaires.
-
-<p>
-Les paquets sources sont constitués de deux ou trois fichiers :
-
- <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 « instable »</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 ; c'est pourquoi nous l'appelons <em>frozen<footnote>
-<em>frozen</em> signifie « gelée »</footnote></em>. Après un mois
-ou un peu plus selon l'avancement, la distribution entre dans une phase de
-« gel complet » où les seules modifications acceptées concernent la
-procédure d'installation. Cette phase s'appelle un « cycle de test »
-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é (« 1.3 » devient « 1.3r1 »,
-« 2.0r2 » devient « 2.0r3 » 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>
-<em>NOTE : <em>experimental</em> ne fonctionne plus depuis la mise en place du
-<em>package pool</em>. Si la distribution <em>experimental</em> est remise en service
-un jour, la présente section aura sûrement besoin d'une mise à jour.</em>
-
-<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. Les utilisateurs qui téléchargent et installent des paquets depuis
-<em>experimental</em> sont prévenus : on ne peut pas faire confiance à la
-distribution <em>experimental</em>.
-
-<p>
-Les responsables doivent être très sélectifs quant à l'utilisation de la
-distribution <em>experimental</em>. Même très instable, un paquet peut aller
-dans <em>unstable</em> ; ajoutez juste quelques avertissements dans la
-description. Par contre, s'il y a une chance que le logiciel endommage
-sérieusement le système, il est préférable de le mettre dans
-<em>experimental</em>.
-
-<p>
-Un système de fichier crypté, par exemple, devrait probablement aller 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. Un nouveau logiciel
-qui a peu de chance d'endommager le système ira dans <em>unstable</em>. 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>
-Par contre, utiliser <em>experimental</em> comme plate-forme n'est pas
-toujours la meilleure idée. Vous ne pouvez pas remplacer ou mettre à jour des
-paquets dans cet espace vous-même (c'est le logiciel de maintenance de
-l'archive qui s'en charge). De plus, il vous faudra penser à demander la
-suppression de vos paquets à l'équipe d'administration de l'archive une fois
-qu'ils seront installés dans <em>unstable</em>. Utiliser vos pages web
-personnelles sur le serveur <tt>klecker.debian.org</tt> est en général une
-meilleure idée, cela permet de décharger l'équipe de maintenance de l'archive.
-
-
-
- <sect id="codenames">Les noms de distribution
-
-<p>
-Chaque distribution Debian diffusée a un nom : Debian 1.1 s'appelle
-« buz » ; Debian 1.2, « rex » ; Debian 1.3 « bo » ;
-Debian 2.0, « hamm » ; Debian 2.1, « slink » et Debian 2.2
-« potato ». Il y a aussi une pseudo-distribution nommée
-« sid », il s'agit de la distribution <em>unstable</em> ; comme les
-paquets vont de <em>unstable</em> à <em>testing</em> quand ils approchent de
-la stabilité, la distribution « sid » n'est jamais diffusée. En plus
-du contenu habituel d'une distribution Debian, « sid » 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 « testing », il aurait fallu le renommer
-« stable » 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 : slink). Ces
-noms sont identiques pendant la période de développement et une fois la
-distribution diffusée ; 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 <ITP<footnote><em>Intent To
-Package</em> : intention de mise en paquet</footnote> :
-<var>NomDuPaquet</var> -- <var> courte description </var>>, en remplaçant
-<var>NomDuPaquet</var> par le nom du paquet. La sévérité du bogue sera
-<em>whishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
-&email-debian-devel; en mettant cette adresse dans le champs X-Debbugs-CC: de
-l'entête du message. N'utilisez pas le champs CC: car de cette manière le
-sujet du message ne contiendrait pas le numéro du bogue.
-
-<p>
-Il faudra aussi ajouter une entrée
-<tt>Closes: bug#<var>nnnnn</var></tt> dans le fichier <file>changelog</file>
-du nouveau paquet. Cette indication fermera automatiquement le rapport de
-bogue à l'installation du nouveau paquet sur les serveurs d'archivage (voir
-<ref id="upload-bugfix">).
-
-<p>
-Il y a plusieurs raisons qui nous poussent à demander aux responsables d'annoncer
-leurs intentions :
-
- <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 « <em>Initial release</em> » 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>
-
-
-
-
-
- <sect id="uploading">Mettre à jour un paquet
-
-
- <sect1>Générer le fichier « changes »
-
-<p>
-Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit
-être accompagnée d'un fichier <tt>.changes</tt>. Ce fichier explique à
-l'administrateur de l'archive Debian ce qu'il doit faire du paquet. Il est en
-général créé par <prgn>dpkg-genchanges</prgn> au cours du processus de
-fabrication du paquet.
-
-<p>
-Le fichier <tt>changes</tt> est un fichier de contrôle qui contient les champs
-suivants :
-
-<p>
-&control-file-fields;
-
-<p>
-Tous ces champs sont obligatoires pour une installation sur les serveurs
-Debian. Vous pouvez consulter la liste des champs de contrôle dans le
-<url id="&url-debian-policy;" name="Debian Policy Manual"> pour connaître
-les valeurs que prennent ces champs. Vous pouvez fermer un rapport de bogue
-automatiquement avec le champ <tt>Description</tt> (voir <ref
-id="upload-bugfix">). Nous ne verrons ici que le champ <tt>Distribution</tt>
-car il est directement lié aux règles d'administration de l'archive.
-
-
-
-
- <sect1 id="upload-dist">Choisir une distribution
-
-<p>
-Le champ <tt>Distribution</tt>, qui provient du fichier
-<file>debian/changelog</file>, indique à quelle distribution le paquet est
-destiné. Il y a quatre valeurs possibles pour ce champ : <em>stable</em>,
-<em>unstable</em>, <em>frozen</em> et <em>experimental</em> ; ces valeurs
-peuvent aussi être combinées. Si, par exemple, Debian a été gelée et vous
-voulez mettre à jour 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 savoir quand vous pouvez faire une mise à jour
-sur <em>frozen</em>). Notez bien qu'il n'y a pas de raison de combiner
-<em>experimental</em> avec quelque distribution que ce soit.
-
-<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). Notez encore que choisir la valeur <em>stable</em> pour ce
-champ signifie que le paquet sera dirigé vers le répertoire
-<tt>proposed-update</tt> des archives Debian pour y être testé avant d'être
-effectivement inclus dans <em>stable</em>. L'équipe responsable de la
-distribution<footnote><em>the release team</em></footnote> (joignable à
-l'adresse &email-debian-release;) prendra la décision d'inclure ou de ne pas
-inclure votre paquet dans la distribution <em>stable</em>. C'est pourquoi vous
-pourrez choisir de leur envoyer un courrier expliquant les motifs qui vous ont
-incité à faire une mise à jour pour <em>stable</em>, si votre fichier
-<file>changelog</file> n'est pas suffisamment clair sur ce point.
-
-<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).
-
-
-
-
-
-
- <sect2 id="upload-frozen">Mettre à jour 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 ; 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 : <strong>pas de code
-nouveau</strong>. C'est une chose difficile à quantifier, voici quelques
-conseils :
-
-<p>
- <list compact>
- <item>
- Les corrections de bogues de sévérité <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 sévérité <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 sévérité <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 sévérité <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 sévérité du bogue corrigé et
-la sévérité du bogue introduit par la correction.
-
-
-
-
- <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) :
-
- <list compact>
- <item>
- Installez le paquet et vérifiez que le logiciel fonctionne. Si le
- paquet existait déjà dans une version plus ancienne, faites une mise à
- jour.
-
- <item>
- Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
- <prgn>lintian</prgn> comme suit : <tt>lintian -v
- <var>package-version</var>.changes</tt>. Ce programme fera une
- vérification sur les paquets source et binaire. Si vous ne comprenez
- 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> Un paquet pour lequel
- <prgn>lintian</prgn> génère des erreurs (elles commencent par
- <tt>E</tt>) <em>ne doit pas</em> être installé dans l'archive.
-
- <p>
- Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la
- section lintian <ref id="lintian">. <item> Faites régresser le paquet
- vers sa version précédente si elle existe -- cela permet de tester les
- scripts <tt>postrm</tt> et <tt>prerm</tt>.
-
- <item>
- Désinstallez le paquet et réinstallez-le.
-
- </list>
-
-
-
-
-
- <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 :</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> :
-
-<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 vous 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> ; 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 :
-
-<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 consulter 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> ; consultez la documentation de ce programme pour en savoir
-plus.
-
-
-
- <sect1>Installer un paquet via <tt>erlangen</tt>
-
-<p>
-Vous pouvez aussi accéder à un serveur situé en Allemagne : il vous suffit
-d'ouvrir une connexion anonyme sur :
-
-<p>
- <url id="&url-upload-erlangen;">.
-
-<p>
-Le téléchargement fait sur ce serveur doit être aussi complet que s'il
-était fait dans le répertoire <tt>Incoming</tt> sur <tt>ftp-master</tt> :
-il doit comporter le fichier <file>.changes</file> et tous les fichiers
-mentionnés dans ce dernier. Le serveur vérifie que le fichier
-<tt>.changes</tt> est bien signé avec la clé PGP d'un développeur Debian pour
-éviter que des faux paquets n'atteignent <tt>ftp-master</tt>. Vérifiez bien
-que le champ <tt>Maintainer</tt> du fichier <tt>.changes</tt> contient
-<em>votre</em> adresse électronique. De même que sur <tt>ftp-master</tt>,
-cette adresse est ensuite utilisée pour toutes les réponses.
-
-<p>
-Il n'est pas nécessaire de déplacer votre fichier dans un autre répertoire
-après le téléchargement, contrairement au serveur <tt>chiark</tt>. Vous
-devriez ensuite recevoir un courrier du serveur expliquant ce qu'il a fait de
-votre paquet. Normalement, il devrait avoir été déplacé vers
-<tt>ftp-master</tt> ;
-vous serez informé par le même biais si une erreur s'est produite au cours du
-processus.
-
-<p>
-<em>Note :</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> ; consultez la documentation de ce programme pour en savoir
-plus.
-
-
-
-
-
- <sect1>Les autres serveurs
-
-<p>
-Un autre serveur est disponible aux États-Unis ; c'est un bon point
-de repli quand il est difficile de joindre <tt>ftp-master</tt>. Livrez vos
-paquets à l'adresse <url id="&url-upload-samosa;"> comme vous le feriez sur
-<tt>erlangen</tt>.
-<p>
-Il existe aussi un serveur au Japon : téléchargez vos paquet par FTP
-anonyme sur <url id="&url-upload-jp;">.
-
-
-
-
- <sect id="upload-announce">Annoncer une mise à jour
-
-<p>
-Quand un paquet est mis à jour, une annonce doit être envoyée sur l'une des
-listes « debian-changes ». Ceci est maintenant géré automatiquement
-par le logiciel de gestion de l'archive quand il est exécuté (en principe une
-fois par jour). Vous devez juste utiliser une version récente de
-<package>dpkg-dev</package> (>= 1.4.1.2). Le courrier généré par le
-logiciel de maintenance de l'archive contiendra le fichier <tt>.changes</tt>
-signé que vous avez livré avec votre paquet. Précédemment, cette charge
-revenait à <prgn>dupload</prgn> ; vérifiez que vous avez bien configuré
-<prgn>dupload</prgn> pour qu'il n'envoie pas ces annonces (cherchez
-<tt>dinstall_runs</tt> dans la documentation de <prgn>dupload</prgn>).
-
-<p>
-Si un paquet est mis à jour pour la distribution <em>stable</em>, l'annonce
-est envoyée sur la liste :
-
-<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>
-De temps en temps, il est nécessaire de mettre à jour simultanément les
-distributions <em>stable</em> et <em>unstable</em> ; cela est possible en
-indiquant les deux distributions sur la ligne <tt>Distribution:</tt>. Dans ce
-dernier cas, l'annonce sera faite sur les deux listes de diffusion citées
-précédemment.
-
-<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>dak</prgn>
-(aussi appelé <prgn>katie</prgn> ou <prgn>dinstall</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é. Lisez attentivement ce
-courrier. Vous pourriez remarquer que votre paquet n'a pas été installé dans
-la section que vous aviez désignée. La raison de ce changement sera dans le
-courrier.
-
-
-
-
- <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>. De temps en temps, ce fichier doit être
-corrigé. Modifier le fichier <file>control</file> du paquet n'aura aucun
-effet. Il vous faudra écrire à &email-override; ou faire un rapport de bogue
-sur le pseudo-paquet <package>ftp.debian.org</package>.
-
-<p>
-Pour en savoir plus sur le fichier <em>override</em>, reportez-vous à <manref
-name="dpkg-scanpackages" section="8">, &file-bts-mailing; et &file-bts-info;.
-
-
-
-
- <chapt id="nmu">Mise à jour indépendante
-
-<p>
-Dans certaines circonstances il est nécessaire qu'une personne autre que le
-responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de mise à
-jour est désigné en anglais par l'expression <em>non-maintainer upload
-(NMU)</em>. Dans le présent document, nous traduisons librement cette
-expression par « mise à jour indépendante ».
-
-<p>
-Ces mises à jour indépendantes font partie du travail normal des porteurs qui
-compilent les paquets pour d'autres architectures (voir <ref id="porting">).
-Nous faisons aussi des mises à jour indépendantes quand un développeur Debian
-corrige le paquet d'un autre développeur pour éliminer un trou de sécurité
-ou un bogue paralysant. Cela se produit plus particulièrement en période de
-gel de la distribution de développement ou quand le responsable officiel du
-paquet ne peut pas fournir une correction dans un délai raisonnable.
-
-<p>
-Ce chapitre contient des informations qui vous expliqueront quand et comment
-faire des mises à jour indépendantes. Une distinction fondamentale doit être
-faite entre les mises à jour indépendantes sources et les mises à jour
-indépendantes binaires. Elle est explicitée dans la section suivante.
-
-
- <sect id="nmu-terms">Terminologie
-
-<p>
-Deux nouvelles expressions sont introduites dans cette section :
-« mise à jour indépendante source » et « mise à
-jour indépendante binaire ». Ces expressions ont une définition
-précie dans le monde Debian. Elles correspondent toutes deux au même type
-d'activité ; elles impliquent toutes deux qu'une personne fait une mise à
-jour d'un paquet alors qu'elle n'est pas officiellement responsable de ce
-paquet. C'est pourquoi nous qualifions ces mises à jours
-d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser
-entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas
-question d'agir sans prévenir le responsable au préalable (voir <ref
-id="nmu-guidelines">).</footnote>.
-
-<p>
-Une mise à jour indépendante source est une livraison de paquet faite par
-une personne qui n'est pas le responsable officiel de ce paquet avec pour
-objectif de corriger un bogue dans le paquet. Une mise à jour indépendante
-source implique toujours une modification des sources du paquet, même s'il
-ne s'agit que d'un changement dans le fichier <file>debian/changelog</file>.
-Ce changement peut tout aussi bien concerner la version amont du source que la
-partie du source spécifique à Debian.
-
-<p>
-Une mise à jour indépendante binaire est une recompilation et un archivage
-d'un paquet pour une nouvelle architecture. Il s'agit souvent du résultat d'un
-effort de portage. Une mise à jour indépendante binaire est la livraison d'un
-paquet compilé (souvent pour une autre architecture) à condition que cette
-compilation n'ait pas nécessité de modifications des sources. Dans de
-nombreux cas, les porteurs
-sont obligés de modifier les sources pour les rendre compilables sur leur
-architecture cible ; il s'agira alors d'une mise à jour indépendante source et
-non d'une mise à jour indépendante binaire. Comme vous pouvez le remarquer,
-nous ne faisons pas de distinction entre les mises à jour indépendantes
-faites par des porteurs et les autres mises à jour indépendantes.
-
-<p>
-Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
-par l'expression « mise à jour indépendante »
-(NMU<footnote>Non-maintainer upload</footnote>). Pourtant cela conduit souvent
-à des confusions car beaucoup associent « mise à jour indépendante »
-et « mise à jour indépendante source ». Il faut donc rester
-vigilant. Dans ce chapitre, si j'utilise « mise à jour
-indépendante » seul, il s'agit des deux types de livraisons.
-
-
-
-
-
- <sect id="nmu-who">Qui peut faire une mise à jour indépendante ?