<!-- 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 -->
+ <!-- common, language independent entities -->
<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.38 $">
+ <!ENTITY cvs-rev "$Revision: 1.39 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
- <!--
- <!ENTITY cvs-en-rev "1.216">
- -->
+ <!-- <!ENTITY cvs-en-rev "1.241"> -->
<!-- how to mark a section that needs more work -->
<!ENTITY FIXME "<em>FIXME:</em> ">
<title>Référence du développeur Debian
<author>L'équipe de la Référence du développeur &email-devel-ref;
- <author>Adam Di Carlo, éditeur
+ <author>Andreas Barth
+ <author>Adam Di Carlo
<author>Raphaël Hertzog
<author>Christian Schwarz
<author>Ian Jackson
<author>
- <translator>version française par Antoine Hulin</translator>
- <translator>et Frédéric Bothamy (traducteur actuel)</translator>
+ <translator>version française par Frédéric Bothamy (traducteur actuel)</translator>
+ <translator>et Antoine Hulin (ancien traducteur)</translator>
<translator>et les membres de la liste <email>debian-l10n-french@lists.debian.org</email></translator>
- <version>Version &version;, &date-fr; (version française 20030718).</version>
+ <version>Version &version;, &date-fr; (version française 20041005).</version>
<copyright>
+ <copyrightsummary>Copyright © 2004 Andreas Barth</copyrightsummary>
<copyrightsummary>Copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>Copyright © 2002—2003 Raphaël Hertzog</copyrightsummary>
<copyrightsummary>Copyright © 1997, 1998 Christian Schwarz.</copyrightsummary>
sur vos paquets avec vous et les téléchargera dans l'archive Debian une fois
qu'il sera satisfait de votre mise en paquet. Pour trouver un parrain, envoyez
une demande de parrainage à la liste &email-debian-mentors; en vous présentant
- et en décrivant votre paquet (voir <ref id="sponsoring"> pour en savoir plus
+ et en décrivant votre paquet (voir <ref id="sponsoring"> et <url
+ id="&url-mentors;"> pour en savoir plus
sur le sujet). Si vous préférez porter Debian sur une architecture ou un noyau
alternatif, abonnez-vous aux listes dédiées au portage et demandez-y comment
démarrer. Finalement, si vous êtes intéressé par la documentation ou
résultat de votre candidature, vous pouvez chercher un parrain qui téléchargera
les paquets à votre place. Les parrains sont des responsables Debian officiels
volontaires pour examiner et télécharger vos paquets. Vous pouvez
- demander un parrainage à l'adresse <url id="&url-sponsors;">.
+ demander un parrainage à l'adresse <url id="&url-sponsors;">. Veuillez tout
+ d'abord lire la FAQ non officielle de debian-mentors à <url id="&url-mentors;">.
<p>
Si vous désirez être mentor ou parrain, reportez-vous à <ref id="newmaint">.
il vous faudra en général ouvrir un rapport de bogue sur un
« pseudo-paquet ». Reportez-vous à la section <ref id="submit-bug">
pour connaître la procédure à suivre.
+ <p>
+Certains des serveurs de base sont à accès restreint, mais les informations de
+ceux-ci sont fournies par d'autres serveurs miroirs.
<sect1 id="servers-bugs">Le serveur pour les rapports de bogues
<p>
<tt>&bugs-host;</tt> est le serveur maître du système de suivi des bogues
(BTS<footnote><p>Système de suivi des bogues se dit <em>Bug Tracking
- System</em> en anglais</footnote>). Si vous envisagez de manipuler les rapports
+ System</em> en anglais</footnote>).
+<p>
+Ce serveur est à accès restreint ; un miroir est disponible sur <tt>merkel</tt>.
+<p>
+ Si vous envisagez de manipuler les rapports
de bogue ou d'en faire une analyse statistique, ce sera le bon endroit pour le
faire. Informez la liste &email-debian-devel; de votre intention avant
d'implémenter quoi que ce soit afin d'éviter un travail en double ou un
gaspillage de temps machine.
-<p>
-Tous les développeurs Debian ont un compte sur
- <tt>&bugs-host;</tt>.
<sect1 id="servers-ftp-master">Le serveur ftp-master
<p>
paquets se font sur ce serveur. Reportez-vous à la section <ref id="upload">
pour en savoir plus.
<p>
+Ce serveur est à accès restreint ; un miroir est disponible sur <tt>merkel</tt>.
+<p>
Les problèmes avec l'archive Debian FTP doivent généralement être rapportés
comme bogues sur le pseudo-paquet <package>ftp.debian.org</package> ou par
courrier électronique à &email-ftpmaster; ; reportez-vous à la section
en précisant le nom de l'espace, le compte Debian propriétaire du répertoire
racine et pourquoi vous en avez besoin.
+ <sect1 id="dchroot">Chroots de différentes distributions
+ <p>
+Sur certaines machines, des chroots de différentes distributions sont
+disponibles. Vous pouvez les utiliser comme ceci :
+
+<example>
+vore% dchroot unstable
+Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
+</example>
+
+Dans tous les chroots, les répertoires normaux des utilisateurs sont disponibles.
+Vous pouvez trouver quels chroots sont disponibles à
+<tt>&url-devel-machines;</tt>.
+
<sect id="devel-db">La base de données des développeurs
<p>
Debian sur une architecture particulière (<file>disk-i386/</file>,
<file>disk-m68k/</file>, etc.).
- <sect1>Les sections
+ <sect1 id="archive-sections">Les sections
<p>
La section <em>main</em> constitue la <strong>distribution &debian-formal;
officielle</strong>. Elle est officielle parce qu'elle est entièrement conforme
reconnaît de nouvelles architectures, comme ARM et UltraSPARC. Puisque Linux
reconnaît ces architectures, le projet Debian a décidé qu'il devait également les
accepter. C'est pourquoi plusieurs portages sont en cours ; en fait, il y
- a aussi des portages vers d'autres noyaux. À côté d'<em>i386</em> (notre nom
+ a aussi des portages vers d'autres noyaux non-Linux. À côté d'<em>i386</em> (notre nom
pour Intel x86), nous avons, au moment où j'écris, <em>m68k</em>,
<em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
<em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>, <em>mips</em>,
que tout fonctionne correctement dans cette distribution, elle est parfois
littéralement « instable ».
<p>
-<ref id="testing"> est générée automatiquement en prenant les paquets
+La distribution <qref id="testing">« testing »</qref> est générée
+ automatiquement en prenant les paquets
d'<em>unstable</em> s'ils satisfont à certains critères. Ces critères
garantissent que les paquets de <em>testing</em> sont de bonne qualité. La
mise à jour de <em>testing</em> est lancée chaque jour après que les
- nouveaux paquets ont été installés.
+ nouveaux paquets ont été installés. Voir <ref id="testing">.
<p>
Après une période de développement, quand le responsable de
distribution<footnote><p><em>Release manager</em></footnote> le juge opportun,
Notez que, pendant la période de gel, les développements continuent sur la
distribution <em>unstable</em> car cette distribution reste en place.
- <sect2 id="testing">
+ <sect2>
<heading>Informations complémentaires sur la distribution
« testing »</heading>
-<p>
-Les scripts qui mettent à jour la distribution <em>testing</em> sont exécutés
- chaque jour après l'installation des paquets mis à jour. Ils fabriquent les
- fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils
- le font d'une manière intelligente pour éviter toute incohérence et essayer de
- n'utiliser que des paquets sans bogue.
-<p>
-L'inclusion d'un paquet d'<em>unstable</em> est soumise aux
- conditions suivantes :
-<list compact="compact">
-<item><p>Le paquet doit avoir été disponible dans <em>unstable</em> depuis
- plusieurs jours ; le nombre précis dépend du champ d'urgence de
- l'envoi. Il s'agit de 10 jours pour une urgence faible, 5 jours pour une
- urgence moyenne et 2 jours pour une urgence élevée. Ces délais peuvent
- être doublés lors d'un gel de distribution ;</item>
-<item><p>Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
- version disponible dans <em>testing</em> ;</item>
-<item><p>Il doit être disponible pour toutes les architectures pour lesquelles
- il a été auparavant construit. <ref id="madison"> peut être
- intéressant pour vérifier cette information ;</item>
-<item><p>Il ne doit pas casser les dépendances d'un paquet qui est déjà
- disponible dans <em>testing</em> ;</item>
-<item><p>Les paquets dont il dépend doivent soit être déjà disponibles dans
- <em>testing</em> soit être acceptés dans <em>testing</em> au
- même moment (et ils doivent eux-mêmes respecter tous ces
- critères).</item>
-</list>
-<p>
-Pour savoir si un paquet a progressé ou non dans <em>testing</em>, veuillez voir la
- sortie du script de <em>testing</em> sur la <url name="page web de la distribution testing"
-id="&url-testing-maint;"> ou utilisez le programme <prgn>grep-excuses</prgn>
-inclus dans le paquet <package>devscripts</package>. Si l'on veut rester
-informé de la progression de ses paquets dans <em>testing</em>, on peut
-facilement le mettre dans la <manref
- section="5" name="crontab">.
-<p>
-Le fichier <file>update_excuses</file> ne donne pas toujours la raison précise
- pour laquelle un paquet est refusé, on peut avoir à la chercher soi-même en
- regardant ce qui serait cassé avec l'inclusion du paquet. La <url
- id="&url-testing-maint;" name="page web de la distribution testing"> donne plus
- d'informations à propos des problèmes courants qui peuvent occasionner cela.
-<p>
-Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce que le
- jeu des inter-relations est trop compliqué et ne peut être résolu par le
- script. Dans ce cas, le responsable de version doit être contacté et il forcera
- l'inclusion du paquet.
+ <p>
+Les paquets sont habituellement installés dans la distribution <em>testing</em>
+après avoir atteint un certain degré de test dans <em>unstable</em>.
<p>
-En général, veuillez vous référer à la <url name="page web de la distribution testing"
-id="&url-testing-maint;"> pour plus d'informations. Cette page inclut également
-des réponses aux questions fréquemment posées.
-
+Pour plus de détails, veuillez consulter les <qref id="testing">informations à
+propos de la distribution <em>testing</em></qref>.
<sect2 id="experimental">Experimental
<p>
<p>
Une solution de rechange à <em>experimental</em> consiste à utiliser vos pages
personnelles sur le serveur <tt>people.debian.org</tt>.
+<p>
+Veuillez considérer l'utilisation de l'option <tt>-v</tt> de
+<prgn>dpkg-buildpackage</prgn> si l'envoi d'un paquet dans <em>unstable</em> ferme
+finalement des bogues qui ont d'abord été corrigés dans <em>experimental</em>.
<sect1 id="codenames">Les noms de distribution
<p>
<p>
Les différentes archives de téléchargement et le site web disposent de plusieurs
miroirs pour soulager les serveurs principaux d'une lourde charge. En fait,
-certains de ces serveurs ne sont pas publics et la charge est
+certains de ces serveurs ne sont pas publics — la charge est
répartie sur une première série de serveurs. De cette façon, les
utilisateurs ont toujours accès aux miroirs et s'y habituent, ce qui permet à
Debian de mieux répartir les besoins en bande passante sur plusieurs serveurs et
Les paquets sont envoyés par tous les responsables Debian dans un répertoire
nommé <file>unchecked</file>. Ce répertoire est parcouru toutes les 15 minutes
par le script <prgn>katie</prgn> qui vérifie l'intégrité des paquets envoyés et
- les signatures de chiffrage. Si le paquet est considéré comme prêt à être
+ leurs signatures de chiffrage. Si le paquet est considéré comme prêt à être
installé, il est déplacé dans le répertoire <file>accepted</file>. S'il s'agit
du premier envoi du paquet, il est déplacé dans le répertoire <file>new</file>
où il attend l'approbation des ftpmasters. Si le paquet contient des fichiers
C'est pourquoi vous ne pouvez pas supprimer un envoi une fois qu'il a été
accepté.
- <sect1 id="delayed-incoming">Incoming différé
+ <sect1 id="delayed-incoming-broken">Incoming différé
+<p>
+<em>Note :</em> la description présentée ici ne fonctionne pas
+ car ftp-master est à accès restreint. Veuillez vous reporter à <ref
+ id="delayed-incoming"> pour la façon actuelle de faire.
<p>
Le répertoire <file>unchecked</file> comprend un sous-répertoire spécial,
<file>DELAYED</file><footnote>Différé en anglais</footnote>. Celui-ci est
les mêmes courriers que le responsable, simplement en vous inscrivant au paquet
dans le PTS.
<p>
-Chaque courrier envoyé par le PTS est classé et associé à l'un des mots-clés
+Chaque courrier envoyé par le PTS est classé sous l'un des mots-clés
listés ci-dessous. Ceci vous permettra de sélectionner les courriers que vous
voulez recevoir.
<p>
chaque paquet source.
<tag><tt>keyword [<adresse>] {+|-|=} <liste de mots-clés></tt>
- <item>Accepte (+) ou refuse (-) les courriers associés au(x) mot(s)-clé(s).
+ <item>Accepte (+) ou refuse (-) les courriers classés sous le(s) mot(s)-clé(s).
Définit la liste (=) des mots-clés acceptés.
<tag><tt>keyword <paquet source> [<adresse>] {+|-|=} <liste de mots-clés></tt>
peut être téléchargé. Cette liste n'est pas limitative.
<p>
Le sujet de votre rapport de bogue devra être <ITP<footnote><p><em>Intent To
- Package</em> : intention de d'empaquetage</footnote> :
+ Package</em> : intention d'empaquetage</footnote> :
<var>NomDuPaquet</var> — <var>courte description</var>>, en remplaçant
<var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera
<em>wishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
« stable-security » et « testing-security », mais
veuillez lire <ref id="bug-security"> pour plus d'informations sur celles-ci.
<p>
-Il est techniquement possible d'envoyer un paquet dans plusieurs distributions
- en même temps, mais ceci n'a habituellement aucun sens d'utiliser cette
- fonctionnalité car les dépendances d'un paquet peuvent varier selon les
- distributions. En particulier, il est absurde de combiner la distribution
- <em>experimental</em> avec tout autre chose.
+Il n'est pas possible d'envoyer un paquet dans plusieurs distributions
+ en même temps.
- <sect1 id="upload-stable">Cas spécial mise à jour d'un paquet de
+ <sect1 id="upload-stable">Cas spécial : mise à jour d'un paquet de
la distribution <em>stable</em>
<p>
Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
<em>stable</em>. Soyez précis (et, si nécessaire, prolixe) quand vous
décrivez, dans le fichier changelog, vos changements pour une livraison
vers <em>stable</em>, sinon le paquet ne sera pas pris en considération.
+ <p>
+Il est fortement conseillé de discuter avec le responsable de la version stable <em>avant</em>
+de réaliser un envoi dans <em>stable</em>/<em>stable-proposed-updates</em>, pour
+que le paquet envoyé corresponde aux besoins de la prochaine révision de <em>stable</em>.
- <sect1 id="upload-t-p-u">Cas spécial : Mise à jour d'un paquet de la
- distribution <em>testing-proposed-updates</em>
-<p>
-La distribution <em>testing</em> est peuplée avec des paquets en provenance
- d'<em>unstable</em> selon des règles expliquées dans <ref id="testing">.
- Cependant, le responsable de distribution peut stopper les scripts de
- <em>testing</em> quand il veut geler la distribution. Dans ce cas, vous
- pouvez envoyer vos paquets vers <em>testing-proposed-updates</em> pour
- fournir des paquets corrigés durant le gel.
-<p>
-Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement,
- ils doivent passer entre les mains du responsable de distribution. Vous devez
- donc avoir une bonne raison pour les y envoyer. Pour savoir ce que
- représente une bonne raison aux yeux du responsable de distribution, vous
- devriez lire les instructions données qu'il envoie régulièrement sur
- &email-debian-devel-announce;.
+ <sect1 id="upload-t-p-u">Cas spécial : mise à jour d'un paquet de la
+ distribution <em>testing</em>/<em>testing-proposed-updates</em>
<p>
-Vous ne devriez pas envoyer un paquet à <em>testing-proposed-updates</em> quand
- vous pouvez le mettre à jour par <em>unstable</em>. Si vous ne pouvez faire
- autrement (par exemple, parce que vous avez une nouvelle version dans
- <em>unstable</em>), vous pouvez l'utiliser, mais il est recommandé de
- demander l'autorisation du responsable de distribution auparavant.
-
+Veuillez consulter les informations dans la <qref id="t-p-u">section sur
+<em>testing</em></qref> pour des détails.
<sect id="upload">Mettre à jour un paquet
<sect1 id="upload-ftp-master">Installer un paquet sur
<tt>ftp-master</tt>
<p>
-Pour installer un paquet, vous avez besoin d'un compte sur
- <ftpsite>&ftp-master-host;</ftpsite>, ce que vous devriez déjà avoir en tant
- que développeur Debian. Si vous utilisez <prgn>scp</prgn> ou
- <prgn>rsync</prgn> pour télécharger vos paquets, placez-les dans
- &us-upload-dir;. Si vous utilisez un FTP anonyme, placez-les dans
- &upload-queue;.
-<p>
-Si vous désirez utiliser la fonctionnalité de délai décrite dans <ref
-id="delayed-incoming">, vous devez effectuer votre envoi vers
-<tt>ftp-master</tt>. Il s'agit de la seule destination d'envoi supportant
-l'incoming différé.
+Pour installer un paquet, vous devez envoyer les fichiers (y compris les
+ fichiers changes et dsc signés) par ftp anonyme sur
+ <ftpsite>&ftp-master-host;</ftpsite> dans le répertoire &upload-queue;. Pour
+ que les fichiers y soient traités, ils doivent être signés avec une clé du
+ porte-clés (<em>keyring</em>) Debian.
+
<p>
Attention, il est préférable de transférer le fichier
<tt>changes</tt> en dernier. Dans le cas contraire, votre livraison pourrait
être rejetée car l'outil de maintenance de l'archive pourrait lire le fichier
- <tt>changes</tt> et constater que les fichiers ne sont pas tous présents. Si
- vous ne voulez pas vous embêter avec l'ordre de transfert des fichiers, vous
- pouvez tout simplement copier vos fichiers dans un répertoire temporaire de
- <tt>ftp-master</tt> et les déplacer ensuite vers &us-upload-dir;.
+ <tt>changes</tt> et constater que les fichiers ne sont pas tous présents.
<p>
<em>Note :</em> ne téléchargez pas sur <tt>ftp-master</tt> de paquets
concernant la cryptographie qui appartiendraient à <em>contrib</em> ou <em>non-free</em>.
<em>non-free</em> à cause de problèmes de distribution et non pas à cause de
la licence du logiciel). Quand vous ne pouvez télécharger sur
<tt>ftp-master</tt>, vous ne pouvez pas non plus télécharger sur
- <tt>chiark</tt> ou <tt>erlangen</tt>. Si vous ne savez pas si votre paquet
+ les sites de repli qui arrivent finalement sur <tt>ftp-master</tt>. Si vous ne savez pas si votre paquet
est protégé par un brevet ou s'il est soumis aux lois de contrôle des
exportations américaines, posez la question sur la liste
&email-debian-devel;.
travail lors du téléchargement. Ces programmes, bien pratiques, aident à
automatiser le processus d'envoi de paquets vers Debian
<p>
-Après avoir téléchargé votre paquet, vous pouvez vérifier ce qu'en
- fera le logiciel de maintenance de l'archive en exécutant
- <prgn>dinstall</prgn> sur votre fichier <file>.changes</file> :
-<example>dinstall -n foo.changes</example>
-<p>
-Notez que <prgn>dput</prgn> peut le faire automatiquement pour vous.
+Pour supprimer des paquets, veuillez lire le fichier README dans ce répertoire
+FTP et le paquet Debian <ref id="dcut">.
<sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
<p>
+<em>Note :</em> non-us n'est plus traité actuellement.
+ <p>
Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
exportations américaines ne doivent pas être installés sur
- <tt>ftp-master</tt>. Installez le paquet sur
- <ftpsite>non-us.debian.org</ftpsite> dans le répertoire &non-us-upload-dir;
+ <tt>ftp-master</tt>. Installez le paquet par FTP anonyme sur
+ <ftpsite>non-us.debian.org</ftpsite> dans le répertoire &upload-queue;
(<ref id="dupload"> et <ref id="dput"> avec les options adéquates peuvent
- tous deux être utilisés pour cela). Par défaut, vous pouvez utiliser le même
- <em>login/mot de passe</em> que pour <tt>ftp-master</tt>. Si vous utilisez
- une connexion FTP anonyme pour le téléchargement, placez vos fichiers dans le
- répertoire &upload-queue;.
-<p>
-Tout comme sur <tt>ftp-master</tt>, vous pouvez vérifier votre téléchargement
- avec : <example>dinstall -n foo.changes</example>
+ tous deux être utilisés pour cela).
<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.
américains de consulter un juriste avant de livrer un paquet sur
<tt>non-US</tt>.
- <sect1>Installer un paquet via <tt>chiark</tt>
-<p>
-Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs
- possibilités. L'une d'elles consiste à télécharger vos fichiers dans
- <file>Incoming</file> en passant par le serveur <tt>chiark</tt> en Europe.
- Pour les détails, consultez <url id="&url-chiark-readme;">.
-<p>
-Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux lois de
- contrôle des exportations américaines sur <tt>chiark</tt>. Les paquets
- téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>, les
- indications de la section <ref id="upload-ftp-master"> sont applicables ici
- aussi.
-<p>
-Le programme <prgn>dupload</prgn> est capable de télécharger sur
- <tt>chiark</tt> ; 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 <url id="&url-upload-erlangen;">.
-<p>
-Le téléchargement fait sur ce serveur doit être aussi complet que s'il était
- fait dans le répertoire <file>Incoming</file> sur <tt>ftp-master</tt> : il
- doit comporter le fichier <file>.changes</file> et tous les fichiers
- mentionnés dans ce dernier. Le serveur vérifie que le fichier
- <file>.changes</file> est bien signé avec la clé PGP d'un développeur Debian
- pour éviter que des faux paquets n'atteignent <tt>ftp-master</tt>. Vérifiez
- bien que le champ <tt>Maintainer</tt> du fichier <file>.changes</file>
- contient <em>votre</em> adresse électronique. De même que sur
- <tt>ftp-master</tt>, cette adresse est ensuite utilisée pour toutes les
- réponses.
-<p>
-Il n'est pas nécessaire de déplacer votre fichier dans un autre répertoire après
- le téléchargement, contrairement au serveur <tt>chiark</tt>. Vous devriez
- ensuite recevoir un courrier du serveur expliquant ce qu'il a fait de votre
- paquet. Normalement, il devrait avoir été déplacé vers
- <tt>ftp-master</tt> ; vous serez informé par le même biais si une erreur
- s'est produite au cours du processus.
-<p>
-Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux lois de
- contrôle des exportations américaines sur <tt>erlangen</tt>. Les paquets
- téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>, les
- indications de la section <ref id="upload-ftp-master"> sont applicables ici
- aussi.
-<p>
-Le programme <prgn>dupload</prgn> est capable de télécharger sur
- <tt>erlangen</tt> ; consultez la documentation de ce programme pour en
- savoir plus.
-
- <sect1>Les autres serveurs
-<p>
-Un autre serveur est disponible aux États-Unis ; c'est un bon point de
- repli quand il est difficile de joindre <tt>ftp-master</tt>. Livrez vos
- paquets à l'adresse <url id="&url-upload-samosa;"> comme vous le feriez sur
- <tt>erlangen</tt>.
-<p>
-Il existe aussi un serveur au Japon : téléchargez vos paquet par FTP
- anonyme sur <url id="&url-upload-jp;">.
+ <sect1 id="delayed-incoming">Envois différés
+ <p>
+Les envois différés sont pour le moment réalisés <em>via</em> la file différée
+ sur gluck. Le répertoire d'envoi est
+ <ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>.
+0-day est envoyé approximativement une heure avant l'exécution de dinstall.
+ <p>
+Avec une version assez récente de dput, cette section
+<example>
+[tfheen_delayed]
+method = scp
+fqdn = gluck.debian.org
+incoming = ~tfheen
+</example>
+dans votre fichier ~/.dput.cf devrait fonctionner correctement pour réaliser des
+envois dans la file DELAYED.
+ <p>
+<em>Note :</em>
+Comme la file d'envoi va sur <tt>ftp-master</tt>, la
+prescription que l'on trouve dans <ref id="upload-ftp-master"> s'applique
+également ici.
+
+ <sect1>Envois de sécurité
+ <p>
+N'envoyez PAS un paquet vers la file d'envoi de sécurité (<em>oldstable-security</em>,
+<em>stable-security</em>, etc.) sans avoir au préalable l'autorisation de l'équipe de
+sécurité. Si le paquet ne correspond pas tout à fait aux besoins de cette
+équipe, il entraînera beaucoup de problèmes et de délais dans la gestion de cet
+envoi non désiré. Pour plus de détails, consultez la section <ref id="bug-security">.
+
+ <sect1>Les autres files d'envoi
+ <p>
+Les files scp sur ftp-master, non-us et security sont pratiquement inutilisables
+à cause des restrictions de connexion sur ces hôtes.
+ <p>
+Les files anonymes sur ftp.uni-erlangen.de et ftp.uk.debian.org sont
+actuellement arrêtées. Un travail est en cours pour les restaurer.
+ <p>
+Les files sur master.debian.org, samosa.debian.org, master.debian.or.jp
+et ftp.chiark.greenend.org.uk sont arrêtées de façon permanente et ne seront pas
+restaurées. La file du Japon sera remplacée par une nouvelle file sur
+hp.debian.or.jp un jour.
+ <p>
+À l'heure actuelle, la file en ftp anonyme sur auric.debian.org (le précédent
+ftp-master) fonctionne, mais elle est déconseillée et sera supprimée à un moment
+donné.
<sect1 id="upload-notification">
<heading>Notification de l'installation d'un nouveau paquet</heading>
qui vous informera de cette différence (voir ci-dessous).
- <sect id="override-file">Déterminer la section et la priorité d'un paquet
+ <sect id="override-file">Spécifier la section, la sous-section et la priorité d'un paquet
<p>
Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
<file>debian/control</file> n'indiquent ni où le paquet sera installé dans
name="dpkg-scanpackages" section="8"> et <url
id="&url-bts-devel;#maintincorrect">.
<p>
-Notez également que le terme « section » est utilisé pour la
- séparation des paquets selon leur licence, e.g <em>main</em>, <em>contrib</em>
- et <em>non-free</em>. Ceci est décrit dans une autre section, <ref
- id="archive">.
-
+Notez que le champ <tt>Section</tt> décrit à la fois la section et la
+sous-section, comme décrit dans <ref id="archive-sections">. Si la section est
+« main », elle devrait être omise. La liste des sous-sections
+autorisées peut être trouvée dans <url
+id="&url-debian-policy;ch-archive.html#s-subsections">.
- <sect id="bug-handling">Gérer les bogues
+<sect id="bug-handling">Gérer les bogues
<p>
Chaque développeur doit être capable de travailler avec le <url name="système de
suivi des bogues" id="&url-bts;"> Debian. Il faut savoir comment remplir
Si vous prenez connaissance d'un bogue lié à un problème de sécurité sur un
paquet Debian, que vous soyez ou non le responsable, regroupez les
informations pertinentes sur le problème et contactez rapidement l'équipe de
- sécurité à &email-security-team; dès que possible. Les informations utiles incluent, par
- exemple :
+ sécurité à &email-security-team; dès que possible. <strong>N'ENVOYEZ
+ PAS</strong> de paquet pour <em>stable</em> ; l'équipe de sécurité le
+ fera.
+
+ Les informations utiles incluent, par exemple :
<list compact>
<item>
sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas
liées.
<p>
+N'incluez <strong>PAS</strong> de changements dans votre paquet qui ne soient
+pas liés directement à la correction de la vulnérabilité. Ceux-ci devraient être
+ensuite enlevés et cela perd du temps. S'il y a d'autres bogues dans votre
+paquet que vous aimeriez corriger, faites un envoi vers
+proposed-updates de la façon habituelle, après l'envoi de l'alerte de sécurité.
+Le mécanisme de mise à jour de sécurité n'est pas un moyen d'introduire des
+changements dans votre paquet qui seraient sinon rejetés de la distribution
+stable, n'essayez donc pas de faire cela, s'il vous plaît.
+<p>
Examinez et testez autant que possible vos changements. Vérifiez les différences
avec la version précédente de manière répétée (<prgn>interdiff</prgn> du
paquet <package>patchutils</package> et <prgn>debdiff</prgn> du paquet
<package>devscripts</package> sont des outils utiles pour cela, voir <ref
id="debdiff">).
<p>
-Lors de la construction de la correction, gardez les points suivants à
-l'esprit :
+Assurez-vous de conserver les points suivants à l'esprit :
<list>
<item>
- Assurez-vous que vous avez pour cible la bonne distribution dans votre
+ Ciblez la bonne distribution dans votre
fichier <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de
<tt>stable-security</tt> et pour <em>testing</em>, c'est
<tt>testing-security</tt> et pour l'ancienne distribution stable, c'est
- <tt>oldstable-security</tt>. Ne ciblez pas
- <var>distribution</var>-proposed-updates !
+ <tt>oldstable-security</tt>. Ne ciblez ni
+ <var>distribution</var>-proposed-updates, ni <tt>stable</tt> !
+</item>
+<item>L'envoi devra avoir « urgency=high ».
+</item>
+<item>
+ Fournissez des entrées de changelog descriptives et complètes. D'autres
+ personnes se baseront dessus pour déterminer si un bogue particulier a été
+ corrigé. Incluez toujours une référence externe, de préférence un
+ identifiant CVE, pour qu'elle puisse être recoupée. Incluez la même
+ information dans le changelog pour <em>unstable</em> pour qu'il soit clair
+ que le même bogue a été corrigé car cela est très utile pour vérifier que
+ le bogue a été corrigé pour la prochaine version stable. Si aucun
+ identifiant CVE n'a encore été assigné, l'équipe de sécurité en demandera
+ un pour qu'il puisse être inclus dans le paquet et dans le changelog.
</item>
<item>
Fournissez des entrées de changelog descriptives et complètes. D'autres
Assurez-vous que le numéro de version est correct. Il doit être plus élevé
que celui du paquet actuel, mais moins que ceux des paquets des versions
des distributions suivantes. En cas de doute, testez-le avec <tt>dpkg
- --compare-versions</tt>. Pour <em>testing</em>, il doit y avoir un numéro
+ --compare-versions</tt>. Soyez attentif à ne pas ré-utiliser un numéro de
+ version que vous auriez déjà utilisé pour un précédent envoi.
+ Pour <em>testing</em>, il doit y avoir un numéro
de version supérieur dans <em>unstable</em>. S'il n'y en a pas encore (par
exemple, si <em>testing</em> et <em>unstable</em> ont la même version),
vous devez envoyer une nouvelle version vers <em>unstable</em> en premier.
également.
</item>
<item>
- Si la source amont a été envoyée auparavant à security.debian.org (par une
- précédente mise à jour de sécurité), construisez le paquet sans la source
- amont (<tt>dpkg-buildpackage -sd</tt>). Sinon, construisez-le avec le
- source complet (<tt>dpkg-buildpackage -sa</tt>).
+ Sauf si la source amont a été envoyée auparavant à security.debian.org (par une
+ précédente mise à jour de sécurité), construisez le paquet avec la source
+ amont complète (<tt>dpkg-buildpackage -sa</tt>). S'il y a déjà eu un
+ précédent envoi à security.debian.org, vous pouvez faire un envoi sans le
+ paquet source (<tt>dpkg-buildpackage -sd</tt>).
</item>
<item>
Assurez-vous d'utiliser exactement le même nom <file>*.orig.tar.gz</file>
déplacer plus tard le correctif de sécurité dans l'archive principale.
</item>
<item>
- Assurez-vous de compiler sur un système
+ Compilez le paquet sur un système
propre, dont tous les paquets appartiennent à la distribution pour laquelle vous
construisez le paquet. Si vous n'avez pas un tel système, vous pouvez
utiliser l'une des machines de debian.org (voir <ref
<p>
Vous ne pouvez demander la suppression d'un paquet que si vous en
êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez
- obtenir l'accord de son dernier responsable.
+ obtenir l'accord de son responsable.
<p>
Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
autres développeurs sur la liste &email-debian-devel;. Le programme
<prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
utile. La commande <tt>apt-cache showpkg <var>paquet</var> </tt> vous
indiquera, entre autres, les paquets qui dépendent de <var>paquet</var>.
+ Le retrait de paquets orphelins est discuté sur &email-debian-qa;.
<p>
Une fois que le paquet a été supprimé, les bogues du paquet doivent être gérés.
Soit ils sont réattribués à un autre paquet dans le cas où le code actuel a
Par le passé, il était possible de supprimer un paquet de <file>Incoming</file>.
Cependant, ce n'est plus possible depuis la mise en place du nouveau système
de file d'attente. Il vous faudra télécharger une nouvelle version de votre
- paquet avec un numéro de version postérieur à celui que vous voulez
+ paquet avec un numéro de version plus élevé que celui que vous voulez
remplacer. Les deux versions seront installées dans l'archive mais seule la
plus récente sera accessible dans <em>unstable</em> car la précédente sera
immédiatement remplacée par la nouvelle. Toutefois, si vous testez
<sect1>Remplacer un paquet ou changer son nom
<p>
-Il peut vous arriver de vous tromper en nommant un paquet et de vouloir
-changer son nom. Dans ce cas, vous devrez intervenir en deux étapes. D'abord, modifiez
+Si vous vous trompez en nommant un paquet, vous devrez intervenir en deux
+ étapes pour changer son nom. D'abord, modifiez
votre fichier <file>debian/control</file> pour que votre nouveau paquet
remplace et entre en conflit avec l'ancien paquet que vous voulez remplacer
(reportez-vous à la <url id="&url-debian-policy;" name="charte Debian"> pour
« <tt>O<footnote><p><em>Orphaned</em> : abandonné.</footnote>:
<var>paquet</var> — <var>courte description</var></tt> » pour
indiquer que le paquet est abandonné. La gravité du bogue sera
- <em>normale</em>. Si vous le jugez nécessaire, envoyez une copie à
+ <em>normale</em> ; si le paquet a une priorité standard ou supérieure,
+ elle devrait être <em>importante</em>. Si vous le jugez nécessaire, envoyez une copie à
&email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le sujet
du message ne contiendra pas le numéro du bogue.
<p>
-Si le paquet est particulièrement important pour la distribution, il vous faudra
- faire un rapport de bogue sur le pseudo-paquet <package>wnpp</package>,
- l'intituler « <tt>RFA<footnote><p><em>Request For Adoption</em> :
- offre d'adoption.</footnote>: <var>paquet</var> — <var>courte
- description</var></tt> » et lui affecter la gravité <em>importante</em>.
- Envoyez une copie de votre rapport de bogue à la liste debian-devel comme
- décrit ci-dessus.
-<p>
-Reportez-vous à la page WNPP<footnote><p><em>Work-needing and prospective
- packages</em> : paquets en souffrance et paquets souhaités.</footnote>
- <url id="&url-wnpp;"> pour en savoir plus.
+Si vous avez simplement l'intention de donner le paquet, mais que vous pouvez
+conserver sa maintenance pour le moment, vous devriez à la place soumettre un
+rapport de bogue sur <package>wnpp</package> et l'intituler <tt>RFA: <var>paquet</var> --
+<var>description courte</var></tt>.
+<tt>RFA</tt> veut dire <em>Request For Adoption</em> (demande d'adoption).
+ <p>
+Vous pouvez trouver plus d'informations sur les <url id="&url-wnpp;" name="pages
+ web WNPP"><footnote><p><em>Work-needing and prospective
+ packages</em> : paquets en souffrance et paquets
+ souhaités.</footnote>.
<sect1 id="adopting">Adopter un paquet
<p>
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.
+Porter un paquet consiste à faire un paquet binaire pour des architectures
+ différentes de celle du paquet binaire fait par le responsable du paquet.
C'est une activité remarquable et essentielle. En fait, les porteurs sont
à l'origine de la plupart des compilations de paquets Debian. Pour un
paquet binaire <em>i386</em>, par exemple, il faut compter une
&number-of-arches; recompilations.
- <sect1 id="kind-to-porters">Être gentil avec les porteurs
+ <sect1 id="kind-to-porters">Être courtois 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
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
+Ici, la première et la plus importante chose est de répondre rapidement aux rapports de bogues et
remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine manière).
Merci pour votre indulgence envers des rapports de bogue succincts ou peu
<var>adresse-porteur</var> par votre adresse électronique. Cette commande
construira les parties du paquet qui dépendent de l'architecture, en utilisant
la cible <em>binary-arch</em> de <file>debian/rules</file>.
+<p>
+Si vous travaillez sur une machine Debian pour vos efforts de portage et que
+vous devez signer votre envoi localement pour son acceptation dans l'archive,
+vous pouvez exécuter <prgn>debsign</prgn> sur votre fichier
+<file>.changes</file> pour qu'il soit signé de manière commode ou utilisez le
+mode de signature à distance de <prgn>dpkg-sig</prgn>.
<sect2 id="binary-only-nmu">
Mises à jour indépendantes binaires ou recompilations
le numéro de version pour que les mauvais anciens paquets soient remplacés dans
l'archive Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
s'ils n'ont pas un numéro de version supérieur à celui actuellement
- disponible). Malgré les modifications nécessaires du changelog, ce type de mise
+ disponible).
+<p>
+Vous devez vous assurez que votre mise à jour indépendante binaire ne rend pas
+ le paquet non installable. Cela peut arriver si un paquet source génère des
+ paquets dépendants et indépendants de l'architecture qui dépendent
+ les uns des autres <em>via</em> $(Source-Version).
+
+<p>
+ Malgré les modifications nécessaires du changelog, ce type de mise
à jour reste une mise à jour indépendante binaire — il n'est pas
nécessaire de reconsidérer le statut des paquets binaires des autres
architectures pour les marquer périmés ou à recompiler.
« 2.9-3 », votre mise à jour portera le numéro
« 2.9-3.0.1 ». Si cette version était « 3.4-2.1 » votre
mise à jour portera le numéro « 3.4-2.1.1 ».
+<p>
+De manière similaire aux envois du porteur initial, la façon correcte d'invoquer
+ <prgn>dpkg-buildpackage</prgn> est <tt>dpkg-buildpackage -B</tt> pour ne
+ construire que les parties dépendant de l'architecture du paquet.
<sect2 id="source-nmu-when-porter">
généralement les instructions de la section <ref id="nmu"> tout comme les
non-porteurs. Les délais d'attente sont cependant plus courts car les
porteurs doivent manipuler un grand nombre de paquets. À nouveau, la
- situation diffère selon la distribution visée.
+ situation diffère selon la distribution visée. Elle varie également selon que
+ l'architecture est candidate pour inclusion dans la prochaine version
+ stable ; les responsables de diffusion décident et annoncent quelles
+ architectures sont candidates.
<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
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).
+ communément acceptées). Pour les envois de <em>stable</em> ou
+ <em>testing</em>, veuillez tout d'abord vous coordonner avec l'équipe de
+ diffusion appropriée.
+
<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>)
upload (NMU)</em>. Dans le présent document, nous traduisons librement
cette expression par « mise à jour indépendante ».
<p>
-Ces mises à jour indépendantes de binaires font de temps en temps partie du
- travail normal des porteurs qui compilent les paquets pour d'autres
- architectures (voir <ref id="porting">). Un développeur peut aussi faire
- des mises à jour indépendantes quand il corrige le paquet d'un autre
- développeur pour éliminer un problème de sécurité ou un bogue bloquant. Cela
- se produit plus particulièrement en période de gel de la distribution de
- développement ou quand le responsable officiel du paquet ne peut pas
+Cette section ne traite que des mises à jour indépendantes de source, c.-à-d.,
+ les mises à jour qui envoient une nouvelle version d'un paquet. Pour les
+ mises à jour indépendantes par des porteurs ou des membres de la QA,
+ veuillez consulter <ref id="binary-only-nmu">. Pour les envois buildd (qui
+ sont également strictement parlant des NMU), veuillez consulter <ref
+ id="buildd">.
+<p>
+La raison principale pour laquelle une mise à jour indépendante est réalisée est
+ quand un développeur a besoin de corriger des paquets d'un autre
+ développeur pour résoudre des problèmes sérieux ou des bogues paralysants
+ ou quand le responsable d'un paquet ne peut pas
fournir une correction dans un délai raisonnable.
<p>
-Ce chapitre contient des informations qui vous expliqueront quand et comment
- faire des mises à jour indépendantes. Une distinction fondamentale doit
- être faite entre les mises à jour indépendantes sources et les mises à
- jour indépendantes binaires. Elle est explicitée dans la section suivante.
-
- <sect1 id="nmu-terms">Terminologie
-<p>
-Deux nouvelles expressions sont introduites dans cette section :
- « mise à jour indépendante source » et « mise à jour
- indépendante binaire ». Ces expressions ont une définition précise dans le
- monde Debian. Elles correspondent toutes deux au même type d'activité ;
- elles impliquent toutes deux qu'une personne fait une mise à jour d'un paquet
- alors qu'elle n'est pas officiellement responsable de ce paquet. C'est pourquoi
- nous qualifions ces mises à jours
- d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser
- entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas
- question d'agir sans prévenir le responsable au préalable (voir <ref
- id="nmu-guidelines">).</footnote>.
-<p>
-Une mise à jour indépendante source est une livraison de paquet faite par une
- personne qui n'est pas le responsable officiel de ce paquet avec pour objectif
- de corriger un bogue dans le paquet. Une mise à jour indépendante source
- implique toujours une modification des sources du paquet, même s'il ne s'agit
- que d'un changement dans le fichier <file>debian/changelog</file>. Ce
- changement peut tout aussi bien concerner la partie amont du source que la
- partie spécifique à Debian. Une mise à jour indépendante source peut aussi
- inclure des paquets spécifiques à une architecture tout comme un fichier
- <em>diff</em> modifié.
-<p>
-Une mise à jour indépendante binaire est constitué par la recompilation et
- l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du
- résultat d'un effort de portage. Une mise à jour indépendante binaire est la
- livraison d'un paquet compilé (souvent pour une autre architecture) à condition
- que cette compilation n'ait pas nécessité de modifications des sources. Dans de
- nombreux cas, les porteurs sont obligés de modifier les sources pour les rendre
- compilables sur leur architecture cible ; 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><p>Non-maintainer upload</footnote>). Pourtant, cela conduit
- souvent à des confusions car beaucoup associent « mise à jour
- indépendante » et « mise à jour indépendante source ». Il faut
- donc rester vigilant. Dans ce chapitre, si nous utilisons l'expression
- « mise à jour indépendante » seule, il s'agit des deux types de
- livraisons.
-
+Tout d'abord, il est capital que ces mises à jour indépendantes soient aussi peu
+ intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
+ modules ou des fichiers, ne déplacez pas les répertoires ; plus
+ généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi
+ petit que possible. Si certaines choses froissent votre sens de l'esthétique,
+ parlez-en au responsable du paquet, au responsable amont ou soumettez un
+ rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
+ pas</em> être effectués lors d'une mise à jour indépendante.
- <sect1 id="nmu-who">Qui peut faire une mise à jour indépendante ?
<p>
-Seuls les responsables Debian officiels peuvent faire des mises à jour
- indépendantes. Un responsable officiel est une personne dont la clé est dans le
- porte-clés Debian. Toute personne est invitée à télécharger les paquets sources
- pour corriger des bogues ; au lieu de faire des mises à jour
- indépendantes, ils pourront soumettre les correctifs qui le méritent au système
- de suivi des bogues. Les responsables apprécient presque toujours les
- correctifs et les rapports de bogue soignés.
+Et souvenez-vous du Serment d'Hippocrate « Par dessus tout, ne pas
+faire de mal ». Il est préférable qu'un paquet ait un bogue ouvert grave
+plutôt qu'un correctif non fonctionnel soit appliqué et que le bogue devienne
+caché, mais toujours non résolu.
+ <sect1 id="nmu-guidelines">Comment faire une mise à jour indépendante ?
+ <p>
+Les mises à jour indépendantes qui corrigent des bogues de gravité importante,
+sérieuse et plus élevée sont encouragées et acceptées. Vous devriez vous
+efforcer de contacter le responsable actuel du paquet : il est peut-être
+sur le point d'envoyer un correctif pour le problème ou il a peut-être une
+meilleure solution.
+ <p>
+Les mises à jour indépendantes doivent être réalisées pour assister un
+responsable de paquet à résoudre des bogues. Les responsables devraient être
+reconnaissants pour cette aide et les personnes faisant la mise à jour
+indépendante devraient respecter les décisions du responsable et tenter
+d'aider personnellement le responsable dans son travail.
+ <p>
+Une mise à jour indépendante devrait suivre toutes les conventions décrites dans
+cette section. Pour un envoi vers <em>testing</em> ou <em>unstable</em>, l'ordre
+suivant des étapes est recommandé :
+ <p>
- <sect1 id="nmu-when">Quand faire une mise à jour indépendante
- source ?
-<p>
-Les recommandations pour déterminer quand faire une mise à jour indépendante
- source dépendent de la distribution visée (i.e. <em>stable</em>,
- <em>unstable</em> ou <em>experimental</em>). Les porteurs, ayant une activité
- particulière, obéissent à des règles légèrement différentes (voir <ref
- id="source-nmu-when-porter">).
-<p>
-Quand une bogue de sécurité est détecté, l'équipe de sécurité peut faire une
- mise à jour indépendante. Veuillez vous reporter à <ref id="bug-security"> pour
- plus d'informations.
-<p>
-Pendant le cycle de mise au point (<em>release cycle</em>, voir <ref
- id="sec-dists">), les livraisons qui corrigent les bogues de gravité
- <em>sérieuse</em> (i.e. <em>serious</em>) et supérieures sont encouragées et
- acceptées. Même pendant cette période, vous devriez tenter d'entrer en contact
- avec le responsable du paquet ; il pourrait bien être sur le point de
- livrer un paquet corrigé lui aussi. Comme pour n'importe quelle mise à jour
- indépendante source, les recommandations de la section <ref
- id="nmu-guidelines"> doivent être respectées. Des exceptions spéciales sont
- effectuées pour <ref id="qa-bsp">.
-<p>
-Envoyer des corrections de bogues vers <em>unstable</em> par une autre personne
- que le responsable ne devrait être fait qu'en suivant ce protocole :
-<p>
<list>
<item>Vérifiez que les bogues du paquet qui devraient être corrigés par la
mise à jour indépendante sont bien référencés dans le système de suivi des
contacter en premier le développeur, et ensuite seulement passer à
l'action.
- <sect1 id="nmu-guidelines">Comment faire une mise à jour indépendante
- source ?
+Veuillez vous reporter à <ref id="qa-bsp"> pour des détails.
<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">.
+Pour la distribution <em>testing</em>, les règles peuvent être changées par les
+responsables de diffusion. Veuillez porter une attention spéciale au fait que le
+moyen habituel pour un paquet d'entrer dans <em>testing</em> est de passer par
+<em>unstable</em>.
<p>
-Tout d'abord, il est capital que ces mises à jour indépendantes soient aussi peu
- intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
- modules ou des fichiers, ne déplacez pas les répertoires ; plus
- généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi
- petit que possible. Si certaines choses froissent votre sens de l'esthétique,
- parlez-en au responsable du paquet, au responsable amont ou soumettez un
- rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
- pas</em> être effectués lors d'une mise à jour indépendante.
-
+Pour la distribution <em>stable</em>, veuillez y apporter une attention
+supplémentaire. Bien sûr, les responsables de version peuvent également modifier
+les rêgles ici. Veuillez vérifier avant l'envoi que tous vos changements sont
+acceptables pour inclusion dans la prochaine version stable par le responsable
+de diffusion.
+<p>
+Quand un bogue de sécurité est détecté, l'équipe de sécurité peut effectuer une
+mise à jour indépendante en utilisant ses propres règles. Veuillez vous référer
+à <ref id="bug-security"> pour plus d'informations.
+<p>
+Pour les différences pour les mises à jour indépendantes par les porteurs,
+veuillez voir <ref id="source-nmu-when-porter">.
+<p>
+Bien sûr, il est toujours possible de s'accorder avec un responsable pour des
+règles spéciales (comme quand le responsable demande « merci d'envoyer le
+correctif directement pour moi et pas de diff nécessaire »).
- <sect2 id="nmu-version">Numéro de version pour les mises à jour
- indépendantes sources
+ <sect1 id="nmu-version">Numéro de version pour les mises à jour
+ indépendantes
<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
fasse une livraison basée sur une nouvelle version amont, cette personne doit
choisir « 0.1 » comme numéro de révision Debian. Le mainteneur du
paquet doit, lui, démarrer sa numérotation à « 1 ».
+<p>
+Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>, vous devrez
+ parfois créer une branche (« fork ») dans l'arbre de numéro des version. Pour cela, vous
+ pouvez utiliser des numéros de version comme 1.1-3sarge0.1.
- <sect2 id="nmu-changelog">
+ <sect1 id="nmu-changelog">
<heading>Les mises à jour indépendantes sources doivent être
mentionnées dans le fichier changelog</heading>
<p>
</example>
- <sect2 id="nmu-patch">Mise à jour indépendante source et système de
+ <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
Si la mise à jour indépendante source (<em>source NMU</em>) corrige des bogues,
ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système de
suivi des bogues plutôt que clos. Par convention, seul le responsable du
- paquet et la personne qui a ouvert le rapport de bogue peuvent clore ce
- rapport. Heureusement, le système d'archivage Debian reconnaît les mises à
+ paquet et la personne qui a ouvert le rapport de bogue ferment les
+ rapports. Heureusement, le système d'archivage Debian reconnaît les mises à
jours indépendantes et positionne correctement le statut des bogues à
<em>fixed</em> si la personne qui fait la mise à jour a listé tous les bogues
dans le fichier changelog en utilisant la syntaxe <tt>Closes:
jusqu'à ce que le responsable du paquet incorpore les modifications de cette
mise à jour dans la version officielle du paquet.
<p>
-Après avoir fait une mise à jour indépendante, il vous faudra aussi ouvrir un
- nouveau rapport de bogue qui inclura un correctif contenant toutes les
- modifications que vous avez faites. Sinon, vous pouvez envoyer cette
- information aux bogues qui sont fixés par votre NMU. Le responsable officiel
+Après avoir fait une mise à jour indépendante, il vous faudra aussi envoyer
+ cette information aux bogues existants que vous avez corrigés par votre NMU
+ en incluant le diff unifié. Sinon, vous pouvez créer un nouveau rapport de
+ bogue et inclure un correctif comprenant toutes les modifications que vous
+ avez réalisées. Le responsable officiel
pourra choisir d'appliquer le correctif, il pourra aussi employer une autre
méthode pour régler le problème. Certains bogues sont corrigés dans la
version amont, ce qui est une bonne raison pour annuler les modifications
<file>changelog</file>.
- <sect2 id="nmu-build">Fabriquer une mise à jour indépendante source
+ <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
comme co-responsable ou responsable de secours (cf. <ref
id="collaborative-maint">).
+ <sect1 id="nmu-vs-qa">Mise à jour indépendante ou envoi de QA ?
+<p>
+Sauf si vous savez que le responsable est toujours actif, il est sage de
+vérifier le paquet pour voir s'il n'a pas été abandonné. La liste actuelle des
+paquets orphelins pour lesquel le champ responsable n'a pas été positionné
+correctement est disponible à <url id="&url-debian-qa-orphaned;">. Si vous
+effectuez une mise à jour indépendante sur un paquet incorrectement orphelin,
+veuillez positionner le responsable à « Debian QA Group
+<packages@qa.debian.org> ».
+
+ <sect1 id="nmu-who">Qui peut faire une mise à jour indépendante ?
+<p>
+Seuls les responsables Debian officiels peuvent faire des mises à jour
+ indépendantes binaire ou source. Un responsable officiel est une personne dont la clé est dans le
+ porte-clés Debian. Tout autre personne est toutefois invitée à télécharger les paquets sources
+ pour corriger des bogues ; au lieu de faire des mises à jour
+ indépendantes, ils pourront soumettre les correctifs qui le méritent au système
+ de suivi des bogues. Les responsables apprécient presque toujours les
+ correctifs et les rapports de bogue soignés.
+
+ <sect1 id="nmu-terms">Terminologie
+<p>
+Deux nouvelles expressions sont introduites dans cette section :
+ « mise à jour indépendante source » et « mise à jour
+ indépendante binaire ». Ces deux expressions ont une signification
+ technique précise dans ce document. Elles correspondent toutes deux au même type d'activité ;
+ elles impliquent toutes deux qu'une personne fait une mise à jour d'un paquet
+ alors qu'elle n'est pas officiellement responsable de ce paquet. C'est pourquoi
+ nous qualifions ces mises à jours
+ d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser
+ entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas
+ question d'agir sans prévenir le responsable au préalable (voir <ref
+ id="nmu-guidelines">).</footnote>.
+<p>
+Une mise à jour indépendante source est une livraison de paquet faite par une
+ personne qui n'est pas le responsable officiel de ce paquet avec pour objectif
+ de corriger un bogue dans le paquet. Une mise à jour indépendante source
+ implique toujours une modification des sources du paquet, même s'il ne s'agit
+ que d'un changement dans le fichier <file>debian/changelog</file>. Ce
+ changement peut tout aussi bien concerner la partie amont du source que la
+ partie spécifique à Debian. Une mise à jour indépendante source peut aussi
+ inclure des paquets spécifiques à une architecture tout comme un fichier
+ <em>diff</em> modifié.
+<p>
+Une mise à jour indépendante binaire est constitué par la recompilation et
+ l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du
+ résultat d'un effort de portage. Une mise à jour indépendante binaire est la
+ livraison d'un paquet compilé (souvent pour une autre architecture) à condition
+ que cette compilation n'ait pas nécessité de modifications des sources. Dans de
+ nombreux cas, les porteurs sont obligés de modifier les sources pour les rendre
+ compilables sur leur architecture cible ; 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><p>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. Il est préférable de toujours utiliser « mise à jour
+ indépendante binaire » ou «NMU binaire » pour les mises à jour
+ indépendantes de binaires seuls.
<sect id="collaborative-maint">
<tt>Standard</tt> ou qui font partie de la base aient des co-responsables.
<p>
Habituellement, il y a un responsable principal et un ou plusieurs
- co-responsables. Le responsable principal est celui dont le nom est indiqué
+ co-responsables. Le responsable principal est la personne dont le nom est indiqué
dans le champ <tt>Maintainer</tt> du fichier <file>debian/control</file>. Les
co-responsables sont tous les autres responsables.
<p>
<p>
La maintenance collaborative peut souvent être facilitée par l'utilisation
d'outils sur Alioth (voir <ref id="alioth">).
+ </sect>
+
+ <sect id="testing">
+ <heading>La distribution <em>testing</em></heading>
+ <p>
+ <sect1 id="testing-basics">
+ <heading>Bases</heading>
+ <p>
+Les paquets sont habituellement installés dans la distribution <em>testing</em>
+après avoir atteint un certain degré de test dans <em>unstable</em>.
+ <p>
+Ils doivent être en synchronisation pour toutes les architectures et ne doivent
+pas avoir de dépendances qui les rendraient ininstallables ; ils doivent
+également n'avoir aucun bogue bloquant l'inclusion du paquet dans une version
+stable (« release-critical ») au moment où ils sont installés dans
+<em>testing</em>. Ainsi, <em>testing</em> devrait toujours être prête pour être
+une version candidate stable. Veuillez voir ci-dessous pour les détails.
+
+ <sect1 id="testing-unstable">
+ <heading>Mises à jour depuis <em>unstable</em></heading>
+ <p>
+Les scripts qui mettent à jour la distribution <em>testing</em> sont exécutés
+ chaque jour après l'installation des paquets mis à jour. Ils fabriquent les
+ fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils
+ le font d'une manière intelligente pour éviter toute incohérence et essayer de
+ n'utiliser que des paquets sans bogue.
+ <p>
+L'inclusion d'un paquet d'<em>unstable</em> est soumise aux conditions
+suivantes :
+<list>
+ <item>
+Le paquet doit avoir été disponible dans <em>unstable</em> depuis 2, 5 ou
+10 jours selon le champ d'urgence de l'envoi (élevée, moyenne ou basse).
+Veuillez noter que cette urgence est « collande » (« sticky »), ce qui
+veut dire que l'envoi avec l'urgence la plus élevée depuis la dernière
+transition dans <em>testing</em> est prise en compte. Ces délais peuvent être
+doublés lors d'un gel de distribution, ou la transition dans <em>testing</em>
+peut être complètement désactivée ;
+ <item>
+Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
+version disponible dans <em>testing</em> ;
+ <item>
+Il doit être disponible pour toutes les architectures pour lesquelles
+il a été auparavant construit. <ref id="madison"> peut être
+intéressant pour vérifier cette information ;
+ <item>
+Il ne doit pas casser les dépendances d'un paquet qui est déjà
+disponible dans <em>testing</em> ;
+ <item>
+Les paquets dont il dépend doivent soit être déjà disponibles dans
+<em>testing</em> soit être acceptés dans <em>testing</em> au
+même moment (et ils doivent respecter tous les critères nécessaires).
+</list>
+ <p>
+Pour savoir si un paquet a progressé ou non dans <em>testing</em>, veuillez voir la
+sortie du script de <em>testing</em> sur la <url name="page web de la distribution testing"
+id="&url-testing-maint;"> ou utilisez le programme <prgn>grep-excuses</prgn>
+inclus dans le paquet <package>devscripts</package>. Si l'on veut rester
+informé de la progression de ses paquets dans <em>testing</em>, on peut
+facilement le mettre dans la <manref section="5" name="crontab">.
+ <p>
+Le fichier <file>update_excuses</file> ne donne pas toujours la raison précise
+ pour laquelle un paquet est refusé, on peut avoir à la chercher soi-même en
+ regardant ce qui serait cassé avec l'inclusion du paquet. La <url
+ id="&url-testing-maint;" name="page web de la distribution testing"> donne plus
+ d'informations à propos des problèmes courants qui peuvent occasionner cela.
+ <p>
+Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce que le
+ jeu des inter-relations est trop compliqué et ne peut être résolu par le
+ script. Voir ci-dessous pour des détails.
+ <p>
+Des analyses de dépendances plus avancées sont présentées sur
+<url id="http://bjorn.haxx.se/debian/"> – mais, attention, elles affichent
+également les dépendances de construction qui ne sont pas considérées par
+britney.
+
+ <sect2 id="outdated">
+ <heading>Désynchronisation</heading>
+ <p>
+Pour le script de migration dans <em>testing</em>, « désynchronisé »
+(<em>outdated</em> veut dire ceci : il y a différentes versions dans
+<em>unstable</em> pour les architectures de version (à l'exception des
+architectures dans fuckedarches ; fuckedarches est une liste des
+architectures qui ne suivent pas le rythme (dans update_out.py), mais
+actuellement cette liste est vide). « Désynchronisé » n'a rien à voir
+avec les architectures que le paquet fournit pour <em>testing</em>.
+ <p>
+Considérons cet exemple :
+ <p>
+ <example>
+foo | alpha | arm
+---------+-------+----
+testing | 1 | -
+unstable | 1 | 2
+</example>
+ <p>
+Le paquet est désynchronisé pour alpha dans <em>unstable</em> et n'entrera pas
+dans <em>testing</em>. Supprimer foo de <em>testing</em> n'aiderait en rien, le
+paquet serait toujours désynchronisé pour alpha et ne se propagerait pas dans
+<em>testing</em>.
+ <p>
+Cependant, si ftp-master supprime un paquet d'<em>unstable</em> (ici pour arm) :
+ <p>
+ <example>
+foo | alpha | arm | hurd-i386
+---------+-------+-----+----------
+testing | 1 | 1 | -
+unstable | 2 | - | 1
+ </example>
+ <p>
+Dans ce cas, le paquet est synchronisé pour toutes les architectures de version
+dans <em>unstable</em> (et l'architecture supplémentaire hurd-i386 ne compte pas
+car ce n'est pas une architecture de version).
+ <p>
+Quelquefois, la question est soulevée pour savoir s'il est possible de permettre
+à des paquets de passer dans <em>testing</em> qui ne sont pas encore construits
+pour toutes les architectures : non. Simplement non. (Excepté si vous êtes
+responsable de glibc ou équivalent).
+
+ <sect2 id="removals">
+ <heading>Suppressions de <em>testing</em></heading>
+ <p>
+Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre
+paquet : ceci ne se produit que pour permettre à un <em>autre</em> paquet
+d'entrer, ce dernier paquet doit être prêt pour tous les autres critères.
+Considérons par exemple qu'un paquet a est en conflit avec la nouvelle version
+de b alors a peut être supprimé pour permettre l'entrée de b.
+ <p>
+Bien sûr, il existe une autre raison pour supprimer un paquet de
+<em>testing</em> : le paquet est trop bogué (et avoir un seul bogue RC est
+suffisant pour être dans cet état).
+
+ <sect2 id="circular">
+ <heading>Dépendances circulaires</heading>
+ <p>
+Une situation qui n'est pas très bien gérée par britney est si un paquet a
+dépend de la nouvelle version d'un paquet b et vice versa.
+ <p>
+Voici un exemple :
+ <p>
+ <example>
+ | testing | unstable
+--+-----------------+------------
+a | 1; dépend: b=1 | 2; dépend: b=2
+b | 1; dépend: a=1 | 2; dépend: a=2
+ </example>
+ <p>
+Le paquet a n'est pas considéré pour la mise à jour, le paquet b non plus.
+ <p>
+Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de
+diffusion. Veuillez les contacter en envoyant un courrier électronique à
+debian-release@lists.debian.org si cela se produit pour l'un de vos paquets.
+
+
+ <sect2>
+ <heading>Influence de paquet dans <em>testing</em></heading>
+ <p>
+Généralement, l'état d'un paquet dans <em>testing</em> ne change rien pour la
+transition de la prochaine version d'<em>unstable</em> vers <em>testing</em>,
+avec deux exceptions : si le nombre de bogues RC du paquet est réduit, le
+paquet peut migrer même s'il a encore des bogues RC. La seconde exception est
+que si la version du paquet dans <em>testing</em> est désynchronisée entre les
+différentes architectures, alors toute architecture peut être mise à jour vers
+la version du paquet source ; cependant, cela ne peut se produire que si le
+paquet a été précédemment forcé, si l'architecture est dans fuckedarches ou s'il
+n'y avait pas du tout de paquet binaire de cette architecture présent dans
+<em>unstable</em> lors de la migration dans <em>testing</em>.
+ <p>
+En résumé, cela veut dire : la seule influence qu'un paquet de
+<em>testing</em> a sur la nouvelle version du même paquet est que la nouvelle
+version peut rentrer plus facilement.
+
+ <sect2 id="details">
+ <heading>Détails</heading>
+ <p>
+Si vous êtes intéressé par les détails, voici comment fonctionne britney :
+ <p>
+Les paquets sont examinés pour savoir si ce sont des candidats valides. Cela
+donne le fichier « update excuses ». Les raisons les plus communes
+pour lesquelles un paquet n'est pas considéré sont la jeunesse du paquet, le
+nombre de bogues RC et la désynchronisation pour certaines architectures. Pour
+cette partie, les responsables de version ont des marteaux de toute taille pour
+forcer britney à considérer un paquet. (Le gel de la base est également codé
+dans cette partie de britney.) (Il y a une chose semblable pour les mises à jour
+binaires pures, mais cela n'est pas décrit ici. Si vous êtes intéressé par cela,
+veuillez utiliser le code.)
+ <p>
+Maintenant, la partie la plus complexe se produit : britney tente de mettre
+à jour <em>testing</em> avec des candidats valides ; en premier, chaque
+paquet individuellement, puis des groupes de plus en plus larges de paquets
+ensemble. Chaque tentative est acceptée si <em>testing</em> n'est pas moins
+ininstallable après la mise à jour qu'avant celle-ci. (Avant et après cette
+partie, certains coups de pouce sont traités ; mais, comme seuls les
+responsables de version peuvent positionner des coups de pouce, cela n'est
+probablement pas très important pour vous.)
+ <p>
+Si vous voulez voir plus de détails, vous pouvez le voir dans
+merkel:/org/ftp.debian.org/testing/update_out/ (ou dans
+~aba/testing/update_out pour voir une configuration avec un fichier de paquets
+plus petit). Par le web, c'est à <url
+id="http://ftp-master.debian.org/testing/update_out_code/">.
+ <p>
+Les coups de pouce sont visibles sur <url
+id="http://ftp-master.debian.org/testing/hints/">.
+
+
+ <sect1 id="t-p-u">
+ <heading>Mises à jour directes dans <em>testing</em></heading>
+ <p>
+La distribution <em>testing</em> est peuplée avec des paquets en provenance
+d'<em>unstable</em> selon des règles expliquées ci-dessus. Cependant, dans
+certains cas, il est nécessaire d'envoyer des paquets construits seulement pour
+<em>testing</em>. Pour cela, vous pouvez envoyer vos paquets vers
+<em>testing-proposed-updates</em>.
+ <p>
+Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement,
+ils doivent passer entre les mains du responsable de distribution. Vous devez
+donc avoir une bonne raison pour les y envoyer. Pour savoir ce que
+représente une bonne raison aux yeux du responsable de distribution, vous
+devriez lire les instructions données qu'il envoie régulièrement sur
+&email-debian-devel-announce;.
+ <p>
+Vous ne devriez pas envoyer un paquet à <em>testing-proposed-updates</em> quand
+vous pouvez le mettre à jour par <em>unstable</em>. Si vous ne pouvez faire
+autrement (par exemple, parce que vous avez une nouvelle version de
+développement dans <em>unstable</em>), vous pouvez l'utiliser, mais il est
+recommandé de demander l'autorisation du responsable de distribution auparavant.
+Même si un paquet est gelé, des mises à jour par <em>unstable</em> sont possibles
+si l'envoi dans <em>unstable</em> ne tire pas de nouvelle dépendance.
+ <p>
+Les numéros de version sont habituellement choisis en ajoutant le nom de
+code de la distribution <em>testing</em> et un numéro d'incrémentation, comme
+1.2sarge1 pour le premier envoi dans <em>testing-proposed-updates</em> du paquet
+en version 1.2.
+
+
+ <sect1 id="faq">
+ <heading>Questions fréquemment posées</heading>
+ <p>
+
+ <sect2 id="rc">
+ <heading>Qu'est-ce que sont les bogues bloquant l'intégration dans la
+ version stable et comment sont-ils comptés ?</heading>
+ <p>
+Tous les bogues de gravité assez élevée sont par défaut considérés
+comme bloquant l'intégration du paquet dans la version stable ;
+actuellement, ce sont les bogues critiques, graves et sérieux.
+ <p>
+Certains bogues sont supposés avoir un impact sur les chances que le paquet a
+d'être diffusé dans la version stable de Debian : en général, si un paquet
+a des bogues bloquants, il n'ira pas dans <em>testing</em> et par conséquent,
+ne pourra pas être diffusé dans <em>stable</em>.
+ <p>
+Le compte des bogues de <em>testing</em> pour un paquet est considéré comme
+étant à peu près le nombre de bogue lors du dernier pointage quand la version
+<em>testing</em> a été égale à la version <em>unstable</em>. Les bogues marqués
+<em>woody</em> ou <em>sarge</em> ne sont pas comptés. Cependant les bogues
+marqués <em>sid</em> sont comptés.
+
+
+ <sect2>
+ <heading>Comment est-ce que l'installation d'un paquet dans
+ <em>testing</em> peut casser d'autres paquets ?</heading>
+ <p>
+La structure des archives de la distribution est faite de telle façon qu'elles
+ne peuvent contenir qu'une version d'un paquet ; un paquet est défini par
+son nom. Donc, quand le paquet source acmefoo est installé dans
+<em>testing</em> avec ses paquets binaires acme-foo-bin, acme-bar-bin,
+libacme-foo1 et libacme-foo-dev, l'ancienne version est supprimée.
+ <p>
+
+Cependant, l'ancienne version pouvait fournir à un paquet binaire un vieux
+soname d'une bibliothèque, comme libacme-foo0. Supprimer l'ancien acmefoo va
+supprimer libacme-foo0, ce qui va casser tout paquet qui en dépend.
+ <p>
+Évidemment, cela touche principalement des paquets qui fournissent des jeux
+changeants de paquets binaires dans différentes version (par suite,
+principalement des bibliothèques). Cependant, cela va aussi toucher des paquets
+sur lesquels une dépendance versionnée a été déclarée du type ==, <= ou <<.
+ <p>
+Quand le jeu de paquets binaires fournis par un paquet source change de cette
+façon, tous les paquets qui dépendent des anciens binaires doivent être mis à
+jour pour dépendre de la nouvelle version à la place. Comme l'installation d'un
+tel paquet source dans <em>testing</em> casse tous les paquets qui en dépendent
+dans <em>testing</em>, une certaine attention doit y être portée : tous les
+paquets en dépendant doivent être mis à jour et prêts à être installés eux-même
+pour qu'ils ne cassent pas et, une fois que tout est prêt, une intervention
+manuelle du responsable de version ou d'un de ses assistants est normalement
+requise.
+ <p>
+Si vous avez des problèmes avec des groupes compliqués de paquets comme ceci,
+contactez debian-devel ou debian-release en demandant de l'aide.
+ </sect>
<chapt id="best-pkging-practices">
<p>
Les pratiques suivantes sont relatives au fichier <file>debian/control</file>.
Elles viennent en complément des <url
-id="&url-debian-policy;ch-miscellaneous.html#s-descriptions" name="règles pour
+id="&url-debian-policy;ch-binary.html#s-descriptions" name="règles pour
les descriptions des paquets">.
<p>
La description du paquet, telle qu'elle est définie par le champ correspondant
<example>ispell -d american -g debian/control</example>
+ <p>
+L'utilisateur s'attend habituellement à ce que les réponses aux questions
+suivantes soient présentes dans la description du paquet.
+ <list>
+ <item>
+Qu'est-ce que fait le paquet ? Si c'est un ajout d'un autre paquet, la
+description courte du paquet dont il est un ajout devrait le spécifier.
+ <item>
+Pourquoi est-ce qu'il voudrait installer ce paquet ? Ceci est lié à ce qui
+est ci-dessus, mais pas tout à fait (c'est un client de messagerie ; il
+est cool, rapide, s'interface avec pgp, ldap et imap, a les fonctionnalités
+X, Y et Z).
+ <item>
+Si ce paquet ne devrait pas être installé directement, mais être tiré par un
+autre paquet, cela devrait être mentionné.
+ <item>
+Si le paquet est expérimental, ou s'il y a d'autres raisons pour lesquelles il
+ne devrait pas être utilisé, si un autre paquet devrait être utilisé à la place,
+cela devrait également être présent.
+ <item>
+En quoi le paquet est différent des paquets concurrents ? Est-ce que c'est
+une meilleure implémentation ? A-t-il plus de fonctionnalités, des
+fonctionnalités différentes ? Pourquoi devrait-il choisir ce paquet (2.
+devrait parler de la classe des paquets et ceci à propos de ce paquet
+particulier, si vous avez des informations liés au deux).
+ </list>
+
</sect1>
<sect1 id="bpp-upstream-info">
descriptif, commencez par insérer le titre de chacun des différents bogues.
<p>
</sect1>
+
+ <sect1 id="bpp-news-debian">
+ <heading>Compléter les changelogs avec les fichiers NEWS.Debian</heading>
+ <p>
+Les nouvelles importantes à propos des changements dans un paquet peuvent
+également être placées dans les fichiers NEWS.Debian. Ces nouvelles seront
+affichées par des outils comme apt-listchanges, avant le reste des changelogs.
+Ceci est le moyen préféré pour informer les utilisateurs des changements
+significatifs dans un paquet. Il est préférable d'utiliser ce fichier plutôt que
+d'utiliser des notes debconf car c'est moins ennuyeux et l'utilisateur peut y
+revenir et se référer au fichier NEWS.Debian après l'installation. Et c'est
+mieux que de lister les changements principaux dans README.Debian car
+l'utilisateur peut facilement rater de telles notes.
+ <p>
+Le format du fichier est le même que pour un fichier de changelog Debian, mais
+il n'utilise pas d'astérisques et décrit chaque élément de nouvelle dans un
+paragraphe complet si nécessaire plutôt que les résumés concis qui iraient dans un
+changelog. C'est une bonne idée de passer votre fichier par dpkg-parsechangelog
+pour vérifier son formatage car il n'est pas vérifié automatiquement pendant la
+construction comme le changelog. Voici un exemple d'un vrai fichier NEWS.Debian :
+<example>
+cron (3.0pl1-74) unstable; urgency=low
+
+ The checksecurity script is no longer included with the cron package:
+ it now has its own package, "checksecurity". If you liked the
+ functionality provided with that script, please install the new
+ package.
+
+ -- Steve Greenland <stevegr&debian.org> Sat, 6 Sep 2003 17:15:03 -0500
+</example>
+ <p>
+Le fichier NEWS.Debian est installé comme
+/usr/share/doc/<package>/NEWS.Debian.gz. Il est compressé et a toujours ce
+nom même dans les paquets natifs Debian. Si vous utilisez debhelper,
+dh_installchangelogs installera les fichiers debian/NEWS pour vous.
+ <p>
+À la différence des fichiers changelog, vous n'avez pas besoin de mettre à jour
+les fichiers NEWS.Debian à chaque nouvelle version. Ne les mettez à jour que si
+vous avez quelque chose de particulièrement important que l'utilisateur a
+besoin de savoir. Si vous n'avez pas de nouvelles du tout, il n'est pas
+nécessaire de fournir de fichier NEWS.Debian dans votre paquet. Pas de
+nouvelles, bonne nouvelle !
+
</sect>
<!-- <sect1 id="pkg-mgmt-cvs">Managing a package with CVS
Debian.
</sect1>
-</sect>
+ <sect1 id="bpp-locale">
+ <heading>Avoir besoin d'une certaine locale pendant la construction</heading>
+ <p>
+Si vous avez besoin d'une certaine locale pendant la construction, vous pouvez
+créer un fichier temporaire par cette astuce :
+ <p>
+Si vous positionnez LOCPATH à l'équivalent de /usr/lib/locale, et LC_ALL au nom
+de la locale que vous générez, vous devriez obtenir ce que vous voulez sans être
+root. Quelque chose comme ceci :
+
+<example>
+LOCALE_PATH=debian/tmpdir/usr/lib/locale
+LOCALE_NAME=en_IN
+LOCALE_CHARSET=UTF-8
+
+mkdir -p $LOCALE_PATH
+localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
+
+# Using the locale
+LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
+</example>
+ </sect1>
+
+ <sect1 id="bpp-transition">
+ <heading>Rendre les paquets de transition conformes avec deborphan</heading>
+ <p>
+Deborphan est un programme qui aide les utilisateurs à détecter quels paquets
+peuvent être enlevés sans problème du système, i.e. ceux dont aucun paquet ne
+dépend. L'opération par défaut est de chercher seulement parmi les sections libs
+et oldlibs pour débusquer les bibliothèques inutilisées. Mais si l'on passe le
+bon argument, il tente d'attraper d'autres paquets inutiles.
+ <p>
+Par exemple, avec --guess-dummy, il cherche tous les paquets de transition qui
+étaient nécessaires pour une mise à jour, mais qui peuvent sans problème être
+supprimés. Pour cela, il recherche la chaîne de caractères « dummy »
+ou « transitional » dans la description courte.
+ <p>
+Ainsi, quand vous créez un tel paquet, assurez-vous d'ajouter ce texte dans la
+description courte. Si vous cherchez des exemples, exécutez simplement :
+ <example>apt-cache search .|grep dummy</example> or
+ <example>apt-cache search .|grep transitional</example>.
+ </sect1>
+
+ </sect>
</chapt>
soit pas désenregistré du système. D'un autre côté, il est possible qu'il
ait simplement besoin d'un rappel.
<p>
+Il y a un système simple (la base de données MIA) dans laquelle les informations
+sur les responsables supposés (deemed ?) inactifs sont enregistrées. Quand un
+membre du groupe QA contacte un responsable inactif ou trouve plus d'informations
+sur celui-ci, c'est enregistré dans la base de données MIA. Ce système
+est disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut être
+interrogé avec un outil de nom <prgn>mia-history</prgn>. Par défaut,
+<prgn>mia-history</prgn> affiche des informations sur toutes les personnes qu'il
+connaît, mais il accepte des expressions rationnelles comme paramètre qu'il
+utilise comme correspondance de noms d'utilisateur. <example>mia-history
+--help</example> affiche quels paramètres sont acceptés. Si vous déterminez
+qu'aucune information n'a encore été enregistrée pour un responsable inactif ou
+que vous voulez ajouter plus d'informations, vous devez utiliser la procédure
+suivante.
+<p>
La première étape est de contacter poliment le responsable et d'attendre une
réponse pendant un temps raisonnable. Il est assez difficile de définir le
« temps raisonnable », mais il est important de prendre en compte que
<example>
dpkg-buildpackage -k<var>KEY-ID</var>
</example>
- avant de l'envoyer dans le répertoire Incoming.
+ avant de l'envoyer dans le répertoire incoming. Bien sûr, vous pouvez également
+utiliser toute partie de votre <var>KEY-ID</var>, tant qu'elle est unique dans
+votre porte-clés secret.
<p>
Le champ Maintainer du fichier <file>control</file> et le fichier
<file>changelog</file> devraient afficher la personne qui a fait l'empaquetage,
Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;" name="liste à
vérifier pour les responsables de candidatures"> sur le site web Debian.
+ <chapt id="l10n">Internationalisation, traduction, être internationalisé et
+ être traduit
+ <p>
+Debian prend en charge un nombre toujours croissant de langues naturelles. Même
+si l'anglais est votre langue maternelle et que vous ne parlez pas d'autre
+langue, il est de votre devoir de responsable d'être conscient des problèmes
+d'internationalisation (abrégé en i18n à cause des 18 lettres entre le i et
+le n dans internationalisation). C'est pourquoi, même si des programmes
+seulement en anglais vous suffisent, vous devriez lire la plupart de ce chapitre.
+ <p>
+Selon l'<url id="http://www.debian.org/doc/manuals/intro-i18n/"
+name="introduction à l'i18n"> de Tomohiro KUBOTA, « I18N
+(internationalisation) veut dire la modification d'un logiciel ou de
+technologies liées pour qu'un logiciel puisse potentiellement gérer des langues
+multiples, des conventions multiples et ainsi de suite dans le monde
+entier » alors que "L10N (localisation) veut dire l'implémentation dans
+une langue spécifique pour un logiciel déjà internationalisé ».
+ <p>
+La l10n et l'i18n sont liées, mais les difficultés liées à chacune sont très
+différentes. Il n'est pas vraiment difficile de permettre à un programme de
+changer la langue dans laquelle sont affichés les textes selon les paramètres de
+l'utilisateur, mais il est très couteux en temps de traduire réellement ces
+messages. D'un autre côté, définir le codage des caractères est trivial, mais
+adapter le code pour utiliser des codages de caractères différents est un
+problème vraiment difficile.
+ <p>
+En laissant de côté les problèmes d'i18n pour lesquels il n'existe pas de règle
+générale, il n'y a pas actuellement d'infrastructure centralisée pour la l10n
+dans Debian qui puisse être comparée au mécanisme dbuild pour le portage. Le
+plus gros du travail doit donc être réalisé manuellement.
+
+
+ <sect id="l10n-handling">Comment sont gérées les traductions au sein de Debian
+ <p>
+La gestion des traductions des textes contenus dans un paquet est encore une
+tâche manuelle et le processus dépend du type de texte que vous désirez voir traduit.
+ <p>
+Pour les messages des programmes, l'infrastructure gettext est utilisée pour la
+plupart d'entre eux. La plupart du temps, la traduction est gérée en amont dans
+des projets comme le
+<url id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="projet de trduction
+ libre">, le <url id="http://developer.gnome.org/projects/gtp/"
+ name="projet de traduction de Gnome"> ou <url
+ id="http://i18n.kde.org/" name="celui de KDE">.
+La seule ressource centralisée dans Debian est les <url
+id="http://www.debian.org/intl/l10n/" name="statistiques de traduction Debian
+ centralisées"> où vous pouvez trouvez des statistiques sur les
+fichiers de traduction trouvés dans les paquets, mais il n'y a aucune
+infrastructure pour faciliter le processus de traduction.
+ <p>
+Un effort pour traduire les descriptions de paquet a démarré il y a longtemps
+même si les outils fournissent très peu de prise en charge pour les utiliser
+vraiement (i.e. seul APT peut les utiliser quand il est configuré
+convenablement). Il n'y a rien à faire de la part des responsables et les
+traducteurs devraient utiliser le <url id="http://ddtp.debian.org/"
+name="DDTP">.
+ <p>
+Pour les questionnaires debconf, le responsable devrait utiliser le paquet
+po-debconf pour faciliter le travail des traducteurs, qui peuvent utiliser le
+DDTP pour faire leur travail (mais les équipes française et brésilienne ne le
+font pas). On peut trouver certaines statistiques à la fois sur le site du
+DDTP (à propos de ce qui est vraiment traduit) et sur le site des <url
+id="http://www.debian.org/intl/l10n/" name="statistiques de traduction
+ Debian centralisées"> (à propos de ce qui est intégré dans les paquets).
+ <p>
+Pour les pages web, chaque équipe l10n a accès au CVS correspondant et les
+statistiques sont disponibles sur le site des statistiques de traduction Debian
+centralisées.
+ <p>
+Pour la documentation générale à propos de Debian, le processus est plus ou
+moins le même que pour les pages web (les traducteurs ont un accès au CVS), mais
+il n'y a pas de page de statistiques.
+ <p>
+Pour la documentation spécifique des paquets (pages de manuel, document info,
+autres formats), presque tout est encore à faire. Le plus notable, le projet KDE
+gère la traduction de ses documentations de la même façon que ses messages de
+programme. Les pages de manuel spécifiques Debian sont gérées dans un <url
+id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="dépôt CVS spécifique">.
+
+ <sect id="l10n-faqm">FAQ I18N & L10N pour les responsables
+ <p>
+Voici une liste des problèmes que les responsables peuvent rencontrer concernant
+l'i18n et la l10n. Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de
+consensus sur ces points au sein de Debian et que ce ne sont que des conseils.
+Si vous avez une meilleure idée pour un problème donné ou si vous êtes en
+désaccord avec certains points, vous êtes libre de fournir vos impressions pour
+que ce document puisse être amélioré.
+
+ <sect1 id="l10n-faqm-tr">Comment faire en sorte qu'un texte soit traduit ?
+ <p>
+Pour traduire une description de paquet ou un questionnaire debconf, nous n'avez
+rien à faire, l'infrastructure du DDTP répartira le matériel à traduire aux
+volontaires sans besoin d'interaction de votre part.
+ <p>
+Pour tous les autres matériels (fichiers gettext, pages de manuel ou autre
+documentation), la meilleure solution est de placer votre texte quelque part sur
+l'Internet et de demander sur debian-i18n pour une traductions dans différentes
+langues. Certains membres des équipes de traduction sont abonnés à cette liste
+et ils prendront soin de la traduction et du processus de relecture. Une fois
+ceci fait, vous recevrez de leur part votre document traduit dans votre boîte à
+lettre.
+
+ <sect1 id="l10n-faqm-rev">Comment faire en sorte qu'une traduction
+ donnée soit relue ?
+ <p>
+De temps en temps, des personnes indépendantes traduiront certains textes
+inclus dans votre paquet et vous demanderont de les inclure dans le paquet.
+Cela peut devenir problématique si vous n'êtes pas familier avec la langue
+donnée. C'est une bonne idée d'envoyer le document à la liste de diffusion l10n
+correspondante en demandant une relecture. Une fois celle-ci faite, vous devriez
+avoir plus confiance dans la qualité de la traduction et l'inclure sans crainte
+dans votre paquet.
+
+ <sect1 id="l10n-faqm-update">Comment faire en sorte qu'une traduction
+ donnée soit mise à jour ?
+ <p>
+Si vous avez certaines traductions d'un texte donné qui trainent (?), chaque fois
+que vous mettez à jour l'original, vous devriez gentiment demander au précédent
+traducteur de mettre à jour sa traduction avec le texte original. Gardez à
+l'esprit que cette tâche demande du temps, au moins une semaine pour obtenir une
+mise à jour relue.
+ <p>
+Si votre traducteur ne répond pas, vous pouvez demander de l'aide sur la liste de
+diffusion correspondante. Si tout échoue, n'oubliez pas de mettre un
+avertissement dans le document traduit, indiquant que la traduction est un peu
+obsolète et que le lecteur devrait se référer au document d'origine si possible.
+ <p>
+Évitez de supprimer complètement une traduction à cause de son obsolescence. Un
+vieux document est souvent mieux que pas de documentation du tout pour les
+personnes non anglophones.
+
+ <sect1 id="l10n-faqm-bug">Comment gérer un rapport de bogue concernant
+ une traduction ?
+ <p>
+La meilleure solution peut être de marquer le bogue comme « suivi au développeur
+amont » (<em>forwarded to upstream</em>) et de faire suivre le bogue à la
+fois au précédent traducteur et à son équipe (en utilisant la liste de diffusion
+debian-l10n-XXX correspondante).
+
+ <sect id="l10n-faqtr">FAQ I18N & L10N pour les traducteurs
+ <p>
+Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de
+procédure générale dans Debian concernant ces points et que, dans tous les cas,
+vous devriez collaborer avec votre équipe et les responsables des paquets.
+
+ <sect1 id="l10n-faqtr-help">Comment aider l'effort de traduction ?
+ <p>
+Choisissez ce que vous désirez traduire, assurez-vous que personne ne travaille
+déjà dessus (en utilisant votre liste de diffusion debian-l10n-XXX),
+traduisez-le, faites-le relire par d'autres personnes dont c'est également la
+langue maternelle sur votre liste de diffusion l10n et fournissez-le au
+responsable du paquet (voir le point suivant).
+
+ <sect1 id="l10n-faqtr-inc">Comment fournir une traduction pour
+ inclusion dans un paquet ?
+ <p>
+Assurez-vous que votre traduction est correcte (en demandant une relecture sur
+votre liste de discussion l10n) avant de la fournir pour inclusion. Cela
+gagnera du temps à tout le monde et évitera le chaos qui résulterait d'avoir
+plusieurs versions du même document dans les rapports de bogue.
+ <p>
+La meilleure solution est de remplir un bogue standard contenant la traduction
+sur le paquet. Assurez-vous d'utiliser l'étiquette « patch » et
+n'utilisez pas une gravité supérieure à « wishlist » car l'absence de
+traduction n'empêche jamais un programme de fonctionner.
+
+ <sect id="l10n-best">Meilleures pratiques actuelles concernant la l10n
+ <p>
+<list>
+ <item>
+En tant que responsable, n'éditez jamais les traductions en aucune façon (même
+pour reformater l'affichage) sans demander à la liste de diffusion l10n
+correspondante. Vous risquez, par exemple, de casser le codage du fichier en
+agissant ainsi. De plus, ce que vous considérez comme une erreur peut être
+correct (ou même nécessaire) pour une langue donnée.
+ <item>
+En tant que traducteur, si vous trouvez une erreur dans le texte d'origine,
+assurez-vous de l'indiquer. Les traducteurs sont souvent les lecteurs les plus
+attentifs d'un texte donné et s'ils ne rendent pas compte des erreurs qu'ils
+trouvent, personne ne le fera.
+ <item>
+Dans tous les cas, rappelez-vous que le problème principal avec la l10n est
+qu'elle demande la coopération de plusieurs personnes et qu'il est très facile
+de démarrer une guerre incendiaire à propos de petits problèmes dûs à une
+incompréhension. Donc, si vous avez des problèmes avec votre interlocuteur,
+demandez de l'aide sur la liste de diffusion l10n correspondante, sur
+debian-i18n ou même sur debian-devel (attention, cependant, les discussions sur
+la l10n tournent très souvent à l'incendie sur cette liste :)
+ <item>
+Dans tous les cas, la coopération ne peut être atteinte qu'avec un
+<strong>respect mutuel</strong>.
+</list>
<appendix id="tools">Aperçu des outils du responsable Debian
Le paquet <package>yada</package> est un autre assistant pour la création de
paquets. Il utilise un fichier <file>debian/packages</file> pour générer
<file>debian/rules</file> et d'autres fichiers nécessaires dans le
- sous-répertoire <file>debian/</file>.
-<p>
-Remarque : <package>yada</package> est qualifié de « quasiment non
- maintenu » par son responsable, Charles Briscoe-Smith. Son usage est donc
- déconseillé.
+ sous-répertoire <file>debian/</file>. Le fichier <file>debian/packages</file>
+ contient des instructions pour construire les paquets et il n'y a pas besoin de
+ créer de fichiers
+<file>Makefile</file>. Il existe la possibilité d'utiliser un moteur de macros
+ semblable à celui utilisé dans les fichiers SPECS des paquets source RPM.</p>
+ <p>
+Pour plus d'informations, voir le
+<tt><url id="http://yada.alioth.debian.org/" name="site de YADA"></tt>.</p>
</sect1>
démarrer <prgn>dinstall</prgn> en mode simulation (<em>dry-run</em>) après le
téléchargement.
</sect1>
+ <sect1 id="dcut">
+ <heading><package>dcut</package></heading>
+ <p>
+Le script <package>dcut</package> (faisant partie du paquet <ref id="dput">)
+aide à la suppression de fichiers du répertoire d'envoi ftp.
+ </sect1>
</sect>
~ianmdlvl / developers-reference.git / commitdiff