1 <!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
2 <!-- include version information so we don't have to hard code it
3 within the document -->
4 <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
5 <!-- common, language independent entities -->
6 <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
7 <!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
9 <!-- CVS revision of this document -->
10 <!ENTITY cvs-rev "$Revision: 1.64 $">
12 <!-- if you are translating this document, please notate the CVS
13 revision of the original developer's reference in cvs-en-rev -->
14 <!-- <!ENTITY cvs-en-rev "1.315"> -->
16 <!-- how to mark a section that needs more work -->
17 <!ENTITY FIXME "<em>FIXME:</em> ">
24 Référence du développeur Debian
27 <name>L'équipe de la Référence du développeur</name>&email-devel-ref;
30 <name>Andreas Barth </name>
33 <name>Adam Di Carlo </name>
36 <name>Raphaël Hertzog </name>
39 <name>Christian Schwarz </name>
42 <name>Ian Jackson </name>
45 version française par Frédéric Bothamy (traducteur actuel)
47 <translator>et Antoine Hulin (ancien traducteur)</translator>
49 et les membres de la liste <email>debian-l10n-french@lists.debian.org</email>
52 Version &version;, &date-fr; (version française 20061130).
56 Copyright © 2004—2006 Andreas Barth
59 Copyright © 1998—2003 Adam Di Carlo
62 Copyright © 2002—2003 Raphaël Hertzog
65 Copyright © 1997, 1998 Christian Schwarz.
68 Ce manuel est un logiciel libre ; il peut être redistribué et/ou
69 modifié selon les termes de la licence publique générale du projet GNU
70 (GNU GPL), telle que publiée par la « Free Software
71 Foundation » (version 2 ou toute version postérieure).
74 Il est distribué dans l'espoir qu'il sera utile, mais <em>sans aucune
75 garantie</em>, sans même la garantie implicite d'une possible valeur
76 marchande ou d'une adéquation à un besoin particulier. Consultez la
77 licence publique générale du projet GNU pour plus de détails.
80 Une copie de la licence publique générale du projet GNU est disponible
81 dans le fichier &file-GPL; de la distribution &debian-formal; ou sur
82 la toile : <url id="http://www.gnu.org/copyleft/gpl.html"
83 name="la licence publique générale du projet GNU">. Vous pouvez
84 également l'obtenir en écrivant à la &fsf-addr;. <![ %htmltext [
87 Si vous désirez imprimer cette référence, vous devriez utiliser la
88 <url id="developers-reference.pdf" name="version PDF">. Cette page est
89 également disponible en <url id="index.en.html" name="anglais">. ]]>
100 Le but de ce document est de donner une vue d'ensemble des procédures à
101 suivre et des ressources mises à la disposition des développeurs Debian.
104 Les procédures décrites ci-après expliquent comment devenir responsable
105 Debian (<ref id="new-maintainer">), comment créer de nouveaux paquets
106 (<ref id="newpackage">) et comment les installer dans l'archive (<ref
107 id="upload">), comment gérer les rapports de bogues (<ref
108 id="bug-handling">), comment déplacer, effacer ou abandonner un paquet
109 (<ref id="archive-manip">), comment faire le portage d'un paquet (<ref
110 id="porting">), quand et comment faire la mise à jour du paquet d'un
111 autre responsable (<ref id="nmu">).
114 Les ressources présentées dans ce manuel incluent les listes de
115 diffusion (<ref id="mailing-lists">) et les serveurs (<ref
116 id="server-machines">), une présentation de la structure de l'archive
117 Debian (<ref id="archive">), des explications sur les serveurs qui
118 acceptent les mises à jour de paquets (<ref id="upload-ftp-master">) et
119 une présentation des outils qui peuvent aider un responsable à améliorer
120 la qualité de ses paquets (<ref id="tools">).
123 Ce manuel de référence ne présente pas les aspects techniques liés aux
124 paquets Debian, ni comment les créer. Il ne décrit pas non plus les
125 règles que doivent respecter les paquets Debian. Cette information est
126 disponible dans la <url id="&url-debian-policy;" name="charte Debian">.
129 De plus ce document <em>n'est pas l'expression d'une politique
130 officielle</em>. Il contient de la documentation sur le système Debian
131 et des conseils pratiques largement suivis. Ce n'est donc pas une sorte
134 <sect>Introduction à la version française
139 Bien que ce document soit en français, l'activité de responsable Debian implique
140 une maîtrise de la langue anglaise. Le projet Debian est un projet international
141 auquel participent des japonais, néo-zélandais, américains, allemands,
142 finlandais, français, espagnols, danois, etc.
145 En conséquence, la langue utilisée dans toutes les listes de diffusion destinées
146 aux développeurs (à l'exception de la liste
147 <email>debian-devel-french@&lists-host;</email>) est l'anglais et les rapports
148 de bogue doivent être rédigés en anglais. En fait, sauf exception rare, tout
149 dialogue avec les autres responsables Debian se fera en anglais quel que soit le
156 Cette section liste les termes techniques qui ont un sens spécifique dans le
157 projet Debian. Pour chacune de ces expressions, vous trouverez la traduction
158 française utilisée dans ce manuel, une définition et une référence à la section
159 du manuel qui traite de ce sujet.
163 <item><em>Upload</em> : mise à jour, téléchargement (parfois
164 livraison). Opération qui consiste à télécharger un nouveau paquet ou
165 une nouvelle version de paquet dans l'archive Debian (<ref
168 <item><em>Non-maintainer upload (NMU)</em> : mise à jour
169 indépendante. Téléchargement d'une nouvelle version de paquet dans
170 l'archive Debian par une personne qui n'est pas officiellement
171 responsable de ce paquet (<ref id="nmu">).
173 <item><em>Source NMU</em> : mise à jour indépendante source. Il
174 s'agit d'une mise à jour indépendante pour un paquet source (<ref
177 <item><em>Binary NMU</em> : mise à jour indépendante binaire. Mise
178 à jour indépendante pour un paquet binaire (<ref id="nmu-terms">).
180 <item><em>Bug Tracking System (BTS)</em> : système de suivi des
181 bogues. Il s'agit du système utilisé par le projet Debian pour suivre
182 les bogues et leur correction (<ref id="bug-handling">).
184 <item><em>Bug submitter</em> : rapporteur du bogue. Personne qui
185 envoie un rapport de bogue au système de suivi des bogues (<ref
188 <item><em>Release critical bug</em> : bogue empêchant l'intégration
189 du paquet dans la distribution. Bogues de gravité <em>critique</em>,
190 <em>grave</em> et <em>sérieuse</em>. Ces bogues ne doivent pas
191 apparaître dans une distribution <em>stable</em>. Ils doivent être
192 corrigés ou bien les paquets en cause doivent être supprimés (<ref
195 <item><em>Package Tracking System (PTS)</em> : système de suivi des
196 paquets. Il s'agit du système utilisé par le projet Debian pour suivre
197 les paquets sources des différentes distributions (<ref
198 id="pkg-tracking-system">).
200 <item><em>Unstable</em> : nom de la distribution en cours
201 de développement. Cette distribution contient les paquets
202 envoyés par les développeurs. Ceux-ci n'étant que des êtres
203 humains, elle est parfois cassée (<ref id="sec-dists">).
205 <item><em>Testing</em> : nom de la distribution en test. Cette
206 distribution reçoit les paquets des développeurs qui ont passé une
207 période de deux semaines dans <em>unstable</em> et pour lesquels aucun
208 bogue remettant en cause la distribution (cf. <em>Release critical
209 bug</em>) n'a été découvert. Cette distribution n'a pas été testée en
210 profondeur. Elle est cependant censée être plus stable
211 qu'<em>unstable</em> (<ref id="sec-dists">).
213 <item><em>Stable</em> : nom de la distribution stable. Cette
214 distribution a été testée, validée et diffusée (<ref id="sec-dists">).
216 <item><em>Debian maintainer</em> : responsable Debian, développeur
217 Debian (parfois mainteneur). Personne qui fait officiellement partie du
218 projet Debian. Elle a accès aux serveurs Debian et participe au
219 développement — au sens large — de la distribution (<ref
220 id="developer-duties">). La plupart des responsables font de la mise en
221 paquet, mais il existe d'autres activités telles que la documentation,
222 la gestion du site web, la création des cédéroms, l'administration des
225 <item><em>Upstream version</em> : version amont. Il s'agit du
226 logiciel tel qu'il est fourni par le responsable amont — par
227 opposition à la version fournie par la distribution Debian. (Voir <ref
228 id="upstream-coordination">.)
230 <item><em>Upstream maintainer</em> : responsable amont ou
231 développeur amont. Personne responsable du développement ou de la
232 maintenance d'un logiciel. En général, le responsable amont n'a rien à
233 voir avec le projet Debian (<ref id="upstream-coordination">).
235 <item><em>Debian keyring</em> : porte-clés Debian. Le porte-clés
236 Debian contient les clés publiques de tous les responsables Debian (<ref
239 <item><em>Work-needing and prospective packages (WNPP)</em> :
240 paquets en souffrance et paquets souhaités. La liste des paquets en
241 souffrance indique les paquets qui n'ont plus de responsable. La liste
242 des paquets souhaités indique les logiciels que des utilisateurs
243 aimeraient bien voir dans la distribution (<ref id="upload">).
247 <chapt id="new-maintainer">
249 Devenir responsable Debian
251 <sect id="getting-started">
256 Vous avez lu toute la documentation, vous avez examiné le <url
257 id="&url-newmaint-guide;" name="guide du nouveau responsable">, vous
258 comprenez l'intérêt de tout ce qui se trouve dans le paquet d'exemple
259 <package>hello</package> et vous vous apprêtez à mettre en paquet votre
260 logiciel préféré. Comment devenir responsable Debian et intégrer votre
261 travail au projet ?
264 Si vous ne l'avez pas encore fait, commencez par vous inscrire à la
265 liste &email-debian-devel;. Pour cela, envoyez un courrier à l'adresse
266 &email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne
267 <em>Objet</em><footnote><p><em>Subject</em> en anglais</p></footnote>
268 de votre message. En cas de problème, contactez l'administrateur de la
269 liste &email-listmaster;. Vous trouverez plus d'informations dans la
270 section <ref id="mailing-lists">. &email-debian-devel-announce; est une
271 autre liste incontournable pour qui veut suivre les développements de
275 Vous suivrez les discussions de cette liste (sans poster) pendant
276 quelque temps avant de coder quoi que ce soit et vous informerez la
277 liste de votre intention de travailler sur quelque chose pour éviter de
278 dupliquer le travail d'un autre.
281 Une autre liste intéressante est &email-debian-mentors;. Voir la
282 section <ref id="mentors"> pour les détails. Le canal IRC
283 <tt>#debian</tt> pourra aussi être utile ; voir <ref
287 Quand vous avez choisi la manière dont vous contribuerez au projet
288 &debian-formal;, prenez contact avec les responsables Debian qui
289 travaillent sur des tâches similaires. Ainsi, vous pourrez apprendre
290 auprès de personnes expérimentées. Si, par exemple, vous voulez mettre
291 en paquet des logiciels existants, trouvez-vous un parrain. Un parrain
292 est une personne qui travaillera sur vos paquets avec vous et les
293 téléchargera dans l'archive Debian une fois qu'il sera satisfait de
294 votre mise en paquet. Pour trouver un parrain, envoyez une demande de
295 parrainage à la liste &email-debian-mentors; en vous présentant et en
296 décrivant votre paquet (voir <ref id="sponsoring"> et <url
297 id="&url-mentors;"> pour en savoir plus sur le sujet). Si vous préférez
298 porter Debian sur une architecture ou un noyau alternatif, abonnez-vous
299 aux listes dédiées au portage et demandez-y comment
300 démarrer. Finalement, si vous êtes intéressé par la documentation ou
301 l'assurance qualité (QA), vous pouvez contacter les responsables qui
302 travaillent déjà sur ces tâches et proposer des correctifs et des
306 Un écueil à éviter est d'avoir la partie locale de votre adresse
307 électronique trop générique : des termes comme mail, admin, root ou
308 master devraient être évitées. Veuillez consulter <url
309 id="http://www.debian.org/MailingLists/"> pour plus de détails.
314 Mentors et parrains Debian
317 La liste de diffusion &email-debian-mentors; a été mise en place pour
318 les responsables débutants recherchant de l'aide avec l'empaquetage
319 initial et d'autres problèmes de développeur. Chaque nouveau
320 développeur est invité à s'abonner à cette liste (voir <ref
321 id="mailing-lists"> pour les détails).
324 Ceux qui préfèrent recevoir une aide plus personnalisée (par exemple,
325 par courriels privés) devraient également envoyer des messages à cette
326 liste et un développeur expérimenté se proposera de les aider.
329 De plus, si vous avez des paquets prêts à être inclus dans Debian, mais
330 que vous attendez que votre demande pour devenir responsable soit
331 acceptée, vous pouvez trouver un parrain pour envoyer vos paquets pour
332 vous. Les parrains sont des développeurs Debian officiels qui sont
333 volontaires pour critiquer et envoyer vos paquets pour vous. Veuillez
334 lire en premier la FAQ non officielle de debian-mentors à <url
338 Si vous désirez être un mentor et/ou un parrain, vous pouvez trouver
339 plus d'informations à <ref id="newmaint">.
342 <sect id="registering">
344 S'enregistrer comme responsable Debian
347 Avant de décider de devenir responsable Debian, il vous faudra lire
348 toute la documentation disponible dans le <url id="&url-newmaint;"
349 name="coin du nouveau responsable">. Elle décrit en détail toutes les
350 étapes préparatoires qu'il vous faudra franchir avant de déposer votre
351 candidature. Par exemple, avant d'être candidat, il vous faudra lire le
352 <url id="&url-social-contract;" name="contrat social Debian">. Devenir
353 responsable Debian implique que vous adhériez à ce contrat social et
354 que vous vous engagiez à le soutenir ; il est très important que
355 les responsables soient en accord avec les principes fondamentaux qui
356 animent le projet &debian-formal;. Lire le <url
357 id="&url-gnu-manifesto;" name="Manifeste GNU"> est aussi une bonne
361 Le processus d'enregistrement a pour but de vérifier votre identité,
362 vos intentions et vos compétences. Le nombre de personnes travaillant
363 pour &debian-formal; a atteint &number-of-maintainers; et notre système
364 est utilisé dans plusieurs endroits très importants : nous devons
365 rester vigilants pour éviter un acte malveillant. C'est pourquoi nous
366 contrôlons les nouveaux responsables avant de leur donner un compte sur
367 nos serveurs et de les autoriser à ajouter des paquets dans l'archive.
370 Pour devenir responsable, il faudra montrer que vous pouvez faire du
371 bon travail et que vous serez un bon contributeur. Pour cela, vous
372 pourrez proposer des correctifs par le système de suivi des bogues
373 (BTS) et maintenir un paquet parrainé par un responsable Debian pendant
374 un temps. Nous attendons
375 aussi des contributeurs qu'ils soient intéressés par le projet dans son
376 ensemble et pas uniquement par leurs propres paquets. Si vous pouvez
377 aider d'autres responsables en fournissant des informations sur un
378 bogue ou même avec un correctif, faites-le !
381 Pour votre candidature, vous devrez être familiarisé avec la
382 philosophie du projet Debian et avec sa documentation technique. Il
383 vous faudra aussi une clé GnuPG signée par un responsable Debian. Si
384 votre clé GnuPG n'est pas encore signée, vous devriez essayer de
385 rencontrer un responsable Debian pour le faire. La <url
386 id="&url-gpg-coord;" name="page de coordination des signatures de clé
387 GnuPG"> devrait vous aider à trouver un responsable Debian près de chez
388 vous. (S'il n'y a pas de responsable près de chez vous, il peut y avoir
389 des moyens alternatifs pour valider votre identité en tant qu'exception
390 absolue étudiée au cas par cas. Veuillez vous reporter à la <url
391 id="&url-newmaint-id;" name="page d'identification"> pour en savoir
395 Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin
396 d'une clé OpenPGP pour signer et vérifier les mises à jour de
397 paquets. Vous lirez la documentation du logiciel de cryptographie que
398 vous utiliserez car elle contient des informations indispensables pour
399 la sécurité de votre clé. Les défaillances de sécurité sont bien plus
400 souvent dues à des erreurs humaines qu'à des problèmes logiciels ou à
401 des techniques d'espionnage avancées. Voir <ref id="key-maint"> pour
402 plus d'informations sur la gestion de votre clé publique.
405 Debian utilise <prgn>GNU Privacy Guard</prgn> (paquet
406 <package>gnupg</package> version 1 ou supérieure) comme standard de
407 base. Vous pouvez aussi utiliser une autre implémentation
408 d'OpenPGP. OpenPGP est un standard ouvert basé sur la <url
409 id="&url-rfc2440;" name="RFC 2440">.
412 Vous avez besoin d'une clé en version 4 à utiliser pour le
413 développement Debian. La longueur de votre clé doit être d'au moins
414 1024 ;bits ; il n'y a pas de raison d'utiliser une clé plus
415 petite et faire cela serait bien moins sûr. <footnote><p>Les clés en
416 version 4 sont des clés conformes au standard OpenPGP défini dans
417 la RFC 2440. La version 4 est le type de clé qui a toujours
418 été créé avec GnuPG. Les versions de PGP depuis la version 5
419 peuvent également créer des clés version 4, l'autre choix ayant
420 été des clés compatibles pgp 2.6.x (également appelées
421 « legacy RSA » par PGP).</p><p>Les clés (primaires) en
422 version 4 peuvent soit utiliser l'algorithme RSA, soit
423 l'algorithme DSA, cela n'a donc rien à voir avec la question de GnuPG à
424 propos de « quel type de clé voulez-vous : (1) DSA et
425 Elgamal, (2) DSA (signature seule), (5) RSA (signature seule). Si vous
426 n'avez pas des besoins spécifiques, choisissez simplement la valeur par
427 défaut ».</p><p>Le moyen le plus simple de dire si une clé
428 existante est une clé v4 ou une clé v3 (ou v2) est de regarder son
429 empreinte : les empreintes des clés en version 4 sont des
430 hachés SHA-1 d'une partie de la clé, il s'agit donc d'une suite de
431 40 chiffres hexadécimaux, habituellement groupés par blocs de
432 4. Les empreintes des anciennes versions de clé utilisaient MD5 et sont
433 généralement affichées par blocs de 2 chiffres hexadécimaux. Par
434 exemple, si votre empreinte ressemble à ceci :
435 <tt>5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F</tt>,
436 alors il s'agit d'une clé v4.</p><p>Une autre possibilité est d'envoyer
437 la clé dans <prgn>pgpdump</prgn>, qui dira quelque chose comme
438 « Public Key Packet - Ver 4 ».</p><p>Notez également que
439 votre clé doit être auto-signée (c.-à-d. elle doit signer tous ses
440 propres identifiants d'utilisateur ; cela empêche la falsification
441 d'identité). Tous les logiciels OpenPGP modernes font cela
442 automatiquement, mais si vous avez une ancienne clé, il se peut que
443 vous deviez ajouter manuellement ces signatures.</p></footnote>
446 Si votre clé publique n'est pas sur un serveur public tel que
447 &pgp-keyserv;, reportez-vous à la documentation disponible à
448 <url id="&url-newmaint-id;" name="Étape 2 : Vérification d'identité">.
449 Cette documentation explique comment mettre votre
450 clé publique sur un serveur. L'équipe <em>New maintainer</em> mettra
451 votre clé publique sur les serveurs de clés si elle n'y est pas déjà.
454 Certains pays limitent l'usage des logiciels de cryptographie. Cela ne
455 devrait cependant pas avoir d'impact sur l'activité d'un responsable de
456 paquet car il peut être tout à fait légal d'utiliser des logiciels de
457 cryptographie pour l'authentification plutôt que pour le
458 chiffrement. Si vous vivez dans un pays où l'utilisation de la
459 cryptographie pour authentification est interdite, contactez-nous pour
460 que nous prenions des dispositions particulières.
463 Pour faire acte de candidature, il vous faut un responsable Debian qui
464 soutiendra votre candidature (un <em>avocat</em>). Après avoir contribué
465 au projet Debian pendant un temps, quand vous choisissez de devenir un
466 responsable Debian officiel, un responsable déjà enregistré avec qui
467 vous aurez travaillé dans les derniers mois devra exprimer que, d'après
468 lui, vous pouvez contribuer avec succès au projet Debian.
471 Quand vous avez trouvé un <em>avocat</em>, quand votre clé GnuPG est
472 signée et quand vous avez déjà contribué au projet, vous êtes prêt à
473 faire acte de candidature. Il vous suffit pour cela de vous enregistrer
474 sur notre <url id="&url-newmaint-apply;" name="page de
475 candidature">. Ensuite, votre avocat devra confirmer votre
476 candidature. Quand il aura accompli cette tâche, un responsable de
477 candidature<footnote><p>Application manager</p></footnote> sera désigné
478 pour vous accompagner dans le processus d'enregistrement. Vous pouvez
479 toujours consulter le <url id="&url-newmaint-db;" name="tableau de bord
480 des candidatures"> pour connaître l'état de votre candidature.
483 Pour en savoir plus, consultez le <url id="&url-newmaint;" name="coin
484 des nouveaux responsables"> sur le site Debian. Assurez-vous de bien
485 connaître les étapes nécessaires au processus d'enregistrement avant de
486 vous porter candidat. Vous gagnerez beaucoup de temps si vous êtes bien
491 <chapt id="developer-duties">
493 Les charges du responsable Debian
495 <sect id="user-maint">
497 Mise à jour de vos références Debian
500 Il existe une base de données LDAP contenant des informations
501 concernant les développeurs Debian à <url id="&url-debian-db;">. Vous
502 devriez y entrer vos informations et les mettre à jour quand elles
503 changent. Le plus important est de vous assurer que l'adresse vers
504 laquelle est redirigée votre adresse debian.org est toujours à jour, de
505 même que l'adresse à laquelle vous recevez votre abonnement à
506 debian-private si vous choisissez d'être abonné à cette liste.
509 Pour plus d'informations à propos de cette base de données, veuillez
510 consulter <ref id="devel-db">.
513 <sect id="key-maint">
515 Gérer votre clé publique
518 Soyez très vigilant en utilisant votre clé privée. Ne la placez pas sur
519 un serveur public ou sur des machines multi-utilisateurs telles que les
520 serveurs Debian (voir <ref id="server-machines">). Sauvegardez vos clés
521 et gardez-en une copie hors connexion. Lisez la documentation fournie
522 avec votre logiciel et la <url id="&url-pgp-faq;" name="FAQ PGP">.
525 Vous devez vous assurer que non seulement votre clé est à l'abri des
526 vols, mais également à l'abri d'une perte. Générez et faites une copie
527 (et également sur papier) de votre certificat de révocation ; il
528 est nécessaire si votre clé est perdue.
531 Si vous ajoutez des signatures ou des identifiants à votre clé
532 publique, vous pouvez mettre à jour le porte-clés Debian en envoyant
533 votre clé publique à <tt>&keyserver-host;</tt>.
536 Si vous voulez ajouter une nouvelle clé ou supprimer une ancienne clé,
537 vous devez faire signer la nouvelle clé par un autre développeur. Si
538 l'ancienne clé est compromise ou invalide, vous devez également ajouter
539 la certification de révocation. S'il n'y pas de vraie raison pour une
540 nouvelle clé, les responsables du trousseau de clés peuvent rejeter la
541 nouvelle clé. Vous pouvez trouver plus de détails à <url
542 id="http://keyring.debian.org/replacing_keys.html">.
545 Les mêmes routines d'extraction de clé décrites dans <ref
546 id="registering"> s'appliquent.
549 Vous pouvez trouver une présentation approfondie de la gestion de clé
550 Debian dans la documentation du paquet
551 <package>debian-keyring</package>.
559 Bien que Debian ne soit pas vraiment une démocratie, nous disposons
560 d'un processus démocratique pour élire nos chefs et pour approuver les
561 résolutions générales. Ces procédures sont définies par la <url
562 id="&url-constitution;" name="charte Debian">.
565 En dehors de l'élection annuelle du chef, les votes ne se tiennent pas
566 régulièrement et ils ne sont pas entrepris à la légère. Chaque
567 proposition est tout d'abord discutée sur la liste de diffusion
568 &email-debian-vote; et elle a besoin de plusieurs approbations avant
569 que le secrétaire du projet n'entame la procédure de vote.
572 Vous n'avez pas besoin de suivre les discussions précédant le vote car
573 le secrétaire enverra plusieurs appels au vote sur la liste
574 &email-debian-devel-announce; (et tous les développeurs devraient être
575 inscrits à cette liste). La démocratie ne fonctionne pas si les
576 personnes ne prennent pas part au vote, c'est pourquoi nous
577 encourageons tous les développeurs à voter. Le vote est conduit par
578 messages signés ou chiffrés par GPG.
581 La liste de toutes les propositions (passées et présentes) est
582 disponible à la page <url id="&url-vote;" name="Informations sur les
583 votes Debian">, ainsi que des informations complémentaires sur la
584 procédure à suivre pour effectuer une proposition, la soutenir et voter
588 <sect id="inform-vacation">
590 Prendre des vacances courtoisement
593 Il est courant pour les développeurs de s'absenter, que ce soit pour
594 des vacances prévues ou parce qu'ils sont submergés de travail. La
595 chose importante à noter est que les autres développeurs ont besoin de
596 savoir que vous êtes en vacances pour qu'ils puissent agir en
597 conséquence si un problème se produit pendant vos vacances.
600 Habituellement, cela veut dire que les autres développeurs peuvent
601 faire des NMU (voir <ref id="nmu">) sur votre paquet si un gros
602 problème (bogue empêchant l'intégration dans la distribution, mise à
603 jour de sécurité, etc.) se produit pendant que vous êtes en
604 vacances. Parfois, ce n'est pas très important, mais il est de toute
605 façon approprié d'indiquer aux autres que vous n'êtes pas disponible.
608 Il y a deux choses à faire pour informer les autres
609 développeurs. Premièrement, envoyez un courrier électronique à
610 &email-debian-private; en commençant le sujet de votre message par
611 « [VAC] »<footnote><p>Ainsi, le message peut être facilement
612 filtré par les personnes qui ne veulent pas lire ces annonces de
613 vacances.</p></footnote> et donnez la période de vos vacances. Vous
614 pouvez également donner quelques instructions pour indiquer comment
615 agir si un problème survenait.
618 L'autre chose à faire est de vous signaler comme « en
619 vacances »<footnote><p><em>on vacation</em> en
620 anglais</p></footnote> dans la <qref id="devel-db">base de données
621 Debian LDAP</qref> (l'accès à cette information est réservé aux
622 développeurs). N'oubliez pas de retirer votre indicateur « en
623 vacances » lorsque celles-ci sont terminées !
626 Idéalement, vous devriez vous connecter sur le <url
627 id="http://nm.debian.org/gpg.php" name="site de coordination GPG">
628 quand vous réservez pour des vacances et vérifier si quelqu'un
629 recherche un échange de signatures. Cela est particulièrement important
630 quand des personnes vont à des endroits exotiques où nous n'avons pas
631 encore de développeurs, mais où il y a des personnes intéressées pour
632 poser leur candidature.
635 <sect id="upstream-coordination">
637 Coordination avec les développeurs amont
640 Une grande part de votre travail de responsable Debian sera de rester
641 en contact avec les développeurs amont. Parfois, les utilisateurs
642 établissent des rapports de bogue qui ne sont pas spécifiques à
643 Debian. Vous devez transmettre ces rapports de bogue aux développeurs
644 amont pour qu'ils soient corrigés dans les prochaines versions.
647 Bien qu'il ne soit pas de votre responsabilité de corriger les bogues
648 non spécifiques à Debian, vous pouvez le faire si vous en êtes
649 capable. Quand vous faites de telles corrections, assurez-vous de les
650 envoyer également au développeur amont. Les utilisateurs et
651 responsables Debian proposent souvent des correctifs pour corriger des
652 bogues amont, il vous faudra alors évaluer ce correctif puis le
653 transmettre aux développeurs amont.
656 Si vous avez besoin de modifier les sources d'un logiciel pour
657 fabriquer un paquet conforme à la charte Debian, alors vous devriez
658 proposer un correctif aux développeurs amont pour qu'il soit inclus
659 dans leur version. Ainsi, vous n'aurez plus besoin de modifier les
660 sources lors des mises à jour amont suivantes. Quels que soient les
661 changements dont vous avez besoin, il faut toujours essayer de rester
662 dans la lignée des sources amont.
667 Comment gérer les bogues empêchant l'intégration du paquet dans la
671 Habituellement, vous devriez traiter les rapports de bogue sur vos
672 paquets tel que cela est décrit dans <ref
673 id="bug-handling">. Cependant, il y a une catégorie spéciale de bogues
674 qui nécessite particulièrement votre attention : les bogues
675 empêchant l'intégration du paquet dans la
676 distribution<footnote><p>Traduction de l'anglais <em>Release-critical
677 bug (RC Bugs)</em></p></footnote>. Tous les rapports de bogue de
678 gravité <em>critique</em>, <em>grave</em> et
679 <em>sérieuse</em><footnote><p>Respectivement <em>critical</em>,
680 <em>grave</em> et <em>serious</em> en anglais</p></footnote> sont
681 considérés comme ayant un impact sur la présence du paquet dans la
682 prochaine version stable de Debian. Ces bogues peuvent retarder la
683 publication d'une distribution Debian ou peuvent justifier la suppression
684 d'un paquet d'une distribution gelée. C'est pourquoi ces bogues doivent
685 être corrigés au plus vite.
688 Les développeurs faisant partie de l'équipe d'<url id="&url-debian-qa;"
689 name="assurance qualité Debian"> surveillent ces bogues et essaient de
690 vous aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas
691 corriger un bogue de ce type dans les deux semaines, vous devriez soit
692 demander de l'aide en envoyant un courrier à l'équipe d'assurance
693 qualité (<em>QA group</em>) à &email-debian-qa;, soit expliquer vos
694 difficultés et présenter un plan pour corriger le problème en répondant
695 au rapport de bogue concerné. Si rien n'est fait, des personnes de
696 l'équipe d'assurance qualité pourraient chercher à corriger votre
697 paquet (voir <ref id="nmu">) après avoir tenté de vous contacter (ils
698 pourraient attendre moins longtemps que d'habitude pour faire leur mise
699 à jour s'il n'y a pas trace d'activité récente de votre part dans le
700 système de suivi des bogues).
708 Si vous choisissez de quitter le projet Debian, procédez comme
710 <enumlist numeration="arabic">
713 abandonnez tous vos paquets comme décrit dans <ref
714 id="orphaning"> ;
719 envoyez un courrier électronique signé par GnuPG à
720 &email-debian-private; indiquant pourquoi vous quittez le
726 signalez aux responsables du porte-clés Debian que vous quittez le
727 projet en écrivant à &email-debian-keyring;.
734 <chapt id="resources">
736 Ressources pour le responsable Debian
739 Dans ce chapitre, vous trouverez une brève description des listes de
740 diffusion, des machines Debian qui seront à votre disposition en tant
741 que responsable Debian ainsi que toutes les autres ressources à votre
742 disposition pour vous aider dans votre travail de responsable.
744 <sect id="mailing-lists">
746 Les listes de diffusion
749 Une grande partie des discussions entre les développeurs Debian (et les
750 utilisateurs) est gérée par un vaste éventail de listes de diffusion
751 que nous hébergeons à <tt><url id="http://&lists-host;/"
752 name="&lists-host;"></tt>. Pour en savoir plus sur comment s'abonner ou
753 se désabonner, comment envoyer un message et comment ne pas en envoyer,
754 comment retrouver d'anciens messages et comment les rechercher, comment
755 contacter les responsables des listes et pour savoir d'autres
756 informations sur les listes de diffusion, veuillez lire <url
757 id="&url-debian-lists;">. Cette section ne couvrira que les aspects des
758 listes de diffusion qui ont un intérêt particulier pour les
761 <sect1 id="mailing-lists-rules">
763 Règles de base d'utilisation
766 Lorsque vous répondez sur une liste de diffusion, veuillez ne pas
767 envoyer de copie (<tt>CC</tt>) à l'auteur d'origine sauf s'il le
768 demande explicitement. Toute personne envoyant un message à une liste
769 de diffusion devrait la suivre pour voir les réponses.
772 Le multi-postage (cross-posting) (envoyer le même message à plusieurs
773 listes) est découragé. Comme toujours sur le net, veuillez réduire la
774 citation des articles auxquels vous répondez. En général, veuillez
775 adhérez aux conventions usuelles d'envoi de messages.
778 Veuillez lire le <url id="&url-debian-lists;#codeofconduct" name="code
779 de conduite"> pour plus d'informations.
782 <sect1 id="core-devel-mailing-lists">
784 Principales listes pour les responsables
787 Les principales listes de diffusion de Debian que les développeurs
788 devraient suivre sont :
792 &email-debian-devel-announce;, utilisée pour les annonces
793 importantes faites aux responsables. Tous les responsables Debian
794 sont censés être inscrits à cette liste,
799 &email-debian-devel;, utilisée pour discuter de diverses questions
800 techniques relatives au développement,
805 &email-debian-policy; où l'on discute et vote les modifications de
811 &email-debian-project;, utilisée pour discuter de questions non
818 Il existe d'autres listes de diffusion spécialisées dans différents
819 thèmes. Reportez-vous à la page <url id="http://&lists-host;/"> pour
820 en obtenir la liste complète.
823 <sect1 id="mailing-lists-special">
828 &email-debian-private; est une liste de diffusion destinée aux
829 discussions privées entre développeurs Debian. Elle doit être utilisée
830 pour tout message qui ne doit pas être publié, quelle qu'en soit la
831 raison. C'est une liste à faible trafic et les utilisateurs sont priés
832 de ne l'utiliser qu'en cas de réelle nécessité. De plus, il ne faut
833 <em>jamais</em> faire suivre un courrier de cette liste à qui que ce
834 soit. Pour des raisons évidentes, les archives de cette liste ne sont
835 pas disponibles sur la toile. Vous pouvez les consulter en visitant le
836 répertoire <file>~debian/archive/debian-private</file> avec votre
837 compte sur <tt>lists.debian.org</tt>.
840 &email-debian-email; est une liste de diffusion fourre-tout. Elle est
841 utilisée pour les correspondances relatives à Debian qu'il serait
842 utile d'archiver, telles que des échanges avec les auteurs amont à
843 propos de licences, de bogues ou encore des discussions sur le projet
844 avec d'autres personnes.
847 <sect1 id="mailing-lists-new">
849 Demander une nouvelle liste relative au développement
852 Avant de demander une liste de diffusion liée au développement d'un
853 paquet (ou d'un petit groupe de paquets liés), veuillez considérer si
854 l'utilisation d'un alias (via un fichier .forward-aliasname sur
855 master.debian.org, ce qui se traduit en une adresse raisonnablement
856 agréable <var>you-aliasname@debian.org</var>) ou une liste de
857 diffusion auto-gérée sur <qref id="alioth">Alioth</qref> serait plus
861 Si vous décidez qu'une liste de diffusion standard sur
862 lists.debian.org est vraiment ce que vous voulez, lancez-vous et
863 faites une demande en suivant <url id="&url-debian-lists-new;"
868 <sect id="irc-channels">
873 Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont
874 principalement hébergés sur le réseau <url id="&url-oftc;"
875 name="Open and free technology community (OFTC)">. L'entrée DNS
876 <tt>irc.debian.org</tt> est simplement un alias vers
877 <tt>irc.oftc.net</tt>.
880 Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un
881 canal important, généraliste, où les utilisateurs peuvent trouver des
882 nouvelles récentes dans le sujet et qui est administré par des
883 robots. <em>#debian</em> est destiné aux anglophones ; il existe
884 également <em>#debian.de</em>, <em>#debian-fr</em>, <em>#debian-br</em>
885 et d'autres canaux avec des noms semblables pour les personnes parlant
889 Le canal principal pour le développement Debian est
890 <em>#debian-devel</em>. C'est un canal très actif avec habituellement
891 plus de 150 personnes connectées en permanence. C'est un canal pour les
892 personnes qui travaillent sur Debian, ce n'est pas un canal d'aide (il
893 existe <em>#debian</em> pour cela). Il est cependant ouvert à tous ceux
894 qui veulent écouter (et apprendre). Le sujet est toujours rempli
895 d'informations intéressantes.
898 Comme <em>#debian-devel</em> est un canal ouvert, vous ne devriez pas y
899 parler de problèmes discutés sur &email-debian-private;. Il existe un
900 canal protégé par clé <em>#debian-private</em> dans ce but. La clé est
901 disponible dans les archives de debian-private à
902 <file>master.debian.org:&file-debian-private-archive;</file>, effectuez
903 simplement un <prgn>zgrep</prgn> avec <em>#debian-private</em> dans
907 Il existe d'autres canaux dédiés à des sujets
908 spécifiques. <em>#debian-bugs</em> est utilisé pour la coordination des
909 <em>chasses aux bogues</em>. <em>#debian-boot</em> est utilisé pour la
910 coordination du travail sur l'installateur Debian. <em>#debian-doc</em>
911 est utilisé occasionnellement pour travailler sur la documentation
912 comme celle que vous lisez actuellement. D'autres canaux sont dédiés à
913 une architecture ou un ensemble de paquets : <em>#debian-bsd</em>,
914 <em>#debian-kde</em>, <em>#debian-jr</em>, <em>#debian-edu</em>,
915 <em>#debian-sf</em> (paquet SourceForge), <em>#debian-oo</em> (paquet
919 Certains canaux pour développeurs non anglophones existent, par
920 exemple, <em>#debian-devel-fr</em> pour les francophones intéressés
921 dans le développement de Debian.
924 Il existe également des canaux dédiés pour Debian sur d'autres réseaux
925 IRC, notamment sur le réseau IRC <url id="&url-openprojects;"
926 name="Freenode">, sur lequel pointait l'alias <tt>irc.debian.org</tt>
927 jusqu'au 4 juin 2006.
930 Pour obtenir un uniforme (« cloak ») sur freenode, vous devez
931 envoyer un courriel signé à Jörg Jaspert <joerg@debian.org>
932 dans lequel vous indiquez quel est votre pseudonyme
933 (« nick »). Mettez « cloak » quelque part dans le
934 sujet. Votre pseudonyme devra être enregistré : <url
935 id="http://freenode.net/faq.shtml#nicksetup" name="Page de
936 configuration des pseudonymes">. Le courriel doit être signé par une
937 clé du porte-clés Debian. Veuillez consulter la <url
938 id="http://freenode.net/faq.shtml#projectcloak" name="documentation de
939 Freenode"> pour plus d'informations sur les uniformes.
942 <sect id="doc-rsrcs">
947 Ce document contient beaucoup d'informations très utiles aux
948 développeurs Debian, mais il ne peut pas tout contenir. La plupart des
949 autres documents intéressants sont référencés dans le <url
950 id="&url-devel-docs;" name="coin du développeur Debian">. Prenez le
951 temps de parcourir tous les liens, vous apprendrez encore beaucoup de
955 <sect id="server-machines">
960 Debian possède plusieurs ordinateurs employés comme serveurs, dont la
961 plupart hébergent les fonctions critiques du projet Debian. La plupart
962 des machines sont utilisées pour des activités de portage et elles ont
963 toutes un accès permanent à Internet.
966 La plupart des machines peuvent être utilisées par les développeurs
967 tant qu'ils respectent les règles définies dans la <url id="&url-dmup;"
968 name="charte d'utilisation des machines Debian">.
971 Dans l'ensemble, vous pouvez faire usage de ces machines pour des buts
972 relatifs à Debian comme vous l'entendez. Veuillez cependant être gentil
973 avec les administrateurs système et ne pas utiliser de grandes
974 quantités d'espace disque, de ressource réseau ou CPU sans obtenir
975 auparavant l'accord des administrateurs. Habituellement, ces machines
976 sont administrées par des volontaires.
979 Veuillez prendre soin de votre mot de passe Debian ainsi que des clés
980 SSH installées sur les machines Debian. Évitez les méthodes de
981 connexion ou d'envoi de données qui envoient les mots de passe en clair
982 par l'Internet comme telnet, FTP, POP, etc.
985 Veuillez ne pas déposer de données non relatives à Debian sur les
986 serveurs Debian à moins que vous n'ayez préalablement obtenu la
987 permission de le faire.
990 La liste actuelle des machines Debian est disponible à <url
991 id="&url-devel-machines;">. Cette page web contient les noms des
992 machines, les informations de contact, les informations sur qui peut
993 s'y connecter, les clés SSH, etc.
996 Si vous avez un problème en utilisant un serveur Debian et si vous
997 estimez que les administrateurs système devraient en être avertis,
998 l'équipe des administrateurs système peut être jointe à
999 <email>debian-admin@lists.debian.org</email>.
1002 Si votre problème est lié à un certain service ou n'est pas lié au
1003 système (paquet à supprimer de l'archive ou suggestion pour le site web
1004 par exemple), il vous faudra en général ouvrir un rapport de bogue sur
1005 un « pseudo-paquet ». Reportez-vous à la section <ref
1006 id="submit-bug"> pour connaître la procédure à suivre.
1009 Certains des serveurs de base sont à accès restreint, mais les
1010 informations de ceux-ci sont fournies par d'autres serveurs miroirs.
1012 <sect1 id="servers-bugs">
1014 Le serveur pour les rapports de bogues
1017 <tt>&bugs-host;</tt> est le serveur maître du système de suivi des
1018 bogues (BTS<footnote><p>Système de suivi des bogues se dit <em>Bug
1019 Tracking System</em> en anglais</p></footnote>).
1022 Ce serveur est à accès restreint ; un miroir est disponible sur
1026 Si vous envisagez de manipuler les rapports de bogue ou d'en faire une
1027 analyse statistique, ce sera le bon endroit pour le faire. Informez la
1028 liste &email-debian-devel; de votre intention avant d'implémenter quoi
1029 que ce soit afin d'éviter un travail en double ou un gaspillage de
1033 <sect1 id="servers-ftp-master">
1035 Le serveur ftp-master
1038 Le serveur <tt>ftp-master.debian.org</tt> est le serveur maître de
1039 l'archive Debian (exception faite des paquets non-US). En général, les
1040 mises à jour de paquets se font sur ce serveur. Reportez-vous à la
1041 section <ref id="upload"> pour en savoir plus.
1044 Ce serveur est à accès restreint ; un miroir est disponible sur
1048 Les problèmes avec l'archive Debian FTP doivent généralement être
1049 rapportés comme bogues sur le pseudo-paquet
1050 <package>ftp.debian.org</package> ou par courrier électronique à
1051 &email-ftpmaster; ; reportez-vous à la section <ref
1052 id="archive-manip"> pour connaître la procédure à suivre.
1055 <sect1 id="servers-non-us">
1060 Le serveur non-US <tt>non-us.debian.org</tt> a été interrompu avec la
1061 publication de <em>Sarge</em>. Le pseudo-paquet
1062 <package>nonus.debian.org</package> existe encore pour le moment.
1065 <sect1 id="servers-www">
1067 Le serveur www-master
1070 Le serveur web principal est <tt>www-master.debian.org</tt>. Il
1071 héberge les pages web officielles, la façade de Debian pour la plupart
1075 Si vous rencontrez un problème avec un serveur web Debian, vous devez
1076 généralement envoyer un rapport de bogue sur le pseudo-paquet
1077 <package>www.debian.org</package>. Vérifiez d'abord sur le <url
1078 id="http://&bugs-host;/www.debian.org" name="système de suivi des
1079 bogues"> que personne ne l'a déjà rapporté avant vous.
1082 <sect1 id="servers-people">
1084 Le serveur web people
1087 <tt>people.debian.org</tt> est le serveur utilisé par les développeurs
1088 pour leurs pages concernant Debian.
1091 Si vous avez des informations spécifiques Debian que vous voulez
1092 rendre disponibles sur le web, vous pouvez le faire en les plaçant
1093 dans le répertoire <file>public_html</file> de votre répertoire
1094 personnel sur <tt>people.debian.org</tt>. Elles seront accessibles à
1096 <tt>http://people.debian.org/~<var>votre-user-id</var>/</tt>.
1099 Vous ne devriez utiliser que cet emplacement particulier car il sera
1100 sauvegardé alors que sur les autres serveurs, ce ne sera pas le cas.
1103 Habituellement, la seule raison pour utiliser un serveur différent est
1104 que vous avez besoin de publier des informations soumises aux
1105 restrictions d'exportation américaines, dans ce cas, vous pouvez
1106 utiliser l'un des autres serveurs situés en dehors des États-Unis.
1109 Veuillez envoyer un courrier à &email-debian-devel; si vous avez une
1113 <sect1 id="servers-cvs">
1118 Notre serveur CVS est situé sur <tt>cvs.debian.org</tt>.
1121 Si vous avez besoin d'un serveur CVS accessible par tous pour, par
1122 exemple, coordonner le travail de plusieurs développeurs sur un
1123 paquet, vous pouvez demander un espace CVS sur ce serveur.
1126 Le serveur <tt>cvs.debian.org</tt> autorise les accès CVS locaux, les
1127 accès en lecture seule pour les connexions client-serveur anonymes et
1128 les accès client-serveur complets pour les connexions
1129 <prgn>ssh</prgn>. L'espace CVS peut aussi être consulté par la toile à
1130 l'adresse <url id="&url-cvsweb;">.
1133 Pour obtenir un espace CVS, envoyez une demande à l'adresse
1134 &email-debian-admin; en précisant le nom de l'espace, le compte Debian
1135 propriétaire du répertoire racine et pourquoi vous en avez besoin.
1138 <sect1 id="dchroot">
1140 Chroots de différentes distributions
1143 Sur certaines machines, des chroots de différentes distributions sont
1144 disponibles. Vous pouvez les utiliser comme ceci :
1146 vore% dchroot unstable
1147 Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
1149 Dans tous les chroots, les répertoires normaux des utilisateurs sont
1150 disponibles. Vous pouvez trouver quels chroots sont disponibles à
1151 <tt>&url-devel-machines;</tt>.
1155 <sect id="devel-db">
1157 La base de données des développeurs
1160 La base de données des développeurs à <url id="&url-debian-db;"> est un
1161 annuaire LDAP de gestion des informations des développeurs Debian. Vous
1162 pouvez utiliser cette ressource pour rechercher la liste des
1163 développeurs Debian. Une partie de ces informations est également
1164 disponible à travers le service <prgn>finger</prgn> sur les serveurs
1165 Debian, essayez <prgn>finger yourlogin@debian.org</prgn> pour voir ce
1169 Les développeurs peuvent <url id="&url-debian-db-login;" name="se
1170 connecter à la base de données"> pour modifier différentes informations
1171 les concernant, comme :
1175 l'adresse de suivi pour leur adresse debian.org,
1180 l'abonnement à debian-private,
1185 l'état en vacances ou non,
1190 des informations personnelles comme les adresse, pays, latitude et
1191 longitude de l'endroit où ils vivent pour utilisation dans la <url
1192 id="http://www.debian.org/devel/developers.loc" name="carte mondiale
1193 des développeurs Debian">, numéros de téléphone et de fax, surnom
1199 le mot de passe et le shell préféré sur les machines du projet
1206 La plupart des informations ne sont naturellement pas accessibles
1207 publiquement. Pour plus d'informations, veuillez lire la documentation
1208 en ligne que vous pouvez trouver à <url id="&url-debian-db-doc;">.
1211 Les développeurs peuvent également envoyer leurs clés SSH pour qu'elles
1212 soient utilisées pour autorisation sur les machines Debian officielles
1213 et même ajouter de nouvelles entrées DNS du type *.debian.net. Ces
1214 fonctionnalités sont documentées à <url id="&url-debian-db-mail-gw;">.
1222 La distribution &debian-formal; est composée d'un grand nombre de
1223 paquets (fichiers <tt>.deb</tt> : actuellement, à peu près
1224 &number-of-pkgs;) et de quelques autres fichiers (comme la
1225 documentation et des images des disquettes d'installation).
1228 Voici un exemple d'arborescence pour une archive Debian complète :
1231 &sample-dist-dirtree;
1235 Comme vous pouvez le voir, le répertoire racine contient deux
1236 répertoires, <file>dists/</file> et <file>pool/</file>. Le second est
1237 un ensemble de répertoires où sont stockés les paquets. Ceux-ci sont
1238 manipulés grâce à la base de données de l'archive et aux logiciels qui
1239 l'accompagnent. Le premier répertoire contient les distributions
1240 <em>stable</em>, <em>testing</em> et <em>unstable</em>. Les fichiers
1241 <file>Packages</file> et <file>Sources</file> qui se trouvent dans les
1242 répertoires de distribution peuvent faire référence à des fichiers du
1243 répertoire <file>pool/</file>. Le découpage en sous-répertoires est
1244 identique d'un répertoire de distribution à l'autre . Ce que nous
1245 exposerons ci-dessous pour la distribution <em>stable</em> est
1246 également applicable aux distributions <em>unstable</em> et
1250 Le répertoire <file>dists/stable</file> contient trois répertoires
1251 nommés <file>main</file>, <file>contrib</file> et
1252 <file>non-free</file>.
1255 Dans chacune de ces sections, se trouve un répertoire contenant les
1256 paquets sources (<file>source/</file>) et un répertoire pour chaque
1257 architecture acceptée (<file>binary-i386/</file>,
1258 <file>binary-m68k/</file>, etc.).
1261 La section <em>main</em> contient d'autres répertoires destinés aux
1262 images de disquettes et à plusieurs documents essentiels pour installer
1263 la distribution Debian sur une architecture particulière
1264 (<file>disk-i386/</file>, <file>disk-m68k/</file>, etc.).
1266 <sect1 id="archive-sections">
1271 La section <em>main</em> constitue la <strong>distribution
1272 &debian-formal; officielle</strong>. Elle est officielle parce qu'elle
1273 est entièrement conforme à toutes nos recommandations. Les deux autres
1274 sections divergent de ces recommandations à différents degrés, elles
1275 <strong>ne</strong> font donc <strong>pas</strong> officiellement
1276 partie de &debian-formal;.
1279 Chaque paquet de la section <em>main</em> doit être conforme aux <url
1280 id="&url-dfsg;" name="directives Debian pour le logiciel
1281 libre"><footnote><p>Debian Free Software Guidelines</p></footnote> et
1282 à toutes les autres recommandations décrites dans <url
1283 id="&url-debian-policy;" name="la charte Debian"><footnote><p>Debian
1284 Policy Manual</p></footnote>. Les DFSG<footnote><p><em>Debian Free
1285 Software Guidelines</em></p></footnote> constituent notre définition
1286 de « logiciel libre ». Reportez-vous à la <em>charte
1287 Debian</em> pour en savoir plus.
1290 Les paquets de la section <em>contrib</em> doivent être conformes aux
1291 DFSG, mais ne respectent pas d'autres contraintes. Ils peuvent, par
1292 exemple, dépendre de paquets de la section <em>non-free</em>.
1295 Les paquets qui ne sont pas conformes aux DFSG sont rangés dans la
1296 section <em>non-free</em>. Bien que nous supportions l'usage de ces
1297 paquets et qu'ils bénéficient de nos infrastructures (système de suivi
1298 des bogues, listes de diffusion, etc.), ces paquets <em>non-free</em>
1299 ne font pas partie de la distribution Debian.
1302 La <em>charte Debian</em> donne des définitions plus précises pour ces
1303 trois sections. Les paragraphes précédents ne constituent qu'une
1307 La séparation de l'archive en trois sections est importante pour toute
1308 personne qui désire distribuer Debian, que ce soit par serveur FTP ou
1309 sur cédérom. Il suffit de distribuer les sections <em>main</em> et
1310 <em>contrib</em> pour éviter tout problème légal. Certains paquets de
1311 la section <em>non-free</em> interdisent leur distribution à titre
1312 commercial par exemple.
1315 D'un autre côté, un distributeur de cédérom pourra facilement vérifier
1316 la licence de chacun des paquets de la section <em>non-free</em> et
1317 inclure tous les paquets qu'il lui sera autorisé (dans la mesure où
1318 cela varie énormément d'un distributeur à l'autre, ce travail ne peut
1319 être fait par les développeurs Debian).
1322 Notez que le terme « section » est également utilisé pour
1323 faire référence aux catégories qui simplifient l'organisation des
1324 paquets disponibles et leur recherche, e.g. <em>admin</em>,
1325 <em>net</em>, <em>utils</em> etc. Il fut un temps où ces sections
1326 (sous-sections, plutôt) existaient sous la forme de sous-répertoires
1327 dans l'archive Debian. Actuellement, elles n'existent plus que dans le
1328 champ en-tête « Section » des paquets.
1336 À ses débuts, le noyau Linux existait uniquement pour les
1337 architectures Intel x86 ; il en était de même pour Debian. Linux
1338 devenant de plus en plus populaire, il a été porté vers d'autres
1342 Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha,
1343 SPARC, Motorola, 680x0 (Atari, Amiga, et Macintosh), MIPS et
1344 PowerPC. Le noyau 2.2 reconnaît de nouvelles architectures, comme ARM
1345 et UltraSPARC. Puisque Linux reconnaît ces architectures, le projet
1346 Debian a décidé qu'il devait également les accepter. C'est pourquoi
1347 plusieurs portages sont en cours ; en fait, il y a aussi des
1348 portages vers d'autres noyaux non-Linux. À côté d'<em>i386</em> (notre
1349 nom pour Intel x86), nous avons, au moment où j'écris, <em>m68k</em>,
1350 <em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
1351 <em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>,
1352 <em>mips</em>, <em>mipsel</em> et <em>sh</em>.
1355 &debian-formal; 1.3 est disponible uniquement pour
1356 <em>i386</em>. Debian 2.0 reconnaît les architectures <em>i386</em> et
1357 <em>m68k</em>. Debian 2.1 reconnaît les architectures <em>i386</em>,
1358 <em>m68k</em>, <em>alpha</em> et <em>sparc</em>. Debian 2.2 accepte en
1359 plus les architectures <em>powerpc</em> et <em>arm</em>. Debian 3.0 a
1360 ajouté cinq nouvelles architectures : <em>ia64</em>,
1361 <em>hppa</em>, <em>s390</em>, <em>mips</em> et <em>mipsel</em>.
1364 Pour chaque portage, vous trouverez des informations destinées aux
1365 développeurs et utilisateurs sur la page <url id="&url-debian-ports;"
1366 name="Portage Debian">.
1374 Il existe deux types de paquets Debian : les paquets sources et
1375 les paquets binaires.
1378 Les paquets sources sont constitués de deux ou trois fichiers :
1379 un fichier <file>.dsc</file> et soit un fichier <file>.tar.gz</file>,
1380 soit un fichier <file>.orig.tar.gz</file> et un fichier
1381 <file>.diff.gz</file>.
1384 Si un paquet est développé spécifiquement pour le projet Debian et
1385 n'est pas distribué en dehors de Debian, il n'y a qu'un fichier
1386 <file>.tar.gz</file> qui contient les sources du programme. Si un
1387 paquet est distribué ailleurs, le fichier <file>.orig.tar.gz</file>
1388 contient ce que l'on appelle <em>code source amont</em>, c'est-à-dire,
1389 le code source distribué par le <em>responsable amont</em> (il s'agit
1390 souvent de l'auteur du logiciel). Dans ce cas, le fichier
1391 <file>.diff.gz</file> contient les modifications faites par le
1395 Le fichier <file>.dsc</file> liste tous les fichiers sources avec
1396 leurs sommes de contrôle (<prgn>md5sums</prgn>) et quelques
1397 informations supplémentaires concernant le paquet (responsable,
1406 L'organisation des répertoires présentée précédemment est elle-même
1407 englobée par les <em>répertoires des distributions</em>. Chaque
1408 distribution est incluse dans le répertoire <file>pool</file> à la
1409 racine de l'archive Debian.
1412 Pour résumer, une archive Debian a un répertoire racine sur un serveur
1413 FTP. Par exemple, sur le site miroir
1414 <ftpsite>ftp.us.debian.org</ftpsite>, l'archive Debian se trouve dans
1415 <ftppath>/debian</ftppath> ce qui est un emplacement courant. Un autre
1416 emplacement courant est <file>/pub/debian</file>.
1419 Une distribution est composée de paquets sources et binaires et des
1420 fichiers <file>Sources</file> et <file>Packages</file> correspondants
1421 qui contiennent toutes les méta-informations sur les paquets. Les
1422 premiers sont conservés dans le répertoire <file>pool/</file> tandis
1423 que les seconds sont conservés dans le répertoire <file>dists/</file>
1424 de l'archive (pour compatibilité descendante).
1426 <sect2 id="sec-dists">
1428 <em>Stable</em>, <em>testing</em> et <em>unstable</em>
1431 Il y a toujours une distribution appelée <em>stable</em> (dans le
1432 répertoire <file>dists/stable</file>), une distribution appelée
1433 <em>testing</em> (dans le répertoire <file>dists/testing</file>) et
1434 une distribution appelée <em>unstable</em> (dans le répertoire
1435 <file>dists/unstable</file>). Ceci reflète le processus de
1436 développement du projet Debian.
1439 Les développements se font sur la distribution
1440 <em>unstable</em><footnote><p><em>unstable</em> signifie
1441 « instable »</p></footnote> (c'est pourquoi elle est aussi
1442 appelée <em>distribution de développement</em>). Chaque développeur
1443 Debian peut modifier ses paquets à tout moment dans cette
1444 distribution. Ainsi son contenu change tous les jours. Comme aucun
1445 effort particulier n'est fait pour s'assurer que tout fonctionne
1446 correctement dans cette distribution, elle est parfois littéralement
1447 « instable ».
1450 La distribution <qref id="testing">« testing »</qref> est
1451 générée automatiquement en prenant les paquets d'<em>unstable</em>
1452 s'ils satisfont à certains critères. Ces critères garantissent que
1453 les paquets de <em>testing</em> sont de bonne qualité. La mise à jour
1454 de <em>testing</em> est lancée chaque jour après que les nouveaux
1455 paquets ont été installés. Voir <ref id="testing">.
1458 Après une période de développement, quand le responsable de
1459 distribution<footnote><p><em>Release manager</em></p></footnote> le
1460 juge opportun, la distribution <em>testing</em> est gelée, ce qui
1461 signifie que les conditions à remplir pour qu'un paquet passe
1462 d'<em>unstable</em> à <em>testing</em> sont durcies. Les paquets trop
1463 bogués sont supprimés et les seules mises à jours autorisées
1464 concernent les corrections de bogues. Après quelque temps, selon
1465 l'avancement, la distribution <em>testing</em> est gelée encore
1466 plus. Les détails de la gestion de la distribution <em>testing</em>
1467 sont publiées par l'équipe de publication sur la liste
1468 debian-devel-announce. Après la résolution des problèmes restants à
1469 la satisfaction de l'équipe de publication, la distribution est
1470 publiée. La publication veut dire que <em>testing</em> est renommée
1471 en <em>stable</em>, une nouvelle copie est créée pour la nouvelle
1472 <em>testing</em> et l'ancienne <em>stable</em> est renommée en
1473 <em>oldstable</em> et y reste jusqu'à ce qu'elle soit finalement
1474 archivée. Lors de l'archivage, son contenu est déplacé sur
1475 <tt>&archive-host;</tt>.
1478 Ce cycle de développement est basé sur l'idée que la distribution
1479 <em>unstable</em> devient <em>stable</em> après une période de test
1480 (<em>testing</em>). Une distribution contient inévitablement des
1481 bogues, même si elle est classée stable. C'est pourquoi les
1482 distributions stables sont mises à jour de temps en temps. Les
1483 corrections introduites sont testées avec une grande attention et
1484 sont ajoutées une à une à l'archive pour diminuer les risques
1485 d'introduire de nouveaux bogues. Vous pouvez trouver des paquets
1486 proposés pour les mises à jour de <em>stable</em> dans le répertoire
1487 <file>proposed-updates</file>. De temps en temps, les paquets de ce
1488 répertoire qui ne présentent pas de problème sont installés dans la
1489 distribution <em>stable</em> et le numéro de révision de cette
1490 distribution est incrémenté (« 3.0 » devient
1491 « 3.0r1 », « 2.2r4 » devient « 2.2r5 »
1492 et ainsi de suite). Veuillez vous référer aux <qref
1493 id="upload-stable">envois dans la distribution <em>stable</em></qref>
1494 pour plus de détails.
1497 Notez que, pendant la période de gel, les développements continuent
1498 sur la distribution <em>unstable</em> car cette distribution reste en
1504 Informations complémentaires sur la distribution
1505 « testing »
1508 Les paquets sont habituellement installés dans la distribution
1509 <em>testing</em> après avoir atteint un certain degré de test dans
1513 Pour plus de détails, veuillez consulter les <qref
1514 id="testing">informations à propos de la distribution
1515 <em>testing</em></qref>.
1518 <sect2 id="experimental">
1523 La distribution <em>experimental</em> est une distribution
1524 particulière. Ce n'est pas une distribution à part entière comme le
1525 sont <em>stable</em> et <em>unstable</em>. Elle est prévue pour
1526 servir de plate-forme de développement pour les projets expérimentaux
1527 qui risquent vraiment de détruire le système ou bien pour des
1528 logiciels qui sont vraiment trop instables pour être inclus dans la
1529 distribution <em>unstable</em> (mais pour lesquels une mise en paquet
1530 est justifiée). Les utilisateurs qui téléchargent et installent des
1531 paquets depuis <em>experimental</em> sont prévenus : on ne peut
1532 pas faire confiance à la distribution <em>experimental</em>.
1535 Voici les lignes de <manref section="5" name="sources.list"> pour
1536 <em>experimental</em> :
1538 deb http://ftp.<var>xy</var>.debian.org/debian/ experimental main
1539 deb-src http://ftp.<var>xy</var>.debian.org/debian/ experimental main
1543 Si un logiciel peut causer des dégâts importants, il sera sûrement
1544 préférable de le mettre dans la distribution
1545 <em>experimental</em>. Un système de fichiers compacté expérimental,
1546 par exemple, devrait probablement aller dans <em>experimental</em>.
1549 Une nouvelle version amont qui ajoute de nouvelles fonctions tout en
1550 supprimant de nombreuses autres ne devra pas être téléchargée dans
1551 l'archive Debian, elle pourra cependant être téléchargée dans
1552 <em>experimental</em>. Une nouvelle version non finalisée d'un
1553 logiciel qui utilise une méthode de configuration complètement
1554 différente pourrait aller dans <em>experimental</em> au gré du
1555 responsable. Si vous travaillez sur un cas de mise à jour complexe ou
1556 incompatible, vous pouvez aussi utiliser <em>experimental</em> comme
1557 plate-forme d'intégration et ainsi fournir un accès aux testeurs.
1560 Quelques logiciels expérimentaux peuvent cependant aller dans
1561 <em>unstable</em>, avec un avertissement dans la description, mais ce
1562 n'est pas recommandé car les paquets d'<em>unstable</em> se propagent
1563 dans <em>testing</em> et aboutissent dans <em>stable</em>. Vous ne
1564 devriez pas avoir peur d'utiliser <em>experimental</em> car ceci ne
1565 cause aucun souci aux ftpmasters, les paquets expérimentaux sont
1566 automatiquement enlevés quand vous envoyez le paquet dans
1567 <em>unstable</em> avec un numéro de version supérieur.
1570 Un nouveau logiciel qui ne risque pas d'endommager le système ira
1571 directement dans <em>unstable</em>.
1574 Une solution de rechange à <em>experimental</em> consiste à utiliser
1575 vos pages personnelles sur le serveur <tt>people.debian.org</tt>.
1578 Veuillez considérer l'utilisation de l'option <tt>-v</tt> de
1579 <prgn>dpkg-buildpackage</prgn> si l'envoi d'un paquet dans
1580 <em>unstable</em> ferme finalement des bogues qui ont d'abord été
1581 corrigés dans <em>experimental</em>. Lors de l'envoi vers
1582 <em>unstable</em> d'un paquet contenant des bogues corrigés dans
1583 <em>experimental</em>, veuillez considérer l'utilisation de l'option
1584 <tt>-v</tt> de <prgn>dpkg-buildpackage</prgn> pour qu'ils soient
1589 <sect1 id="codenames">
1591 Les noms de distribution
1594 Chaque distribution Debian diffusée a un <em>nom de code</em> :
1595 Debian 1.1 s'appelle « Buzz » ; Debian 1.2,
1596 « Rex » ; Debian 1.3, « Bo » ;
1597 Debian 2.0, « Hamm » ; Debian 2.1,
1598 « Slink »; Debian 2.2, « Potato » ;
1599 Debian 3.0, « Woody » ; Debian 3.1,
1600 « Sarge » ; Debian 4.0,
1601 « Etch ». Il y a aussi une pseudo-distribution nommée
1602 « Sid », il s'agit de la distribution
1603 <em>unstable</em> ; comme les paquets vont d'<em>unstable</em> à
1604 <em>testing</em> quand ils approchent de la stabilité, la distribution
1605 « Sid » n'est jamais diffusée. En plus du contenu habituel
1606 d'une distribution Debian, « Sid » contient des paquets pour
1607 des architectures qui ne sont pas encore officiellement prises en
1608 charge ou pour lesquelles la distribution n'a pas encore été
1609 publiée. Ces architectures seront intégrées ultérieurement à la
1610 distribution principale.
1613 Comme Debian est un projet de développement ouvert (i.e. tout le monde
1614 peut participer et suivre les développements), même les distributions
1615 <em>unstable</em> et <em>testing</em> sont disponibles sur les
1616 serveurs HTTP et FTP de Debian. Si nous avions nommé le répertoire qui
1617 contient la prochaine distribution à diffuser « testing »,
1618 il aurait fallu changer son nom en « stable » au moment de
1619 la publication, ce qui aurait forcé les miroirs FTP à télécharger à
1620 nouveau la distribution complète (qui est plutôt volumineuse).
1623 D'un autre côté, si une distribution s'appelait <em>Debian-x.y</em>
1624 dès le départ, des personnes pourraient s'imaginer que la distribution
1625 Debian <em>x.y</em> est disponible. (Cela s'est produit par le passé,
1626 un distributeur avait gravé des cédéroms Debian 1.0 en utilisant une
1627 version de développement pré-1.0. C'est pour cette raison que la
1628 première version officielle était la version 1.1 et non la 1.0).
1631 En conséquence, les noms de répertoire des distributions dans
1632 l'archive sont déterminés par leur nom de code et non par leur statut
1633 (exemple : slink). Ces noms sont identiques pendant la période de
1634 développement et une fois la distribution diffusée ; des liens
1635 symboliques, qui peuvent être modifiés facilement, indiquent la
1636 distribution stable actuelle. Tout ceci explique pourquoi les
1637 répertoires des distributions sont nommés à partir des noms de code
1638 des distributions alors que <em>stable</em>, <em>testing</em> et
1639 <em>unstable</em> sont des liens symboliques qui pointent vers les
1640 répertoires appropriés.
1649 Les différentes archives de téléchargement et le site web disposent de
1650 plusieurs miroirs pour soulager les serveurs principaux d'une lourde
1651 charge. En fait, certains de ces serveurs ne sont pas
1652 publics — la charge est répartie sur une première série de
1653 serveurs. De cette façon, les utilisateurs ont toujours accès aux
1654 miroirs et s'y habituent, ce qui permet à Debian de mieux répartir les
1655 besoins en bande passante sur plusieurs serveurs et plusieurs réseaux
1656 différents et évite aux utilisateurs de surcharger l'emplacement
1657 primaire. Notez que, dans cette première série, les serveurs sont aussi
1658 à jour que possible car la mise à jour est déclenchée par les sites
1662 Toutes les informations sur les miroirs Debian peuvent être trouvées à
1663 <url id="&url-debian-mirrors;">, y compris une liste des miroirs
1664 publics disponibles FTP/HTTP. Cette page utile inclut également des
1665 informations et des outils pour créer son propre miroir, soit en
1666 interne soit pour un accès public.
1669 Les miroirs sont en général mis en œuvre par des tiers qui
1670 veulent aider Debian. C'est pourquoi les développeurs n'ont en général
1671 pas de compte sur ces machines.
1674 <sect id="incoming-system">
1679 Le système Incoming est responsable de la collecte des paquets mis à
1680 jour et de leur installation dans l'archive Debian. Il est constitué
1681 d'un ensemble de répertoires et de scripts qui sont installés sur
1682 <tt>&ftp-master-host;</tt>.
1685 Les paquets sont envoyés par tous les responsables Debian dans un
1686 répertoire nommé <file>UploadQueue</file>. Ce répertoire est parcouru
1687 toutes les quelques minutes par un démon appelé <prgn>queued</prgn>,
1688 les fichiers <file>*.command</file> sont exécutés et les fichiers
1689 <file>*.changes</file> restants et correctement signés sont déplacés
1690 avec leurs fichiers correspondants dans le répertoire
1691 <file>unchecked</file>. Ce répertoire n'est pas visible de la plupart
1692 des développeurs car ftp-master est à accès restreint ; il est
1693 parcouru toutes les 15 minutes par le script <prgn>katie</prgn> qui
1694 vérifie l'intégrité des paquets envoyés et leurs signatures de
1695 chiffrage. Si le paquet est considéré comme prêt à être installé, il
1696 est déplacé dans le répertoire <file>accepted</file>. S'il s'agit du
1697 premier envoi du paquet (ou s'il a de nouveaux paquets binaire), il est
1698 déplacé dans le répertoire <file>new</file> où il attend l'approbation
1699 des ftpmasters. Si le paquet contient des fichiers devant être
1700 installés <em>à la main</em>, il est déplacé dans le répertoire
1701 <file>byhand</file> où il attend une installation manuelle par les
1702 ftpmasters. Sinon, si une erreur a été détectée, le paquet est refusé
1703 et il est déplacé dans le répertoire <file>reject</file>.
1706 Une fois que le paquet est accepté, le système envoie une confirmation
1707 par courrier au responsable et ferme les bogues corrigés par l'envoi,
1708 puis les compilateurs automatiques peuvent commencer la
1709 recompilation. Le paquet est maintenant accessible publiquement à <url
1710 id="&url-incoming;"> jusqu'à ce qu'il soit vraiment installé dans
1711 l'archive Debian. Cela se produit seulement une fois par jour (et c'est
1712 également appelé une « exécution dinstall » pour des raisons
1713 historiques) ; le paquet est alors supprimé de
1714 <file>Incoming</file> et installé dans le pool avec les autres
1715 paquets. Une fois que toutes les autres mises à jour (fabrication des
1716 nouveaux fichiers d'index <file>Packages</file> et <file>Sources</file>
1717 par exemple) ont été effectuées, un script spécial est appelé pour
1718 demander aux miroirs primaires de se mettre à jour.
1721 Le logiciel de maintenance de l'archive enverra également le fichier
1722 <file>.changes</file> signé avec OpenPGP/GnuPG que vous avez envoyé, à
1723 la liste de diffusion appropriée. Si un paquet est diffusé avec le
1724 champ <tt>Distribution:</tt> positionné à « stable »,
1725 l'annonce sera envoyée à &email-debian-changes;. Si un paquet est
1726 diffusé avec le champ <tt>Distribution:</tt> positionné à
1727 « unstable » ou « experimental », l'annonce sera à
1728 la place envoyée à &email-debian-devel-changes;.
1731 Bien que ftp-master soit à accès restreint, une copie de l'installation
1732 est disponible à tous les développeurs sur
1733 <tt>&ftp-master-mirror;</tt>.
1736 <sect id="pkg-info">
1738 Informations sur un paquet
1742 <sect1 id="pkg-info-web">
1747 Chaque paquet a plusieurs pages web
1748 dédiées. <tt>http://&packages-host;/<var>nom-paquet</var></tt> affiche
1749 chaque version du paquet disponible dans les différentes
1750 distributions. Les informations détaillées par version incluent la
1751 description du paquet, les dépendances et des liens pour télécharger
1755 Le système de suivi des bogues trie les bogues par paquet. Vous pouvez
1756 regarder les bogues de chaque paquet à
1757 <tt>http://&bugs-host;/<var>nom-paquet</var></tt>.
1760 <sect1 id="madison">
1762 L'outil <prgn>madison</prgn>
1765 <prgn>madison</prgn> est un outil en ligne de commande qui est
1766 disponible sur <tt>&ftp-master-host;</tt> et sur le miroir
1767 <tt>&ftp-master-mirror;</tt>. Il utilise un seul paramètre qui
1768 correspond au nom du paquet. Il affiche comme résultat quelle version
1769 du paquet est disponible pour chaque combinaison d'architecture et de
1770 distribution. Un exemple l'expliquera mieux.
1774 $ madison libdbd-mysql-perl
1775 libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
1776 libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
1777 libdbd-mysql-perl | 1.2216-2.0.1| testing | alpha
1778 libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
1782 Dans cet exemple, vous pouvez voir que la version dans
1783 <em>unstable</em> diffère de celle de <em>testing</em> et qu'il y a eu
1784 une NMU binaire seulement pour l'architecture alpha. Chaque version du
1785 paquet a été recompilée sur la plupart des architectures.
1789 <sect id="pkg-tracking-system">
1791 Système de suivi des paquets
1794 Le système de suivi des paquets (PTS)<footnote><p>« Package
1795 Tracking System »</p></footnote> est un outil pour suivre par
1796 courrier l'activité concernant un paquet source. Cela veut vraiment
1797 dire que vous pourrez recevoir les mêmes courriers que le responsable,
1798 simplement en vous inscrivant au paquet dans le PTS.
1801 Chaque courrier envoyé par le PTS est classé sous l'un des mots-clés
1802 listés ci-dessous. Ceci vous permettra de sélectionner les courriers
1803 que vous voulez recevoir.
1806 Par défaut, vous recevrez :
1813 Tous les rapports de bogue et les discussions qui suivent.
1817 <tt>bts-control</tt>
1821 Les courriers de notification de
1822 <email>control@bugs.debian.org</email> sur les changement d'état de
1823 l'un des rapports de bogue.
1827 <tt>upload-source</tt>
1831 Le courrier de notification de <prgn>katie</prgn> quand un paquet
1832 source envoyé a été accepté.
1836 <tt>katie-other</tt>
1840 Les autres courriers d'avertissement et d'erreur de
1841 <prgn>katie</prgn> (comme une incohérence de passage en force pour
1842 les champs section ou priorité).
1850 Tout courrier non automatique envoyé au PTS par les personnes qui
1851 veulent contacter les inscrits au paquet. Ceci peut être fait en
1852 envoyant un courrier à
1853 <tt><var>paquet-source</var>@&pts-host;</tt>. Pour prévenir l'envoi
1854 de pourriels, tous les courriers envoyés à ces adresses doivent
1855 contenir l'en-tête <tt>X-PTS-Approved</tt> avec une valeur non vide.
1863 Des courriers de résumé réguliers sur l'état du paquet. Actuellement,
1864 seule la progression du paquet dans <em>testing</em> est envoyée.
1870 Vous pouvez également décider de recevoir des informations
1871 supplémentaires :
1874 <tt>upload-binary</tt>
1878 Le courrier d'information de <prgn>katie</prgn> quand un paquet
1879 binaire envoyé est accepté. En d'autres termes, à chaque fois qu'un
1880 démon de compilation ou un porteur envoie votre paquet pour une
1881 autre architecture, vous recevez un courrier pour suivre comment
1882 votre paquet est recompilé pour toutes les architectures.
1890 Les notifications de modifications CVS<footnote><p><em>CVS
1891 commits</em></p></footnote> si le responsable a mis en place un
1892 système pour faire suivre les notifications de modifications vers le
1901 Les traductions des descriptions ou des questionnaires debconf
1902 soumis au Projet de traduction des descriptions de paquets
1903 Debian<footnote><p><em>Debian Description Translation Project,
1904 DDTP</em></p></footnote>.
1908 <tt>derivatives</tt>
1912 Des informations sur les changements effectués sur le paquet dans les
1913 distributions dérivées (par exemple, Ubuntu).
1918 <sect1 id="pts-commands">
1920 L'interface de courrier du PTS
1923 Vous pouvez contrôler votre (vos) inscription(s) au PTS en envoyant
1924 différentes commandes à <email>pts@qa.debian.org</email>.
1927 <tt>subscribe <paquet source> [<adresse>]</tt>
1931 Inscrit <var>adresse</var> aux communications liées au paquet
1932 source <var>paquet source</var>. L'adresse de l'expéditeur est
1933 utilisée si le second paramètre n'est pas présent. Si <var>paquet
1934 source</var> n'est pas un paquet source valide, vous obtiendrez un
1935 avertissement. Cependant, s'il s'agit d'un paquet binaire valide,
1936 le PTS vous inscrira pour le paquet source correspondant.
1940 <tt>unsubscribe <paquet source> [<adresse>]</tt>
1944 Supprime une inscription précédente au paquet source <var>paquet
1945 source</var> en utilisant l'adresse spécifiée ou l'adresse de
1946 l'expéditeur si le second paramètre n'est pas rempli.
1950 <tt>unsubscribeall [<adresse>]</tt>
1954 Supprime toutes les inscriptions précédentes de l'adresse spécifiée
1955 ou de l'adresse de l'expéditeur si le second paramètre n'est pas
1960 <tt>which [<adresse>]</tt>
1964 Liste les inscriptions pour l'expéditeur ou pour l'adresse indiquée
1965 si elle est spécifiée.
1969 <tt>keyword [<adresse>]</tt>
1973 Donne les mots-clés que vous acceptez. Pour une explication des ces
1974 mots-clés, <qref id="pkg-tracking-system">voir
1975 ci-dessus</qref>. Voici un rapide résumé :
1979 <tt>bts</tt> : courriers venant du système de gestion de
1985 <tt>bts-control</tt> : réponses aux courriers envoyés à
1986 &bugs-host;&email-bts-control;
1991 <tt>summary</tt> : courriers de résumé automatique sur
1997 <tt>cvs</tt> : notifications de modifications CVS
2002 <tt>ddtp</tt> : traductions des descriptions et
2003 questionnaires debconf
2008 <tt>derivatives</tt> : changements effectués sur le paquet
2009 dans des distributions dérivées
2014 <tt>upload-source</tt> : annonce d'un nouvel envoi de
2015 paquet source qui a été accepté
2020 <tt>upload-binary</tt> : annonce d'un nouvel envoi de
2021 binaire seulement (portage)
2026 <tt>katie-other</tt> : autres courriers des ftpmasters
2027 (incohérence de passage en force, etc.)
2032 <tt>default</tt> : tous les autres courriers (ceux qui ne
2033 sont pas automatiques)
2040 <tt>keyword <paquet source> [<adresse>]</tt>
2044 Identique à l'élément précédent, mais pour un paquet source donné
2045 car vous pouvez sélectionner un ensemble de mots-clés différent
2046 pour chaque paquet source.
2050 <tt>keyword [<adresse>] {+|-|=} <liste de
2055 Accepte (+) ou refuse (-) les courriers classés sous le(s)
2056 mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés. Ceci
2057 change l'ensemble par défaut des mots-clés acceptés par un
2062 <tt>keywordall [<adresse>] {+|-|=} <liste de
2067 Accepte (+) ou refuse (-) les courriers classés sous le(s)
2068 mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés. Ceci
2069 change les mots-clés de toutes les inscriptions actuellement en cours
2074 <tt>keyword <paquet source> [<adresse>] {+|-|=}
2075 <liste de mots-clés></tt>
2079 Identique à l'élément précédent, mais remplace la liste des
2080 mots-clés pour le paquet source indiqué.
2084 <tt>quit | thanks | --</tt>
2088 Arrête le traitement des commandes. Toutes les lignes suivantes
2089 sont ignorées par le robot.
2095 L'utilitaire en ligne de commande <prgn>pts-subscribe</prgn> (du paquet
2096 <package>devscripts</package>) peut être pratique pour s'inscrire
2097 temporairement à certains paquets, par exemple après avoir fait une mise
2098 à jour indépendante (NMU).
2102 <sect1 id="pts-mail-filtering">
2104 Filtrer les courriers du PTS
2107 Une fois que vous vous êtes inscrit à un paquet, vous recevrez les
2108 courriers envoyés à <tt><var>paquet
2109 source</var>@packages.qa.debian.org</tt>. Ces courriers ont des
2110 en-têtes spéciaux ajoutés pour vous permettre de les filtrer dans des
2111 boîtes aux lettres (par exemple, avec <prgn>procmail</prgn>). Les
2112 en-têtes ajoutés sont <tt>X-Loop</tt>, <tt>X-PTS-Package</tt>,
2113 <tt>X-PTS-Keyword</tt> et <tt>X-Unsubscribe</tt>.
2116 Voici un exemple d'en-têtes ajoutés pour une notification d'envoi de
2117 source sur le paquet <package>dpkg</package> :
2119 X-Loop: dpkg@&pts-host;
2121 X-PTS-Keyword: upload-source
2122 X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
2126 <sect1 id="pts-cvs-commit">
2128 Faire suivre les modifications de CVS vers le PTS
2131 Si vous utilisez un référentiel CVS accessible publiquement pour
2132 maintenir votre paquet Debian, vous pouvez vouloir faire suivre les
2133 notifications de modifications vers le PTS pour que les inscrits
2134 (ainsi que des possibles co-responsables) puissent suivre de près
2135 l'évolution du paquet.
2138 Une fois que votre référentiel génère des notifications de
2139 modifications, vous devez simplement vous assurer qu'il envoie une
2140 copie de tous ces courriers à <tt><var>paquet
2141 source</var>_cvs@&pts-host;</tt>. Seules les personnes qui ont accepté
2142 le mot-clé <em>cvs</em> recevront les notifications.
2145 <sect1 id="pts-web">
2147 L'interface web du PTS
2150 Le PTS possède une interface web à <url id="http://&pts-host;/"> qui
2151 réunit beaucoup d'informations au même endroit à propos de chaque
2152 paquet source. Il propose plusieurs liens utiles (BTS, statistiques
2153 QA, informations de contact, état de traduction DDTP, journaux de
2154 compilation automatique) et il regroupe beaucoup d'autres informations
2155 provenant de différents endroits (les 30 dernières entrées de
2156 changelog, l'état dans <em>testing</em>, etc.). Il s'agit d'un outil
2157 très pratique si vous désirez connaître ce qu'il en est d'un paquet
2158 source spécifique. De plus, il y a un formulaire qui permet de
2159 facilement s'inscrire au PTS par courrier.
2162 Vous pouvez aller directement à la page web concernant un paquet
2163 source avec une URL comme <tt>http://&pts-host;/<var>paquet
2167 Cette interface a été conçue comme un portail pour le développements
2168 des paquets : vous pouvez ajouter du contenu personnalisé aux
2169 pages de vos paquets. Vous pouvez ajouter des « informations
2170 statiques »<footnote><p><em>Static
2171 information</em></p></footnote> (des annonces qui sont destinées à
2172 rester disponibles indéfiniment) et des nouvelles dans la section
2173 « dernières nouvelles »<footnote><p><em>Latest
2174 news</em></p></footnote>.
2177 Les annonces statiques peuvent être utilisées pour indiquer :
2181 la disponibilité d'un projet hébergé sur <qref
2182 id="alioth">Alioth</qref> pour la co-maintenance du paquet,
2187 un lien vers le site web amont,
2192 un lien vers le suivi de bogues amont,
2197 l'existence d'un canal IRC dédié au logiciel,
2202 toute autre ressource disponible qui peut être utile à la
2203 maintenance du paquet.
2207 Les nouvelles usuelles peuvent être utilisées pour annoncer que :
2211 des paquets bêta sont disponibles pour test,
2216 des paquets finaux sont attendus pour la semaine prochaine,
2221 l'empaquetage est sur le point d'être intégralement refait,
2226 des rétroportages sont disponibles,
2231 le responsable est en vacance (s'il désire publier cette
2237 une mise à jour indépendante (NMU) est en cours de réalisation,
2242 quelque chose d'important va affecter le paquet.
2248 Les deux types d'informations sont fabriqués de façon similaire :
2249 il vous suffit d'envoyer un courrier soit à
2250 <email>pts-static-news@qa.debian.org</email> (pour les annonces
2251 statiques), soit à <email>pts-news@qa.debian.org</email> (pour les
2252 nouvelles usuelles). Le courrier devrait indiquer quel paquet est
2253 concerné par la nouvelle en donnant le nom du paquet source dans un
2254 en-tête de courrier <tt>X-PTS-Package</tt> ou dans un pseudo-en-tête
2255 <tt>Package</tt> (comme pour les rapports de bogue du BTS). Si une URL
2256 est disponible dans l'en-tête de courrier <tt>X-PTS-Url</tt> ou dans
2257 un pseudo-en-tête <tt>Url</tt>, le résultat est un lien vers cette URL
2258 au lieu d'une nouvelle complète.
2261 Voici quelques exemples de courriers valides utilisés pour générer des
2262 nouvelles dans le PTS. Le premier ajoute un lien vers l'interface
2263 cvsweb de debian-cd dans la section « Informations
2264 statiques » :
2266 From: Raphael Hertzog <hertzog@debian.org>
2267 To: pts-static-news@qa.debian.org
2268 Subject: Browse debian-cd CVS repository with cvsweb
2271 Url: http://cvs.debian.org/debian-cd/
2275 Le second est une annonce envoyée à une liste de diffusion et
2276 également envoyée au PTS pour qu'elle soit publiée sur la page web du
2277 PTS du paquet. Notez l'utilisation du champ BCC pour éviter que des
2278 réponses ne soient envoyées par erreur au PTS.
2280 From: Raphael Hertzog <hertzog@debian.org>
2281 To: debian-gtk-gnome@lists.debian.org
2282 Bcc: pts-news@qa.debian.org
2283 Subject: Galeon 2.0 backported for woody
2284 X-PTS-Package: galeon
2288 I'm glad to announce that galeon has been backported for woody. You'll find
2294 Réfléchissez-y à deux fois avant d'ajouter une nouvelle au PTS car
2295 vous ne pourrez pas l'enlever par la suite et vous ne pourrez pas non
2296 plus l'éditer. La seule chose que vous puissiez faire est d'envoyer
2297 une deuxième nouvelle qui va déprécier l'information contenue dans la
2304 Vue d'ensemble des paquets d'un développeur
2307 Un portail web pour l'Assurance Qualité (QA) est disponible à <url
2308 id="&url-ddpo;"> qui affiche un tableau de tous les paquets d'un
2309 développeur (y compris ceux pour lequel il est co-responsable). Le
2310 tableau donne un bon résumé sur les paquets d'un développeur :
2311 nombre de bogues par gravité, liste des versions disponibles, état des
2312 tests et des liens vers d'autres informations utiles.
2315 C'est une bonne idée de vérifier régulièrement vos données pour ne pas
2316 oublier de bogues ouverts et pour ne pas oublier quels paquets sont
2317 sous votre responsabilité.
2322 Debian *Forge : Alioth
2325 Alioth est un service de Debian plutôt récent, basé sur une version
2326 légèrement modifiée du logiciel GForge (qui a évolué à partir de
2327 SourceForge). Ce logiciel offre aux développeurs l'accès à des outils
2328 faciles d'utilisation comme un gestionnaire de suivi de bogues, un
2329 gestionnaire de correctifs, un gestionnaire de tâches et de projets, un
2330 service d'hébergement de fichiers, des listes de diffusion, des dépôts
2331 CVS, etc. Tous ces outils sont gérés par une interface web.
2334 Alioth est destiné à fournir des facilités pour des projets de
2335 logiciels soutenus ou dirigés par Debian, à faciliter les contributions
2336 de développeurs externes aux projets initiés par Debian et à aider des
2337 projets dont les buts sont de promouvoir Debian ou ses dérivés.
2340 Tous les développeurs Debian ont automatiquement un compte sur
2341 Alioth. Ils peuvent l'activer en utilisant la fonctionnalité de
2342 récupération des mots de passe. Les développeurs externes peuvent
2343 demander un compte invité sur Alioth.
2346 Pour plus d'informations, veuillez visiter <url id="&url-alioth;">.
2349 <sect id="developer-misc">
2351 « Goodies » pour les développeurs
2360 Depuis octobre 2002, HP parraine l'abonnement à LWN pour tous les
2361 développeurs Debian intéressés. Les détails sur les moyens d'accéder à
2362 cet avantage sont expliqués dans <url
2363 id="http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html">.
2373 Ce chapitre contient des informations relatives à la création, l'envoi,
2374 la maintenance et le portage des paquets.
2376 <sect id="newpackage">
2381 Si vous voulez créer un nouveau paquet pour la distribution Debian,
2382 vous devriez commencer par consulter la liste des <url id="&url-wnpp;"
2383 name="paquets en souffrance et paquets souhaités">. Vous pourrez ainsi
2384 vérifier que personne ne travaille déjà sur ce paquet et éviter un
2385 double travail. Consultez aussi cette page si vous voulez en savoir
2389 Supposons que personne ne travaille sur le paquet que vous visez, vous
2390 devez alors envoyer un rapport de bogue (voir <ref id="submit-bug">)
2391 concernant le pseudo-paquet <package>wnpp</package>. Ce courrier devra
2392 décrire le paquet que vous projetez de créer, la licence de ce paquet
2393 et l'URL à laquelle le source peut être téléchargé. Cette liste n'est
2397 Le sujet de votre rapport de bogue devra être
2398 <ITP<footnote><p><em>Intent To Package</em> : intention
2399 d'empaquetage</p></footnote> : <var>NomDuPaquet</var> —
2400 <var>courte description</var>>, en remplaçant <var>NomDuPaquet</var>
2401 par le nom du paquet. La gravité du bogue sera <em>wishlist</em>. Si
2402 vous le jugez nécessaire, envoyez une copie à &email-debian-devel; en
2403 mettant cette adresse dans le champ <tt>X-Debbugs-CC:</tt> de l'en-tête
2404 du message. N'utilisez pas le champ <tt>CC:</tt> car de cette manière
2405 le sujet du message ne contiendrait pas le numéro du bogue.
2408 Il faudra aussi ajouter une entrée <tt>Closes:
2409 bug#<var>nnnnn</var></tt> dans le fichier <file>changelog</file> du
2410 nouveau paquet. Cette indication fermera automatiquement le rapport de
2411 bogue à l'installation du nouveau paquet sur les serveurs d'archivage
2412 (voir <ref id="upload-bugfix">).
2415 Lors de la fermeture de bogues de sécurité, incluez les numéros CVS ainsi
2416 que « Closes: #nnnnn ». Ceci est utile l'équipe de sécurité
2417 pour suivre les failles de sécurité. Si un envoi est effectué pour
2418 corriger le bogue avant que l'identifiant de l'alerte soit connu, il est
2419 conseillé de modifier l'entrée de changelog historique lors du prochain
2420 envoi. Même dans ce cas, veuillez inclure tous les pointeurs disponibles
2421 vers les informations de contexte dans l'entrée de changelog d'origine.
2424 Plusieurs raisons nous poussent à demander aux responsables d'annoncer
2425 leur intention :
2426 <list compact="compact">
2429 Les responsables ont ainsi la possibilité de puiser dans
2430 l'expérience des autres responsables et cela leur permet de savoir
2431 si une autre personne travaille déjà dessus.
2436 D'autres personnes qui envisagent de travailler sur le même paquet
2437 apprendront ainsi qu'il existe déjà un volontaire, l'effort peut
2443 Cela permet aux autres responsables de connaître le nouveau paquet
2444 mieux que ne le permettent la description d'une ligne et
2445 l'habituelle entrée de type changelog <em>Initial release</em>
2446 postée sur <tt>debian-devel-changes</tt>.
2451 C'est une information utile pour les gens qui utilisent la
2452 distribution <em>unstable</em> et qui sont nos premiers
2453 testeurs. Nous devons leur faciliter la tâche.
2458 Avec ces annonces, les développeurs Debian et toutes les autres
2459 personnes intéressées peuvent se faire une meilleure idée des
2460 évolutions et des nouveautés du projet.
2466 Veuillez consulter <url
2467 id="http://ftp-master.debian.org/REJECT-FAQ.html"> pour les raisons
2468 courantes de rejet des nouveaux paquets.
2471 <sect id="changelog-entries">
2473 Enregistrer les modifications dans le paquet
2476 Les modifications que vous apportez au paquet doivent être notifiées
2477 dans le fichier <file>debian/changelog</file>. Ces notes doivent donner
2478 une description concise des changements, expliquer les raisons de
2479 ceux-ci (si ce n'est pas clair) et indiquer si des rapports de bogue
2480 ont été clos. Il faut aussi indiquer quand le paquet a été terminé. Ce
2481 fichier sera installé dans
2482 <file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
2483 <file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un
2487 Le fichier <file>debian/changelog</file> a une structure précise
2488 comportant différents champs. Le champ <em>distribution</em> est décrit
2489 dans <ref id="distribution">. Vous trouverez plus d'informations sur la
2490 structure de ce fichier dans la section
2491 « <file>debian/changelog</file> » de la <em>charte
2495 Les entrées du fichier <file>changelog</file> peuvent être utilisées
2496 pour fermer des rapports de bogue au moment où le paquet est installé
2497 dans l'archive. Voir la section <ref id="upload-bugfix">.
2500 Par convention, l'entrée changelog d'un paquet contenant une nouvelle
2501 version amont ressemble à :
2503 * new upstream version
2507 Quelques outils peuvent vous aider à créer des entrées et à finaliser
2508 le fichier <file>changelog</file> pour une livraison — voir les
2509 sections <ref id="devscripts"> et <ref id="dpkg-dev-el">.
2512 Voir aussi <ref id="bpp-debian-changelog">.
2515 <sect id="sanitycheck">
2520 Avant d'envoyer votre paquet, vous devriez faire quelques tests de
2521 base. Vous devriez au moins faire les tests suivants (il vous faut une
2522 ancienne version du paquet) :
2526 Installez le paquet et vérifiez que le logiciel fonctionne. Si le
2527 paquet existait déjà dans une version plus ancienne, faites une mise
2533 Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
2534 <prgn>lintian</prgn> comme suit : <tt>lintian -v
2535 <var>version-paquet</var>.changes</tt>. Ce programme fera une
2536 vérification sur les paquets source et binaire. Si vous ne comprenez
2537 pas les messages retournés par <prgn>lintian</prgn>, essayez
2538 l'option <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn>
2539 beaucoup plus bavard dans sa description du problème.
2542 En principe, un paquet pour lequel <prgn>lintian</prgn> renvoie des
2543 erreurs (elles commencent par <tt>E</tt>) <em>ne doit pas</em> être
2544 installé dans l'archive.
2547 Pour en savoir plus sur <prgn>lintian</prgn>, reportez-vous à la
2548 section <ref id="lintian">.
2553 Vous pouvez facultativement exécuter <ref id="debdiff"> pour
2554 analyser les modifications depuis une ancienne version si celle-ci
2560 Faites régresser le paquet vers sa version précédente si elle existe
2561 — cela permet de tester les scripts <file>postrm</file> et
2567 Désinstallez le paquet et réinstallez-le.
2572 Copiez le paquet source dans une répertoire différent et tentez de
2573 le décompacter et de le reconstruire. Ceci teste si le paquet repose
2574 sur des fichiers existants en dehors de ceux du paquet ou s'il
2575 repose sur des permissions préservées des fichiers livrés dans le
2582 <sect id="sourcelayout">
2584 Disposition du paquet source
2587 Il existe deux types de paquets source Debian :
2591 les paquets appelés <em>natifs</em> pour lesquels il n'y a pas de
2592 distinction entre les sources d'origine et les correctifs appliqués
2598 les paquets (plus courants) où il y a un fichier archive source
2599 d'origine accompagné par un autre fichier contenant les correctifs
2606 Pour les paquets natifs, le paquet source inclut un fichier de contrôle
2607 source Debian (<tt>.dsc</tt>) et l'archive source
2608 (<tt>.tar.gz</tt>). Un paquet source d'un paquet non natif inclut un
2609 fichier de contrôle source Debian, l'archive source d'origine
2610 (<tt>.orig.tar.gz</tt>) et les correctifs Debian (<tt>.diff.gz</tt>).
2613 Le caractère natif d'un paquet est déterminé lorsqu'il est construit
2614 par <manref section="1" name="dpkg-buildpackage">. Le reste de cette
2615 section ne se rapporte qu'aux paquets non natifs.
2618 La première fois qu'un paquet est installé dans l'archive pour une
2619 version amont donnée, le fichier <file>tar</file> de cette version
2620 amont doit être téléchargé et mentionné dans le fichier
2621 <file>.changes</file>. Par la suite, ce fichier <file>tar</file> sera
2622 utilisé pour générer les fichiers <file>diff</file> et
2623 <file>.dsc</file> et il ne sera pas nécessaire de le télécharger à
2627 Par défaut, <prgn>dpkg-genchanges</prgn> et
2628 <prgn>dpkg-buildpackage</prgn> incluront le fichier <file>tar</file>
2629 amont si et seulement si le numéro de révision du paquet source est 0
2630 ou 1, ce qui indique une nouvelle version amont. Ce comportement peut
2631 être modifié en utilisant <tt>-sa</tt> pour l'inclure systématiquement
2632 ou <tt>-sd</tt> pour ne jamais l'inclure.
2635 Si la mise à jour ne contient pas le fichier <file>tar</file> des
2636 sources originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour
2637 construire les fichiers <file>.dsc</file> et <file>diff</file> de la
2638 mise à jour, utiliser un fichier <tt>tar</tt> identique à l'octet près
2639 à celui déjà présent dans l'archive.
2642 Veuillez noter que, dans des paquets non natifs, les permissions sur
2643 des fichiers qui ne sont pas présents dans l'archive .orig.tar.gz ne
2644 seront pas préservées car diff ne stocke pas les permissions de fichier
2648 <sect id="distribution">
2650 Choisir une distribution
2653 Chaque envoi doit spécifier à quelle distribution le paquet est
2654 destiné. Le processus de construction de paquet extrait cette
2655 information à partir de la première ligne du fichier
2656 <file>debian/changelog</file> et la place dans le champ
2657 <tt>Distribution</tt> du fichier <tt>.changes</tt>.
2660 Il existe plusieurs valeurs possibles pour ce champ :
2661 « stable », « unstable »,
2662 « testing-proposed-updates » et « experimental ».
2665 En fait, il y a deux autres possibilités :
2666 « stable-security » et « testing-security », mais
2667 veuillez lire <ref id="bug-security"> pour plus d'informations sur
2671 Il n'est pas possible d'envoyer un paquet dans plusieurs distributions
2674 <sect1 id="upload-stable">
2676 Cas spécial : mise à jour d'un paquet de la distribution
2680 Livrer un paquet pour la distribution <em>stable</em> signifie que le
2681 paquet sera dirigé vers le répertoire
2682 <file>stable-proposed-updates</file> des archives Debian pour y être
2683 testé avant d'être effectivement inclus dans <em>stable</em>.
2686 Une livraison pour la distribution <em>stable</em> requiert des soins
2687 supplémentaires. Un paquet de cette distribution ne devrait être mis à
2688 jour que dans les cas suivants :
2692 un problème fonctionnel vraiment critique,
2697 un paquet devenu non installable,
2702 un paquet indisponible pour une architecture.
2708 Par le passé, des envois vers <em>stable</em> étaient également
2709 utilisés pour corriger les problèmes de sécurité. Cependant, cette
2710 pratique est dépréciée car les envois utilisés pour les avis de
2711 sécurité Debian<footnote><p>Debian security advisory</p></footnote>
2712 sont automatiquement copiés dans l'archive
2713 <file>proposed-updates</file> appropriée quand l'avis est
2714 publié. Reportez-vous à <ref id="bug-security"> pour des informations
2715 plus détaillées sur la gestion des problèmes de sécurité.
2718 Il est fortement déconseillé de changer quoi que ce soit si ce n'est
2719 pas important car même une modification triviale peut provoquer un
2723 Les paquets livrés pour <em>stable</em> doivent être compilés avec la
2724 distribution <em>stable</em> pour que leurs dépendances se limitent
2725 aux bibliothèques (et autres paquets) disponibles dans
2726 <em>stable</em> ; un paquet livré pour la distribution
2727 <em>stable</em> qui dépend d'une bibliothèque qui n'est disponible que
2728 dans <em>unstable</em> sera rejeté. Modifier les dépendances d'autres
2729 paquets (en manipulant le champ <tt>Provides</tt> ou les fichiers
2730 shlibs) et, peut-être, rendre ces paquets non installables, est
2731 fortement déconseillé.
2734 L'équipe responsable de la distribution<footnote><p><em>the Release
2735 team</em></p></footnote> (joignable à l'adresse
2736 &email-debian-release;) évaluera régulièrement le contenu de
2737 <em>stable-proposed-updates</em> et décidera si votre paquet peut être
2738 inclus dans la distribution <em>stable</em>. Soyez précis (et, si
2739 nécessaire, prolixe) quand vous décrivez, dans le fichier changelog,
2740 vos changements pour une livraison vers <em>stable</em>, sinon le
2741 paquet ne sera pas pris en considération.
2744 Il est fortement conseillé de discuter avec le responsable de la
2745 version stable <em>avant</em> de réaliser un envoi dans
2746 <em>stable</em>/<em>stable-proposed-updates</em>, pour que le paquet
2747 envoyé corresponde aux besoins de la prochaine révision de
2751 <sect1 id="upload-t-p-u">
2753 Cas spécial : mise à jour d'un paquet de la distribution
2754 <em>testing</em>/<em>testing-proposed-updates</em>
2757 Veuillez consulter les informations dans la <qref id="t-p-u">section
2758 sur <em>testing</em></qref> pour des détails.
2764 Mettre à jour un paquet
2766 <sect1 id="upload-ftp-master">
2768 Installer un paquet sur <tt>ftp-master</tt>
2771 Pour installer un paquet, vous devez envoyer les fichiers (y compris
2772 les fichiers changes et dsc signés) par ftp anonyme sur
2773 <ftpsite>&ftp-master-host;</ftpsite> dans le répertoire
2774 &upload-queue;. Pour que les fichiers y soient traités, ils doivent
2775 être signés avec une clé du porte-clés (<em>keyring</em>) Debian.
2778 Attention, il est préférable de transférer le fichier <tt>changes</tt>
2779 en dernier. Dans le cas contraire, votre livraison pourrait être
2780 rejetée car l'outil de maintenance de l'archive pourrait lire le
2781 fichier <tt>changes</tt> et constater que les fichiers ne sont pas
2785 Les paquets <ref id="dupload"> ou <ref id="dput"> pourront vous
2786 faciliter le travail lors du téléchargement. Ces programmes bien
2787 pratiques aident à automatiser le processus d'envoi de paquets vers
2791 Pour supprimer des paquets, veuillez lire le fichier README dans ce
2792 répertoire FTP et le paquet Debian <ref id="dcut">.
2795 <sect1 id="upload-non-us">
2797 Installer un paquet sur <tt>non-US</tt>
2800 <em>Note :</em> non-us a été interrompu avec la publication de
2804 <sect1 id="delayed-incoming">
2809 Les envois différés sont pour le moment réalisés <em>via</em> la file
2810 différée sur gluck. Le répertoire d'envoi est
2811 <ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>. 0-day est
2812 envoyé approximativement plusieurs fois par jour vers ftp-master.
2815 Avec une version assez récente de dput, cette section
2819 fqdn = gluck.debian.org
2822 dans votre fichier ~/.dput.cf devrait fonctionner correctement pour
2823 réaliser des envois dans la file DELAYED.
2826 <em>Note :</em> Comme la file d'envoi va sur <tt>ftp-master</tt>,
2827 la prescription que l'on trouve dans <ref id="upload-ftp-master">
2828 s'applique également ici.
2836 N'envoyez <strong>PAS</strong> un paquet vers la file d'envoi de sécurité
2837 (<em>oldstable-security</em>, <em>stable-security</em>, etc.) sans
2838 avoir obtenu au préalable l'autorisation de l'équipe de sécurité. Si
2839 le paquet ne correspond pas tout à fait aux besoins de cette équipe,
2840 il entraînera beaucoup de problèmes et de délais dans la gestion de
2841 cet envoi non désiré. Pour plus de détails, consultez la section <ref
2847 Les autres files d'envoi
2850 Les files scp sur ftp-master et security sont pratiquement
2851 inutilisables à cause des restrictions de connexion sur ces hôtes.
2854 Les files anonymes sur ftp.uni-erlangen.de et ftp.uk.debian.org sont
2855 actuellement arrêtées. Un travail est en cours pour les restaurer.
2858 Les files sur master.debian.org, samosa.debian.org,
2859 master.debian.or.jp et ftp.chiark.greenend.org.uk sont arrêtées de
2860 façon permanente et ne seront pas restaurées. La file du Japon sera
2861 remplacée par une nouvelle file sur hp.debian.or.jp un jour.
2864 À l'heure actuelle, la file en ftp anonyme sur auric.debian.org (le
2865 précédent ftp-master) fonctionne, mais elle est déconseillée et sera
2866 supprimée à un moment donné.
2869 <sect1 id="upload-notification">
2871 Notification de l'installation d'un nouveau paquet
2874 Les administrateurs de l'archive Debian sont responsables de
2875 l'installation des mises à jour. La plupart des mises à jour sont
2876 gérées quotidiennement par le logiciel de gestion de l'archive
2877 <prgn>katie</prgn>. Les mises à jour de paquets sur la distribution
2878 <em>unstable</em> sont installées ainsi. Dans les autres cas et
2879 notamment dans le cas d'un nouveau paquet, celui-ci sera installé
2880 manuellement. Il peut s'écouler jusqu'à un mois entre le
2881 téléchargement d'un paquet vers un serveur et son installation
2882 effective. Soyez patient.
2885 Dans tous les cas, vous recevrez un accusé de réception par courrier
2886 électronique indiquant que votre paquet a été installé et quels
2887 rapports de bogues ont été clos. Lisez attentivement ce courrier et
2888 vérifiez que tous les rapports de bogue que vous vouliez clore sont
2889 bien dans cette liste.
2892 L'accusé de réception indique aussi la section dans laquelle le paquet
2893 a été installé. S'il ne s'agit pas de votre choix, vous recevrez un
2894 second courrier qui vous informera de cette différence (voir
2898 Notez que si vous envoyez <em>via</em> les files, le logiciel de démon
2899 de file vous enverra également une notification par courriel.
2903 <sect id="override-file">
2905 Spécifier la section, la sous-section et la priorité d'un paquet
2908 Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
2909 <file>debian/control</file> n'indiquent ni où le paquet sera installé
2910 dans l'archive Debian, ni sa priorité. Afin de conserver la cohérence
2911 de l'archive, ce sont les administrateurs qui contrôlent ces
2912 champs. Les valeurs du fichier <file>debian/control</file> sont juste
2916 Les administrateurs de l'archive indiquent les sections et priorités
2917 des paquets dans le fichier <em>override</em>. Si ce fichier
2918 <em>override</em> et le fichier <file>debian/control</file> de votre
2919 paquet diffèrent, vous en serez informé par courrier électronique quand
2920 votre paquet sera installé dans l'archive. Vous pourrez corriger votre
2921 fichier <em>debian/control</em> avant votre prochain téléchargement ou
2922 alors vous pourrez vouloir modifier le fichier <em>override</em>.
2925 Pour modifier la section dans laquelle un paquet est archivé, vous
2926 devez d'abord vérifier que fichier <file>debian/control</file> est
2927 correct. Ensuite, envoyez un courrier à &email-override; ou un rapport
2928 de bogue sur le pseudo-paquet <package>ftp.debian.org</package>
2929 demandant la modification de la section ou de la priorité de votre
2930 paquet. Exposez bien les raisons qui vous amènent à demander ces
2934 Pour en savoir plus sur les <em>fichiers override</em>, reportez-vous à
2935 <manref section="1" name="dpkg-scanpackages"> et <url
2936 id="&url-bts-devel;#maintincorrect">.
2939 Notez que le champ <tt>Section</tt> décrit à la fois la section et la
2940 sous-section, comme décrit dans <ref id="archive-sections">. Si la
2941 section est « main », elle devrait être omise. La liste des
2942 sous-sections autorisées peut être trouvée dans <url
2943 id="&url-debian-policy;ch-archive.html#s-subsections">.
2946 <sect id="bug-handling">
2951 Chaque développeur doit être capable de travailler avec le <url
2952 id="&url-bts;" name="système de suivi des bogues"> Debian. Il faut
2953 savoir comment remplir des rapports de bogue correctement (voir <ref
2954 id="submit-bug">), comment les mettre à jour et les réordonner et
2955 comment les traiter et les fermer.
2958 Les fonctionnalités du système de suivi des bogues sont décrites dans
2959 la <url id="&url-bts-devel;" name="documentation du BTS pour les
2960 développeurs">. Ceci inclut la fermeture des bogues, l'envoi des
2961 messages de suivi, l'assignation des niveaux de gravité et des marques,
2962 l'indication que les bogues ont été envoyés au développeur amont et
2966 Des opérations comme réassigner des bogues à d'autres paquets, réunir
2967 des rapports de bogues séparés traitant du même problème ou rouvrir des
2968 bogues quand ils ont été prématurément fermés, sont gérées en utilisant
2969 le serveur de courrier de contrôle. Toutes les commandes disponibles
2970 pour ce serveur sont décrites dans la <url id="&url-bts-control;"
2971 name="documentation du serveur de contrôle du BTS">.
2973 <sect1 id="bug-monitoring">
2975 Superviser les rapports de bogue
2978 Si vous voulez être un bon responsable, consultez régulièrement la
2979 page du <url id="&url-bts;" name="système de suivi des bogues">. Cette
2980 page contient tous les rapports de bogue qui concernent vos
2981 paquets. Vous pouvez les vérifier avec cette page :
2982 <tt>http://&bugs-host;/<var>votre_compte</var>@debian.org</tt>.
2985 Les responsables interagissent avec le système de suivi des bogues en
2986 utilisant l'adresse électronique <tt>&bugs-host;</tt>. Vous trouverez
2987 une documentation sur les commandes disponibles à l'adresse <url
2988 id="&url-bts;"> ou, si vous avez installé le paquet
2989 <package>doc-debian</package>, dans les fichiers locaux
2993 Certains trouvent utile de recevoir régulièrement une synthèse des
2994 rapports de bogues ouverts. Si vous voulez recevoir une synthèse
2995 hebdomadaire relevant tous les rapports de bogue ouverts pour vos
2996 paquets, vous pouvez configurer <prgn>cron</prgn> comme suit :
2998 # Synthèse hebdomadaire des rapports de bogue qui me concernent
3001 Remplacez <var>address</var> par votre adresse officielle de
3005 <sect1 id="bug-answering">
3007 Répondre à des rapports de bogue
3010 Lorsque vous répondez à des rapports de bogue, assurez-vous que toutes
3011 vos discussions concernant les bogues sont envoyées au rapporteur du
3012 bogue et au bogue lui-même (<email>123@&bugs-host;</email> par
3013 exemple). Si vous rédigez un nouveau courrier et si vous ne vous
3014 souvenez plus de l'adresse du rapporteur de bogue, vous pouvez
3015 utiliser l'adresse <email>123-submitter@&bugs-host;</email> pour
3016 contacter le rapporteur <em>et</em> enregistrer votre courrier dans le
3017 journal du bogue (ce qui veut dire que vous n'avez pas besoin
3018 d'envoyer une copie du courrier à <email>123@&bugs-host;</email>).
3021 Si vous recevez un bogue mentionnant « FTBFS », cela veut
3022 dire « Fails To Build From Source » (Erreur de construction
3023 à partir du source). Les porteurs emploient fréquemment cet acronyme.
3026 Une fois que vous avez traité un rapport de bogue (i.e. que vous
3027 l'avez corrigé), marquez-le comme <em>done</em> (fermez-le) en
3028 envoyant un message d'explication à
3029 <email>123-done@&bugs-host;</email>. Si vous corrigez un bogue en
3030 changeant et en envoyant une nouvelle version du paquet, vous pouvez
3031 fermer le bogue automatiquement comme décrit dans <ref
3032 id="upload-bugfix">.
3035 Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant
3036 la commande <tt>close</tt> à l'adresse &email-bts-control;.Si vous le
3037 faites, le rapporteur n'aura aucune information sur la clôture de son
3041 <sect1 id="bug-housekeeping">
3043 Gestion générale des bogues
3046 En tant que responsable de paquet, vous trouverez fréquemment des
3047 bogues dans d'autres paquets ou vous aurez des bogues sur vos paquets
3048 qui sont en fait des bogues sur d'autres paquets. Les fonctions
3049 intéressantes du système de suivi des bogues sont décrites dans la
3050 <url id="&url-bts-devel;" name="documentation du BTS pour les
3051 développeurs Debian">. Les <url id="&url-bts-control;"
3052 name="instructions du serveur de contrôle du BTS"> documentent les
3053 opérations techniques du BTS, telles que comment remplir, réassigner,
3054 regrouper et marquer des bogues. Cette section contient des lignes
3055 directrices pour gérer vos propres bogues, définies à partir de
3056 l'expérience collective des développeurs Debian.
3059 Remplir des rapports de bogue pour des problèmes que vous trouvez dans
3060 d'autres paquet est l'une des « obligations civiques » du
3061 responsable, reportez-vous à <ref id="submit-bug"> pour les
3062 détails. Cependant, gérer les bogues de vos propres paquets est encore
3066 Voici une liste des étapes que vous pouvez suivre pour gérer un
3067 rapport de bogue :
3068 <enumlist numeration="arabic">
3071 Décider si le rapport correspond à un bogue réel ou non. Parfois,
3072 les utilisateurs exécutent simplement un programme de la mauvaise
3073 façon car ils n'ont pas lu la documentation. Si c'est votre
3074 diagnostic, fermez simplement le bogue avec assez d'informations
3075 pour laisser l'utilisateur corriger son problème (donnez des
3076 indications vers la bonne documentation et ainsi de suite). Si le
3077 rapport de bogue revient régulièrement, vous devriez vous demander
3078 si la documentation est assez bonne ou si le programme ne devrait
3079 pas détecter une mauvaise utilisation pour donner un message
3080 d'erreur informatif. Il s'agit d'un problème qui peut être discuté
3081 avec l'auteur amont.
3084 Si le rapporteur de bogue n'est pas d'accord avec votre décision de
3085 fermeture du bogue, il peut le ré-ouvrir jusqu'à ce que vous
3086 trouviez un accord sur la façon de le gérer. Si vous n'en trouvez
3087 pas, vous pouvez marquer le bogue avec <tt>wontfix</tt> pour
3088 indiquer aux personnes que le bogue existe, mais ne sera pas
3089 corrigé. Si cette situation n'est pas acceptable, vous (ou le
3090 rapporteur) pouvez vouloir demander une décision par le comité
3091 technique en réattribuant le bogue à <package>tech-ctte</package>
3092 (vous pouvez utiliser la commande <tt>clone</tt> du BTS si vous
3093 désirez garder le bogue comme rapporté sur votre paquet). Avant de
3094 faire cela, veuillez lire la <url id="&url-tech-ctte;"
3095 name="procédure recommandée">.
3100 Si le bogue est réel, mais est causé par un autre paquet,
3101 réattribuez simplement le bogue à l'autre paquet. Si vous ne savez
3102 pas à quel paquet il doit être réattribué, vous pouvez demander de
3103 l'aide sur <qref id="irc-channels">IRC</qref> ou sur
3104 &email-debian-devel;. Veuillez vous assurer que le (ou les)
3105 responsable(s) du paquet sur lequel est réattribué le paquet sait
3106 pourquoi vous l'avez ainsi réattribué.
3109 Parfois, vous devez également ajuster la gravité du bogue pour
3110 qu'elle corresponde à notre définition de gravité des bogues. C'est
3111 dû au fait que les gens tendent à augmenter la gravité des bogues
3112 pour s'assurer que leurs bogues seront corrigés rapidement. La
3113 gravité de certains bogues peut même être rétrogradée en
3114 <em>wishlist</em> (souhait) quand le changement demandé est
3115 seulement d'ordre cosmétique.
3120 Si le bogue est réel, mais que le problème a déjà été rapporté par
3121 quelqu'un d'autre, les deux rapports de bogues pertinents devraient
3122 être fusionnés en un seul en utilisant la commande <tt>merge</tt>
3123 (fusion) du BTS. Ainsi, quand le bogue sera corrigé, tous les
3124 créateurs de rapport de bogue en seront informés (notez, cependant,
3125 que les courriels envoyés à l'un des créateurs de rapport de bogue
3126 ne seront pas automatiquement envoyés aux autres créateurs de
3127 rapport de bogue). Pour plus de détails sur les technicités de la
3128 commande de fusion et sa voisine, la commande <tt>unmerge</tt>
3129 (séparation), veuillez consulter la documentation du serveur de
3135 Le rapporteur de bogue peut avoir oublié de fournir certaines
3136 informations. Dans ce cas, vous devez lui demander les informations
3137 nécessaires. Vous pouvez utiliser la marque <tt>moreinfo</tt> (plus
3138 d'information) sur le bogue. De plus, si vous ne pouvez pas
3139 reproduire le bogue, vous pouvez le marquer comme
3140 <tt>unreproducible</tt> (non reproductible). Une personne qui
3141 arriverait à reproduire le bogue est alors invitée à fournir plus
3142 d'informations sur la façon de le reproduire. Après quelques mois,
3143 si cette information n'a été envoyée par personne, le bogue peut
3149 Si le bogue est lié à l'empaquetage, vous devez simplement le
3150 corriger. Si vous ne pouvez pas le corriger vous-même, marquez
3151 alors le bogue avec <tt>help</tt> (aide). Vous pouvez également
3152 demander de l'aide sur &email-debian-devel; ou
3153 &email-debian-qa;. S'il s'agit d'un problème amont, vous devez
3154 faire suivre le rapport à l'auteur amont. Faire suivre un bogue
3155 n'est pas suffisant, vous devez vérifier à chaque version si le
3156 bogue a été corrigé ou non. S'il a été corrigé, vous le fermez
3157 simplement, sinon vous devez le rappeler à l'auteur. Si vous avez
3158 les compétences nécessaires, vous pouvez préparer un correctif pour
3159 corriger le bogue et l'envoyer en même temps à
3160 l'auteur. Assurez-vous d'envoyer le correctif au BTS et marquez le
3161 bogue avec <tt>patch</tt> (correctif).
3166 Si vous avez corrigé un bogue sur votre copie locale ou si un
3167 correctif a été inclus dans le référentiel CVS, vous pouvez marquer
3168 le bogue avec <tt>pending</tt> (en attente) pour informer que le
3169 bogue est corrigé et qu'il sera fermé lors du prochain envoi
3170 (ajoutez le <tt>closes:</tt> dans le <file>changelog</file>). C'est
3171 particulièrement utile si plusieurs développeurs travaillent sur le
3177 Une fois que le paquet corrigé est disponible dans la distribution
3178 <em>unstable</em>, vous pouvez fermer le bogue. Ceci peut être fait
3179 automatiquement, pour cela, reportez-vous à <ref
3180 id="upload-bugfix">.
3186 <sect1 id="upload-bugfix">
3188 Quand les rapports de bogue sont-ils fermés par une mise à jour ?
3191 Au fur et à mesure que les bogues et problèmes sont corrigés dans vos
3192 paquets, il est de votre responsabilité en tant que responsable du
3193 paquet de fermer les rapports de bogue associés. Cependant, vous ne
3194 devez pas les fermer avant que le paquet n'ait été accepté dans
3195 l'archive Debian. C'est pourquoi, vous pouvez et vous devez clore les
3196 rapports dans le système de suivi des bogues une fois que vous avez
3197 reçu l'avis indiquant que votre nouveau paquet a été installé dans
3198 l'archive. Le bogue devrait être fermé avec la bonne version.
3201 Cependant, il est possible d'éviter d'avoir à fermer manuellement les
3202 bogues après l'envoi — indiquez simplement les bogues corrigés
3203 dans le fichier <file>changelog</file> en suivant une syntaxe
3204 précise. Par exemple :
3206 acme-cannon (3.1415) unstable; urgency=low
3208 * Frobbed with options (closes: Bug#98339)
3209 * Added safety to prevent operator dismemberment, closes: bug#98765,
3211 * Added man page. Closes: #98725.
3213 Techniquement parlant, l'expression rationnelle Perl suivante décrit
3214 comment les lignes de <em>changelogs</em> de fermeture de bogues sont
3217 /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
3219 Nous préférons la syntaxe <tt>closes: #<var>XXX</var></tt>, car c'est
3220 l'entrée la plus concise et la plus facile à intégrer dans le texte du
3221 fichier <file>changelog</file>.
3224 À moins que cela soit spécifié différemment par l'option <var>-v</var> de
3225 <prgn>dpkg-buildpackage</prgn>, seuls les bogues fermés dans l'entrée de
3226 changelog la plus récente sont fermés (fondamentalement, seuls les
3227 bogues mentionnés dans la partie de changelog du fichier
3228 <file>.changes</file> sont fermés).
3231 <!-- les bogues des envois ... ? -->
3232 Historiquement, les envois identifiés comme <qref id="nmu">Mise à jour
3233 indépendante</qref> (« Non-maintainer upload » ou NMU) étaient
3234 marqués comme <tt>fixed</tt> au lieu d'être fermés, mais cette pratique
3235 a cassé avec l'ajout du suivi des versions. Le même raisonnement
3236 s'applique à l'étiquette <tt>fixed-in-experimental</tt>.
3239 Si vous entrez un numéro de bogue incorrect ou si vous oubliez un
3240 bogue dans les entrées du fichier <file>changelog</file>, n'hésitez
3241 pas à annuler tout dommage que l'erreur a entraîné. Pour rouvrir un
3242 bogue fermé par erreur, envoyez une commande <tt>reopen
3243 <var>XXX</var></tt> à l'adresse de contrôle du système de suivi des
3244 bogues, &email-bts-control;. Pour fermer tous les bogues restants qui
3245 ont été corrigés par votre envoi, envoyez le fichier
3246 <file>.changes</file> à <email>XXX-done@&bugs-host;</email> où
3247 <var>XXX</var> est le numéro du bogue et placez « Version:
3248 YYY » et une ligne vide dans les deux premières lignes du corps du
3249 courrier où <var>YYY</var> est la première version dans laquelle le
3250 bogue a été corrigé.
3253 Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en
3254 utilisant le <file>changelog</file> tel que décrit ci-dessus. Si vous
3255 désirez simplement fermer les bogues qui n'ont rien à voir avec l'un
3256 de vos envois, faites-le simplement en envoyant une explication à
3257 <email>XXX-done@&bugs-host;</email>. Vous <strong>ne devez
3258 pas</strong> pas fermer des bogues dans une entrée de changelog d'une
3259 version si les changements dans cette version n'ont rien à voir avec
3263 Pour une information plus générale sur ce qu'il faut mettre dans les
3264 entrées de changelog, veuillez vous reporter aux <ref
3265 id="bpp-debian-changelog">.
3268 <sect1 id="bug-security">
3270 Gérer les bogues de sécurité
3273 À cause de leur nature sensible, les bogues liés à la sécurité doivent
3274 être soigneusement traités. L'équipe de sécurité de Debian est là pour
3275 coordonner cette activité, pour faire le suivi des problèmes de
3276 sécurité en cours, pour aider les responsables ayant des problèmes de
3277 sécurité ou pour les corriger elle-même, pour envoyer les annonces de
3278 sécurité et pour maintenir le site security.debian.org.
3281 Si vous prenez connaissance d'un bogue lié à un problème de sécurité
3282 sur un paquet Debian, que vous soyez ou non le responsable, regroupez
3283 les informations pertinentes sur le problème et contactez rapidement
3284 l'équipe de sécurité à &email-security-team; dès que
3285 possible. <strong>N'ENVOYEZ PAS</strong> de paquet pour
3286 <em>stable</em> ; l'équipe de sécurité le fera. Les informations
3287 utiles incluent, par exemple :
3288 <list compact="compact">
3291 les versions du paquet connues pour être affectées par le
3292 bogue. Vérifiez chaque version présente dans les distributions
3293 maintenues par Debian ainsi que dans <em>testing</em> et dans
3299 la nature d'une solution si elle est disponible (les correctifs
3300 sont particulièrement utiles),
3305 tout paquet corrigé que vous avez vous-même préparé (envoyez
3306 seulement les fichiers <file>.diff.gz</file> et <file>.dsc</file>
3307 et lisez d'abord <ref id="bug-security-building">),
3312 toute assistance que vous pouvez fournir pour aider les tests
3313 (exploits, tests de régression, etc.),
3318 toute information nécessaire pour l'annonce de sécurité (voir <ref
3319 id="bug-security-advisories">).
3324 <sect2 id="bug-security-confidentiality">
3329 À la différence de la plupart des autres activités au sein de Debian,
3330 les informations sur les problèmes de sécurité doivent parfois être
3331 gardées en privé pour un certain temps. Ceci permet aux distributeurs
3332 de logiciels de coordonner leur dévoilement afin de minimiser
3333 l'exposition de leurs utilisateurs. Cette décision dépend de la
3334 nature du problème et de l'existence d'une solution correspondante et
3335 également s'il s'agit d'un fait connu publiquement.
3338 Il existe plusieurs façons pour un développeur de prendre
3339 connaissance d'un problème de sécurité :
3340 <list compact="compact">
3343 il le remarque sur un forum public (liste de diffusion, site web,
3349 quelqu'un remplit un rapport de bogue,
3354 quelqu'un l'informe par courrier privé.
3358 Dans les deux premiers cas, l'information est publique et il est
3359 important d'avoir une solution le plus vite possible. Dans le dernier
3360 cas, cependant, ce n'est peut-être pas une information publique. Dans
3361 ce cas, il existe quelques options possibles pour traiter le
3366 si l'exposition de sécurité est mineure, il n'y a parfois pas
3367 besoin de garder le secret sur le problème et une correction
3368 devrait être effectuée et diffusée,
3373 si le problème est grave, il est préférable de partager cette
3374 information avec d'autres vendeurs et de coordonner une
3375 publication. L'équipe de sécurité reste en contact avec les
3376 différentes organisations et individus et peut prendre soin des
3383 Dans tous les cas, si la personne qui indique le problème demande à
3384 ce que l'information ne soit pas diffusée, cela devrait être respecté
3385 avec l'évidente exception d'informer l'équipe de sécurité pour qu'une
3386 correction puisse être effectuée pour la version stable de
3387 Debian. Quand vous envoyez des informations confidentielles à
3388 l'équipe de sécurité, assurez-vous de bien mentionner ce fait.
3391 Veuillez noter que si le secret est nécessaire, vous ne pourrez pas
3392 envoyer un correctif vers <em>unstable</em> (ou ailleurs) puisque les
3393 informations de changelog et de diff sont publiques pour
3397 Il existe deux raisons pour diffuser l'information même si le secret
3398 est demandé : le problème est connu depuis un certain temps ou
3399 le problème ou son exploitation est devenu public.
3402 <sect2 id="bug-security-advisories">
3404 Annonces de sécurité
3407 Les annonces de sécurité ne sont émises que pour la distribution
3408 actuelle diffusée <em>stable</em>, <em>PAS</em> pour <em>testing</em>
3409 ou <em>unstable</em>. Quand elle est diffusée, l'annonce est envoyée
3410 à la liste de diffusion &email-debian-security-announce; et elle est
3411 postée sur <url id="&url-debian-security-advisories;" name="la page
3412 de sécurité">. Les annonces de sécurité sont écrites et postées par
3413 les membres de l'équipe de sécurité. Cependant, ils ne verront aucun
3414 inconvénient à ce qu'un responsable leur apporte des informations ou
3415 écrive une partie du texte. Les informations qui devraient être
3416 présentes dans une annonce incluent :
3417 <list compact="compact">
3420 une description du problème et de sa portée, y compris :
3424 le type du problème (usurpation de privilège, déni de service,
3430 quels sont les privilèges obtenus et par quels utilisateurs (si
3436 comment il peut être exploité,
3441 si le problème peut être exploité à distance ou localement,
3446 comment le problème a été corrigé,
3450 Ces informations permettent aux utilisateurs d'estimer la menace
3451 pesant sur leurs systèmes.
3456 les numéros de version des paquets affectés,
3461 les numéros de version des paquets corrigés,
3466 une information sur la façon de récupérer les paquets mis à jour
3467 (habituellement l'archive de sécurité Debian),
3472 des références à des annonces amont, des identifiants <url
3473 id="http://cve.mitre.org" name="CVE"> et toute autre information
3474 utile pour recouper les références de la vulnérabilité.
3480 <sect2 id="bug-security-building">
3482 Préparer les paquets pour corriger des problèmes de sécurité
3485 Une façon d'aider l'équipe de sécurité dans ses travaux est de lui
3486 fournir des paquets corrigés convenables pour une annonce de sécurité
3487 pour la version <em>stable</em> de Debian
3490 Quand une mise à jour de la version <em>stable</em> est effectuée, un
3491 soin particulier doit être apporté pour éviter de modifier le
3492 comportement du système ou d'introduire de nouveaux bogues. Pour
3493 cela, faites le moins de changements possibles pour corriger le
3494 bogue. Les utilisateurs et les administrateurs s'attendent à un
3495 comportement identique dans une version lorsque celle-ci est
3496 diffusée, donc tout changement qui est fait est susceptible de casser
3497 le système de quelqu'un. Ceci est spécialement vrai pour les
3498 bibliothèques : assurez-vous ne de jamais changer l'API ou
3499 l'ABI, aussi minimal que soit le changement.
3502 Cela veut dire que passer à une version amont supérieure n'est pas
3503 une bonne solution. À la place, les changements pertinents devraient
3504 être rétroportés vers la version présente dans la distribution
3505 <em>stable</em> de Debian. Habituellement, les développeurs amont
3506 veulent bien aider. Sinon, l'équipe de sécurité Debian peut le faire.
3509 Dans certains cas, il n'est pas possible de rétroporter un correctif
3510 de sécurité, par exemple, quand de grandes quantités de code source
3511 doivent être modifiées ou récrites. Si cela se produit, il peut être
3512 nécessaire de passer à une nouvelle version amont. Cependant, ceci
3513 n'est fait que dans des situations extrêmes et vous devez toujours
3514 coordonner cela avec l'équipe de sécurité au préalable.
3517 Il existe une autre règle de conduite liée à cela : testez
3518 toujours vos changements. Si une exploitation du problème existe,
3519 essayez-la et vérifiez qu'elle réussit sur le paquet non corrigé et
3520 échoue sur le paquet corrigé. Testez aussi les autres actions
3521 normales car parfois un correctif de sécurité peut casser de manière
3522 subtile des fonctionnalités qui ne semblent pas liées.
3525 N'incluez <strong>PAS</strong> de changements dans votre paquet qui
3526 ne soient pas liés directement à la correction de la
3527 vulnérabilité. Ceux-ci devraient être ensuite enlevés et cela perd du
3528 temps. S'il y a d'autres bogues dans votre paquet que vous aimeriez
3529 corriger, faites un envoi vers proposed-updates de la façon
3530 habituelle, après l'envoi de l'alerte de sécurité. Le mécanisme de
3531 mise à jour de sécurité n'est pas un moyen d'introduire des
3532 changements dans votre paquet qui seraient sinon rejetés de la
3533 distribution stable, n'essayez donc pas de faire cela, s'il vous
3537 Examinez et testez autant que possible vos changements. Vérifiez les
3538 différences avec la version précédente de manière répétée
3539 (<prgn>interdiff</prgn> du paquet <package>patchutils</package> et
3540 <prgn>debdiff</prgn> du paquet <package>devscripts</package> sont des
3541 outils utiles pour cela, voir <ref id="debdiff">).
3544 Assurez-vous de conserver les points suivants à l'esprit :
3548 Ciblez la bonne distribution dans votre fichier
3549 <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de
3550 <tt>stable-security</tt> et pour <em>testing</em>, c'est
3551 <tt>testing-security</tt> et pour l'ancienne distribution stable,
3552 c'est <tt>oldstable-security</tt>. Ne ciblez ni
3553 <var>distribution</var>-proposed-updates, ni
3554 <tt>stable</tt> !
3559 L'envoi devra avoir « urgency=high ».
3564 Fournissez des entrées de changelog descriptives et
3565 complètes. D'autres personnes se baseront dessus pour déterminer
3566 si un bogue particulier a été corrigé. Incluez toujours une
3567 référence externe, de préférence un identifiant CVE, pour qu'elle
3568 puisse être recoupée. Incluez la même information dans le
3569 changelog pour <em>unstable</em> pour qu'il soit clair que le même
3570 bogue a été corrigé car cela est très utile pour vérifier que le
3571 bogue a été corrigé pour la prochaine version stable. Si aucun
3572 identifiant CVE n'a encore été assigné, l'équipe de sécurité en
3573 demandera un pour qu'il puisse être inclus dans le paquet et dans
3579 Assurez-vous que le numéro de version est correct. Il doit être
3580 plus élevé que celui du paquet actuel, mais moins que ceux des
3581 paquets des versions des distributions suivantes. En cas de doute,
3582 testez-le avec <tt>dpkg --compare-versions</tt>. Soyez attentif à
3583 ne pas ré-utiliser un numéro de version que vous auriez déjà
3584 utilisé pour un précédent envoi. Pour <em>testing</em>, il doit y
3585 avoir un numéro de version supérieur dans <em>unstable</em>. S'il
3586 n'y en a pas encore (par exemple, si <em>testing</em> et
3587 <em>unstable</em> ont la même version), vous devez envoyer une
3588 nouvelle version vers <em>unstable</em> en premier.
3593 Ne faites pas d'envoi de source seul si votre paquet possède un ou
3594 plusieurs paquets binary-all (n'utilisez pas l'option <tt>-S</tt>
3595 de <prgn>dpkg-buildpackage</prgn>). L'infrastructure
3596 <prgn>buildd</prgn> ne construira pas ceux-ci. Ce point s'applique
3597 aux envois de paquets normaux également.
3602 Sauf si la source amont a été envoyée auparavant à
3603 security.debian.org (par une précédente mise à jour de sécurité),
3604 construisez le paquet avec la source amont complète
3605 (<tt>dpkg-buildpackage -sa</tt>). S'il y a déjà eu un précédent
3606 envoi à security.debian.org, vous pouvez faire un envoi sans le
3607 paquet source (<tt>dpkg-buildpackage -sd</tt>).
3612 Assurez-vous d'utiliser exactement le même nom
3613 <file>*.orig.tar.gz</file> que celui utilisé dans l'archive
3614 normale, sinon il ne sera pas possible de déplacer plus tard le
3615 correctif de sécurité dans l'archive principale.
3620 Compilez le paquet sur un système propre, dont tous les paquets
3621 appartiennent à la distribution pour laquelle vous construisez le
3622 paquet. Si vous n'avez pas un tel système, vous pouvez utiliser
3623 l'une des machines de debian.org (voir <ref id="server-machines">)
3624 ou mettez en place un chroot (voir <ref id="pbuilder"> et <ref
3631 <sect2 id="bug-security-upload">
3633 Mettre à jour le paquet corrigé
3636 Vous <em>NE</em> devez <em>PAS</em> envoyer un paquet dans la file
3637 d'attente des envois de sécurité (oldstable-security,
3638 stable-security, etc.) sans l'accord préalable de l'équipe de
3639 sécurité. Si le paquet ne remplit pas exactement les exigences de
3640 l'équipe, il causera beaucoup de problèmes, ainsi que des délais dans
3641 la gestion de l'envoi indésirable.
3644 Vous <em>NE</em> devez <em>PAS</em> envoyer votre correction dans
3645 <em>proposed-updates</em> sans vous coordonner avec l'équipe de
3646 sécurité. Les paquets seront copiés de security.debian.org dans le
3647 répertoire <file>proposed-updates</file> automatiquement. Si un
3648 paquet avec le même numéro de version ou un numéro plus grand est
3649 déjà installé dans l'archive, la mise à jour de sécurité sera rejetée
3650 par le système d'archive. Ainsi, la distribution <em>stable</em> se
3651 retrouvera à la place sans la mise à jour de sécurité de ce paquet.
3654 Une fois que vous avez créé et testé le nouveau paquet et qu'il a été
3655 approuvé par l'équipe de sécurité, il doit être envoyé pour être
3656 installé dans les archives. Pour les envois de sécurité, l'adresse
3658 <tt>ftp://security-master.debian.org/pub/SecurityUploadQueue/</tt>.
3661 Une fois que l'envoi vers la file d'attente de sécurité a été
3662 accepté, le paquet sera automatiquement recompilé pour toutes les
3663 architectures et stocké pour vérification par l'équipe de sécurité.
3666 Les envois en attente d'acceptation ou de vérification ne sont
3667 accessibles que par l'équipe de sécurité. C'est nécessaire car il
3668 pourrait y avoir des correctifs pour des problèmes de sécurité qui ne
3669 peuvent pas encore être diffusés.
3672 Si une personne de l'équipe de sécurité accepte un paquet, il sera
3673 installé sur security.debian.org et proposé pour le répertoire
3674 <var>distribution</var>-proposed-updates qui convient sur ftp-master.
3679 <sect id="archive-manip">
3681 Déplacer, effacer, changer le nom, adopter et abandonner des paquets
3684 Certaines manipulations de l'archive ne sont pas possibles avec le
3685 processus de mise à jour automatisé. Elles sont appliquées manuellement
3686 par les développeurs. Ce chapitre décrit ce qu'il faut faire dans ces
3689 <sect1 id="moving-pkgs">
3691 Déplacer des paquets
3694 Il se peut qu'un paquet puisse changer de section. Une nouvelle
3695 version d'un paquet de la section <tt>non-free</tt> pourrait, par
3696 exemple, être distribuée sous licence GNU GPL ; dans ce cas, le
3697 paquet doit être déplacé dans la section <tt>main</tt> ou
3698 <tt>contrib</tt><footnote><p>Reportez-vous à la <url
3699 id="&url-debian-policy;" name="charte Debian"> pour savoir dans quelle
3700 section un paquet doit être classé.</p></footnote>.
3703 Si vous avez besoin de modifier la section de l'un de vos paquets,
3704 modifiez les informations de contrôle du paquet pour le placer dans la
3705 section désirée et téléchargez à nouveau votre paquet dans
3706 l'archive. Reportez-vous à la <url id="&url-debian-policy;"
3707 name="charte Debian"> pour en savoir plus. Vous devez vous assurer
3708 d'inclure le fichier <file>.orig.tar.gz</file> dans votre envoi (même si
3709 vous n'envoyez pas de nouvelle version amon) ou il n'apparaîtra pas dans
3710 la nouvelle section avec le reste du paquet. Si votre nouvelle section
3711 est valide, il sera déplacé automatiquement. Si ce n'est pas le cas,
3712 contactez les responsables ftp pour comprendre ce qui s'est passé.
3715 Si vous avez besoin de modifier la sous-section de l'un de vos paquets
3716 (<tt>devel</tt> ou <tt>admin</tt> par exemple), la procédure est
3717 légèrement différente. Modifiez la sous-section dans le fichier de
3718 contrôle de votre paquet et téléchargez-le. Il vous faudra ensuite
3719 demander la modification du fichier <em>override</em> comme décrit
3720 dans la section <ref id="override-file">.
3723 <sect1 id="removing-pkgs">
3725 Supprimer des paquets
3728 Si, pour une raison ou une autre, vous avez besoin de supprimer
3729 complètement un paquet de l'archive (disons qu'il s'agit d'une vieille
3730 bibliothèque devenue inutile que l'on conservait pour des raisons de
3731 compatibilité), il vous faudra envoyer un rapport de bogue concernant
3732 le pseudo-paquet <tt>ftp.debian.org</tt> et demander sa
3733 suppression ; comme pour tous les bogues, ce bogue devrait être
3734 de gravité normale. N'oubliez pas de préciser de quelle distribution
3735 le paquet doit être supprimé. Normalement, vous ne devriez avoir à
3736 supprimer que des paquets d'<em>unstable</em> ou
3737 d'<em>experimental</em>. Les paquets de <em>testing</em> ne sont pas
3738 supprimés directement. Ils sont plutôt enlevés automatiquement après
3739 que le paquet a été supprimé d'<em>unstable</em> et si aucun paquet de
3740 <em>testing</em> n'en dépend.
3743 Il existe une exception pour laquelle il n'est pas nécessaire de faire
3744 une demande explicite de suppression : si un paquet (source ou
3745 binaire) est orphelin, il sera supprimé de façon semi-automatique. Pour
3746 un paquet binaire, cela veut dire s'il n'y a plus de paquet source
3747 produisant le paquet binaire ; si le paquet binaire n'est
3748 simplement plus produit pour certaines architectures, une demande de
3749 suppression est toujours nécessaire. Pour un paquet source, cela veut
3750 dire que tous les paquets binaires auxquels il se réfère ont été
3751 récupérés par un autre paquet source.
3754 Vous devez détailler dans votre demande de suppressions les raisons
3756 demande. Ceci a pour but d'éviter les suppressions non désirées et de
3757 garder une trace de la raison pour laquelle un paquet a été
3758 supprimé. Par exemple, vous pouvez fournir le nom du paquet qui
3759 remplace celui à supprimer.
3762 Vous ne pouvez demander la suppression d'un paquet que si vous en êtes
3763 le responsable. Si vous voulez supprimer un autre paquet, vous devez
3764 obtenir l'accord de son responsable.
3767 Si vous ne savez pas bien si un paquet peut être supprimé, demandez
3768 l'avis des autres développeurs sur la liste &email-debian-devel;. Le
3769 programme <prgn>apt-cache</prgn> du paquet <package>apt</package>
3770 pourra aussi vous être utile. La commande <tt>apt-cache showpkg
3771 <var>paquet</var> </tt> vous indiquera, entre autres, les paquets qui
3772 dépendent de <var>paquet</var>.
3773 Parmi d'autres programmes utiles, citons <tt>apt-cache rdepends</tt>,
3774 <prgn>apt-rdepends</prgn> et <prgn>grep-dctrl</prgn>.
3775 Le retrait de paquets orphelins est discuté sur &email-debian-qa;.
3778 Une fois que le paquet a été supprimé, les bogues du paquet doivent
3779 être gérés. Soit ils sont réattribués à un autre paquet dans le cas où
3780 le code actuel a évolué en un autre paquet (par exemple,
3781 <tt>libfoo12</tt> a été supprimé parce que <tt>libfoo13</tt> le
3782 remplace) ou ils sont fermés si le logiciel ne fait simplement plus
3787 Supprimer des paquets dans <tt>Incoming</tt>
3790 Par le passé, il était possible de supprimer un paquet de
3791 <file>Incoming</file>. Cependant, ce n'est plus possible depuis la
3792 mise en place du nouveau système de file d'attente. Il vous faudra
3793 télécharger une nouvelle version de votre paquet avec un numéro de
3794 version plus élevé que celui que vous voulez remplacer. Les deux
3795 versions seront installées dans l'archive mais seule la plus récente
3796 sera accessible dans <em>unstable</em> car la précédente sera
3797 immédiatement remplacée par la nouvelle. Toutefois, si vous testez
3798 correctement vos paquets, le besoin d'en remplacer un ne devrait pas
3805 Remplacer un paquet ou changer son nom
3808 Si vous vous trompez en nommant un paquet, vous devrez intervenir en
3809 deux étapes pour changer son nom. D'abord, modifiez votre fichier
3810 <file>debian/control</file> pour que votre nouveau paquet remplace et
3811 entre en conflit avec l'ancien paquet que vous voulez remplacer
3812 (reportez-vous à la <url id="&url-debian-policy;" name="charte
3813 Debian"> pour les détails). Une fois que votre paquet est installé
3814 dans l'archive, faites un rapport de bogue concernant le pseudo-paquet
3815 <tt>ftp.debian.org</tt> et demandez la suppression du paquet mal
3816 nommé. N'oubliez pas de réattribuer correctement les bogues du paquet
3820 D'autres fois, vous pouvez commettre une erreur en construisant le
3821 paquet et vous désirez le remplacer. La seule façon de faire est
3822 d'incrémenter le numéro de version et d'envoyer une nouvelle
3823 version. L'ancienne version expirera de la façon habituelle. Notez que
3824 ceci s'applique à chaque partie de votre paquet, y compris les
3825 sources : si vous désirez remplacer l'archive source amont de
3826 votre paquet, vous devez l'envoyer avec un numéro de version
3827 différent. Une possibilité simple est de remplacer
3828 <file>foo_1.00.orig.tar.gz</file> par
3829 <file>foo_1.00+0.orig.tar.gz</file>. Cette restriction donne à chaque
3830 fichier du site ftp un nom unique, ce qui aide à garantir la
3831 consistance dans le réseau des miroirs.
3834 <sect1 id="orphaning">
3836 Abandonner un paquet
3839 Si vous ne pouvez plus maintenir un paquet, vous devez en informer les
3840 autres et faire le nécessaire pour qu'il soit marqué
3841 <em>abandonné</em> (i.e. <em>orphaned</em>). Vous devriez aussi
3842 remplacer votre nom par <tt>Debian QA Group &orphan-address;</tt> dans
3843 le champ <tt>maintainer</tt> du paquet et faire un rapport de bogue
3844 sur le pseudo-paquet <package>wnpp</package>. Le titre de votre
3845 rapport de bogue devrait être
3846 « <tt>O<footnote><p><em>Orphaned</em> :
3847 abandonné.</p></footnote>: <var>paquet</var> — <var>courte
3848 description</var></tt> » pour indiquer que le paquet est
3849 abandonné. La gravité du bogue sera <em>normale</em> ; si le
3850 paquet a une priorité standard ou supérieure, elle devrait être
3851 <em>importante</em>. Si vous le jugez nécessaire, envoyez une copie à
3852 &email-debian-devel; en mettant cette adresse dans le champ
3853 X-Debbugs-CC: de l'en-tête du message. N'utilisez pas le champ CC: car
3854 de cette manière le sujet du message ne contiendra pas le numéro du
3858 Si vous avez simplement l'intention de donner le paquet, mais que vous
3859 pouvez conserver sa maintenance pour le moment, vous devriez à la
3860 place soumettre un rapport de bogue sur <package>wnpp</package> et
3861 l'intituler <tt>RFA: <var>paquet</var> -- <var>description
3862 courte</var></tt>. <tt>RFA</tt> veut dire <em>Request For
3863 Adoption</em> (demande d'adoption).
3866 Vous pouvez trouver plus d'informations sur les <url id="&url-wnpp;"
3867 name="pages web WNPP"><footnote><p><em>Work-needing and prospective
3868 packages</em> : paquets en souffrance et paquets
3869 souhaités.</p></footnote>.
3872 <sect1 id="adopting">
3877 Une liste des paquets en attente de nouveau responsable est disponible
3878 à la page <url id="&url-wnpp;" name="paquets en souffrance et paquets
3879 souhaités">. Si vous voulez prendre en charge un paquet de cette
3880 liste, reportez-vous à la page mentionnée ci-dessus pour connaître la
3884 Prendre un paquet parce qu'il vous semble que celui-ci est négligé
3885 n'est pas correct — ce serait un détournement de
3886 paquet. Vous pouvez prendre contact avec le responsable actuel et lui
3887 demander si vous pouvez prendre en charge ce paquet. Si vous avez le
3888 sentiment qu'un responsable est parti sans prévenir depuis un moment,
3889 veuillez vous reporter à <ref id="mia-qa">).
3892 Généralement, vous ne pouvez pas adopter un paquet sans l'accord du
3893 responsable actuel. Même s'il vous ignore, ce n'est pas une raison
3894 pour le faire. Les plaintes à propos des responsables devraient être
3895 portées sur la liste de diffusion des développeurs. Si la discussion
3896 ne se termine pas par une conclusion positive et que le problème est
3897 de nature technique, envisagez de porter le cas à l'attention du
3898 comité technique (voir la <url id="&url-tech-ctte;" name="page web du
3899 comité technique"> pour plus d'information).
3902 Si vous reprenez un vieux paquet, vous voudrez sûrement que le système
3903 de suivi des bogues indique que vous êtes le responsable du
3904 paquet. Cela se produira automatiquement une fois que vous aurez
3905 installé une nouvelle version du paquet dans l'archive avec le champ
3906 <tt>Maintainer</tt> à jour. Cela peut prendre quelques heures après le
3907 téléchargement. Si vous pensez ne pas avoir de mise à jour à faire
3908 pour un moment, vous pouvez utiliser le <ref id="pkg-tracking-system">
3909 pour recevoir les rapports de bogue. Cependant, assurez-vous que cela
3910 ne pose aucun problème à l'ancien responsable de continuer à recevoir
3911 les bogues durant ce temps.
3920 Debian accepte un nombre croissant d'architectures. Même si vous n'êtes
3921 pas un porteur et même si vous n'utilisez qu'une architecture, il est
3922 de votre responsabilité de développeur d'être attentif aux questions de
3923 portabilité. C'est pourquoi il est important que vous lisiez ce
3924 chapitre même si vous n'êtes pas un porteur.
3927 Porter un paquet consiste à faire un paquet binaire pour des
3928 architectures différentes de celle du paquet binaire fait par le
3929 responsable du paquet. C'est une activité remarquable et
3930 essentielle. En fait, les porteurs sont à l'origine de la plupart des
3931 compilations de paquets Debian. Pour un paquet binaire <em>i386</em>,
3932 par exemple, il faut compter une recompilation pour chaque autre
3933 architecture, soit un total de &number-of-arches; recompilations.
3935 <sect1 id="kind-to-porters">
3937 Être courtois avec les porteurs
3940 Les porteurs ont une tâche remarquable et difficile car ils doivent
3941 gérer un grand nombre de paquets. Idéalement, tout paquet source
3942 devrait compiler sans modification. Malheureusement, c'est rarement le
3943 cas. Cette section contient une liste d'erreurs commises régulièrement
3944 par les responsables Debian — problèmes courants qui bloquent
3945 souvent les porteurs et compliquent inutilement leur travail.
3948 Ici, la première et la plus importante chose est de répondre
3949 rapidement aux rapports de bogues et remarques soulevées par les
3950 porteurs. Traitez-les courtoisement, comme s'ils étaient
3951 co-responsables de vos paquets (ce qu'ils sont d'une certaine
3952 manière). Merci pour votre indulgence envers des rapports de bogue
3953 succincts ou peu clairs ; faites de votre mieux pour éliminer le
3957 Les problèmes les plus couramment rencontrés par les porteurs sont
3958 causés par des erreurs de mise en paquet dans le paquet source. Voici
3959 un pense-bête pour les choses auxquelles vous devez être
3961 <enumlist numeration="arabic">
3964 Vérifiez que les champs <tt>Build-Depends</tt> et
3965 <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file>
3966 sont corrects. Le meilleur moyen de le vérifier est d'utiliser le
3967 paquet <package>debootstrap</package> pour créer un environnement
3968 <em>unstable</em> <em>chrooté</em> (voir <ref
3969 id="debootstrap">). Dans cet environnement <em>chrooté</em>, il
3970 faudra installer le paquet <package>build-essential</package> et
3971 tous les paquets mentionnés dans les champs <tt>Build-Depends</tt>
3972 et <tt>Build-Depends-Indep</tt>. Ensuite, vous essayerez de
3973 fabriquer votre paquet dans cet environnement. Ces étapes peuvent
3974 être automatisées en utilisant le programme <prgn>pbuilder</prgn>
3975 qui est fourni par le paquet de même nom (voir <ref
3979 Si vous n'arrivez pas à installer un environnement
3980 <em>chrooté</em>, <prgn>dpkg-depcheck</prgn> pourra peut-être vous
3981 aider (voir <ref id="dpkg-depcheck">).
3984 Consultez la <url id="&url-debian-policy;" name="charte Debian">
3985 pour en savoir plus sur les dépendances de fabrication.
3990 Ne choisissez pas d'autres valeurs que <em>all</em> ou <em>any</em>
3991 pour le champ architecture sans avoir de bonnes raisons pour le
3992 faire. Trop souvent, les développeurs ne respectent pas les
3993 instructions de la <url id="&url-debian-policy;" name="charte
3994 Debian">. Choisir la valeur « i386 » est la plupart du
4000 Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
4001 <var>paquet</var>.dsc</tt> pour vous assurer que le paquet se
4002 décompresse correctement. En utilisant le résultat de ce test,
4003 construisez votre paquet binaire à l'aide de la commande
4004 <prgn>dpkg-buildpackage</prgn>.
4009 Vérifiez que les fichiers <file>debian/files</file> et
4010 <file>debian/substvars</file> ne sont pas dans votre paquet
4011 source. Ils doivent être effacés par la cible <em>clean</em> de
4012 <file>debian/rules</file>.
4017 Assurez-vous que vous ne vous appuyez pas sur des éléments de
4018 configuration ou des logiciels installés ou modifiés
4019 localement. Par exemple, vous ne devriez jamais appeler des
4020 programmes du répertoire <file>/usr/local/bin</file> ou de
4021 répertoires équivalents. Essayez de ne pas vous appuyer sur des
4022 logiciels configurés de manière spéciale. Essayez de construire
4023 votre paquet sur une autre machine, même s'il s'agit de la même
4029 Ne vous appuyez pas sur une installation préexistante de votre
4030 paquet (un sous-cas de la remarque précédente).
4035 Si possible, ne vous appuyez pas sur une particularité présente
4036 dans un compilateur précis ou dans une certaine version d'un
4037 compilateur. Si vous ne pouvez pas faire autrement, assurez-vous
4038 que les dépendances de fabrication reflètent bien cette
4039 restriction. Dans ce cas, vous cherchez sûrement les problèmes car
4040 quelques architectures pourraient choisir un compilateur différent.
4045 Vérifiez que votre fichier <file>debian/rules</file> distingue les
4046 cibles <em>binary-arch</em> et <em>binary-indep</em> comme l'exige
4047 la charte Debian. Vérifiez que ces cibles sont indépendantes l'une
4048 de l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer
4049 l'une de ces cibles avant d'invoquer l'autre. Pour vérifier cela,
4050 essayez d'exécuter <tt>dpkg-buildpackage -B</tt>.
4056 <sect1 id="porter-guidelines">
4058 Instructions pour les mises à jour des porteurs
4061 Si le paquet se construit tel quel sur l'architecture que vous visez,
4062 vous avez de la chance et votre travail est facile. Cette section
4063 s'applique dans ce cas ; elle décrit comment construire et
4064 installer correctement votre paquet binaire dans l'archive Debian. Si
4065 vous devez modifier le paquet pour le rendre compilable sur votre
4066 architecture cible vous devez faire une mise à jour des sources,
4067 consultez la section <ref id="nmu-guidelines">.
4070 Pour un envoi de portage, ne faites pas de changement dans les
4071 sources. Vous n'avez pas besoin de modifier les fichiers du paquet
4072 source (cela inclut le fichier <file>debian/changelog</file>).
4075 La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la
4076 suivante : <tt>dpkg-buildpackage -B
4077 -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
4078 <var>adresse-porteur</var> par votre adresse électronique. Cette
4079 commande construira les parties du paquet qui dépendent de
4080 l'architecture, en utilisant la cible <em>binary-arch</em> de
4081 <file>debian/rules</file>.
4084 Si vous travaillez sur une machine Debian pour vos efforts de portage
4085 et que vous devez signer votre envoi localement pour son acceptation
4086 dans l'archive, vous pouvez exécuter <prgn>debsign</prgn> sur votre
4087 fichier <file>.changes</file> pour qu'il soit signé de manière commode
4088 ou utilisez le mode de signature à distance de <prgn>dpkg-sig</prgn>.
4090 <sect2 id="binary-only-nmu">
4092 Mises à jour indépendantes binaires ou recompilations
4095 Parfois, l'envoi du portage initial pose problème car l'environnement
4096 dans lequel le paquet a été construit n'était pas bon (bibliothèques
4097 plus à jour ou obsolètes, mauvais compilateur, etc.). Il se peut que
4098 vous ayez à le recompiler dans un environnement mis à
4099 jour. Cependant, dans ce cas, vous devez changer le numéro de version
4100 pour que les mauvais anciens paquets soient remplacés dans l'archive
4101 Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
4102 s'ils n'ont pas un numéro de version supérieur à celui actuellement
4106 Vous devez vous assurer que votre mise à jour indépendante binaire ne
4107 rend pas le paquet non installable. Cela peut arriver si un paquet
4108 source génère des paquets dépendants et indépendants de
4109 l'architecture qui dépendent les uns des autres <em>via</em>
4113 Malgré les modifications nécessaires du changelog, ce type de mise à
4114 jour reste une mise à jour indépendante binaire — il n'est
4115 pas nécessaire de reconsidérer le statut des paquets binaires des
4116 autres architectures pour les marquer périmés ou à recompiler.
4119 Ces recompilations nécessitent des numéros de version
4120 « magiques » pour que le système de maintenance de
4121 l'archive comprenne que, bien qu'il y ait une nouvelle version, il
4122 n'y a pas eu de modification des sources. Si vous ne faites pas cela
4123 correctement, les administrateurs de l'archive rejetteront votre mise
4124 à jour (car il n'y aura pas de code source associé).
4127 La « magie » d'une mise à jour indépendante par
4128 recompilation uniquement est déclenchée par l'utilisation d'un
4129 suffixe ajouté au numéro de version du paquet de la forme
4130 b<numéro>. Par exemple, si la dernière version que vous avez
4131 recompilée était la version 2.9.3, votre mise à jour indépendante
4132 aura le numéro de version 2.9-3+b1. Si la dernière version était
4133 3.4+b1 (i.e. un paquet natif avec une précédente mise à jour
4134 indépendante par recompilation), votre mise à jour indépendant aura
4135 le numéro de version 3.4+b2. <footnote><p>Par le passé, de telles
4136 mises à jour indépendantes utilisaient le numéro de troisième niveau
4137 de la partie Debian de la révision pour dénoter l'état de
4138 recompilation uniquement ; cependant, cette syntaxe était
4139 ambigüe pour les paquets natifs et ne permettait pas un ordre correct
4140 des mises à jour indépendantes par recompilation uniquement, des
4141 mises à jour indépendantes de source et des mises à jour
4142 indépendantes de sécurité sur le même paquet et elle a donc été
4143 abandonnée en faveur de cette nouvelle syntaxe.</p></footnote>
4146 De manière similaire aux envois du porteur initial, la façon correcte
4147 d'invoquer <prgn>dpkg-buildpackage</prgn> est <tt>dpkg-buildpackage
4148 -B</tt> pour ne construire que les parties dépendant de
4149 l'architecture du paquet.
4152 <sect2 id="source-nmu-when-porter">
4154 Quand faire une mise à jour indépendante source pour un
4158 Les porteurs qui font des mises à jour indépendantes sources suivent
4159 généralement les instructions de la section <ref id="nmu"> tout comme
4160 les non-porteurs. Les délais d'attente sont cependant plus courts car
4161 les porteurs doivent manipuler un grand nombre de paquets. À nouveau,
4162 la situation diffère selon la distribution visée. Elle varie
4163 également selon que l'architecture est candidate pour inclusion dans
4164 la prochaine version stable ; les responsables de publication
4165 décident et annoncent quelles architectures sont candidates.
4168 Si vous êtes porteur et faites une mise à jour pour
4169 <em>unstable</em>, les instructions précédentes sont applicables à
4170 deux différences près. Tout d'abord, le temps d'attente raisonnable
4171 — délai entre le moment où vous envoyez un rapport au
4172 système de suivi des bogues et le moment où vous pouvez faire une
4173 mise à jour indépendante <em>(NMU)</em> — est de sept
4174 jours. Ce délai peut être raccourci si le problème est crucial et met
4175 l'effort de portage en difficulté : c'est à la discrétion de l'équipe
4176 de portage. (Souvenez-vous, il ne s'agit pas d'un règlement, mais de
4177 recommandations communément acceptées). Pour les envois de
4178 <em>stable</em> ou <em>testing</em>, veuillez tout d'abord vous
4179 coordonner avec l'équipe de publication appropriée.
4182 Deuxième différence, les porteurs qui font des mises à jour
4183 indépendantes sources doivent choisir une gravité <em>sérieuse</em>
4184 (i.e. <em>serious</em>) ou supérieure quand ils envoient leur rapport
4185 au système de suivi des bogues. Ceci assure qu'un paquet source
4186 unique permet de produire un paquet binaire pour chaque architecture
4187 supportée au moment de la sortie de la distribution. Il est très
4188 important d'avoir un paquet source et un paquet binaire pour toutes
4189 les architectures pour être conforme à plusieurs licences.
4192 Les porteurs doivent éviter d'implémenter des contournements pour des
4193 bogues de l'environnement de compilation, du noyau ou de la
4194 libc. Quelques fois, ces contournements sont inévitables. Si vous
4195 devez faire quelque chose de ce genre, marquez proprement vos
4196 modifications avec des <tt>#ifdef</tt> et documentez votre
4197 contournement pour que l'on sache le retirer une fois que le problème
4201 Les porteurs peuvent aussi avoir une adresse où ils publient le
4202 résultat de leur travail pendant le délai d'attente. Ainsi, d'autres
4203 personnes peuvent bénéficier du travail du porteur même pendant ce
4204 délai. Bien sûr, ces adresses n'ont rien d'officiel, alors soyez sur
4205 vos gardes si vous les utilisez.
4209 <sect1 id="porter-automation">
4211 Infrastructure de portage et automatisation
4214 Il existe une infrastructure et plusieurs outils pour faciliter
4215 l'automatisation du portage des paquets. Cette section contient un
4216 bref aperçu de cette automatisation et du portage de ces outils ;
4217 veuillez vous reporter à la documentation des paquets ou les
4218 références pour une information complète.
4222 Listes de diffusion et pages web
4225 Les pages web contenant l'état de chaque portage peuvent être
4226 trouvées à <url id="&url-debian-ports;">.
4229 Chaque portage de Debian possède sa propre liste de diffusion. La
4230 liste des listes de diffusion de portage peut être trouvée à <url
4231 id="&url-debian-port-lists;">. Ces listes sont utilisées pour
4232 coordonner les porteurs et pour mettre en relation les utilisateurs
4233 d'un portage donné avec les porteurs.
4238 Outils pour les porteurs
4241 Les descriptions de plusieurs outils de portage peuvent être trouvées
4242 dans les <ref id="tools-porting">.
4247 <package>buildd</package>
4250 Le système <package>buildd</package> est un système distribué pour la
4251 compilation d'une distribution. Il est habituellement utilisé en
4252 conjonction avec des automates de compilation ; ce sont des
4253 machines « esclaves » qui récupèrent des paquets sources et
4254 tentent de les compiler. Il est aussi possible d'interagir par
4255 courrier électronique avec ce système. Cette interface est utilisée
4256 par les porteurs pour récupérer un paquet source (en général, un
4257 paquet qui ne peut être compilé automatiquement) et travailler
4261 <package>buildd</package> n'est pas disponible sous forme de
4262 paquet ; pourtant, la plupart des équipes de porteurs
4263 l'utilisent aujourd'hui ou ont prévu de l'utiliser bientôt. L'outil
4264 de construction automatisé réel est dans le paquet
4265 <package>sbuild</package>, voir la description dans <ref
4266 id="sbuild">. Le système <package>buildd</package> regroupe également
4267 un ensemble de composants très utiles, continuellement utilisés, mais
4268 non encore mis en paquet, tels que <prgn>andrea</prgn> et
4269 <prgn>wanna-build</prgn>.
4272 Une partie des informations produites par <package>buildd</package>
4273 — utiles pour les porteurs — est disponible sur
4274 la toile à l'adresse <url id="&url-buildd;">. Ces informations
4275 incluent les résultats produits toutes les nuits par
4276 <prgn>andrea</prgn> (dépendances des sources) et
4277 <prgn>quinn-diff</prgn> (paquets à recompiler).
4280 Nous sommes très fiers de ce système car il a de nombreux usages
4281 potentiels. Des groupes de développeurs indépendants peuvent utiliser
4282 ce système pour créer différentes saveurs de Debian — qui
4283 peuvent être ou ne pas être intéressantes pour tous (par exemple, une
4284 version de Debian compilée avec des vérifications relatives à
4285 <prgn>gcc</prgn>). Ce système nous permettra aussi de recompiler
4286 rapidement toute une distribution.
4289 Les administrateurs des buildds pour chaque architecture peuvent être
4290 contactés à l'adresse électronique $arch@buildd.debian.org.
4294 <sect1 id="packages-arch-specific">
4296 Quand votre paquet <em>n'est pas</em> portable
4299 Certains paquets ont encore des problèmes pour être construits et/ou
4300 pour fonctionner sur certaines des architectures prises en charge par
4301 Debian et ne peuvent pas du tout être portés, ou pas dans un laps de
4302 temps raisonnable. Un exemple est un paquet qui est spécifique SGVA
4303 (i386 seulement) ou qui utilise des fonctionnalités spécifiques au
4304 matériel qui ne sont pas gérées sur toutes les architectures.
4307 Pour éviter que des paquets cassés soient envoyés dans l'archive et
4308 qu'ils fassent perdre du temps des buildd, vous devez faire plusieurs
4315 Tout d'abord, assurez-vous que votre paquet <em>échoue</em> à la
4316 compilation sur les architectures qu'il ne gère pas. Il y a
4317 plusieurs moyens de faire cela. Le moyen préféré est d'avoir une
4318 petite suite de tests pendant la construction qui testera la
4319 fonctionnalité et qui échouera si cela ne fonctionne pas. C'est de
4320 toute façon une bonne idée et empêchera des (certains) envois
4321 cassés pour toutes les architectures, et cela permettra également
4322 au paquet d'être construit dès que la fonctionnalité nécessaire est
4326 De plus, si vous croyez que la liste des architectures gérées est
4327 plutôt constante, vous devriez changer « any » en une
4328 liste des architectures gérées dans le fichier
4329 <file>debian/control</file>. Ainsi, la construction échouera
4330 également et l'indiquera à un lecteur humain sans vraiment essayer.
4335 Pour empêcher les compilateurs automatiques de tenter sans raison
4336 de construire votre paquet, il doit être inclus dans
4337 <file>packages-arch-specific</file>, une liste utilisée par le
4338 script <prgn>wanna-build</prgn>. La version actuelle est disponible
4340 id="http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak"> ;
4341 veuillez consulter le début du fichier pour savoir qui contacter
4348 Veuillez noter qu'il est insuffisant de simplement ajouter votre
4349 paquet à Packages-arch-specific sans le faire également échouer lors
4350 de compilation sur les architectures non gérées : un porteur ou
4351 toute autre personne essayant de construire votre paquet peut
4352 accidentellement l'envoyer sans remarquer qu'il ne fonctionne pas. Si
4353 dans le passé, certains paquets binaires ont été envoyés pour des
4354 architectures non gérées, demandez leur suppression en remplissant un
4355 bogue sur <package>ftp.debian.org</package>.
4361 Mise à jour indépendante
4364 Dans certaines circonstances, il est nécessaire qu'une personne autre
4365 que le responsable d'un paquet fasse une mise à jour de ce paquet. Ce
4366 type de mise à jour est désigné en anglais par l'expression
4367 <em>non-maintainer upload (NMU)</em>. Dans le présent document, nous
4368 traduisons librement cette expression par « mise à jour
4369 indépendante ».
4372 Cette section ne traite que des mises à jour indépendantes de source,
4373 c.-à-d., les mises à jour qui envoient une nouvelle version d'un
4374 paquet. Pour les mises à jour indépendantes par des porteurs ou des
4375 membres de la QA, veuillez consulter <ref id="binary-only-nmu">. Si un
4376 buildd construit et envoie un paquet, cela est également à strictement
4377 parler une NMU binaire. Veuillez consulter <ref id="buildd"> pour plus
4381 La raison principale pour laquelle une mise à jour indépendante est
4382 réalisée est quand un développeur a besoin de corriger le paquet d'un
4383 autre développeur pour résoudre des problèmes sérieux ou des bogues
4384 paralysants ou quand le responsable d'un paquet ne peut pas fournir une
4385 correction dans un délai raisonnable.
4388 Tout d'abord, il est capital que ces mises à jour indépendantes soient
4389 aussi peu intrusives que possible. Ne faites pas de ménage, ne modifiez
4390 pas le nom des modules ou des fichiers, ne déplacez pas les
4391 répertoires ; plus généralement, ne corrigez pas ce qui n'est pas
4392 cassé. Faites un correctif aussi petit que possible. Si certaines
4393 choses froissent votre sens de l'esthétique, parlez-en au responsable
4394 du paquet, au responsable amont ou soumettez un rapport de
4395 bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
4396 pas</em> être effectués lors d'une mise à jour indépendante.
4399 Et souvenez-vous du Serment d'Hippocrate « Par dessus tout,
4400 ne pas faire de mal ». Il est préférable de laisser un paquet avec
4401 un bogue ouvert grave plutôt qu'appliquer un correctif non fonctionnel
4402 ou un correctif qui cache le bogue sans le résoudre.
4404 <sect1 id="nmu-guidelines">
4406 Comment faire une mise à jour indépendante ?
4409 Les mises à jour indépendantes qui corrigent des bogues de gravité
4410 importante, sérieuse et plus élevée sont encouragées et
4411 acceptées. Vous devriez vous efforcer de contacter le responsable
4412 actuel du paquet : il est peut-être sur le point d'envoyer un
4413 correctif pour le problème ou il a peut-être une meilleure solution.
4416 Les mises à jour indépendantes doivent être réalisées pour assister un
4417 responsable de paquet à résoudre des bogues. Les responsables
4418 devraient être reconnaissants pour cette aide et les personnes faisant
4419 la mise à jour indépendante devraient respecter les décisions du
4420 responsable et tenter d'aider personnellement le responsable dans son
4424 Une mise à jour indépendante devrait suivre toutes les conventions
4425 décrites dans cette section. Pour un envoi vers <em>testing</em> ou
4426 <em>unstable</em>, l'ordre suivant des étapes est recommandé :
4432 Vérifiez que les bogues du paquet qui devraient être corrigés par
4433 la mise à jour indépendante sont bien référencés dans le système de
4434 suivi des bogues. S'ils n'y sont pas, faites des rapports de bogue
4440 Attendez la réponse du responsable quelques jours. Si vous
4441 n'obtenez aucune réponse, vous pouvez l'aider en lui envoyant le
4442 correctif qui corrige le bogue. N'oubliez pas de marquer le bogue
4443 avec le mot-clé « patch ».
4448 Patientez quelques jours. Si vous n'avez toujours aucune réponse du
4449 responsable, envoyez-lui un courrier annonçant votre intention
4450 d'effectuer une mise à jour indépendante du paquet. Préparez la NMU
4451 comme décrit dans cette section et testez-la soigneusement sur
4452 votre machine (cf. <ref id="sanitycheck">). Re-vérifiez que votre
4453 correctif n'a aucun effet de bord inattendu. Assurez-vous que votre
4454 correctif est aussi minimaliste et non intrusif que possible.
4459 Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file>
4460 (cf. <ref id="delayed-incoming">), envoyez le correctif final au
4461 responsable par le BTS et expliquez-lui qu'il a 7 jours pour réagir
4462 s'il veut annuler la NMU.
4467 Suivez ce qui se passe, vous êtes responsable pour tout bogue que
4468 vous auriez introduit avec votre NMU. Vous devriez probablement
4469 utiliser le <ref id="pkg-tracking-system"> (PTS) pour vous tenir
4470 informé de l'état du paquet après votre NMU.
4476 Parfois, le responsable de version ou un groupe organisé de
4477 développeurs peut annoncer une certaine période de temps au cours de
4478 laquelle les règles de mise à jour indépendante seront plus
4479 souples. Ceci implique habituellement une période plus courte
4480 d'attente avant d'envoyer des correctifs et une période de délai plus
4481 courte. Il est important de noter que, même au cours de ces
4482 « chasses aux bogues », la personne désirant faire la mise à
4483 jour indépendante doit remplir des bogues et contacter en premier le
4484 développeur, et ensuite seulement passer à l'action. Veuillez vous
4485 reporter à <ref id="qa-bsp"> pour des détails.
4488 Pour la distribution <em>testing</em>, les règles peuvent être
4489 changées par les responsables de publication. Veuillez porter une
4490 attention spéciale au fait que le moyen habituel pour un paquet
4491 d'entrer dans <em>testing</em> est de passer par <em>unstable</em>.
4494 Pour la distribution <em>stable</em>, veuillez y apporter une
4495 attention supplémentaire. Bien sûr, les responsables de publication
4496 peuvent également modifier les règles ici. Veuillez vérifier avant
4497 votre envoi que tous vos changements sont acceptables pour inclusion
4498 dans la prochaine version stable par le responsable de publication.
4501 Quand un bogue de sécurité est détecté, l'équipe de sécurité peut
4502 effectuer une mise à jour indépendante en utilisant ses propres
4503 règles. Veuillez vous référer à <ref id="bug-security"> pour plus
4507 Pour les différences concernant les mises à jour indépendantes par les
4508 porteurs, veuillez voir <ref id="source-nmu-when-porter">.
4511 Bien sûr, il est toujours possible de s'accorder avec un responsable
4512 pour des règles spéciales (comme quand le responsable demande
4513 « merci d'envoyer le correctif directement pour moi et pas de
4514 diff nécessaire »).
4517 <sect1 id="nmu-version">
4519 Numéro de version pour les mises à jour indépendantes
4522 Chaque fois que vous modifiez un paquet, le numéro de version de ce
4523 paquet doit changer, même pour la plus triviale des
4524 modifications. Notre système de gestion de paquets s'appuie sur ces
4528 Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez
4529 ajouter un numéro de version mineur à la partie
4530 <var>révision-debian</var> du numéro de version (la partie qui suit le
4531 dernier trait d'union). Ce numéro supplémentaire débutera à
4532 « 1 ». Prenons pour exemple le paquet « foo » qui
4533 porte le numéro de version 1.1-3. Dans l'archive, le fichier de
4534 contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
4535 version amont est « 1.1 » et la révision Debian est
4536 « 3 ». La mise à jour indépendante suivante ajouterait le
4537 numéro de version mineur « .1 » au numéro de révision
4538 Debian ; le nouveau fichier de contrôle du paquet source serait
4539 alors <file>foo_1.1-3.1.dsc</file>.
4542 Le numéro de révision mineur est nécessaire pour éviter de prendre un
4543 numéro de version au responsable officiel du paquet, ce qui pourrait
4544 perturber son travail. Cela a aussi l'avantage de montrer clairement
4545 que le paquet n'a pas été livré par le responsable officiel.
4548 S'il n'y a pas de partie <var>révision-debian</var> dans le numéro de
4549 version du paquet, il faut en créer une en démarrant à
4550 « 0.1 ». S'il est absolument nécessaire qu'une personne qui
4551 n'est pas responsable d'un paquet fasse une livraison basée sur une
4552 nouvelle version amont, cette personne doit choisir « 0.1 »
4553 comme numéro de révision Debian. Le responsable du paquet doit, lui,
4554 démarrer sa numérotation à « 1 ».
4557 Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>,
4558 vous devrez parfois créer une branche (« fork ») dans
4559 l'arbre de numéro des version. Pour cela, vous pouvez utiliser des
4560 numéros de version comme 1.1-3sarge0.1.
4563 <sect1 id="nmu-changelog">
4565 Les mises à jour indépendantes sources doivent être mentionnées dans
4566 le fichier changelog
4569 Une personne qui fait une mise à jour indépendante source doit ajouter
4570 une entrée dans le fichier <file>changelog</file> qui indique les
4571 bogues corrigés et qui précise pourquoi cette mise à jour était
4572 nécessaire. Cette entrée comportera l'adresse de la personne ayant
4573 fait l'envoi ainsi que la version livrée.
4576 Par convention, dans le cas d'une mise à jour indépendante source
4577 <em>(NMU)</em>, l'entrée du fichier changelog débute par la
4580 * Non-maintainer upload
4584 <sect1 id="nmu-patch">
4586 Mise à jour indépendante source et système de suivi des bogues
4589 Un développeur qui n'est pas responsable d'un paquet doit faire aussi
4590 peu de modifications que possible et doit toujours envoyer ses
4591 modifications au système de suivi des bogues au format diff unifié
4595 Et si vous recompilez simplement le paquet ? Si vous avez
4596 simplement besoin de recompiler le paquet pour une seule architecture,
4597 vous pouvez faire une NMU binaire seulement comme décrit dans <ref
4598 id="binary-only-nmu"> qui ne nécessite pas qu'un correctif soit
4599 envoyé. Si vous désirez que le paquet soit recompilé pour toutes les
4600 architectures, vous devez alors faire une NMU source et vous devrez
4601 envoyer un correctif.
4604 Si la mise à jour indépendante source (<em>source NMU</em>) corrige
4605 des bogues, ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans
4606 le système de suivi des bogues plutôt que clos. Par convention, seul
4607 le responsable du paquet et la personne qui a ouvert le rapport de
4608 bogue ferment les rapports. Heureusement, le système d'archivage
4609 Debian reconnaît les mises à jours indépendantes et positionne
4610 correctement le statut des bogues à <em>fixed</em> si la personne qui
4611 fait la mise à jour a listé tous les bogues dans le fichier changelog
4612 en utilisant la syntaxe <tt>Closes: bug#<var>nnnnn</var></tt> (voir
4613 <ref id="upload-bugfix"> pour en savoir plus sur la fermeture de bogue
4614 par le fichier <file>changelog</file>). Ce passage au statut
4615 <em>fixed</em> assure que chacun sait que le bogue est corrigé par une
4616 mise à jour indépendante tout en laissant le rapport de bogue ouvert
4617 jusqu'à ce que le responsable du paquet incorpore les modifications de
4618 cette mise à jour dans la version officielle du paquet.
4621 Après avoir fait une mise à jour indépendante, il vous faudra aussi
4622 envoyer l'information aux bogues existants que vous avez corrigés
4623 par votre NMU en incluant le diff unifié. Historiquement, c'était une
4624 habitude de créer un
4625 nouveau rapport de bogue et inclure un correctif comprenant toutes les
4626 modifications que vous avez réalisées. Le responsable officiel pourra
4627 choisir d'appliquer le correctif, il pourra aussi employer une autre
4628 méthode pour régler le problème. Certains bogues sont corrigés dans la
4629 version amont, ce qui est une bonne raison pour annuler les
4630 modifications d'une mise à jour indépendante. Si le responsable
4631 choisit de mettre à jour le paquet plutôt que d'utiliser les
4632 correctifs de la mise à jour indépendante, il devra s'assurer que
4633 cette nouvelle version corrige effectivement chacun des bogues
4634 corrigés dans la mise à jour indépendante.
4637 De plus, le responsable officiel devrait <em>toujours</em> conserver
4638 les entrées documentant une mise à jour indépendante dans le fichier
4639 <file>changelog</file> — et bien sûr, également conserver les
4640 modifications. Si vous annulez certaines des modifications, veuillez
4641 réouvrir les rapports de bogue correspondants.
4644 <sect1 id="nmu-build">
4646 Fabriquer une mise à jour indépendante source
4649 Les paquets faisant l'objet d'une mise à jour indépendante source sont
4650 construits comme les autres. Sélectionnez une distribution en
4651 utilisant les règles décrites dans la section <ref id="distribution">
4652 en suivant toutes les instructions de la section <ref id="upload">.
4655 Vérifiez que vous n'avez pas modifié la valeur du champ
4656 <tt>maintainer</tt> dans le fichier <file>debian/control</file>. Votre
4657 nom, mentionné dans l'entrée du fichier <file>debian/changelog</file>
4658 concernant la mise à jour, sera utilisé pour signer le fichier
4659 <file>.changes</file>.
4662 <sect1 id="ack-nmu">
4664 Valider une mise à jour indépendante
4667 Si l'un de vos paquets a subi une mise à jour indépendante, vous devez
4668 récupérer les changements dans votre copie des sources. Ceci est aisé,
4669 vous avez simplement à appliquer le correctif qui vous a été
4670 envoyé. Une fois ceci fait, vous devez fermer les bogues qui ont été
4671 marqués comme fixés par la mise à jour. Le moyen le plus simple est
4672 d'utiliser l'option <tt>-v</tt> de <prgn>dpkg-buildpackage</prgn> car
4673 cela vous permet d'inclure tous les changements depuis votre dernier
4674 envoi de responsable. Sinon, vous pouvez soit les fermer manuellement
4675 en envoyant les courriers nécessaires au BTS soit ajouter les
4676 <tt>closes: #nnnn</tt> nécessaires dans l'entrée du changelog de votre
4680 Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une
4681 NMU n'est pas une attaque personnelle contre le responsable. C'est une
4682 preuve que le paquet est important pour quelqu'un et qu'il est
4683 désireux de vous aider dans votre travail, vous devriez donc lui être
4684 reconnaissant. Vous pouvez également lui demander s'il serait
4685 intéressé pour vous aider sur une base plus régulière comme
4686 co-responsable ou responsable de secours (cf. <ref
4687 id="collaborative-maint">).
4690 <sect1 id="nmu-vs-qa">
4692 Mise à jour indépendante ou envoi de QA ?
4695 Sauf si vous savez que le responsable est toujours actif, il est sage
4696 de vérifier le paquet pour voir s'il n'a pas été abandonné. La liste
4697 actuelle des paquets orphelins pour lesquels le champ responsable n'a
4698 pas été positionné correctement est disponible à <url
4699 id="&url-debian-qa-orphaned;">. Si vous effectuez une mise à jour
4700 indépendante sur un paquet incorrectement orphelin, veuillez
4701 positionner le responsable à « Debian QA Group
4702 <packages@qa.debian.org> ».
4705 <sect1 id="nmu-who">
4707 Qui peut faire une mise à jour indépendante ?
4710 Seuls les responsables Debian officiels peuvent faire des mises à jour
4711 indépendantes binaire ou source. Un responsable officiel est une
4712 personne dont la clé est dans le porte-clés Debian. Tout autre
4713 personne est toutefois invitée à télécharger les paquets sources pour
4714 corriger des bogues ; au lieu de faire des mises à jour
4715 indépendantes, ils pourront soumettre les correctifs qui le méritent
4716 au système de suivi des bogues. Les responsables apprécient presque
4717 toujours les correctifs et les rapports de bogue soignés.
4720 <sect1 id="nmu-terms">
4725 Deux nouvelles expressions sont introduites dans cette section :
4726 « mise à jour indépendante source » et « mise à jour
4727 indépendante binaire ». Ces deux expressions ont une
4728 signification technique précise dans ce document. Elles correspondent
4729 toutes deux au même type d'activité ; elles impliquent toutes
4730 deux qu'une personne fait une mise à jour d'un paquet alors qu'elle
4731 n'est pas officiellement responsable de ce paquet. C'est pourquoi nous
4732 qualifions ces mises à jours
4733 d'<em>indépendantes</em><footnote><p>Contrairement à ce que pourrait
4734 laisser entendre cette traduction de <em>non-maintainer upload</em>,
4735 il n'est pas question d'agir sans prévenir le responsable au préalable
4736 (voir <ref id="nmu-guidelines">).</p></footnote>.
4739 Une mise à jour indépendante source est une livraison de paquet faite
4740 par une personne qui n'est pas le responsable officiel de ce paquet
4741 avec pour objectif de corriger un bogue dans le paquet. Une mise à
4742 jour indépendante source implique toujours une modification des
4743 sources du paquet, même s'il ne s'agit que d'un changement dans le
4744 fichier <file>debian/changelog</file>. Ce changement peut tout aussi
4745 bien concerner la partie amont du source que la partie spécifique à
4746 Debian. Une mise à jour indépendante source peut aussi inclure des
4747 paquets spécifiques à une architecture tout comme un fichier
4748 <em>diff</em> modifié.
4751 Une mise à jour indépendante binaire est constituée par la
4752 recompilation et l'archivage d'un paquet pour une architecture
4753 donnée. Il s'agit souvent du résultat d'un effort de portage. Une mise
4754 à jour indépendante binaire est la livraison d'un paquet compilé
4755 (souvent pour une autre architecture) à condition que cette
4756 compilation n'ait pas nécessité de modifications des sources. Dans de
4757 nombreux cas, les porteurs sont obligés de modifier les sources pour
4758 les rendre compilables sur leur architecture cible ; il s'agira
4759 alors d'une mise à jour indépendante source et non d'une mise à jour
4760 indépendante binaire. Comme vous pouvez le remarquer, nous ne faisons
4761 pas de distinction entre les mises à jour indépendantes faites par des
4762 porteurs et les autres mises à jour indépendantes.
4765 Les mises à jour indépendantes sources et binaires sont toutes deux
4766 couvertes par l'expression « mise à jour indépendante »
4767 (NMU<footnote><p>Non-maintainer upload</p></footnote>). Pourtant, cela
4768 conduit souvent à des confusions car beaucoup associent « mise à
4769 jour indépendante » et « mise à jour indépendante
4770 source ». Il faut donc rester vigilant : utilisez toujours
4771 « mise à jour indépendante binaire » ou «NMU binaire »
4772 pour les mises à jour indépendantes de binaires seuls.
4776 <sect id="collaborative-maint">
4778 Maintenance collective
4781 « Maintenance collective » est un terme décrivant le partage
4782 des devoirs de la maintenance d'un paquet Debian par plusieurs
4783 personnes. Cette collaboration est presque toujours une bonne idée car
4784 il en résulte généralement une meilleure qualité et un temps de
4785 correction de bogues plus petit. Il est fortement recommandé que les
4786 paquets de priorité <tt>Standard</tt> ou qui font partie de la base
4787 aient des co-responsables.
4790 Habituellement, il y a un responsable principal et un ou plusieurs
4791 co-responsables. Le responsable principal est la personne dont le nom
4792 est indiqué dans le champ <tt>Maintainer</tt> du fichier
4793 <file>debian/control</file>. Les co-responsables sont tous les autres
4797 Dans sa forme la plus simple, ajouter un nouveau co-responsable est
4802 Donner au co-responsable un accès aux sources à partir desquelles
4803 vous construisez le paquet. Habituellement, cela implique que vous
4804 utilisiez un système de contrôle de version comme <prgn>CVS</prgn>
4805 ou <prgn>Subversion</prgn>.
4810 Ajouter les nom et adresse correctes du co-responsable au champ
4811 <tt>Uploaders</tt> dans la partie globale du fichier
4812 <file>debian/control</file>.
4814 Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
4820 En utilisant le PTS (<ref id="pkg-tracking-system">), les
4821 co-responsables devraient s'inscrire eux-mêmes aux paquets sources
4828 La maintenance collective peut souvent être facilitée par l'utilisation
4829 d'outils sur Alioth (voir <ref id="alioth">).
4834 La distribution <em>testing</em>
4838 <sect1 id="testing-basics">
4843 Les paquets sont habituellement installés dans la distribution
4844 <em>testing</em> après avoir atteint un certain degré de test dans
4848 Ils doivent être en synchronisation pour toutes les architectures et
4849 ne doivent pas avoir de dépendances qui les rendraient non
4850 installables ; ils doivent également n'avoir aucun bogue bloquant
4851 l'inclusion du paquet dans une version stable
4852 (« release-critical ») au moment où ils sont installés dans
4853 <em>testing</em>. Ainsi, <em>testing</em> devrait toujours être prête
4854 pour être une version candidate stable. Veuillez voir ci-dessous pour
4858 <sect1 id="testing-unstable">
4860 Mises à jour depuis <em>unstable</em>
4863 Les scripts qui mettent à jour la distribution <em>testing</em> sont
4864 exécutés chaque jour après l'installation des paquets mis à
4865 jour ; ces scripts sont appelés <em>britney</em>. Ils fabriquent
4866 les fichiers <file>Packages</file> pour la distribution
4867 <em>testing</em>, mais ils le font d'une manière intelligente pour
4868 éviter toute incohérence et essayer de n'utiliser que des paquets sans
4872 L'inclusion d'un paquet d'<em>unstable</em> est soumise aux conditions
4877 Le paquet doit avoir été disponible dans <em>unstable</em> depuis
4878 2, 5 ou 10 jours selon le champ d'urgence de l'envoi (élevée,
4879 moyenne ou basse). Veuillez noter que cette urgence est
4880 « collante » (« sticky »), ce qui veut dire que
4881 l'envoi avec l'urgence la plus élevée depuis la précédente
4882 transition dans <em>testing</em> est prise en compte. Ces délais
4883 peuvent être doublés lors d'un gel de distribution, ou les
4884 transitions dans <em>testing</em> peuvent être complètement
4890 Il doit avoir autant ou moins de bogues empêchant l'intégration
4891 dans la distribution que la version actuellement disponible dans
4892 <em>testing</em> ;
4897 Il doit être disponible pour toutes les architectures pour
4898 lesquelles il a été auparavant construit. <ref id="madison"> peut
4899 être intéressant pour vérifier cette information ;
4904 Il ne doit pas casser les dépendances d'un paquet qui est déjà
4905 disponible dans <em>testing</em> ;
4910 Les paquets dont il dépend doivent soit être déjà disponibles dans
4911 <em>testing</em> soit être acceptés dans <em>testing</em> au même
4912 moment (et ils doivent remplir tous les critères nécessaires).
4918 Pour savoir si un paquet a progressé ou non dans <em>testing</em>,
4919 veuillez voir la sortie du script de <em>testing</em> sur la <url
4920 id="&url-testing-maint;" name="page web de la distribution testing">
4921 ou utilisez le programme <prgn>grep-excuses</prgn> inclus dans le
4922 paquet <package>devscripts</package>. Si vous voulez rester informé de
4923 la progression de vos paquets dans <em>testing</em>, vous pouvez
4924 facilement le mettre dans la <manref section="5" name="crontab">.
4927 Le fichier <file>update_excuses</file> ne donne pas toujours la raison
4928 précise pour laquelle un paquet est refusé ; on peut avoir à la
4929 chercher soi-même en regardant ce qui serait cassé avec l'inclusion du
4930 paquet. La <url id="&url-testing-maint;" name="page web de la
4931 distribution testing"> donne plus d'informations à propos des
4932 problèmes courants qui peuvent occasionner cela.
4935 Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce
4936 que le jeu des inter-relations est trop compliqué et ne peut être
4937 résolu par le script. Voir ci-dessous pour des détails.
4940 Des analyses de dépendances plus avancées sont présentées sur <url
4941 id="http://bjorn.haxx.se/debian/"> — mais, attention, cette page
4942 affiche également les dépendances de construction qui ne sont pas
4943 considérées par britney.
4945 <sect2 id="outdated">
4950 Pour le script de migration dans <em>testing</em>,
4951 « désynchronisé » (<em>outdated</em> veut dire ceci :
4952 il y a différentes versions dans <em>unstable</em> pour les
4953 architectures de version (à l'exception des architectures dans
4954 fuckedarches ; fuckedarches est une liste des architectures qui
4955 ne suivent pas le rythme (dans update_out.py), mais actuellement
4956 cette liste est vide). « Désynchronisé » n'a rien à voir
4957 avec les architectures que le paquet fournit pour <em>testing</em>.
4960 Considérons cet exemple :
4965 ---------+-------+----
4971 Le paquet est désynchronisé pour alpha dans <em>unstable</em> et
4972 n'entrera pas dans <em>testing</em>. Supprimer foo de
4973 <em>testing</em> n'aiderait en rien, le paquet serait toujours
4974 désynchronisé pour alpha et ne se propagerait pas dans
4978 Cependant, si ftp-master supprime un paquet d'<em>unstable</em> (ici
4983 foo | alpha | arm | hurd-i386
4984 ---------+-------+-----+----------
4986 unstable | 2 | - | 1
4990 Dans ce cas, le paquet est synchronisé pour toutes les architectures
4991 de version dans <em>unstable</em> (et l'architecture supplémentaire
4992 hurd-i386 ne compte pas car ce n'est pas une architecture de
4996 Quelquefois, la question est soulevée pour savoir s'il est possible
4997 de permettre à des paquets de passer dans <em>testing</em> qui ne
4998 sont pas encore construits pour toutes les architectures :
4999 non. Simplement non. (Excepté si vous êtes responsable de glibc ou
5003 <sect2 id="removals">
5005 Suppressions de <em>testing</em>
5008 Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre
5009 paquet : ceci ne se produit que pour permettre à un
5010 <em>autre</em> paquet d'entrer, ce dernier doit être prêt pour tous
5011 les autres critères. Considérons, par exemple, qu'un paquet
5012 <em>a</em> ne peut pas être installé avec la nouvelle version de
5013 <em>b</em> alors <em>a</em> peut être supprimé pour permettre
5014 l'entrée de <em>b</em>.
5017 Bien sûr, il existe une autre raison pour supprimer un paquet de
5018 <em>testing</em> : le paquet est trop bogué (et avoir un seul
5019 bogue RC est suffisant pour être dans cet état).
5022 De plus, si un paquet a été supprimé d'<em>unstable</em> et qu'aucun
5023 paquet de <em>testing</em> n'en dépend plus, il sera alors
5024 automatiquement supprimé.
5028 <sect2 id="circular">
5030 Dépendances circulaires
5033 Une situation qui n'est pas très bien gérée par britney est si un
5034 paquet <em>a</em> dépend de la nouvelle version d'un paquet
5035 <em>b</em> et vice versa.
5038 Voici un exemple :
5042 | testing | unstable
5043 --+-----------------+------------
5044 a | 1; dépend: b=1 | 2; dépend: b=2
5045 b | 1; dépend: a=1 | 2; dépend: a=2
5049 Aucun des paquets <em>a</em> et <em>b</em> ne sera considéré pour
5053 Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de
5054 publication. Veuillez les contacter en envoyant un courrier
5055 électronique à debian-release@lists.debian.org si cela se produit
5056 pour l'un de vos paquets.
5061 Influence d'un paquet dans <em>testing</em>
5064 Généralement, l'état d'un paquet dans <em>testing</em> ne change rien
5065 pour la transition de la prochaine version d'<em>unstable</em> vers
5066 <em>testing</em>, avec deux exceptions : si le nombre de bogues
5067 RC du paquet est réduit, le paquet peut migrer même s'il a encore des
5068 bogues RC. La seconde exception est que si la version du paquet dans
5069 <em>testing</em> est désynchronisée entre les différentes
5070 architectures, alors toute architecture peut être mise à jour vers la
5071 version du paquet source ; cependant, cela ne peut se produire
5072 que si le paquet a été précédemment forcé, si l'architecture est dans
5073 fuckedarches ou s'il n'y avait pas du tout de paquet binaire de cette
5074 architecture présent dans <em>unstable</em> lors de la migration dans
5078 En résumé, cela veut dire : la seule influence qu'un paquet de
5079 <em>testing</em> a sur la nouvelle version du même paquet est que la
5080 nouvelle version peut rentrer plus facilement.
5083 <sect2 id="details">
5088 Si vous êtes intéressé par les détails, voici comment fonctionne
5092 Les paquets sont examinés pour savoir si ce sont des candidats
5093 valides. Cela donne le fichier « update excuses ». Les
5094 raisons les plus communes pour lesquelles un paquet n'est pas
5095 considéré sont la jeunesse du paquet, le nombre de bogues RC et la
5096 désynchronisation pour certaines architectures. Pour cette partie de britney,
5097 les responsables de version ont des marteaux de toute taille pour
5098 forcer britney à considérer un paquet. (Le gel de la base est
5099 également codé dans cette partie de britney.) (Il y a une chose
5100 semblable pour les mises à jour binaires pures, mais cela n'est pas
5101 décrit ici. Si vous êtes intéressé par cela, veuillez étudier
5102 attentivement le code.)
5105 Maintenant, la partie la plus complexe se produit : britney
5106 tente de mettre à jour <em>testing</em> avec des candidats
5107 valides ; en premier, chaque paquet individuellement, puis des
5108 groupes de plus en plus larges de paquets ensemble. Chaque tentative
5109 est acceptée si <em>testing</em> n'est pas moins non installable
5110 après la mise à jour qu'avant celle-ci. (Avant et après cette partie,
5111 certains coups de pouce (« hints ») sont traités ;
5112 mais, comme seuls les responsables de version peuvent positionner des
5113 coups de pouce, cela n'est probablement pas très important pour
5117 Si vous voulez voir plus de détails, vous pouvez le voir dans
5118 merkel:/org/ftp.debian.org/testing/update_out/ (ou dans
5119 ~aba/testing/update_out pour voir une configuration avec un fichier
5120 de paquets plus petit). Par le web, c'est à <url
5121 id="http://ftp-master.debian.org/testing/update_out_code/">.
5124 Les coups de pouce sont visibles sur <url
5125 id="http://ftp-master.debian.org/testing/hints/">.
5131 Mises à jour directes dans <em>testing</em>
5134 La distribution <em>testing</em> est peuplée avec des paquets en
5135 provenance d'<em>unstable</em> selon des règles expliquées
5136 ci-dessus. Cependant, dans certains cas, il est nécessaire d'envoyer
5137 des paquets construits seulement pour <em>testing</em>. Pour cela,
5138 vous pouvez envoyer vos paquets vers
5139 <em>testing-proposed-updates</em>.
5142 Souvenez-vous que les paquets envoyés là ne sont pas traités
5143 automatiquement, ils doivent passer entre les mains du responsable de
5144 distribution. Vous devez donc avoir une bonne raison pour les y
5145 envoyer. Pour savoir ce que représente une bonne raison aux yeux des
5146 responsables de distribution, vous devriez lire les instructions
5147 données qu'ils envoient régulièrement sur
5148 &email-debian-devel-announce;.
5151 Vous ne devriez pas envoyer un paquet à
5152 <em>testing-proposed-updates</em> quand vous pouvez le mettre à jour
5153 par <em>unstable</em>. Si vous ne pouvez faire autrement (par exemple,
5154 parce que vous avez une nouvelle version de développement dans
5155 <em>unstable</em>), vous pouvez utiliser cette facilité, mais il est
5156 recommandé de demander l'autorisation du responsable de distribution
5157 auparavant. Même si un paquet est gelé, des mises à jour par
5158 <em>unstable</em> sont possibles si l'envoi dans <em>unstable</em> ne
5159 tire pas de nouvelles dépendances.
5162 Les numéros de version sont habituellement choisis en ajoutant le nom
5163 de code de la distribution <em>testing</em> et un numéro incrémenté,
5164 comme 1.2sarge1 pour le premier envoi dans
5165 <em>testing-proposed-updates</em> du paquet en version 1.2.
5168 Veuillez vous assurer que vous n'oubliez aucun des éléments suivants
5169 lors de votre envoi :
5173 vérifiez que votre paquet doit vraiment aller dans
5174 <em>testing-proposed-updates</em> et ne peut pas passer par
5175 <em>unstable</em> ;
5180 vérifiez que vous n'incluez que le minimum de changements ;
5185 vérifiez que vous incluez une explication appropriée dans le
5191 vérifiez que vous avez bien indiqué <em>testing</em> ou
5192 <em>testing-proposed-updates</em> comme votre distribution
5198 vérifiez que vous avez construit et testé votre paquet dans
5199 <em>testing</em> et non dans <em>unstable</em> ;
5204 vérifiez que votre numéro de version est plus élevé que les
5205 versions de <em>testing</em> et de
5206 <em>testing-proposed-updates</em> et moins élevé que celle de
5207 <em>unstable</em> ;
5212 après l'envoi et la construction réussie sur toutes les
5213 plates-formes, contactez l'équipe de publication à
5214 &email-debian-release; et demandez-leur d'approuver votre envoi.
5222 Questions fréquemment posées
5228 Quels sont les bogues bloquant l'intégration dans la version stable
5229 et comment sont-ils comptés ?
5232 Tous les bogues de gravité assez élevée sont par défaut considérés
5233 comme bloquant l'intégration du paquet dans la version stable ;
5234 actuellement, ce sont les bogues critiques, graves et sérieux.
5237 Certains bogues sont supposés avoir un impact sur les chances que le
5238 paquet a d'être diffusé dans la version stable de Debian : en
5239 général, si un paquet a des bogues bloquants, il n'ira pas dans
5240 <em>testing</em> et par conséquent, ne pourra pas être diffusé dans
5244 Le compte des bogues d'<em>unstable</em> est effectué avec tous les
5245 bogues bloquants sans étiquette de version (comme <em>potato</em>,
5246 <em>woody</em>) ou avec une étiquette <em>sid</em> et également s'ils
5247 ne sont ni corrigés ou marqués avec <em>sarge-ignore</em>. Le compte
5248 des bogues de <em>testing</em> pour un paquet est considéré comme à
5249 peu près le nombre de bogues d'<em>unstable</em> lors du dernier
5250 pointage quand la version <em>testing</em> a été égale à la version
5254 Cela changera après la sortie de <em>Sarge</em> dès que nous aurons
5255 des versions dans le système de suivi des bogues.
5260 Comment est-ce que l'installation d'un paquet dans <em>testing</em>
5261 peut casser d'autres paquets ?
5264 La structure des archives de la distribution est faite de telle façon
5265 qu'elles ne peuvent contenir qu'une version d'un paquet ; un
5266 paquet est défini par son nom. Donc, quand le paquet source acmefoo
5267 est installé dans <em>testing</em> avec ses paquets binaires
5268 acme-foo-bin, acme-bar-bin, libacme-foo1 et libacme-foo-dev,
5269 l'ancienne version est supprimée.
5272 Cependant, l'ancienne version pouvait fournir à un paquet binaire un
5273 vieux soname d'une bibliothèque, comme libacme-foo0. Supprimer
5274 l'ancien acmefoo va supprimer libacme-foo0, ce qui va casser tout
5275 paquet qui en dépend.
5278 Évidemment, cela touche principalement des paquets qui fournissent
5279 des jeux changeant de paquets binaires dans différentes versions (par
5280 suite, principalement des bibliothèques). Cependant, cela va aussi
5281 toucher des paquets sur lesquels une dépendance versionnée a été
5282 déclarée du type ==, <= ou <<.
5285 Quand le jeu de paquets binaires fournis par un paquet source change
5286 de cette façon, tous les paquets qui dépendent des anciens binaires
5287 doivent être mis à jour pour dépendre de la nouvelle version à la
5288 place. Comme l'installation d'un tel paquet source dans
5289 <em>testing</em> casse tous les paquets qui en dépendent dans
5290 <em>testing</em>, une certaine attention doit y être portée :
5291 tous les paquets en dépendant doivent être mis à jour et prêts à être
5292 installés eux-même pour qu'ils ne cassent pas et, une fois que tout
5293 est prêt, une intervention manuelle du responsable de version ou d'un
5294 de ses assistants est normalement requise.
5297 Si vous avez des problèmes avec des groupes compliqués de paquets
5298 comme ceci, contactez debian-devel ou debian-release en demandant de
5305 <chapt id="best-pkging-practices">
5307 Les meilleurs pratiques pour la construction des paquets
5310 La qualité de Debian est principalement due à la <url
5311 id="&url-debian-policy;" name="charte Debian"> qui définit explicitement
5312 les obligations que tous les paquets doivent suivre. Mais c'est
5313 également grâce à une histoire partagée d'expériences qui va au-delà de
5314 la charte Debian, une accumulation d'années d'expérience pour la
5315 construction des paquets ; des développeurs de grand talent ont
5316 créé de bons outils qui vous aideront, vous, responsable Debian, à créer
5317 et maintenir d'excellents paquets.
5320 Ce chapitre fournit les meilleurs pratiques pour les développeurs
5321 Debian. Ce ne sont que des recommandations, non pas des obligations ou
5322 des règles. Ce sont seulement des astuces et conseils subjectifs et des
5323 liens collectés pour les développeurs Debian. Prenez et choisissez ce
5324 qui vous convient le mieux.
5326 <sect id="bpp-debian-rules">
5328 Les meilleures pratiques pour le fichier <file>debian/rules</file>
5331 Les recommandations suivantes s'appliquent au fichier
5332 <file>debian/rules</file>. Comme ce fichier contrôle le processus de
5333 compilation et qu'il sélectionne les fichiers inclus dans le paquet
5334 (directement ou indirectement), il s'agit habituellement du fichier sur
5335 lequel les responsables passent le plus de temps.
5337 <sect1 id="helper-scripts">
5342 La raison sous-jacente à l'utilisation des scripts d'aide dans le
5343 fichier <file>debian/rules</file> est que cela permet aux responsables
5344 d'utiliser et de partager une logique commune pour un grand nombre de
5345 paquets. Prenez, par exemple, la question de l'installation des
5346 entrées de menu : vous avez besoin de placer un fichier dans
5347 <file>/usr/share/menu</file> (ou <file>/usr/lib/menu</file> pour des
5348 fichiers de menu binaires exécutables, si nécessaire) et d'ajouter des
5349 commandes aux scripts de maintenance pour enregistrer et
5350 désenregistrer ces entrées de menu. Comme il s'agit d'une chose très
5351 commune, pourquoi chaque responsable devrait-il écrire sa propre
5352 version, parfois avec des bogues ? Supposons également que le
5353 répertoire de menu soit modifié, chaque paquet devrait être modifié.
5356 Les scripts d'aide peuvent résoudre ces problèmes. En supposant que
5357 vous vous conformiez aux conventions attendues par le script d'aide,
5358 celui-ci prend soin de tous les détails. Les changements dans la
5359 charte peuvent alors être faits dans le script d'aide ; les
5360 paquets ont alors simplement besoin d'être reconstruits avec la
5361 nouvelle version du script et sans aucun changement supplémentaire.
5364 L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus courant
5365 et le meilleur (à notre avis) système est
5366 <package>debhelper</package>. Les précédents systèmes d'aide comme
5367 <package>debmake</package> étaient « monolithiques » :
5368 vous ne pouviez pas choisir quelles parties intéressantes vous pouviez
5369 utiliser, mais vous étiez obligé de choisir le système pour tout
5370 faire. <package>debhelper</package>, à l'inverse, consiste en un
5371 certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple,
5372 <prgn>dh_installman</prgn> installe et compacte les pages de manuel,
5373 <prgn>dh_installmenu</prgn> installe les fichiers de menu et ainsi de
5374 suite. Ainsi, il offre une flexibilité suffisante pour pouvoir
5375 utiliser les scripts d'aide quand ils sont utiles, en complément de
5376 commandes définies manuellement dans le fichier
5377 <file>debian/rules</file>.
5380 Vous pouvez débuter avec <package>debhelper</package> en lisant
5381 <manref section="1" name="debhelper"> et en regardant les exemples
5382 fournis avec le paquet. <prgn>dh_make</prgn> du paquet
5383 <package>dh-make</package> (voir <ref id="dh-make">) peut être utilisé
5384 pour convertir un paquet source « vierge » en une version
5385 utilisant <package>debhelper</package>. Ce raccourci ne devrait
5386 cependant pas vous faire croire que vous n'avez pas besoin de
5387 comprendre les scripts individuels <prgn>dh_*</prgn>. Si vous comptez
5388 utiliser un système d'aide, vous devez prendre le temps d'apprendre à
5389 utiliser ce système pour savoir ce que vous pouvez en attendre ainsi
5390 que son comportement.
5393 Plusieurs personnes pensent que des fichiers <file>debian/rules</file>
5394 vierges sont préférables car vous n'avez pas à apprendre les détails
5395 internes d'un quelconque système d'aide. La décision vous appartient
5396 complètement. Utilisez ce qui vous convient. Plusieurs exemples de
5397 fichiers <file>debian/rules</file> sont disponibles à <url
5398 id="&url-rules-files;">.
5401 <sect1 id="multiple-patches">
5403 Séparer vos correctifs en plusieurs fichiers
5406 Les gros paquets peuvent avoir plusieurs bogues que vous devez
5407 gérer. Si vous corrigez sans faire attention les bogues dans les
5408 sources, vous ne pourrez pas différencier facilement les nombreux
5409 correctifs que vous aurez appliqués. Cela peut devenir très compliqué
5410 de mettre à jour le paquet avec une nouvelle version amont qui intègre
5411 certains correctifs (mais pas tous). Vous ne pouvez pas prendre
5412 l'ensemble des correctifs (par exemple, dans les fichiers
5413 <file>.diff.gz</file>) et décider quels correctifs il vous faut
5414 enlever parce que les bogues ont été corrigés en amont.
5417 Malheureusement, le système de création des paquets tel qu'il est
5418 actuellement ne fournit pas de moyen de séparer les correctifs en
5419 plusieurs fichiers. Cependant, il existe des moyens de séparer les
5420 correctifs : les fichiers correctifs sont livrés dans le fichier
5421 correctif Debian (<file>.diff.gz</file>), habituellement dans le
5422 répertoire <file>debian/</file>. La seule différence est qu'ils ne
5423 sont pas appliqués immédiatement par dpkg-source, mais par la règle
5424 <tt>build</tt> du fichier <file>debian/rules</file>. Inversement, ils
5425 sont annulés par la règle <tt>clean</tt>.
5428 <prgn>dbs</prgn> est l'une des approches les plus populaires pour
5429 cela. Il fait ce qui est décrit ci-dessus et fournit la possibilité de
5430 créer de nouveaux correctifs et de mettre à jour d'anciens
5431 correctifs. Veuillez vous reporter au paquet <package>dbs</package>
5432 pour plus d'informations et au paquet <package>hello-dbs</package>
5436 <prgn>Dpatch</prgn> fournit également ces fonctions, mais il est prévu
5437 pour être encore plus facile d'utilisation. Veuillez voir le paquet
5438 <package>dpatch</package> pour la documentation et des exemples (dans
5439 <file>/usr/share/doc/dpatch</file>).
5442 <sect1 id="multiple-binary">
5444 Paquets binaires multiples
5447 Un simple paquet source va souvent permettre de construire plusieurs
5448 paquets binaires différents, que ce soit pour fournir plusieurs
5449 saveurs du même paquet (par exemple, le paquet source
5450 <package>vim</package>) ou pour créer plusieurs petits paquets au lieu
5451 d'un seul gros (afin, par exemple, que l'utilisateur puisse n'installer
5452 que la partie nécessaire et ainsi économiser de l'espace disque).
5455 Le second cas peut facilement être géré dans le fichier
5456 <file>debian/rules</file>. Vous avez simplement besoin de déplacer les
5457 fichiers appropriés du répertoire de construction dans les
5458 arborescence temporaires du paquet. Vous pouvez le faire en utilisant
5459 <prgn>install</prgn> ou <prgn>dh_install</prgn> du paquet
5460 <package>debhelper</package>. Assurez-vous de vérifier les différentes
5461 permutations de paquets, en garantissant que vous avez bien défini les
5462 dépendances entre les paquets dans le fichier
5463 <file>debian/control</file>.
5466 Le premier cas est un peu plus difficile car il implique de multiples
5467 recompilations du même logiciel, mais avec différentes options de
5468 configuration. Le paquet source <package>vim</package> est un exemple
5469 de la façon de gérer cela avec un fichier <file>rules</file> écrit à
5474 <sect id="bpp-debian-control">
5476 Les meilleures pratiques pour le fichier <file>debian/control</file>
5479 Les pratiques suivantes sont relatives au fichier
5480 <file>debian/control</file>. Elles viennent en complément des <url
5481 id="&url-debian-policy;ch-binary.html#s-descriptions" name="règles pour
5482 les descriptions des paquets">.
5485 La description du paquet, telle qu'elle est définie par le champ
5486 correspondant dans le fichier <file>control</file>, contient à la fois
5487 le résumé du paquet et la description longue pour le paquet. <ref
5488 id="bpp-desc-basics"> décrit des lignes générales pour les deux parties
5489 de la description. Ensuite, <ref id="bpp-pkg-synopsis"> fournit des
5490 principes spécifiques pour le résumé et <ref id="bpp-pkg-desc">
5491 contient des principes spécifiques pour la description longue.
5493 <sect1 id="bpp-desc-basics">
5495 Les règles générales pour les descriptions des paquets
5498 La description du paquet devrait être écrite pour l'utilisateur moyen,
5499 l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple,
5500 les paquets de développement sont pour les développeurs et leur
5501 description peut utiliser un langage technique. Pour les applications
5502 à but plus général comme un éditeur, la description devrait être
5503 écrite pour un non-spécialiste.
5506 Notre critique des descriptions des paquets nous amène à conclure que
5507 la plupart des descriptions des paquets sont techniques, c'est-à-dire,
5508 qu'elles ne sont pas écrites pour être comprises par les
5509 non-spécialistes. À moins que votre paquet ne soit que pour les
5510 techniciens, c'est un problème.
5513 Comment écrire pour les non-spécialistes ? Évitez le
5514 jargon. Évitez de vous référer à d'autres applications et cadres de
5515 travail avec lesquels l'utilisateur n'est pas forcément familier
5516 — « GNOME » ou « KDE » sont corrects
5517 car les utilisateurs sont probablement familiers avec ces termes, mais
5518 « GTK+ » ne l'est probablement pas. Ne supposez aucune
5519 connaissance. Si vous devez utiliser des termes techniques,
5523 Soyez objectif. Les descriptions de paquet ne sont pas un endroit pour
5524 promouvoir votre paquet, quel que soit l'amour que vous lui
5525 portez. Rappelez-vous que le lecteur n'a pas forcément les mêmes
5529 Des références aux noms de tout autre paquet de logiciels, noms de
5530 protocoles, standards ou spécifications devraient utiliser leurs
5531 formes canoniques si elles existent. Par exemple, utilisez « X
5532 Window System », « X11 » ou « X » et non
5533 « X Windows », « X-Windows » ou « X
5534 Window ». Utilisez « GTK+ » et non « GTK » ou
5535 « gtk ». Utilisez « GNOME » et non
5536 « Gnome ». Utilisez « PostScript » et non
5537 « Postscript » ou « postscript ».
5540 Si vous avez des problèmes pour écrire votre description, vous pouvez
5541 l'envoyer à &email-debian-l10n-english; et demander un retour
5545 <sect1 id="bpp-pkg-synopsis">
5547 Le résumé du paquet ou description courte
5550 La ligne de résumé (la description courte) devrait être concise. Elle
5551 ne doit pas répéter le nom du paquet (c'est une règle).
5554 C'est une bonne idée de penser au résumé comme à une clause apposée et
5555 non une phrase complète. Une clause apposée est définie dans WordNet
5556 comme une relation grammaticale entre un mot et une phrase pronominale
5557 qui la suit, par exemple « Rudolph, le renne au nez
5558 rouge ». La clause apposée ici est « le renne au nez
5559 rouge ». Comme le résumé est une clause et non une phrase
5560 complète, nous recommandons de ne pas la commencer par une majuscule
5561 et de ne pas la finir par un point. Il ne doit pas non plus commencer
5562 avec un article, défini (« le ») ou indéfini
5566 Cela peut vous aider d'imaginer le résumé combiné avec le nom du
5567 paquet de la façon suivante :
5568 <example><var>nom-paquet</var> est un <var>résumé</var>.</example>
5569 Sinon, il peut être plus compréhensible de le voir comme
5570 <example><var>nom-paquet</var> est <var>résumé</var>.</example>
5571 ou, si le nom du paquet est lui-même un pluriel (comme
5572 « developer-tools »)
5573 <example><var>nom-paquet</var> sont <var>résumé</var>.</example>
5574 Cette façon de former une phrase à partir du nom du paquet et du
5575 résumé devrait être considérée comme une heuristique et non comme une
5576 règle stricte. Il y a certains cas où cela n'a aucun sens de former
5580 <sect1 id="bpp-pkg-desc">
5582 La description longue
5585 La description longue du paquet est la première information dont
5586 dispose l'utilisateur avant d'installer un paquet. Aussi, elle devrait
5587 fournir toutes les informations nécessaires pour le laisser décider de
5588 l'installation du paquet. Vous pouvez supposer que l'utilisateur a
5589 déjà lu le résumé du paquet.
5592 La description longue devrait toujours être constituée de phrases
5596 Le premier paragraphe de la description longue devrait répondre aux
5597 questions suivantes : qu'est-ce que fait le paquet ? Quelle
5598 tâche aide-t-il l'utilisateur à accomplir ? Il est important de
5599 décrire ceci d'une manière non technique, à moins que le paquet ne
5600 s'adresse qu'à un auditoire de techniciens.
5603 Les paragraphes suivants devraient répondre aux questions
5604 suivantes : Pourquoi, en tant qu'utilisateur, ai-je besoin de ce
5605 paquet ? Quelles sont les autres fonctionnalités dont dispose le
5606 paquet ? Quelles sont les fonctionnalités marquantes et les
5607 déficiences de ce paquet comparé à d'autres paquets (par exemple,
5608 « si vous avez besoin de X, utilisez Y à la place ») ?
5609 Est-ce que le paquet est lié à d'autres paquets d'une certaine façon
5610 qui n'est pas gérée par le gestionnaire de paquet (par exemple,
5611 « il s'agit d'un client pour le serveur foo ») ?
5614 Soyez attentif à éviter les fautes d'orthographe et de
5615 grammaire. N'oubliez pas votre vérificateur orthographique. Les deux
5616 programmes <prgn>ispell</prgn> et <prgn>aspell</prgn> possèdent des
5617 modes spéciaux pour vérifier les fichiers
5618 <file>debian/control</file> :
5619 <example>ispell -d american -g debian/control</example>
5620 <example>aspell -d en -D -c debian/control</example>
5623 Les utilisateurs s'attendent habituellement à ce que les réponses aux
5624 questions suivantes soient présentes dans la description du
5629 Qu'est-ce que fait le paquet ? Si c'est un ajout d'un autre
5630 paquet, la description courte du paquet dont c'est un ajout devrait
5636 Pourquoi est-ce qu'il voudrait installer ce paquet ? Ceci est
5637 lié à ce qui est ci-dessus, mais pas tout à fait (c'est un client
5638 de messagerie ; il est cool, rapide, s'interface avec PGP,
5639 LDAP et IMAP, a les fonctionnalités X, Y et Z).
5644 Si ce paquet ne devrait pas être installé directement, mais être
5645 tiré par un autre paquet, cela devrait être mentionné.
5650 Si le paquet est expérimental, ou s'il y a d'autres raisons pour
5651 lesquelles il ne devrait pas être utilisé, si un autre paquet
5652 devrait être utilisé à la place, cela devrait également être
5658 En quoi le paquet est différent des paquets concurrents ?
5659 Est-ce que c'est une meilleure implémentation ? A-t-il plus de
5660 fonctionnalités, des fonctionnalités différentes ? Pourquoi
5661 devrait-il choisir ce paquet ?
5667 <sect1 id="bpp-upstream-info">
5669 Page d'accueil amont
5672 Nous vous recommandons d'ajouter l'adresse de la page d'accueil du
5673 paquet à la description du paquet dans le fichier
5674 <file>debian/control</file>. Cette information devrait être ajoutée à
5675 la fin de la description en utilisant le format suivant :
5677 Homepage: http://some-project.some-place.org/</example>
5678 Veuillez noter les espaces au début de la ligne, ils servent à séparer
5679 les lignes correctement. Pour voir un exemple de ce que cela affiche,
5680 veuillez vous reporter à <url id="&url-eg-desc-upstream-info;">.
5683 Ne mettez rien s'il n'existe pas de page pour le logiciel.
5686 Veuillez noter que nous espérons que ce champ sera remplacé par un
5687 vrai champ de <file>debian/control</file> qui serait compris par
5688 <prgn>dpkg</prgn> et <tt>&packages-host;</tt>. Si vous ne voulez pas
5689 vous embêter à déplacer la page d'accueil depuis la description vers
5690 ce nouveau champ, vous devriez probablement attendre qu'il soit
5691 disponible. Veuillez vous assurer que cette ligne correspond à
5692 l'expression rationnelle <tt>/^ Homepage: [^ ]*$/</tt> car cela permet
5693 à <file>packages.debian.org</file> de l'analyser correctement.
5697 <sect id="bpp-debian-changelog">
5699 Les meilleures pratiques pour le fichier <file>debian/changelog</file>
5702 Les pratiques suivantes viennent en complément de la <url
5703 id="&url-debian-policy;ch-docs.html#s-changelogs" name="directive sur
5704 les fichiers changelog">.
5706 <sect1 id="bpp-changelog-do">
5708 Écrire des entrées de changelog utiles
5711 L'entrée de changelog pour une révision de paquet documente les
5712 changements dans cette révision et seulement ceux-ci. Concentrez-vous
5713 sur la description des changements significatifs et visibles de
5714 l'utilisateur qui ont été effectués depuis la dernière version.
5717 Ciblez <em>ce</em> qui a été changé — qui, comment et quand
5718 cela a été fait est généralement de moindre importance. Ceci dit,
5719 rappelez-vous de nommer poliment les personnes qui ont fourni une aide
5720 notable pour réaliser le paquet (par exemple, ceux qui ont envoyé des
5724 Vous n'avez pas besoin de détailler les changements triviaux et
5725 évidents. Vous pouvez également regrouper plusieurs de ces changements
5726 dans une seule entrée. D'un autre côté, ne soyez pas trop concis si
5727 vous avez entrepris un changement majeur. Soyez tout spécialement
5728 clair s'il y a des changements qui modifient le comportement du
5729 programme. Pour plus d'explications, utilisez le fichier
5730 <file>README.Debian</file>.
5733 Utilisez un langage anglais commun pour que la majorité des lecteur
5734 puissent le comprendre. Évitez les abréviations, le parler technique
5735 et le jargon quand vous expliquez des changements fermant un bogue,
5736 spécialement pour les rapports de bogue créés par des utilisateurs qui
5737 ne vous paraissent pas particulièrement à l'aise techniquement. Vous
5738 devez être poli et ne pas jurer.
5741 Il est parfois désirable de préfixer les entrées de changelog avec le
5742 nom des fichiers qui ont été modifiés. Cependant, il n'est pas besoin
5743 de lister explicitement tous les fichiers modifiés, particulièrement
5744 si la modification est petite ou répétitive. Vous pouvez utiliser les
5745 caractères génériques.
5748 Quand vous faites référence aux bogues, ne supposez rien a
5749 priori. Dites ce qu'était le problème, comment il a été résolu et
5750 ajoutez la chaîne de caractères « closes: #nnnnn ». Veuillez
5751 voir <ref id="upload-bugfix"> pour plus d'informations.
5754 <sect1 id="bpp-changelog-misconceptions">
5756 idées fausses communes sur les entrées de changelog
5759 Les entrées de changelog <strong>ne devraient pas</strong> documenter
5760 des problèmes génériques d'empaquetage (« Hé, si vous cherchez
5761 foo.conf, il est dans /etc/blah/. ») car les administrateurs et
5762 utilisateurs sont supposés être au moins vaguement rompus à la façon
5763 dont les choses sont arrangées sur un système Debian. Mentionnez
5764 cependant tout changement d'emplacement d'un fichier de configuration.
5767 Les seuls bogues fermés par une entrée de changelog devraient être
5768 ceux qui sont vraiment corrigés dans la même révision du
5769 paquet. Fermer des bogues non liés par le fichier changelog est
5770 considéré comme une très mauvaise pratique. Veuillez voir <ref
5771 id="upload-bugfix">.
5774 Les entrées de changelog <strong>ne devraient pas</strong> être le
5775 lieu de discussions avec les émetteurs de bogues (« Je ne vois
5776 pas de segfaults lors du lancement de foo avec l'option bar ;
5777 envoyez-moi plus d'informations. »), ni celui de phrases
5778 génériques sur la vie, l'univers et tout le reste (« Désolé, cet
5779 envoi m'a pris du temps, mais j'avais attrapé la grippe ») ou
5780 celui de demandes d'aide (« La liste des bogues sur ce paquet est
5781 énorme, donnez-moi un coup de main »). Ceci ne sera généralement
5782 pas remarqué par les personnes ciblées, mais peut ennuyer les
5783 personnes qui désirent lire des informations sur les changements réels
5784 du paquet. Veuillez vous reporter à <ref id="bug-answering"> pour plus
5785 d'informations sur la façon d'utiliser le système de suivi des bogues.
5788 C'est une vieille tradition de valider les bogues fixés par une mise à
5789 jour indépendante dans la première entrée du changelog de l'envoi du
5790 vrai responsable. Comme nous avons maintenant le suivi des versions, il
5791 est suffisant de garder les entrées de changelog des mises à jour
5792 indépendantes et de simplement mentionner ce fait dans votre propre
5793 entrée de changelog.
5796 <sect1 id="bpp-changelog-errors">
5798 Erreurs communes dans les entrées de changelogs
5801 Les exemples suivants montrent des erreurs communes ou des exemples de
5802 mauvais style dans les entrées de changelog<footnote><p>NdT : Les
5803 entrées de changelog sont ici affichées en français pour faciliter la
5804 compréhension, mais vos entrées devront naturellement être rédigées en
5805 anglais.</p></footnote>.
5809 * Corrige tous les bogues restants.
5811 Ceci n'indique visiblement rien d'utile au lecteur.
5815 * Correctif de Jane Random appliqué.
5817 Sur quoi portait le correctif ?
5821 * Révision de cible d'installation la nuit dernière.
5823 Qu'a accompli la révision ? Est-ce que la mention de la nuit
5824 dernière est supposée nous rappeler que nous ne devons pas faire
5825 confiance à ce code ?
5829 * Corrige MRD vsync av. anciens CRTs.
5831 Trop d'acronymes et il n'est pas très clair de ce qu'était vraiment
5832 cette... euh... merde (oups, un mot interdit !) ou comment cela a
5837 * Ceci n'est pas un bogue. Closes: #nnnnnn.
5839 Premièrement, il n'y a absolument pas besoin d'envoyer un paquet pour
5840 communiquer cette information ; à la place, utilisez le système
5841 de suivi des bogues. Deuxièmement, il n'y a aucune explication
5842 concernant la raison pour laquelle le rapport n'était pas un bogue.
5846 * A été fixé il y a longtemps, mais j'ai oublié de le fermer. Closes: #54321.
5848 Si, pour toute raison, vous n'aviez pas indiqué le numéro du bogue
5849 dans une précédente entrée de changelog, ceci n'est pas un problème,
5850 fermez simplement le bogue normalement dans le BTS. Il n'y a pas
5851 besoin de modifier le fichier changelog, en supposant que la
5852 description de la correction est déjà intégrée (ceci s'applique aux
5853 correctifs par les auteurs/responsables amont également, vous n'avez
5854 pas à suivre les bogues qui ont été corrigés il y a longtemps dans
5859 * Closes: #12345, #12346, #15432.
5861 Où est la description ?! Si vous n'arrivez pas à trouver un
5862 message descriptif, commencez par insérer le titre de chacun des
5866 <sect1 id="bpp-news-debian">
5868 Compléter les changelogs avec les fichiers NEWS.Debian
5871 Les nouvelles importantes à propos des changements dans un paquet
5872 peuvent également être placées dans les fichiers NEWS.Debian. Ces
5873 nouvelles seront affichées par des outils comme apt-listchanges, avant
5874 le reste des changelogs. Ceci est le moyen préféré pour informer les
5875 utilisateurs des changements significatifs dans un paquet. Il est
5876 préférable d'utiliser ce fichier plutôt que d'utiliser des notes
5877 debconf car c'est moins ennuyeux et l'utilisateur peut y revenir et se
5878 référer au fichier NEWS.Debian après l'installation. Et c'est mieux
5879 que de lister les changements principaux dans README.Debian car
5880 l'utilisateur peut facilement rater de telles notes.
5883 Le format du fichier est le même que pour un fichier de changelog
5884 Debian, mais il n'utilise pas d'astérisques et décrit chaque élément
5885 de nouvelle dans un paragraphe complet si nécessaire plutôt que les
5886 résumés concis qui iraient dans un changelog. C'est une bonne idée de
5887 passer votre fichier par dpkg-parsechangelog pour vérifier son
5888 formatage car il n'est pas vérifié automatiquement pendant la
5889 construction comme le changelog. Voici un exemple d'un vrai fichier
5892 cron (3.0pl1-74) unstable; urgency=low
5894 The checksecurity script is no longer included with the cron package:
5895 it now has its own package, "checksecurity". If you liked the
5896 functionality provided with that script, please install the new
5899 -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
5903 Le fichier NEWS.Debian est installé comme
5904 /usr/share/doc/<package>/NEWS.Debian.gz. Il est compressé et a
5905 toujours ce nom même dans les paquets natifs Debian. Si vous utilisez
5906 debhelper, dh_installchangelogs installera les fichiers debian/NEWS
5910 À la différence des fichiers changelog, vous n'avez pas besoin de
5911 mettre à jour les fichiers NEWS.Debian à chaque nouvelle version. Ne
5912 les mettez à jour que si vous avez quelque chose de particulièrement
5913 important que l'utilisateur a besoin de savoir. Si vous n'avez pas de
5914 nouvelles du tout, il n'est pas nécessaire de fournir de fichier
5915 NEWS.Debian dans votre paquet. Pas de nouvelles, bonne nouvelle !
5919 <sect id="bpp-debian-maint-scripts">
5921 Les meilleures pratiques pour les scripts de maintenance
5924 Les scripts de maintenance incluent les fichiers
5925 <file>debian/postinst</file>, <file>debian/preinst</file>,
5926 <file>debian/prerm</file> et <file>debian/postrm</file>. Ces scripts
5927 prennent en charge la configuration d'installation ou de
5928 désinstallation des paquets, ce qui n'est pas simplement créer ou
5929 supprimer des fichiers et des répertoires. Les instructions suivantes
5930 complètent la <url id="&url-debian-policy;" name="charte Debian">.
5933 Les scripts de maintenance doivent être idempotents. Cela veut dire que
5934 vous devez vous assurer que rien de grave ne se produit si un script
5935 est appelé deux fois là où il ne devrait habituellement être appelé
5939 Les entrée et sortie standard peuvent être redirigées (par exemple,
5940 dans des tubes<footnote><p>pipes</p></footnote>) pour des besoins
5941 d'enregistrement d'activité, donc vous ne devez pas supposer que ce
5945 Tous les affichages et les configurations interactives devraient être
5946 minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet
5947 <package>debconf</package> pour l'interface. Rappelez-vous que, dans
5948 tous les cas, l'affichage ne doit se faire que dans l'étape de
5949 configuration, <tt>configure</tt> du script de post-installation,
5950 <file>postinst</file>.
5953 Gardez les scripts de maintenance aussi simples que possible. Nous vous
5954 suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que
5955 si vous avez besoin d'une fonctionnalité de Bash, le script de
5956 maintenance doit préciser bash dans sa première ligne. Un shell POSIX
5957 ou Bash sont préférés à Perl car ils permettent à
5958 <package>debhelper</package> d'ajouter facilement des parties aux
5962 Si vous modifiez les scripts de maintenance, assurez-vous de tester la
5963 suppression du paquet, la double installation et la purge
5964 complète. Assurez-vous qu'il ne reste rien d'un paquet purgé,
5965 c'est-à-dire, que la purge doit enlever tout fichier créé, directement
5966 ou indirectement, par les scripts de maintenance.
5969 Si vous avez besoin de vérifier l'existence d'une commande, vous
5970 devriez utiliser quelque chose comme :
5971 <example>if [ -x /usr/sbin/install-docs ]; then ...</example>
5972 Si vous ne désirez pas mettre en dur le chemin d'une commande dans le
5973 script de maintenance, la fonction de shell suivante conforme à POSIX
5974 peut vous aider : &example-pathfind; Vous pouvez utiliser cette
5975 fonction pour rechercher le <tt>$PATH</tt> pour un nom de commande
5976 passé en paramètre. Il renvoie vrai (zéro) si la commande a été trouvée
5977 et faux sinon. Il s'agit réellement de la façon la plus portable de
5978 faire car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn>
5982 Bien que <prgn>which</prgn> soit une alternative acceptable car il est
5983 présent dans le paquet classé <em>required</em>
5984 <package>debianutils</package>, il n'est pas présent dans la partition
5985 racine. Autrement dit, il est placé dans <file>/usr/bin</file> au lieu
5986 de <file>/bin</file>, il n'est donc pas possible de l'utiliser dans les
5987 scripts qui sont exécutés avant que la partition <file>/usr</file> soit
5988 montée. Cependant, la plupart des scripts n'auront pas ce problème.
5991 <sect id="bpp-config-mgmt">
5993 Gestion de la configuration avec <package>debconf</package>
5996 <package>Debconf</package> est un système de gestion de configuration
5997 qui peut être utilisé par les divers scripts de maintenance
5998 (principalement en post-installation dans le fichier
5999 <file>postinst</file>) pour demander à l'utilisateur des informations
6000 concernant la configuration du paquet. Il faut maintenant éviter les
6001 interactions directes avec l'utilisateur et préférer les interactions
6002 utilisant <package>debconf</package>. Ceci permettra à l'avenir des
6003 installations non interactives.
6006 Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs
6007 erreurs communes sont référencées dans la page de manuel <manref
6008 section="7" name="debconf-devel">. Vous devriez vraiment lire cette
6009 page si vous décidez d'utiliser debconf. Nous documentons également
6010 plusieurs des meilleures pratiques ici.
6013 Ces lignes directives incluent plusieurs recommandations de style
6014 d'écriture et de typographie, des considérations générales à propos de
6015 l'utilisation de debconf ainsi que des recommandations plus spécifiques
6016 pour certaines parties de la distribution (par exemple, le système
6021 N'abusez pas de debconf
6024 Depuis que debconf est apparu dans Debian, il a été largement abusé et
6025 plusieurs critiques reçues par la distribution Debian proviennent
6026 d'utilisation abusive de debconf avec la nécessité de répondre à un
6027 grand nombre de questions avant d'avoir n'importe quel petit logiciel
6031 Garder les notes d'utilisation à leur place : le fichier
6032 NEWS.Debian ou le fichier README.Debian. N'utilisez des notes que pour
6033 des notes importantes qui peuvent directement concerner l'utilisation
6034 du paquet. Rappelez-vous que les notes bloqueront toujours
6035 l'installation avant leur confirmation ou qu'elles embêtent
6036 l'utilisateur par un courriel.
6039 Choisissez avec soin les priorités des questions dans les scripts de
6040 responsable. Reportez-vous à <manref section="7" name="debconf-devel">
6041 pour plus de détails sur les priorités. La plupart des questions
6042 devraient utiliser un priorité moyenne ou basse.
6047 Recommandations générales pour les auteurs et traducteurs
6053 Écrivez un anglais correct
6056 La plupart des responsables de paquets Debian n'ont pas l'anglais
6057 comme langue maternelle. Écrire des modèles correctement rédigés peut
6058 donc ne pas être facile pour eux.
6061 Veuillez utiliser (et abuser de) la liste de discussions
6062 &email-debian-l10n-english;. Faites relire vos questionnaires.
6065 Des questionnaires écrits incorrectement donnent une pauvre image de
6066 votre paquet, de votre travail... ou même de Debian elle-même.
6069 Évitez le jargon technique autant que possible. Si certains termes
6070 vous semblent courants, ils peuvent être impossibles à expliquer à
6071 d'autres personnes. Si vous ne pouvez pas les éviter, essayez de les
6072 expliquer (en utilisant la description étendue). Quand vous faites
6073 cela, essayez d'équilibrer la verbosité et la simplicité.
6078 Être courtois avec les traducteurs
6081 Les questionnaires debconf peuvent être traduits. Debconf, avec son
6082 paquet-frêre <package>po-debconf</package>, offre un cadre de travail
6083 simple pour obtenir des questionnaires traduits par les équipes de
6084 traduction ou même par des individus isolés.
6087 Veuillez utiliser les questionnaires basés sur gettext. Installez
6088 <package>po-debconf</package> sur votre système de développement et
6089 lisez sa documentation (« man po-debconf » est un bon
6093 Évitez de changer vos questionnaires trop souvent. Modifier le texte
6094 des questionnaires entraîne plus de travail pour les traducteurs dont
6095 les traductions seront rendues « floues »
6096 (« fuzzy »). Si vous prévoyez des modifications dans vos
6097 questionnaires d'origine, veuillez contacter les traducteurs. La
6098 plupart des traducteurs actifs sont très réactifs et obtenir leur
6099 travail inclus avec vos questionnaires modifiés vous économisera des
6100 envois supplémentaires. Si vous utilisez des modèles basés sur
6101 gettext, le nom et l'adresse électronique du traducteur sont
6102 mentionnés dans les en-têtes des fichiers PO.
6105 L'utilisation de <prgn>podebconf-report-po</prgn> du paquet
6106 <package>po-debconf</package> est hautement recommandée pour avertir
6107 les traducteurs qui ont des traductions incomplètes et pour leur
6108 demander des mises à jour.
6111 En cas de doutes, vous pouvez également contacter l'équipe de
6112 traduction pour une langue donnée
6113 (debian-l10n-xxxxx@lists.debian.org) ou la liste de discussions
6114 &email-debian-i18n;.
6117 Les appels à traductions postés sur &email-debian-i18n; avec le
6118 fichier <file>debian/po/templates.pot</file> attaché ou référencé
6119 dans une URL sont encouragés. Assurez-vous de mentionner dans ces
6120 appels pour de nouvelles traductions quelles sont les langues pour
6121 lesquelles vous avez déjà des traductions existantes, pour éviter
6122 toute duplication de travail.
6127 « Dé-fuzzy-fiez » les traductions complètes lors des
6128 corrections de typos et d'orthographe
6131 Quand le texte d'un questionnaire debconf est corrigé et que vous
6132 êtes <strong>certain</strong> que les changements <strong>n'ont
6133 aucun</strong> effet sur les traductions, soyez courtois avec les
6134 traducteurs et dé-fuzzy-fiez leurs traductions.
6137 Si vous ne le faites pas, le questionnaire entier ne sera pas traduit
6138 jusqu'à ce qu'un traducteur vous envoie une mise à jour.
6141 Pour <strong>dé-fuzzy-fier</strong> les traductions, vous pouvez
6142 procéder ainsi :
6143 <enumlist numeration="arabic">
6146 enlevez tous les fichiers PO incomplets. Vous pouvez vérifier si
6147 les fichiers sont complets en utilisant (il faut que le paquet
6148 <package>gettext</package> soit installé) :
6149 <example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
6150 --statistics $i; done</example>
6155 déplacez tous les fichiers ayant des chaînes floues
6156 (« fuzzy ») dans un emplacement temporaire. Les fichiers
6157 n'ayant aucune chaîne floue (seulement des chaînes traduites et
6158 non traduites) seront conservées où ils sont placés,
6163 maintenant <strong>et seulement maintenant</strong>, corrigez les
6164 typos dans le questionnaire et vérifiez que les traductions ne
6165 sont pas impactées (les typos, les fautes d'orthographe et parfois
6166 les corrections de typographie sont généralement acceptables),
6171 exécutez <prgn>debconf-updatepo</prgn>. Cela va fuzzifier toutes
6172 les chaînes que vous avez modifiées dans les traductions. Vous
6173 pouvez constater cela en exécutant à nouveau la commande
6179 utilisez la commande suivante :
6180 <example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
6185 déplacez dans debian/po les fichiers qui avaient des chaînes
6186 floues dans la première étape,
6191 exécutez à nouveau <prgn>debconf-updatepo</prgn>.
6199 Ne faites pas de suppositions à propos des interfaces
6202 Le texte des modèles ne doit pas faire référence aux composants
6203 appartenant à l'une des interfaces debconf. Des phrases comme
6204 « If you answer Yes... » n'a aucun sens pour les
6205 utilisateurs d'interfaces graphiques qui utilisent des cases à cocher
6206 pour les questions booléennes.
6209 Les modèles de chaînes de caractères devraient éviter de mentionner
6210 les valeurs par défaut dans leur description. Tout d'abord, parce que
6211 cela est redondant avec les valeurs lues par les
6212 utilisateurs. Ensuite, parce ces valeurs par défaut peuvent être
6213 différentes selon les choix du responsable (par exemple, quand la
6214 base de données debconf a été préremplie).
6217 Plus généralement, essayez d'éviter de vous référer à toute action de
6218 l'utilisation. Donnez simplement des faits.
6223 N'utilisez pas la première personne
6226 Vous devriez éviter d'utiliser la première personne (« I will do
6227 this... » ou « We recommend... »). L'ordinateur n'est
6228 pas une personne et les questionnaires debconf ne parlent pas pour
6229 les développeurs Debian. Vous devriez utiliser une construction
6230 neutre et souvent une forme passive. Pour ceux d'entre vous qui
6231 écrivent déjà des publications scientifiques, écrivez simplement vos
6232 questionnaires comme vous écririez un papier scientifique.
6237 Soyez neutre dans le genre
6240 Le monde est fait d'hommes et de femmes. Veuillez utiliser des
6241 constructions neutres dans le genre dans votre texte. Ce n'est pas du
6242 politiquement correct, c'est simplement montrer du respect pour toute
6249 Définition des champs de questionnaires
6252 Cette partie donne plusieurs informations qui sont principalement
6253 extraites de la page de manuel <manref section="7"
6254 name="debconf-devel">.
6264 string: (chaîne de caractères)
6267 Résulte en un champ d'entrée libre dans lequel l'utilisateur peut
6268 écrire toute chaîne.
6273 password: (mot de passe)
6276 Demande un mot de passe à l'utilisateur. Veuillez utiliser ce champ
6277 avec précaution ; soyez conscient que le mot de passe que
6278 l'utilisateur entre sera écrit dans la base de données debconf. Vous
6279 devriez probablement enlever cette valeur de la base de données dès
6288 Un choix vrai/faux. Rappelez-vous : vrai/faux, <strong>pas oui/non</strong>...
6296 Un choix parmi un certain nombre de valeurs. Les choix doivent être
6297 spécifiés dans un champ nommé « Choices ». Séparez les
6298 valeurs possibles par des virgules et des espaces ainsi :
6299 Choices: yes, no, maybe
6304 multiselect: (sélection multiple)
6307 Comme le type de données select, excepté que l'utilisateur peut
6308 choisir un nombre quelconque d'éléments dans la liste de choix (ou
6317 Plutôt que d'être une question en tant que telle, ce type de donnée
6318 indiqué une note qui peut être affichée à l'utilisateur. Il ne
6319 devrait être utilisé que pour des données importantes que
6320 l'utilisateur doit réellement voir, car debconf fera tout ce qu'il
6321 peut pour s'assurer que l'utilisateur le voit ; il stoppera
6322 l'installation en attendant que l'utilisateur appuie sur une touche
6323 ou il leur enverra même la note par courrier dans certains cas.
6331 Ce type est maintenant considéré comme obsolète : ne l'utilisez
6340 <strong>CE TYPE DE MODÈLE N'EST PAS ENCORE GÉRÉ PAR
6344 Il a été ajouté à cdebconf, la version C de debconf, utilisé en
6345 premier dans l'installateur Debian.
6348 Veuillez ne pas l'utiliser à moins que debconf ne le prenne en
6352 Ce type est conçu pour gérer des messages d'erreur. Il est presque
6353 semblable au type « note ». Des interfaces peuvent le
6354 présenter différemment (par exemple, l'interface dialog de cdebconf
6355 affiche un écran rouge au lieu de l'écran bleu habituel).
6361 Description: description courte et étendue
6364 Les descriptions des modèles sont composées de deux parties :
6365 une courte et une étendue. La description courte est dans la ligne
6366 « Description: » du questionnaire.
6369 La description courte devrait être gardée courte (50 caractères
6370 ou moins) pour qu'elle puisse être ajustée par la plupart des
6371 interfaces debconf. La garder courte aide également les traducteurs,
6372 car les traductions ont tendance à être plus longues que l'original.
6375 La description courte devrait se suffire à elle-même. Certaines
6376 interfaces n'affichent pas la description longue par défaut ou
6377 seulement si l'utilisateur la demande explicitement ou même ne
6378 l'affichent pas du tout. Évitez des choses comme « What do you
6379 want to do ? ».
6382 Il n'est pas nécessaire que la description courte soit une phrase
6383 complète. Cela fait partie de la recommandation « gardez-la
6384 courte et efficace ».
6387 La description étendue ne devrait pas répéter la description courte
6388 mot pour mot. Si vous ne trouvez pas de description longue, commencez
6389 par à y réfléchir plus. Envoyez un message sur debian-devel. Demandez
6390 de l'aide. Suivez un cours d'écriture ! La description étendue
6391 est importante. Si, après tout cela, vous ne trouvez toujours rien,
6395 La description étendue devrait utiliser des phrases complètes. Des
6396 paragraphes devraient être gardés court pour améliorer la
6397 lisibilité. Ne mélangez pas deux idées dans le même paragraphe, mais
6398 utilisez plutôt un autre paragraphe.
6401 Ne soyez pas trop verbeux. Les utilisateurs ont tendance à ignorer les
6402 écrans trop longs. Par expérience, 20 lignes est la limite à
6403 éviter de dépasser car cela veut dire sinon que, dans l'interface dialogue
6404 classique, les utilisateurs devront faire défiler le texte et un grand
6405 nombre de personnes ne le font simplement pas.
6408 Pour des règles spécifiques selon le type de questionnaire (chaîne de
6409 caractères, booléen, etc.), veuillez lire ci-dessous.
6417 Ce champ devrait utilisé pour des types Select et Multiselect. Il
6418 contient les choix possibles qui seront présentés aux
6419 utilisateurs. Ces choix devraient être séparés par des virgules.
6424 Default (valeur par défaut)
6427 Ce champ est facultatif. Il contient la réponse par défaut pour les
6428 modèles chaîne de caractères, sélection et multi-sélection. Pour des
6429 questionnaires multi-sélection, il peut contenir une liste de choix
6430 séparés par des virgules.
6436 Guide de style spécifique par champ de questionnaires
6445 Aucune indication spécifique excepté : utilisez le type
6446 approprié en vous référant à la section précédente.
6454 Voici ci-dessous des instructions spécifiques pour écrire
6455 correctement la description (courte et étendue) selon le type de
6460 questionnaire chaîne de caractères/mot de passe
6466 La description courte est une invite et <strong>non</strong> un
6467 titre. Évitez des invites de style question (« IP
6468 Address? ») en faveur d'invites « ouvertes »à
6469 (« IP address: »). L'utilisation des deux-points est
6475 La description étendue est un complément à la description
6476 courte. Dans la partie étendue, expliquez ce qui est demandé,
6477 plutôt que de poser la même question à nouveau en utilisant des
6478 mots plus longs. Utilisez des phrases complètes. Un style
6479 d'écriture trop concis est fortement découragé.
6493 La description courte devrait être rédigée sous la forme d'une
6494 question qui devrait être gardée courte et devrait généralement
6495 se terminer par un point d'interrogation. Un style d'écriture
6496 concis est permis et même encouragé si la question est plutôt
6497 longue (rappelez-vous que les traductions sont souvent plus
6498 longue que les versions d'origine)
6503 La description étendue ne devrait <strong>pas</strong> inclure de
6509 À nouveau, veuillez éviter de vous référer à des composants
6510 d'interface spécifiques. Une erreur courante pour de telles
6511 questionnaires est les constructions du type « if you answer
6520 sélection/multi-sélection
6526 La description courte est une invite et <strong>non</strong> un
6527 titre. N'utilisez <strong>pas</strong> des constructions inutiles
6528 du type « Please choose... ». Les utilisateurs sont assez
6529 intelligents pour réaliser qu'ils doivent choisir quelque chose...:)
6534 La description étendue devra compléter la description
6535 courte. Elle peut se référer aux choix disponibles. Elle peut
6536 également mentionner que l'utilisateur peut choisir plus d'un des
6537 choix disponibles si le questionnaire est du type sélection
6538 multiple (bien que l'interface rende souvent cela clair).
6552 La description courte devrait être considéré comme un *titre*.
6557 La description étendue est ce qui sera affiché comme une
6558 description plus détaillée de la note. Faites des phrases,
6559 n'utilisez pas un style d'écriture trop concis.
6564 <strong>N'abusez pas de debconf.</strong> Les notes sont le moyen le plus courant
6565 d'abus de debconf. Comme il est écrit dans la page de manuel de
6566 debconf-devel : il est préférable de ne les utiliser que
6567 pour des avertissements à propos de problèmes très sérieux. Les
6568 fichiers NEWS.Debian ou README.Debian sont les endroits
6569 appropriés pour un grand nombre de notes. Si, en lisant ceci,
6570 vous envisagez de convertir vos modèles de type note en entrées
6571 dans NEWS/Debian ou README.Debian, veuillez considérer de
6572 conserver les traductions existantes pour une utilisation future.
6584 S'il est probable que les choix changent souvent, veuillez considérer
6585 l'utilisation de l'astuce « __Choices ». Cela séparera
6586 chaque choix individuel en une chaîne de caractères seule, ce qui
6587 aidera considérablement les traducteurs à faire leur travail.
6595 S'il est probable que la valeur par défaut d'un modèle
6596 « select » change selon la langue de l'utilisateur (par
6597 exemple, s'il s'agit d'un choix de langue), veuillez utiliser
6598 l'astuce « _DefaultChoice ».
6601 Ce champ spécial permet aux traducteurs de positionner le choix le
6602 plus approprié selon leur propre langue. Cela deviendra le choix par
6603 défaut quand leur langue sera sélectionnée alors votre choix par
6604 défaut sera utilisé pour l'anglais.
6607 Un exemple tiré des modèles du paquet geneweb :
6609 Template: geneweb/lang
6611 __Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
6612 # This is the default choice. Translators may put their own language here
6613 # instead of the default.
6614 # WARNING : you MUST use the ENGLISH FORM of your language
6615 # For instance, the french translator will need to put "French (fr)" here.
6616 _DefaultChoice: English (en)[ translators, please see comment in PO files]
6617 _Description: Geneweb default language:
6621 Notez l'utilisation de crochets qui permettent des commentaires
6622 internes dans les champs debconf. Notez également l'utilisation de
6623 commentaires qui apparaîtront dans les fichiers sur lesquels
6624 travailleront les traducteurs.
6627 Les commentaires sont nécessaires car l'astuce DefaultChoice est un
6628 peu déroutante : les traducteurs peuvent y placer leur propre
6637 N'utilisez PAS de champ par défaut vide. Si vous ne voulez pas
6638 utiliser de valeurs par défaut, n'utilisez simplement pas du tout
6642 Si vous utilisez po-debconf (et vous <strong>devriez</strong> le faire, voir 2.2),
6643 veuillez considérer de rendre ce champ traduisible, si vous pensez
6644 qu'il peut être traduit.
6647 Si la valeur par défaut peut varier selon la langue ou le pays (par
6648 exemple, la valeur par défaut pour un choix de langue), veuillez
6649 considérer l'utilisation du type spécial « _DefaultChoice »
6650 documenté dans <manref section="7" name="po-debconf">).
6655 <sect id="bpp-i18n">
6657 Internationalisation
6659 <sect1 id="bpp-i18n-debconf">
6661 Gestion des traductions de debconf
6664 Comme les porteurs, les traducteurs ont une tâche difficile. Ils
6665 travaillent sur un grand nombre de paquets et doivent donc collaborer
6666 avec plusieurs responsables différents. De plus, la plupart du temps,
6667 l'anglais n'est pas leur langue maternelle, il se peut que vous deviez
6668 être particulièrement patient avec eux.
6671 Le but de <package>debconf</package> était de faciliter la
6672 configuration des paquets aux responsables et aux utilisateurs. À
6673 l'origine, les traductions des questionnaires debconf étaient gérées
6674 avec <prgn>debconf-mergetemplate</prgn>. Cependant, cette technique
6675 est maintenant déconseillée ; la meilleure façon pour
6676 l'internationalisation de <package>debconf</package> est d'utiliser le
6677 paquet <package>po-debconf</package>. Cette méthode est plus facile
6678 pour le responsable et pour les traducteurs ; des scripts de
6679 transition sont fournis.
6682 Lors de l'utilisation de <package>po-debconf</package>, la traduction
6683 est stockée dans des fichiers <file>po</file> (à l'instar des
6684 techniques de traduction de <prgn>gettext</prgn>). Des fichiers
6685 modèles contiennent les messages d'origine et indiquent quels sont les
6686 champs traduisibles. Quand vous modifiez l'état d'un champ traduisible
6687 en appelant <prgn>debconf-updatepo</prgn>, la traduction est marquée
6688 comme ayant besoin de l'attention des traducteurs. Puis, lors de la
6689 construction du paquet, le programme <prgn>dh_installdebconf</prgn>
6690 prendra soin de toute la magie nécessaire à l'ajout du modèle avec les
6691 traductions à jour dans les paquets binaires. Veuillez vous reporter à
6692 la page de manuel <manref section="7" name="po-debconf"> pour les
6696 <sect1 id="bpp-i18n-docs">
6698 Documentation traduite
6701 La traduction de la documentation est cruciale pour les utilisateurs,
6702 mais elle représente un important travail. Il n'existe aucun moyen
6703 d'éliminer ce travail, mais vous pouvez faciliter les choses pour les
6707 Si vous êtes responsable d'une documentation quelle que soit sa
6708 taille, il est plus facile pour les traducteurs d'avoir accès à un
6709 système de contrôle de source. Ceci permet aux traducteurs de voir les
6710 différences entre deux versions de la documentation, pour, par
6711 exemple, qu'ils puissent voir ce qui a besoin d'être retraduit. Il est
6712 recommandé que le document traduit inclue une note à propos de la
6713 révision de contrôle du source sur laquelle la traduction est
6714 basée. Un système intéressant est fourni par <url
6715 id="&url-i18n-doc-check;" name="doc-check"> dans le paquet
6716 <package>boot-floppies</package> qui donne un aperçu de l'état de la
6717 traduction pour une langue donnée, en utilisant les commentaires
6718 structurés pour une révision donnée du fichier à traduire et, pour un
6719 fichier traduit, la révision du fichier d'origine sur laquelle la
6720 traduction est basée. Vous pouvez vouloir adapter et fournir ceci dans
6721 votre référentiel CVS.
6724 Si vous maintenez de la documentation au format XML ou SGML, nous vous
6725 suggérons d'isoler les informations indépendantes de la langue et de
6726 les définir comme des entités dans un fichier séparé qui sera inclus
6727 par les différentes traductions. Ceci aide, par exemple, à garder à
6728 jour les adresses pour plusieurs fichiers.
6732 <sect id="bpp-common-situations">
6734 Pratiques communes d'empaquetage
6736 <sect1 id="bpp-autotools">
6738 Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
6741 Conserver à jour les fichiers d'<prgn>autoconf</prgn>,
6742 <file>config.sub</file> et <file>config.guess</file>, est critique
6743 pour les porteurs, spécialement pour les architectures plus
6744 changeantes. De très bonnes pratiques d'empaquetage utilisant
6745 <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été regroupées
6746 dans &file-bpp-autotools; du paquet
6747 <package>autotools-dev</package>. Vous êtes vivement encouragé à lire
6748 ce fichier et à suivre les recommandations indiquées.
6751 <sect1 id="bpp-libraries">
6756 Pour diverses raisons, il a toujours été difficile d'empaqueter les
6757 bibliothèques. La charte impose plusieurs contraintes pour faciliter
6758 la maintenance et pour garantir que les mises à jour sont aussi
6759 simples que possible quand une nouvelle version amont est
6760 disponible. Une erreur dans une bibliothèque peut rendre défectueux
6761 une douzaine de paquets qui en dépendent.
6764 Les bonnes pratiques d'empaquetage des bibliothèques ont été
6765 regroupées dans <url id="&url-libpkg-guide;" name="le guide
6766 d'empaquetage des bibliothèques">.
6769 <sect1 id="bpp-docs">
6774 Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html"
6775 name="règles sur la documentation">.
6778 Si votre paquet contient de la documentation construite à partir de
6779 XML ou SGML, nous vous recommandons de ne pas fournir le source XML ou
6780 SGML dans le(s) paquet(s) binaire(s). Si les utilisateurs désirent
6781 avoir le source de la documentation, ils peuvent récupérer le paquet
6785 La Charte spécifie que la documentation doit être fournie au format
6786 HTML. Nous vous recommandons également de la fournir au format PDF et
6787 texte simple si c'est adapté et qu'une sortie de qualité raisonnable
6788 est possible. Cependant, il n'est généralement pas approprié de
6789 fournir des versions en texte simple pour la documentation dont le
6790 format source est du HTML.
6793 Les principaux manuels fournis devraient être enregistrés par le
6794 paquet <package>doc-base</package> à l'installation. Reportez-vous à
6795 la documentation du paquet <package>doc-base</package> pour plus
6799 <sect1 id="bpp-other">
6801 Types spécifiques de paquets
6804 Plusieurs types spécifiques de paquets ont des sous-chartes spéciales
6805 et des règles et pratiques d'empaquetage correspondantes :
6809 Les paquets liés à Perl ont leur <url id="&url-perl-policy;"
6810 name="charte Perl">, quelques exemples de paquets qui suivent cette
6811 charte sont <package>libdbd-pg-perl</package> (module perl binaire)
6812 ou <package>libmldbm-perl</package> (module perl indépendant de
6818 Les paquets liés à Python ont leur charte Python ; voir
6819 &file-python-policy; dans le paquet <package>python</package>.
6824 Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;"
6825 name="charte Emacs">.
6830 Les paquets liés à Java ont leur <url id="&url-java-policy;"
6831 name="charte Java">.
6836 Les paquets liés à Ocaml ont leur propre charte que l'on trouve
6837 dans &file-ocaml-policy; du paquet <package>ocaml</package>. Un bon
6838 exemple est le paquet source <package>camlzip</package>.
6843 Les paquets fournissant des DTD XML ou SGML devraient se conformer
6844 aux recommandations que l'on peut trouver dans le paquet
6845 <package>sgml-base-doc</package>
6850 Les paquets Lisp devraient s'enregistrer avec le paquet
6851 <package>common-lisp-controller</package> pour lequel vous pouvez
6852 vous reporter au fichier &file-lisp-controller;.
6858 <sect1 id="bpp-archindepdata">
6860 Données indépendantes de l'architecture
6863 Il n'est pas rare d'avoir une grande quantité de données indépendantes
6864 de l'architecture fournie avec un programme. Par exemple, des fichiers
6865 audio, une collection d'icônes, des motifs de papiers peints ou autres
6866 fichiers graphiques. Si la taille des données est négligeable par
6867 rapport à la taille du reste du paquet, il est probablement mieux de
6868 tout garder dans le même paquet.
6871 Cependant, si la taille des données est considérable, vous devez
6872 envisager de les partager dans un paquet séparé et indépendant de
6873 l'architecture (« _all.deb »). Ainsi, en faisant cela, vous
6874 évitez une duplication inutile des mêmes données dans onze fichiers
6875 .debs pour chaque architecture. Bien que ceci ajoute une surcharge
6876 supplémentaire aux fichiers <file>Packages</file>, ceci sauve beaucoup
6877 d'espace disque sur les miroirs Debian. Séparer les données
6878 indépendantes de l'architecture réduit également le temps de
6879 traitement de <prgn>lintian</prgn> ou de <prgn>linda</prgn> (voir <ref
6880 id="tools-lint">) quand ils sont exécutés sur l'ensemble de l'archive
6884 <sect1 id="bpp-locale">
6886 Avoir besoin d'une certaine locale pendant la construction
6889 Si vous avez besoin d'une certaine locale pendant la construction,
6890 vous pouvez créer un fichier temporaire par cette astuce :
6893 Si vous positionnez LOCPATH à l'équivalent de /usr/lib/locale, et
6894 LC_ALL au nom de la locale que vous générez, vous devriez obtenir ce
6895 que vous voulez sans être root. Quelque chose comme ceci :
6897 LOCALE_PATH=debian/tmpdir/usr/lib/locale
6899 LOCALE_CHARSET=UTF-8
6901 mkdir -p $LOCALE_PATH
6902 localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
6905 LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
6909 <sect1 id="bpp-transition">
6911 Rendre les paquets de transition conformes avec deborphan
6914 Deborphan est un programme pour aider les utilisateurs à détecter
6915 quels paquets peuvent être enlevés sans problème du système, i.e. ceux
6916 dont aucun paquet ne dépend. L'opération par défaut est de chercher
6917 seulement parmi les sections libs et oldlibs pour débusquer les
6918 bibliothèques inutilisées. Mais si l'on passe le bon paramètre, il
6919 tente d'attraper d'autres paquets inutiles.
6922 Par exemple, avec --guess-dummy, deborphan cherche tous les paquets de
6923 transition qui étaient nécessaires pour une mise à jour, mais qui
6924 peuvent sans problème être supprimés. Pour cela, il recherche la
6925 chaîne de caractères « dummy » ou « transitional »
6926 dans la description courte.
6929 Ainsi, quand vous créez un tel paquet, assurez-vous d'ajouter ce texte
6930 dans la description courte. Si vous cherchez des exemples, exécutez
6932 <example>apt-cache search .|grep dummy</example>
6934 <example>apt-cache search .|grep transitional</example>
6938 <sect1 id="bpp-origtargz">
6940 Les meilleures pratiques pour les fichiers <file>orig.tar.gz</file>
6943 Il existe deux types d'archives tar (« tarball ») source
6944 d'origine : les sources vierges et les sources amont
6947 <sect2 id="pristinesource">
6952 La caractéristique définissant une archive source vierge est que le
6953 fichier .orig.tar.gz est identique octet-pour-octet à l'archive tar
6954 officielle distribuée par l'auteur amont. <footnote><p>Nous ne
6955 pouvons pas empêcher les auteurs amont de changer l'archive tar
6956 qu'ils distribuent sans également incrémenter le numéro de version,
6957 il ne peut donc pas y avoir de garantie qu'une archive vierge est
6958 identique à ce que l'auteur amont distribue <em>actuellement</em> à
6959 tout moment. La seule chose à laquelle on peut s'attendre est que
6960 c'est identique à quelque chose que l'amont <em>a</em> un jour
6961 distribuée. Si une différence se produit plus tard (par exemple, si
6962 l'amont remarque qu'il n'a pas utilisé la compression maximale pour
6963 sa distribution d'origine et qu'il la recompresse), c'est vraiment
6964 trop dommage. Comme il n'y a pas de bonne façon d'envoyer un nouveau
6965 .orig.tar.gz pour la même version, il n'y a même pas de raison de
6966 traiter cette situation comme un bogue.</p></footnote> Cela rend
6967 possible d'utiliser des vérifications de somme pour vérifier
6968 facilement que tous les changements entre la version Debian et celle
6969 de l'amont sont contenus dans le fichier diff Debian. Également, si
6970 le source amont est énorme, les auteurs amont et d'autres qui ont
6971 déjà l'archive tar amont peuvent économiser du temps de
6972 téléchargement s'ils veulent inspecter votre empaquetage en détail.
6975 Il n'y a pas de règles universellement acceptées suivies par les
6976 auteurs amont concernant la structure des répertoires dans leur
6977 archive tar, mais <prgn>dpkg-source</prgn> est cependant capable de
6978 traiter la plupart des archives tar comme source vierge. Sa stratégie
6979 est équivalente à la suivante :
6982 <enumlist numeration="arabic">
6985 Il décompacte l'archive tar dans un répertoire temporaire vide par
6987 zcat chemin/vers/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf -
6993 Si, après cela, le répertoire temporaire ne contient qu'un
6994 répertoire et pas d'autres fichiers, <prgn>dpkg-source</prgn>
6995 renomme ce répertoire en
6996 <tt><packagename>-<version-amont>(.orig)</tt>. Le nom
6997 du répertoire de premier niveau dans l'archive tar n'a pas
6998 d'importance et est oublié.
7003 Sinon, l'archive tar a dû être empaqueté sans répertoire de
7004 premier niveau commun (honte à l'auteur amont !). Dans ce
7005 cas, <prgn>dpkg-source</prgn> renomme le répertoire temporaire
7006 <em>lui-même</em> en
7007 <tt><packagename>-<version-amont>(.orig)</tt>.
7013 <sect2 id="repackagedorigtargz">
7015 Réempaquetage des sources amont
7018 Vous <strong>devriez</strong> envoyer des paquets sources avec une
7019 archive tar vierge si possible, mais il peut y avoir diverses raisons
7020 pour lesquelles cela n'est pas possible. C'est le cas si l'amont ne
7021 distribue pas le source comme un tar gzipé du tout ou si l'archive
7022 tar amont contient du matériel non libre au sens des DFSG que vous
7023 devez supprimer avant l'envoi.
7026 Dans tous ces cas, le développeur doit construire un fichier
7027 .orig.tar.gz convenable lui-même. Nous nous référerons à une telle
7028 archive tar comme un « source amont réempaqueté ». Notez
7029 qu'un « source amont réempaqueté » est différent d'un
7030 paquet natif Debian. Un source réempaqueté est toujours fourni avec
7031 des changements spécifiques Debian dans un fichier <tt>.diff.gz</tt>
7032 séparé et il a toujours un numéro de version composé de
7033 <tt><source-amont></tt> et de <tt><debian-revision></tt>.
7036 Il peut y avoir des cas où il est souhaitable de réempaqueter le
7037 source même si l'amont distribue un fichier <tt>.tar.gz</tt> qui
7038 pourrait en principe être utilisé dans sa forme vierge. Le plus
7039 évident est si des économies d'espaces <em>significatives</em>
7040 peuvent être réalisées en recompressant l'archive tar ou en
7041 supprimant des parties fondamentalement inutiles de l'archive
7042 source. Agissez à votre guise à cet endroit, mais soyez prêt à
7043 défendre votre décision si vous réempaquetez un source qui aurait pu
7047 Un .orig.tar.gz réempaqueté :
7050 <enumlist numeration="arabic">
7053 <strong>doit</strong> contenir des informations détaillées sur la
7054 façon dont a été obtenu le source réempaqueté et comment cela peut
7055 être reproduit dans le fichier <file>README.Debian-source</file>
7056 ou un fichier similaire. Ce fichier devrait être dans la partie
7057 <file>diff.gz</file> du paquet source Debian, habituellement dans
7058 le répertoire <file>debian</file>, <em>pas</em> dans le
7059 <file>orig.tar.gz</file> réempaqueté. C'est également une bonne
7060 idée de fournir une cible <tt>get-orig-source</tt> dans votre
7061 fichier <file>debian/rules</file> qui répète le processus, comme
7062 décrit dans la Charte, <url
7063 id="&url-debian-policy;ch-source.html#s-debianrules"
7064 name="debian/rules, le principal script de construction">.
7069 <strong>ne devrait pas</strong> contenir de fichiers qui ne
7070 viennent pas de l'auteur amont ou dont vous avez changé le
7071 contenu. <footnote><p>Comme exception spéciale, si l'omission d'un
7072 fichier non libre devait entraîner l'échec de la compilation du
7073 source sans assistance du diff Debian, il peut être approprié au
7074 lieu de cela d'éditer les fichiers, en omettant seulement les
7075 parties non libres de ceux-ci et/ou d'expliquer la situation dans
7076 un fichier README.Debian-source à la racine de l'arborescence du
7077 source. Mais dans ce cas, veuillez également demander instamment à
7078 l'auteur amont de faciliter la séparation des composants non
7079 libres du reste du source.</p></footnote>
7084 <strong>devrait</strong>, sauf cas impossible pour des raisons
7085 légales, préserver l'infrastructure de construction entière et de
7086 portabilité fournie par l'auteur amont. Par exemple, ce n'est pas
7087 une raison suffisante pour omettre un fichier qui n'est utilisé
7088 que pour la construction sur MS-DOS. De manière similaire, un
7089 Makefile fourni par l'amont ne devrait pas être réécrit en
7090 exécutant un script configure.
7093 (<em>Explication :</em> il est courant que les utilisateurs
7094 Debian qui ont besoin de reconstruire un logiciel pour des
7095 plates-formes non-Debian récupèrent le source d'un miroir Debian
7096 plutôt que de chercher à localiser un point de distribution
7102 <strong>devrait</strong> utiliser
7103 <tt><nom-du-paquet>-<version-amont>.orig</tt> comme
7104 nom du répertoire de premier niveau dans son archive tar. Cela
7105 rend possible la distinction entre des archives tar vierges
7106 d'archives réempaquetées.
7111 <strong>devrait</strong> être gzipé avec une compression maximale.
7117 La façon canonique de réaliser les deux derniers points est de
7118 laisser <tt>dpkg-source -b</tt> construire l'archive tar réempaquetée
7119 à partir du répertoire décompacté.
7122 <sect2 id="changed-binfiles">
7124 Changer des fichiers binaires dans le <tt>diff.gz</tt>
7127 Il est parfois nécessaire de changer des fichiers binaires contenus
7128 dans l'archive tar d'origine ou d'ajouter des fichiers binaires qui
7129 ne sont pas dans celle-ci. Si cela est fait en copiant simplement les
7130 fichiers dans l'arborescence de l'archive debianisée,
7131 <prgn>dpkg-source</prgn> ne pourra pas gérer cela. D'un autre côté,
7132 selon les règles détaillées ci-dessus, vous ne pouvez pas inclure un
7133 tel fichier binaire modifié dans un fichier <file>orig.tar.gz</file>
7134 réempaqueté. Au lieu de cela, incluez le fichier dans le répertoire
7135 <file>debian</file> dans un format <prgn>uuencode</prgn> (ou
7136 semblable) <footnote><p>Le fichier devrait avoir un nom qui indique
7137 clairement quel fichier binaire il encode. Habituellement, un
7138 postfixe indiquant le codage devrait être ajouté au nom du fichier
7139 d'origine. Notez que vous n'avez pas besoin de dépendre de
7140 <package>sharutils</package> pour avoir le programme
7141 <prgn>uudecode</prgn> si vous utilisez la fonction <tt>pack</tt> de
7142 <prgn>perl</prgn>. Le code pourrait ressembler à ceci :
7145 perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded
7148 perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file)
7150 </p></footnote>. Le fichier sera ensuite décodé et copié à
7151 son emplacement pendant l'étape de construction. Le changement sera
7152 donc visible assez facilement.
7155 Certains paquets utilisent <prgn>dbs</prgn> pour gérer les correctifs
7156 à leur source amont et créent toujours un nouveau fichier
7157 <tt>orig.tar.gz</tt> contenant le vrai <tt>orig.tar.gz</tt> dans son
7158 répertoire de premier niveau. Cela est discutable concernant la
7159 préférence pour un source vierge. D'un autre côté, il est facile de
7160 modifier ou d'ajouter des fichiers binaires dans ce cas : placez
7161 les simplement dans le fichier <tt>orig.tar.gz</tt> nouvellement créé
7162 à côté du vrai et copiez les au bon endroit pendant l'étape de
7169 <chapt id="beyond-pkging">
7171 Au-delà de l'empaquetage
7174 Debian, c'est beaucoup plus que de l'empaquetage de logiciels et de la
7175 maintenance de paquets. Ce chapitre contient des informations sur les
7176 façons, souvent vraiment importantes, de contribuer à Debian au-delà de
7177 la simple création et maintenance de paquets.
7180 En tant qu'organisation de volontaires, Debian repose sur la liberté de
7181 choisir ce sur quoi l'on désire travailler et de choisir la partie la
7182 plus importante à laquelle on veut consacrer son temps.
7184 <sect id="submit-bug">
7186 Rapporter des bogues
7189 Nous vous encourageons à remplir des rapports de bogue quand vous
7190 trouvez des bogues dans les paquets Debian. En fait, les développeurs
7191 Debian sont souvent les testeurs de première ligne. Trouver et
7192 rapporter les bogues dans les paquets d'autres développeurs améliore la
7196 Lisez les <url id="&url-bts-report;" name="instructions pour créer un
7197 rapport de bogue"> dans le <url id="&url-bts;" name="système de suivi
7198 des bogues"> Debian.
7201 Essayez de soumettre le bogue à partir d'un compte utilisateur normal
7202 sur lequel vous pouvez recevoir des courriers, pour que les personnes
7203 puissent vous joindre s'ils ont besoin de plus d'informations à propos
7204 du bogue. Ne soumettez pas de bogues en tant que root.
7207 Vous pouvez utiliser un outil comme <manref section="1"
7208 name="reportbug"> pour soumettre des bogues. Il peut automatiser et
7209 dans l'ensemble faciliter le processus.
7212 Assurez-vous que le bogue n'a pas déjà été rapporté. Chaque paquet
7213 dispose d'une liste de bogues facilement accessible à
7214 <tt>http://&bugs-host;/<var>nom_paquet</var></tt>. Des outils comme
7215 <manref section="1" name="querybts"> peuvent également vous fournir ces
7216 informations (et <prgn>reportbug</prgn> invoquera également
7217 habituellement <prgn>querybts</prgn> avant l'envoi).
7220 Essayez d'envoyer vos bogues au bon emplacement. Quand, par exemple,
7221 votre bogue concerne un paquet qui réécrit des fichiers d'un autre
7222 paquet, vérifiez les listes des bogues pour les <em>deux</em> paquets
7223 pour éviter de créer des rapports de bogues dupliqués.
7226 Vous pouvez également parcourir les bogues d'autres paquets, en les
7227 regroupant s'ils sont indiqués plus d'une fois, ou en les marquant avec
7228 « fixed » quand ils ont déjà été corrigés. Notez cependant
7229 que si vous n'êtes ni le rapporteur du bogue, ni le responsable du
7230 paquet, vous ne devriez pas fermer réellement le bogue (à moins que
7231 vous n'ayez obtenu la permission du responsable).
7234 De temps en temps, vous pourrez vouloir vérifier ce qui s'est passé à
7235 propos des bogues que vous avez rapportés. Saisissez cette occasion
7236 pour fermer les bogues que vous ne pouvez plus reproduire. Pour trouver
7237 tous les bogues que vous avez rapportés, vous avez simplement besoin
7239 <tt>http://&bugs-host;/from:<var><votre-adresse-de-courrier></var></tt>.
7241 <sect1 id="submit-many-bugs">
7243 Ouvrir un grand nombre de rapports en une seule fois (« mass bug
7247 Ouvrir un grand nombre de rapports pour le même problème sur un grand
7248 nombre de paquets — plus de dix — est une
7249 pratique que nous déconseillons. Prenez toutes les mesures possibles
7250 pour éviter cette situation. Si le problème peut être détecté
7251 automatiquement par exemple, ajoutez un nouveau test dans le paquet
7252 <package>lintian</package> pour générer une erreur ou un
7256 Si vous ouvrez plus de dix rapports sur le même sujet, il est
7257 préférable d'indiquer votre intention sur la liste
7258 &email-debian-devel; et de mentionner le fait dans le sujet de votre
7259 message. Cela donnera à d'autres développeurs la possibilité de
7260 vérifier que le problème existe vraiment. De plus, cela permet
7261 d'éviter que plusieurs responsables ne rédigent les mêmes rapports de
7262 bogue simultanément.
7265 Veuillez utiliser les programmes <prgn>dd-list</prgn> et si nécessaire,
7266 <prgn>whodepends</prgn> (du paquet <package>devscripts</package>) pour
7267 générer une liste de tous les paquets concernés et incluez la sortie
7268 dans votre courrier à &email-debian-devel;.
7271 Quand vous envoyez un grand nombre de rapports sur le même sujet, vous
7272 devriez les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils
7273 ne soient pas redirigés vers les listes de diffusion.
7277 <sect id="qa-effort">
7279 Effort d'assurance qualité
7281 <sect1 id="qa-daily-work">
7286 Bien qu'il y ait un groupe de personnes dédié à l'assurance qualité,
7287 les devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez
7288 participer à cet effort en conservant vos paquets aussi exempts de
7289 bogues que possible et aussi corrects que possible selon
7290 <prgn>lintian</prgn> (reportez-vous à <ref id="lintian">). Si cela
7291 vous paraît impossible, vous devriez alors envisager d'abandonner
7292 certains de vos paquets (reportez-vous à <ref id="orphaning">). Sinon,
7293 vous pouvez demander de l'aide à d'autres personnes pour qu'elles
7294 puissent rattraper votre retard dans la correction des bogues (vous
7295 pouvez demander de l'aide sur &email-debian-qa; ou
7296 &email-debian-devel;). En même temps, vous pouvez rechercher des
7297 co-responsables (reportez-vous à <ref id="collaborative-maint">).
7302 Les chasses aux bogues
7305 De temps en temps, le groupe d'assurance qualité organise des chasses
7306 aux bogues<footnote><p><em>Bug Squashing Party</em></p></footnote>
7307 pour essayer de supprimer le plus de problèmes possible. Elles sont
7308 annoncées sur &email-debian-devel-announce; et l'annonce explique quel
7309 domaine sera visé pendant la chasse : habituellement, il s'agit
7310 des bogues empêchant l'intégration du paquet dans la distribution
7311 (« Release Critical »), mais il peut arriver qu'ils décident
7312 d'aider à finir une transition majeure (comme une nouvelle version de
7313 Perl qui demande la recompilation de tous les modules binaires).
7316 Les règles pour les mises à jour indépendantes sont différentes au
7317 cours de la chasse parce que l'annonce de la chasse est considérée
7318 comme une annonce préalable pour les mises à jour indépendantes. Si
7319 vous avez des paquets qui peuvent être affectées par la chasse (parce
7320 qu'ils ont des bogues critiques par exemple), vous devriez envoyer une
7321 mise à jour pour chaque bogue correspondant pour expliquer leur état
7322 actuel et ce que vous attendez de la chasse. Si vous ne voulez pas
7323 d'une mise à jour indépendante ou si vous n'êtes intéressé que par un
7324 correctif ou si vous voulez gérer vous-même le bogue, veuillez
7325 l'expliquer dans le BTS.
7328 Les personnes qui participent à la chasse ont des règles spécifiques
7329 pour les mises à jour indépendantes, ils peuvent en faire une sans
7330 avertissement préalable s'ils envoient leur paquet avec un délai d'au
7331 moins 3 jours dans DELAYED/3-day. Toutes les autres règles de mise à
7332 jour indépendante s'appliquent comme d'habitude ; ils devraient
7333 envoyer le correctif de la mise à jour dans le BTS (pour l'un des
7334 bogues ouverts corrigé par la mise à jour ou pour un nouveau bogue
7335 marqué comme fixé). Ils devraient également respecter tout souhait du
7336 responsable s'il en a exprimé.
7339 Si vous ne vous sentez pas à l'aise avec une mise à jour indépendante,
7340 envoyez simplement un correctif au BTS. C'est de loin meilleur qu'une
7341 mise à jour défectueuse.
7345 <sect id="contacting-maintainers">
7347 Contacter d'autres responsables
7350 Pendant vos activités dans Debian, vous aurez à contacter d'autres
7351 responsables pour différentes raisons. Vous pourrez vouloir discuter
7352 d'une nouvelle façon de coopérer au sein d'un ensemble de paquets liés,
7353 ou vous pouvez simplement rappeler à quelqu'un qu'une nouvelle version
7354 est disponible et que vous en avez besoin.
7357 Chercher l'adresse d'un responsable d'un paquet peut être
7358 fastidieux. Heureusement, il existe un alias de courrier simple,
7359 <tt><paquet>@&packages-host;</tt>, qui fournit un moyen d'envoyer
7360 un courrier à un responsable, quelle que soit son adresse (ou ses
7361 adresses). Remplacez <tt><paquet></tt> par le nom du paquet
7365 Vous pouvez également vouloir contacter les personnes qui sont
7366 inscrites à un paquet de source donné par le <ref
7367 id="pkg-tracking-system">. Vous pouvez le faire en utilisant l'adresse
7368 <tt><paquet>@&pts-host;</tt>.
7373 Gérer les responsables non joignables
7376 Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous
7377 assurer que le responsable est toujours actif et qu'il continue à
7378 travailler sur ses paquets. Il est possible qu'il ne soit plus actif,
7379 mais qu'il ne se soit pas désenregistré du système. D'un autre côté, il
7380 est possible qu'il ait simplement besoin d'un rappel.
7383 Il y a un système simple (la base de données MIA) dans laquelle les
7384 informations sur les responsables supposés Absents En Exercice
7385 (« Missing In Action) sont enregistrées. Quand un membre du groupe
7386 QA contacte un responsable inactif ou trouve plus d'informations sur
7387 celui-ci, c'est enregistré dans la base de données MIA. Ce système est
7388 disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut
7389 être interrogé avec un outil de nom <prgn>mia-query</prgn>.
7390 Utilisez <example>mia-query --help</example> pour voir comment interroger
7391 la base de données. Si vous déterminez qu'aucune
7392 information n'a encore été enregistrée pour un responsable inactif ou
7393 si vous voulez ajouter plus d'informations, vous deviez utiliser la
7397 La première étape est de contacter poliment le responsable et
7398 d'attendre une réponse pendant un temps raisonnable. Il est assez
7399 difficile de définir le « temps raisonnable », mais il est
7400 important de prendre en compte que la vraie vie est parfois assez
7401 mouvementée. Une façon de gérer cela pourrait être d'envoyer un rappel
7402 après deux semaines.
7405 Si le responsable ne répond pas après quatre semaines (un mois), on
7406 peut supposer qu'il n'y aura probablement pas de réponse. Si ceci se
7407 produit, vous devriez poursuivre vos investigations et essayer de
7408 réunir toutes les informations utiles sur ce responsable. Ceci
7415 Les informations « echelon » disponibles dans la <url
7416 id="&url-debian-db;" name="base de données LDAP des développeurs">,
7417 qui indiquent quand le développeur a envoyé un message pour la
7418 dernière fois sur une liste de diffusion Debian (cela inclut les
7419 envois via les listes debian-*-changes). Rappelez-vous également de
7420 vérifier si le responsable est indiqué comme en vacances dans la
7426 Le nombre de paquets de ce responsable et les conditions de ces
7427 paquets. En particulier, reste-t-il des bogues empêchant
7428 l'intégration du paquet dans la distribution qui sont ouverts depuis
7429 des lustres ? De plus, combien de bogues y a-t-il en
7430 général ? Un autre point d'information important est si les
7431 paquets ont subi des mises à jour indépendantes et si oui, par qui.
7436 Est-ce que le responsable est actif en dehors de Debian ? Par
7437 exemple, il peut avoir envoyé des messages récemment à des listes de
7438 diffusion non-Debian ou des groupes de discussion.
7444 Un problème particulier est représenté par les paquets parrainés
7445 — le responsable n'est pas un développeur Debian
7446 officiel. Les informations « echelon » ne sont pas
7447 disponibles pour les personnes parrainées, par exemple, vous devez donc
7448 trouver et contacter le responsable Debian qui a réellement envoyé le
7449 paquet. Étant donné qu'il a signé le paquet, il est responsable de
7450 l'envoi de toute façon et il est probable qu'il sait ce qui s'est passé
7451 avec la personne qu'il parraine.
7454 Il est également permis d'envoyer une demande à &email-debian-devel;
7455 demandant si quelqu'un est au courant d'information sur le responsable
7456 manquant. Veuillez mettre en CC: la personne en question.
7459 Une fois que vous avez réuni toutes ces informations, vous pouvez
7460 contacter &email-mia;. Les personnes de cet alias utiliseront les
7461 informations que vous aurez fournies pour décider comment procéder. Par
7462 exemple, ils peuvent abandonner un ou tous les paquets du
7463 responsable. Si un paquet a subi une mise à jour indépendante, ils
7464 peuvent préférer contacter le responsable ayant fait cette mise à jour
7465 — il est peut-être intéressé par le paquet.
7468 Un dernier mot : veuillez vous souvenir d'être poli. Nous sommes
7469 tous des volontaires et nous ne pouvons dédier l'intégralité de notre
7470 temps à Debian. Vous n'êtes pas non plus au courant des circonstances
7471 de la personne impliquée. Elle est peut-être sérieusement malade ou
7472 pourrait même nous avoir quitté — vous ne savez pas qui
7473 recevra vos courriers. Imaginez comme un proche se sentira s'il lit un
7474 courrier pour la personne décédée et trouve un message très impoli, en
7475 colère et accusateur !
7478 D'un autre côté, bien que nous soyons tous volontaires, nous avons une
7479 responsabilité. Vous pouvez donc insister sur l'importance du plus
7480 grand intérêt — si un responsable n'a plus le temps ou
7481 l'envie, il devrait « laisser filer » et donner le paquet à
7482 quelqu'un ayant plus de temps.
7485 Si vous êtes intéressé pour travailler dans l'équipe MIA, veuillez
7486 étudier le fichier README dans /org/qa.debian.org/mia sur qa.debian.org
7487 où les détails techniques et les procédures MIA sont documentées et
7488 contactez &email-mia;.
7491 <sect id="newmaint">
7493 Interagir avec de futurs développeurs Debian
7496 Le succès de Debian dépend de sa capacité à attirer et retenir de
7497 nouveaux et talentueux volontaires. Si vous êtes un développeur
7498 expérimenté, nous vous recommandons de vous impliquer dans le processus
7499 d'apport des nouveaux responsables. Cette section décrit comment aider
7500 les futurs développeurs.
7502 <sect1 id="sponsoring">
7504 Parrainer des paquets
7507 Parrainer un paquet veut dire envoyer un paquet pour un responsable
7508 qui n'est pas encore autorisé à le faire lui-même, un candidat nouveau
7509 responsable. Parrainer un paquet veut aussi dire que vous en acceptez
7513 Les nouveaux responsables ont habituellement certaines difficultés à
7514 créer des paquets Debian — ceci est bien
7515 compréhensible. C'est pourquoi le parrain est là pour vérifier que le
7516 paquet parrainé est assez bon pour être inclus dans Debian. (Notez que
7517 si le paquet parrainé est nouveau, les ftpmasters devront également
7518 l'inspecter avant de l'intégrer)
7521 Effectuer un parrainage en signant simplement l'envoi ou en
7522 recompilant le paquet <strong>n'est définitivement pas
7523 recommandé</strong>. Vous devez construire le paquet source comme si
7524 vous vouliez construire l'un de vos paquets. Rappelez-vous que cela ne
7525 change rien si vous avez laissé le nom du candidat développeur dans le
7526 changelog et dans le fichier de contrôle, il est toujours possible de
7527 savoir que c'est vous qui avez fait l'envoi.
7530 Si vous êtes un gestionnaire de candidature pour un futur développeur,
7531 vous pouvez également être son parrain. Ainsi, vous pourrez vérifier
7532 comment le candidat gère la partie « Tâches et
7533 Capacités »<footnote><p>Tasks and Skills</p></footnote> de sa
7539 Gérer les paquets parrainés
7542 En envoyant un paquet sponsorisé vers Debian, vous certifiez que le
7543 paquet atteint les standards minimum de Debian. Ceci implique que vous
7544 devez construire et tester le paquet sur votre propre système avant
7548 Vous ne pouvez pas simplement envoyer un fichier <file>.deb</file>
7549 binaire d'un filleul. En théorie, vous devriez seulement demander le
7550 fichier diff et l'emplacement de l'archive source d'origine et ensuite
7551 vous devriez récupérer le source et appliquer le diff vous-même. En
7552 pratique, vous pouvez vouloir utiliser le paquet source construit par
7553 votre filleul. Dans ce cas, vous devez vérifier qu'il n'a pas modifié
7554 les fichiers sources du fichier <file>.orig.tar.gz</file> qu'il
7558 N'ayez pas peur de répondre au filleul et de lui indiquer les
7559 changements qu'il doit faire. Cela prend souvent plusieurs échanges de
7560 courriers avant que le paquet ne soit dans un état acceptable. Être un
7561 parrain veut dire être un mentor.
7564 Une fois que le paquet a atteint les standards Debian, construisez et
7565 signez le paquet avec
7566 <example>dpkg-buildpackage -k<var>KEY-ID</var></example>
7567 avant de l'envoyer dans le répertoire incoming. Bien sûr, vous pouvez
7568 également utiliser toute partie de votre <var>KEY-ID</var>, tant
7569 qu'elle est unique dans votre porte-clés secret.
7572 Le champ Maintainer du fichier <file>control</file> et le fichier
7573 <file>changelog</file> devraient afficher la personne qui a fait
7574 l'empaquetage, c'est-à-dire, le filleul. Celui-ci recevra donc tous
7575 les courriers du système de suivi des bogues (BTS) à propos de son
7579 Si vous préférez laisser une trace plus visible de votre travail de
7580 parrainage, vous pouvez ajouter une ligne l'indiquant dans la plus
7581 récente entrée du changelog.
7584 Vous êtes encouragé à garder un œil sur le suivi des paquets que
7585 vous parrainez en utilisant le <ref id="pkg-tracking-system">.
7590 Recommander un nouveau développeur
7593 Reportez-vous à la page sur les <url id="&url-newmaint-advocate;"
7594 name="recommandations pour un développeur prospectif"> sur le site web
7600 Gérer les candidatures des nouveaux candidats
7603 Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;"
7604 name="liste à vérifier pour les responsables de candidatures"> sur le
7612 Internationalisation, traduction, être internationalisé et être traduit
7615 Debian prend en charge un nombre toujours croissant de langues
7616 naturelles. Même si l'anglais est votre langue maternelle et que vous ne
7617 parlez pas d'autre langue, il est de votre devoir de responsable d'être
7618 conscient des problèmes d'internationalisation (abrégé en i18n à cause
7619 des 18 lettres entre le i et le n dans internationalisation). C'est
7620 pourquoi, même si des programmes seulement en anglais vous suffisent,
7621 vous devriez lire la plupart de ce chapitre.
7624 Selon l'<url id="http://www.debian.org/doc/manuals/intro-i18n/"
7625 name="introduction à l'i18n"> de Tomohiro KUBOTA, « I18N
7626 (internationalisation) veut dire la modification d'un logiciel ou de
7627 technologies liées pour qu'un logiciel puisse potentiellement gérer des
7628 langues multiples, des conventions multiples et ainsi de suite dans le
7629 monde entier » alors que « L10N (localisation) veut dire
7630 l'implémentation dans une langue spécifique pour un logiciel déjà
7631 internationalisé ».
7634 La l10n et l'i18n sont interconnectées, mais les difficultés liées à
7635 chacune sont très différentes. Il n'est pas vraiment difficile de
7636 permettre à un programme de changer la langue dans laquelle sont
7637 affichés les textes selon les paramètres de l'utilisateur, mais il est
7638 très coûteux en temps de traduire réellement ces messages. D'un autre
7639 côté, définir le codage des caractères est trivial, mais adapter le code
7640 pour utiliser des codages de caractères différents est un problème
7644 En laissant de côté les problèmes d'i18n pour lesquels il n'existe pas
7645 de règle générale, il n'y a pas actuellement d'infrastructure
7646 centralisée pour la l10n dans Debian qui puisse être comparée au
7647 mécanisme dbuild pour le portage. Le plus gros du travail doit donc être
7648 réalisé manuellement.
7650 <sect id="l10n-handling">
7652 Comment sont gérées les traductions au sein de Debian
7655 La gestion des traductions des textes contenus dans un paquet est
7656 encore une tâche manuelle et le processus dépend du type de texte que
7657 vous désirez voir traduit.
7660 Pour les messages des programmes, l'infrastructure gettext est utilisée
7661 pour la plupart d'entre eux. La plupart du temps, la traduction est
7662 gérée en amont dans des projets comme le <url
7663 id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="projet de
7664 traduction libre">, le <url
7665 id="http://developer.gnome.org/projects/gtp/" name="projet de
7666 traduction de Gnome"> ou <url id="http://i18n.kde.org/" name="celui de
7667 KDE">. La seule ressource centralisée dans Debian est les <url
7668 id="http://www.debian.org/intl/l10n/" name="statistiques de traduction
7669 Debian centralisées"> où vous pouvez trouver des statistiques sur les
7670 fichiers de traduction trouvés dans les paquets, mais il n'y a aucune
7671 infrastructure pour faciliter le processus de traduction.
7674 Un effort pour traduire les descriptions de paquet a démarré il y a
7675 longtemps, même si les outils fournissent très peu de prise en charge
7676 pour les utiliser vraiment (i.e., seul APT peut les utiliser quand il
7677 est configuré convenablement). Les responsables n'ont rien à faire de
7678 particulier pour gérer les traductions des descriptions de
7679 paquets ; les traducteurs devraient utiliser le <url
7680 id="http://ddtp.debian.org/" name="DDTP">.
7683 Pour les questionnaires debconf, les responsable devraient utiliser le
7684 paquet po-debconf pour faciliter le travail des traducteurs, qui
7685 peuvent utiliser le DDTP pour faire leur travail (mais les équipes
7686 française et brésilienne ne le font pas). On peut trouver certaines
7687 statistiques à la fois sur le site du DDTP (à propos de ce qui est
7688 vraiment traduit) et sur le site des <url
7689 id="http://www.debian.org/intl/l10n/" name="statistiques de traduction
7690 Debian centralisées"> (à propos de ce qui est intégré dans les
7694 Pour les pages web, chaque équipe l10n a accès au CVS correspondant et
7695 les statistiques sont disponibles sur le site des statistiques de
7696 traduction Debian centralisées.
7699 Pour la documentation générale à propos de Debian, le processus est
7700 plus ou moins le même que pour les pages web (les traducteurs ont accès
7701 au CVS), mais il n'y a pas de page de statistiques.
7704 Pour la documentation spécifique aux paquets (pages de manuel,
7705 documents info, autres formats), presque tout est encore à faire.
7708 Le plus notablement, le projet KDE gère la traduction de ses
7709 documentations de la même façon que ses messages de programme.
7712 Il existe un effort pour gérer les pages de manuel spécifiques Debian
7714 id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="dépôt CVS
7718 <sect id="l10n-faqm">
7720 FAQ I18N & L10N pour les responsables
7723 Voici une liste des problèmes que les responsables peuvent rencontrer
7724 concernant l'i18n et la l10n. Lorsque vous lirez cela, gardez à
7725 l'esprit qu'il n'y a pas de consensus sur ces points au sein de Debian
7726 et que ce ne sont que des conseils. Si vous avez une meilleure idée
7727 pour un problème donné ou si vous êtes en désaccord avec certains
7728 points, vous êtes libre de fournir vos impressions pour que ce document
7729 puisse être amélioré.
7731 <sect1 id="l10n-faqm-tr">
7733 Comment faire en sorte qu'un texte soit traduit
7736 Pour traduire des descriptions de paquet ou des questionnaires
7737 debconf, vous n'avez rien à faire, l'infrastructure du DDTP répartira
7738 le matériel à traduire aux volontaires sans besoin d'interaction de
7742 Pour tous les autres matériels (fichiers gettext, pages de manuel ou
7743 autre documentation), la meilleure solution est de placer votre texte
7744 quelque part sur l'Internet et de demander sur debian-i18n la
7745 traduction dans différentes langues. Certains membres des équipes de
7746 traduction sont abonnés à cette liste et ils prendront soin de la
7747 traduction et du processus de relecture. Une fois qu'ils ont fini,
7748 vous recevrez de leur part votre document traduit dans votre boîte aux
7752 <sect1 id="l10n-faqm-rev">
7754 Comment faire en sorte qu'une traduction donnée soit relue
7757 De temps en temps, des personnes indépendantes traduiront certains
7758 textes inclus dans votre paquet et vous demanderont d'inclure la
7759 traduction dans le paquet. Cela peut devenir problématique si vous
7760 n'êtes pas familier avec la langue donnée. C'est une bonne idée
7761 d'envoyer le document à la liste de diffusion l10n correspondante en
7762 demandant une relecture. Une fois celle-ci faite, vous devriez avoir
7763 plus confiance dans la qualité de la traduction et l'inclure sans
7764 crainte dans votre paquet.
7767 <sect1 id="l10n-faqm-update">
7769 Comment faire en sorte qu'une traduction donnée soit mise à jour
7772 Si vous avez certaines traductions d'un texte donné qui traînent,
7773 chaque fois que vous mettez à jour l'original, vous devriez demander
7774 au précédent traducteur de mettre à jour sa traduction avec vos
7775 nouveaux changements. Gardez à l'esprit que cette tâche demande du
7776 temps ; au moins une semaine pour obtenir une mise à jour relue.
7779 Si votre traducteur ne répond pas, vous pouvez demander de l'aide sur
7780 la liste de diffusion correspondante. Si tout échoue, n'oubliez pas de
7781 mettre un avertissement dans le document traduit, indiquant que la
7782 traduction est un peu obsolète et que le lecteur devrait se référer au
7783 document d'origine si possible.
7786 Évitez de supprimer complètement une traduction à cause de son
7787 obsolescence. Un vieux document est souvent mieux que pas de
7788 documentation du tout pour les personnes non anglophones.
7791 <sect1 id="l10n-faqm-bug">
7793 Comment gérer un rapport de bogue concernant une traduction
7796 La meilleure solution peut être de marquer le bogue comme « suivi
7797 au développeur amont » (<em>forwarded to upstream</em>) et de
7798 faire suivre le bogue à la fois au précédent traducteur et à son
7799 équipe (en utilisant la liste de diffusion debian-l10n-XXX
7804 <sect id="l10n-faqtr">
7806 FAQ I18N & L10N pour les traducteurs
7809 Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de procédure
7810 générale dans Debian concernant ces points et que, dans tous les cas,
7811 vous devriez collaborer avec votre équipe et les responsables des
7814 <sect1 id="l10n-faqtr-help">
7816 Comment aider l'effort de traduction
7819 Choisissez ce que vous désirez traduire, assurez-vous que personne ne
7820 travaille déjà dessus (en utilisant votre liste de diffusion
7821 debian-l10n-XXX), traduisez-le, faites-le relire par d'autres
7822 personnes dont c'est également la langue maternelle sur votre liste de
7823 diffusion l10n et fournissez-le au responsable du paquet (voir le
7827 <sect1 id="l10n-faqtr-inc">
7829 Comment fournir une traduction pour inclusion dans un paquet
7832 Assurez-vous que votre traduction est correcte (en demandant une
7833 relecture sur votre liste de discussion l10n) avant de la fournir pour
7834 inclusion. Cela gagnera du temps à tout le monde et évitera le chaos
7835 qui résulterait d'avoir plusieurs versions du même document dans les
7839 La meilleure solution est de créer un rapport de bogue standard
7840 contenant la traduction sur le paquet. Assurez-vous d'utiliser
7841 l'étiquette « patch » et n'utilisez pas une gravité
7842 supérieure à « wishlist » car l'absence de traduction n'a
7843 jamais empêché un programme de fonctionner.
7847 <sect id="l10n-best">
7849 Meilleures pratiques actuelles concernant la l10n
7855 En tant que responsable, ne modifiez jamais les traductions en
7856 aucune façon (même pour reformater l'affichage) sans demander à la
7857 liste de diffusion l10n correspondante. Vous risquez, par exemple,
7858 de casser le codage du fichier en agissant ainsi. De plus, ce que
7859 vous considérez comme une erreur peut être correct (ou même
7860 nécessaire) pour une langue donnée.
7865 En tant que traducteur, si vous trouvez une erreur dans le texte
7866 d'origine, assurez-vous de l'indiquer. Les traducteurs sont souvent
7867 les lecteurs les plus attentifs d'un texte donné et s'ils ne rendent
7868 pas compte des erreurs qu'ils trouvent, personne ne le fera.
7873 Dans tous les cas, rappelez-vous que le problème principal avec la
7874 l10n est qu'elle demande la coopération de plusieurs personnes et
7875 qu'il est très facile de démarrer une guerre incendiaire à propos de
7876 petits problèmes dûs à des incompréhensions. Donc, si vous avez des
7877 problèmes avec votre interlocuteur, demandez de l'aide sur la liste
7878 de diffusion l10n correspondante, sur debian-i18n ou même sur
7879 debian-devel (attention, cependant, les discussions sur la l10n
7880 tournent très souvent à l'incendie sur cette liste :)
7885 Dans tous les cas, la coopération ne peut être atteinte qu'avec un
7886 <strong>respect mutuel</strong>.
7893 <appendix id="tools">
7895 Aperçu des outils du responsable Debian
7898 Cette section contient un aperçu rapide des outils dont dispose le
7899 responsable. Cette liste n'est ni complète, ni définitive, il s'agit
7900 juste d'un guide des outils les plus utilisés.
7903 Les outils du responsable Debian sont destinés à aider les responsables
7904 et libérer leur temps pour des tâches plus cruciales. Comme le dit Larry
7905 Wall, il y a plus d'une manière de le faire.
7908 Certaines personnes préfèrent utiliser des outils de haut niveau,
7909 d'autres pas. Debian n'a pas de position officielle sur la
7910 question ; tout outil conviendra du moment qu'il fait le
7911 boulot. C'est pourquoi cette section n'a pas été conçue pour indiquer à
7912 chacun quel outil il doit utiliser ou comment il devrait faire pour
7913 gérer sa charge de responsable Debian. Elle n'est pas non plus destinée
7914 à favoriser l'utilisation d'un outil aux dépens d'un autre.
7917 La plupart des descriptions de ces outils proviennent des descriptions
7918 de leurs paquets. Vous trouverez plus d'informations dans les
7919 documentations de ces paquets. Vous pouvez aussi obtenir plus
7920 d'informations avec la commande <tt>apt-cache show
7921 <nom_paquet></tt>.
7923 <sect id="tools-core">
7928 Les outils suivants sont pratiquement nécessaires à tout responsable.
7930 <sect1 id="dpkg-dev">
7932 <package>dpkg-dev</package>
7935 Le paquet <package>dpkg-dev</package> contient les outils (y compris
7936 <prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et
7937 livrer des paquets Debian source. Ces utilitaires fournissent les
7938 fonctionnalités de bas niveau indispensables pour créer et manipuler
7939 les paquets ; en tant que tels, ils sont essentiels à tout
7943 <sect1 id="debconf">
7945 <package>debconf</package>
7948 Le paquet <package>debconf</package> fournit une interface unifiée
7949 pour configurer les paquets interactivement. Il est indépendant de
7950 l'interface et permet une configuration en mode texte, par une
7951 interface HTML ou par boîtes de dialogue. D'autres types d'interface
7952 peuvent être ajoutés sous forme de modules.
7955 Vous trouverez la documentation de ce paquet dans le paquet
7956 <package>debconf-doc</package>.
7959 Beaucoup pensent que ce système devrait être utilisé pour tout paquet
7960 nécessitant une configuration interactive ; reportez-vous à la
7961 <ref id="bpp-config-mgmt">. <package>debconf</package> n'est pas
7962 requis par la <em>charte Debian</em> pour le moment ; cependant,
7963 cela pourra changer.
7966 <sect1 id="fakeroot">
7968 <package>fakeroot</package>
7971 <package>fakeroot</package> simule les privilèges <em>root</em>. Cela
7972 permet de fabriquer un paquet sans être root (en général, les paquets
7973 installent des fichiers appartenant à <em>root</em>). Si vous avez
7974 installé <package>fakeroot</package>, vous pouvez construire un paquet
7975 en tant que simple utilisateur avec : <tt>dpkg-buildpackage
7980 <sect id="tools-lint">
7982 Outils du paquet lint
7985 Selon le « Free On-line Dictionary of Computing » (FOLDOC),
7986 « lint » est « un outil de traitement de langage C qui
7987 contient beaucoup plus de tests complets sur le code que n'en font
7988 habituellement les compilateurs C. ». Les outils du paquet lint
7989 aide les responsables de paquet à trouver automatiquement des problèmes
7990 habituels et des violations de charte dans leurs paquets
7992 <sect1 id="lintian">
7994 <package>lintian</package>
7997 <package>lintian</package> dissèque les paquets pour y repérer des
7998 bogues et des manquements aux règles de développement. Il contient des
7999 tests automatisés pour vérifier de nombreuses règles et quelques
8003 Vous devriez récupérer la dernière version de
8004 <package>lintian</package> depuis <em>unstable</em> régulièrement et
8005 vérifier tous vos paquets. Notez que l'option <tt>-i</tt> donne des
8006 explications détaillées sur la signification de chaque erreur, la
8007 partie concernée dans la charte et le moyen habituel de régler le
8011 Veuillez vous reporter à <ref id="sanitycheck"> pour plus
8012 d'informations sur comment et quand utiliser Lintian.
8015 Vous pouvez aussi obtenir un résumé de tous les problèmes reportés par
8016 Lintian sur vos paquets à <url id="&url-lintian;">. Ces rapports
8017 contiennent la sortie de la dernière version de <prgn>lintian</prgn>
8018 pour l'ensemble de la distribution de développement
8019 (<em>unstable</em>).
8024 <package>linda</package>
8027 <package>linda</package> est un autre vérificateur de paquet. Il est
8028 semblable à <package>lintian</package>, mais il a un ensemble de tests
8029 différents. Il est écrit en Python plutôt qu'en Perl.
8032 <sect1 id="debdiff">
8034 <package>debdiff</package>
8037 <prgn>debdiff</prgn> (du paquet <package>devscripts</package>, <ref
8038 id="devscripts">) compare des listes de fichiers et des fichiers de
8039 contrôle de deux paquets. C'est un simple test de régression qui peut
8040 vous aider à remarquer si le nombre de paquets binaires a changé
8041 depuis le dernier envoi ou si autre chose a changé dans le fichier de
8042 contrôle. Bien sûr, certains des changements qu'il indique sont
8043 normaux, mais il peut aider à empêcher différents accidents.
8046 Vous pouvez l'exécuter sur un couple de paquets binaires :
8048 debdiff package_1-1_arch.deb package_2-1_arch.deb
8052 Ou même sur un couple de fichiers de changements :
8054 debdiff package_1-1_arch.changes package_2-1_arch.changes
8058 Pour plus d'informations, veuillez voir <manref section="1"
8063 <sect id="tools-helpers">
8065 Aides pour le fichier <file>debian/rules</file>
8068 Des outils de construction de paquets rendent le processus d'écriture
8069 du fichier <file>debian/rules</file> plus facile. Veuillez voir les
8070 <ref id="helper-scripts"> pour plus d'informations sur les raisons pour
8071 lesquelles ils peuvent être désirables ou non.
8073 <sect1 id="debhelper">
8075 <package>debhelper</package>
8078 Le paquet <package>debhelper</package> regroupe un ensemble de
8079 programmes qui peuvent être utilisés dans <file>debian/rules</file>
8080 pour automatiser les tâches courantes relatives à la fabrication des
8081 paquets Debian binaires. <package>debhelper</package> inclut des
8082 programmes pour installer différents fichiers, les compresser, ajuster
8083 leurs droits et intégrer votre paquet dans le système de menu Debian.
8086 À la différence d'autres approches, <package>debhelper</package> est
8087 divisé en plusieurs petits utilitaires simples qui agissent de manière
8088 cohérente. Ce découpage permet un contrôle des opérations plus fin que
8089 certains des autres « <em>outils debian/rules</em> ».
8092 Il existe aussi un certain nombre de petites extensions
8093 <package>debhelper</package> trop éphémères pour être
8094 documentées. Vous en listerez la plupart en faisant <tt>apt-cache
8098 <sect1 id="debmake">
8100 <package>debmake</package>
8103 <package>debmake</package> — un précurseur de
8104 <package>debhelper</package> — est un assistant moins modulaire
8105 pour manipuler le fichier <file>debian/rules</file>. Il inclut deux
8106 programmes principaux : <prgn>deb-make</prgn>, utile au
8107 développeur Debian pour convertir un paquet source normal (non-Debian)
8108 en paquet source Debian, et <prgn>debstd</prgn> qui regroupe le type
8109 de fonction que l'on trouve dans <package>debhelper</package>.
8112 Le consensus actuel est que l'utilisation de
8113 <package>debmake</package> est déconseillée au profit de
8114 <package>debhelper</package>. C'est un bogue d'utiliser
8115 <package>debmake</package> pour les nouveaux paquets. Les nouveaux
8116 paquets utilisant <package>debmake</package> seront rejetés de
8120 <sect1 id="dh-make">
8122 <package>dh-make</package>
8125 Le paquet <package>dh-make</package> contient <prgn>dh_make</prgn>, un
8126 programme qui crée un squelette de fichiers nécessaires à la
8127 construction d'un paquet Debian à partir d'une arborescence
8128 source. Comme le nom le suggère, <prgn>dh_make</prgn> est une
8129 réécriture de <package>debmake</package> et ses fichiers modèles
8130 utilisent les programmes dh_* de <package>debhelper</package>.
8133 Quoique les fichiers de règles fabriqués par <prgn>dh_make</prgn>
8134 constituent en général une base suffisante pour un paquet fonctionnel,
8135 ce ne sont que les fondations : la charge incombe toujours au
8136 responsable d'affiner les fichiers générés et de rendre le paquet
8137 complètement fonctionnel et en conformité avec la charte.
8142 <package>yada</package>
8145 Le paquet <package>yada</package> est un autre assistant pour la
8146 création de paquets. Il utilise un fichier
8147 <file>debian/packages</file> pour générer <file>debian/rules</file> et
8148 d'autres fichiers nécessaires dans le sous-répertoire
8149 <file>debian/</file>. Le fichier <file>debian/packages</file> contient
8150 des instructions pour construire les paquets et il n'y a pas besoin de
8151 créer de fichiers <file>Makefile</file>. Il existe la possibilité
8152 d'utiliser un moteur de macros semblable à celui utilisé dans les
8153 fichiers SPECS des paquets source RPM.
8156 Pour plus d'informations, voir le <tt><url
8157 id="http://yada.alioth.debian.org/" name="site de YADA"></tt>.
8162 <package>equivs</package>
8165 <package>equivs</package> est un autre paquet pour faire des
8166 paquets. Il est souvent conseillé pour un usage local, si vous avez
8167 besoin de faire un paquet pour satisfaire des dépendances. Il est
8168 aussi parfois utilisé pour faire des « méta-paquets » qui
8169 sont des paquets dont l'unique objet est de dépendre d'autres paquets.
8173 <sect id="tools-builders">
8175 Constructeurs de paquets
8178 Les paquets suivants aident le processus de construction des paquets,
8179 en général en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que la
8180 gestion du support de tâches.
8182 <sect1 id="cvs-buildpackage">
8184 <package>cvs-buildpackage</package>
8187 Le paquet <package>cvs-buildpackage</package> permet de mettre à jour
8188 ou de récupérer des paquets sources dans un référentiel CVS, il permet
8189 de fabriquer un paquet Debian depuis le référentiel CVS et il assiste
8190 le développeur lors de l'intégration de modifications amont dans le
8194 Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS
8195 pour le responsable Debian. Il permet de conserver des branches CVS
8196 distinctes pour les distributions <em>stable</em>, <em>unstable</em>
8197 et probablement <em>experimental</em> et de bénéficier des avantages
8198 d'un système de contrôle de version.
8201 <sect1 id="debootstrap">
8203 <package>debootstrap</package>
8206 Le paquet <package>debootstrap</package> vous permet d'amorcer un
8207 système Debian de base à n'importe quel endroit dans votre système de
8208 fichiers. Par « système de base », nous entendons le strict
8209 minimum nécessaire pour fonctionner et installer le reste du système.
8212 Avoir un système comme celui-ci peut vous servir de différentes
8213 manières. Vous pouvez, par exemple, déplacer votre racine dans ce
8214 système avec <prgn>chroot</prgn> pour tester vos dépendances de
8215 construction. Vous pouvez aussi l'utiliser pour voir comment se
8216 comporte votre paquet quand il est installé dans un environnement
8220 <sect1 id="pbuilder">
8222 <package>pbuilder</package>
8225 <package>pbuilder</package> construit un système « chrooté »
8226 et compile des paquets dans ce système. Ceci est très utile pour
8227 vérifier que les dépendances de compilation de votre paquet sont
8228 correctes et pour vous assurer qu'aucune dépendance de construction
8229 inutile ou incorrecte n'existe dans le paquet résultant.
8232 Un paquet lié est <package>pbuilder-uml</package>, qui va même plus
8233 loin en réalisant la construction au sein d'un environnement
8234 « User Mode Linux ».
8239 <package>sbuild</package>
8242 <package>sbuild</package> est un autre compilateur automatique. Il
8243 peut aussi être utilisé dans un environnement
8244 « chrooté ». Il peut être utilisé seul ou comme partie d'un
8245 environnement de compilation distribué en réseau. Comme le précédent,
8246 c'est une partie du système utilisé par les porteurs pour construire
8247 des paquets binaires pour toutes les architectures
8248 disponibles. Veuillez vous reporter à <ref id="buildd"> pour plus
8249 d'informations et à <url id="&url-buildd;"> pour voir le système en
8254 <sect id="uploaders">
8256 Téléchargeurs de paquets
8259 Les paquets suivants aident à automatiser ou à simplifier le processus
8260 d'envoi de paquets dans l'archive officielle.
8262 <sect1 id="dupload">
8264 <package>dupload</package>
8267 Le paquet <package>dupload</package> contient un script du même nom
8268 pour mettre à jour des paquets dans l'archive Debian, tracer les mises
8269 à jour et les annoncer par courrier électronique automatiquement. Vous
8270 pouvez le configurer pour faire des mises à jour à d'autres endroits
8271 et avec d'autres méthodes.
8276 <package>dput</package>
8279 Le script <package>dput</package> fait à peu près la même chose que
8280 <package>dupload</package>, mais il le fait différemment. Il a aussi
8281 quelques fonctions supplémentaires telles que la possibilité de
8282 vérifier la signature GnuPG et les sommes de contrôles avant le
8283 téléchargement et la possibilité de démarrer <prgn>dinstall</prgn> en
8284 mode simulation (<em>dry-run</em>) après le téléchargement.
8289 <package>dcut</package>
8292 Le script <package>dcut</package> (faisant partie du paquet <ref
8293 id="dput">) aide à la suppression de fichiers du répertoire d'envoi
8298 <sect id="tools-maint-automate">
8300 Automatisation de la maintenance
8303 Les outils suivants aident à automatiser les différentes tâches de
8304 maintenance par l'ajout des entrées de changelog ou de lignes de
8305 signatures, par la recherche de bogues à partir d'Emacs et par
8306 l'utilisation du fichier officiel <file>config.sub</file> le plus
8309 <sect1 id="devscripts">
8311 <package>devscripts</package>
8314 Le paquet <package>devscripts</package> contient des scripts et outils
8315 qui sont très utiles pour maintenir vos paquets Debian. Parmi ces
8316 scripts, vous trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui
8317 manipulent votre fichier <file>debian/changelog</file> depuis la ligne
8318 de commande et <prgn>debuild</prgn> qui est construit au-dessus de
8319 <prgn>dpkg-buildpackage</prgn>. L'outil <prgn>bts</prgn> est également
8320 très utile pour mettre à jour l'état des rapports de bogue depuis la
8321 ligne de commande. Le programme <prgn>uscan</prgn> peut être utilisé
8322 pour suivre les nouvelles versions amont de vos paquets. Le programme
8323 <prgn>debrsign</prgn> peut être utilisé pour signer à distance un
8324 paquet avant de l'envoyer, ce qui est agréable quand la machine sur
8325 laquelle vous construisez le paquet est différente de celle où
8326 résident vos clés GPG.
8329 Vérifiez la page de manuel <manref section="1" name="devscripts"> pour
8330 une liste complète des scripts disponibles.
8333 <sect1 id="autotools-dev">
8335 <package>autotools-dev</package>
8338 <package>autotools-dev</package> contient les meilleurs pratiques pour
8339 des personnes assurant la maintenance de paquets qui utilisent
8340 <prgn>autoconf</prgn> et/ou <prgn>automake</prgn>. Contient également
8341 des fichiers canoniques <file>config.sub</file> et
8342 <file>config.guess</file> qui sont connus pour fonctionner avec tous
8343 les portages Debian.
8346 <sect1 id="dpkg-repack">
8348 <package>dpkg-repack</package>
8351 <prgn>dpkg-repack</prgn> crée un paquet Debian à partir d'un paquet
8352 qui a déjà été installé. Si des changements ont été effectués sur le
8353 paquet quand il a été décompacté (par exemple, des fichiers dans
8354 <file>/etc</file> ont été modifiés), le nouveau paquet héritera de ces
8358 Cet utilitaire peut faciliter la copie de paquet d'un ordinateur vers
8359 un autre ou la re-création de paquets installés sur un système, mais
8360 qui ne sont plus disponibles ailleurs ou pour sauvegarder l'état
8361 actuel d'un paquet avant de le mettre à jour.
8366 <package>alien</package>
8369 <prgn>alien</prgn> convertit des paquets binaires entre différents
8370 formats de paquets, y compris des paquets Debian, RPM (RedHat), LSB
8371 (Linux Standard Base), Solaris et Slackware.
8374 <sect1 id="debsums">
8376 <package>debsums</package>
8379 <prgn>debsums</prgn> vérifie des paquets installés par rapport à leur
8380 somme de hachage MD5. Veuillez noter que tous les paquets n'ont pas de
8381 sommes MD5 car elles ne sont pas requises par la charte.
8384 <sect1 id="dpkg-dev-el">
8386 <package>dpkg-dev-el</package>
8389 <package>dpkg-dev-el</package> fournit des macros Emacs Lisp qui
8390 apportent une aide lors de l'édition des fichiers du répertoire
8391 <file>debian</file> de votre paquet. Par exemple, il y a des fonctions
8392 pratiques pour lister les bogues actuels d'un paquet et pour finaliser
8393 la dernière entrée d'un fichier <file>debian/changelog</file> file.
8396 <sect1 id="dpkg-depcheck">
8398 <package>dpkg-depcheck</package>
8401 <prgn>dpkg-depcheck</prgn> (du paquet <package>devscripts</package>,
8402 <ref id="devscripts">) exécute une commande sous <prgn>strace</prgn>
8403 pour déterminer tous les paquets utilisés par la commande.
8406 Pour les paquets Debian, c'est utile quand vous devez créer une ligne
8407 <tt>Build-Depends</tt> pour votre nouveau paquet : exécuter le
8408 processus de compilation avec <prgn>dpkg-depcheck</prgn> vous fournira
8409 une bonne première approximation des dépendances de compilation. Par
8412 dpkg-depcheck -b debian/rules build
8416 <prgn>dpkg-depcheck</prgn> peut aussi être utilisé pour vérifier les
8417 dépendances d'exécution, particulièrement si votre paquet utilise
8418 exec(2) pour exécuter d'autres programmes.
8421 Pour plus d'informations, veuillez voir <manref section="1"
8422 name="dpkg-depcheck">.
8426 <sect id="tools-porting">
8431 Les outils suivants facilitent le travail des porteurs et la
8432 compilation croisée.
8434 <sect1 id="quinn-diff">
8436 <package>quinn-diff</package>
8439 <package>quinn-diff</package> est utilisé pour localiser les
8440 différences d'une architecture à l'autre. Il pourrait vous dire, par
8441 exemple, quels paquets de l'architecture <var>X</var> doivent être
8442 portés sur l'architecture <var>Y</var>.
8445 <sect1 id="dpkg-cross">
8447 <package>dpkg-cross</package>
8450 <package>dpkg-cross</package> est un outil qui installe les
8451 bibliothèques et les en-têtes nécessaires à une compilation
8452 croisée<footnote><p><em>cross-compilation</em></p></footnote> d'une
8453 manière similaire à <package>dpkg</package>. De plus, les paquets
8454 <prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
8455 améliorés pour accepter les compilations croisées.
8459 <sect id="tools-doc">
8461 Documentation et information
8464 Les paquets suivants fournissent des informations pour les responsables
8465 ou de l'aide pour construire de la documentation
8467 <sect1 id="debiandoc-sgml">
8469 <package>debiandoc-sgml</package>
8472 <package>debiandoc-sgml</package> fournit la DTD DebianDoc SGML qui
8473 est habituellement utilisée pour la documentation Debian. Ce manuel,
8474 par exemple, est écrit en DebianDoc. Il fournit également des scripts
8475 pour construire et décliner le source en de multiples formats de
8479 La documentation sur la DTD peut être trouvée dans le paquet
8480 <package>debiandoc-sgml-doc</package>.
8483 <sect1 id="debian-keyring">
8485 <package>debian-keyring</package>
8488 Contient les clés publiques GPG et PGP des développeurs Debian. Voir
8489 <ref id="key-maint"> et la documentation du paquet pour plus
8493 <sect1 id="debview">
8495 <package>debview</package>
8498 <package>debview</package> fournit un mode Emacs pour voir les paquets
8499 binaires Debian. Il vous permet d'examiner un paquet sans le