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.58 $">
11 <!-- if you are translating this document, please notate the CVS
12 revision of the developers reference here -->
13 <!-- <!ENTITY cvs-en-rev "1.282"> -->
15 <!-- how to mark a section that needs more work -->
16 <!ENTITY FIXME "<em>FIXME:</em> ">
22 <title>Référence du développeur Debian
24 <author>L'équipe de la Référence du développeur &email-devel-ref;
27 <author>Raphaël Hertzog
28 <author>Christian Schwarz
31 <translator>version française par Frédéric Bothamy (traducteur actuel)</translator>
32 <translator>et Antoine Hulin (ancien traducteur)</translator>
33 <translator>et les membres de la liste <email>debian-l10n-french@lists.debian.org</email></translator>
34 <version>Version &version;, &date-fr; (version française 20051114).</version>
37 <copyrightsummary>Copyright © 2004—2005 Andreas Barth</copyrightsummary>
38 <copyrightsummary>Copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
39 <copyrightsummary>Copyright © 2002—2003 Raphaël Hertzog</copyrightsummary>
40 <copyrightsummary>Copyright © 1997, 1998 Christian Schwarz.</copyrightsummary>
42 Ce manuel est un logiciel libre ; il peut être redistribué et/ou modifié
43 selon les termes de la licence publique générale du projet GNU (GNU GPL), telle
44 que publiée par la « Free Software Foundation » (version 2 ou toute
48 Il est distribué dans l'espoir qu'il sera utile, mais <em>sans aucune
49 garantie</em>, sans même la garantie implicite d'une possible valeur marchande
50 ou d'une adéquation à un besoin particulier. Consultez la licence publique
51 générale du projet GNU pour plus de détails.
53 <p>Une copie de la licence publique générale du projet GNU est disponible dans
54 le fichier &file-GPL; de la distribution &debian-formal; ou sur la toile :
55 <url id="&url-gpl" name="la licence publique générale du projet GNU">. Vous
56 pouvez également l'obtenir en écrivant à la &fsf-addr;.
60 Si vous désirez imprimer cette référence, vous devriez utiliser la <url
61 id="developers-reference.pdf" name="version PDF">.
62 Cette page est également disponible en <url id="index.en.html" name="anglais">.
67 <chapt id="scope">Portée de ce document
70 Le but de ce document est de donner une vue d'ensemble des procédures à suivre
71 et des ressources mises à la disposition des développeurs Debian.
73 <!-- FIXME: rewrites -->
75 Les procédures décrites ci-après expliquent comment devenir responsable Debian
76 (<ref id="new-maintainer">), comment créer de nouveaux paquets (<ref
77 id="newpackage">) et comment les installer dans l'archive (<ref id="upload">),
78 comment gérer les rapports de bogues (<ref id="bug-handling">), comment
79 déplacer, effacer ou abandonner un paquet (<ref id="archive-manip">), comment
80 faire le portage d'un paquet (<ref id="porting">), quand et comment faire la
81 mise à jour du paquet d'un autre responsable (<ref id="nmu">).
84 Les ressources présentées dans ce manuel incluent les listes de diffusion (<ref
85 id="mailing-lists">) et les serveurs (<ref id="server-machines">), une
86 présentation de la structure de l'archive Debian (<ref id="archive">), des
87 explications sur les serveurs qui acceptent les mises à jour de paquets (<ref
88 id="upload-ftp-master">) et une présentation des outils qui peuvent aider un
89 responsable à améliorer la qualité de ses paquets (<ref id="tools">).
92 Ce manuel de référence ne présente pas les aspects techniques liés aux paquets
93 Debian, ni comment les créer. Il ne décrit pas non plus les règles que doivent
94 respecter les paquets Debian. Cette information est disponible dans la <url
95 id="&url-debian-policy;" name="charte Debian">.
98 De plus ce document <em>n'est pas l'expression d'une politique officielle</em>.
99 Il contient de la documentation sur le système Debian et des conseils pratiques
100 largement suivis. Ce n'est donc pas une sorte de guide de normes.
102 <sect>Introduction à la version française
107 Bien que ce document soit en français, l'activité de responsable Debian implique
108 une maîtrise de la langue anglaise. Le projet Debian est un projet international
109 auquel participent des japonais, néo-zélandais, américains, allemands,
110 finlandais, français, espagnols, danois, etc.
113 En conséquence, la langue utilisée dans toutes les listes de diffusion destinées
114 aux développeurs (à l'exception de la liste
115 <email>debian-devel-french@&lists-host;</email>) est l'anglais et les rapports
116 de bogue doivent être rédigés en anglais. En fait, sauf exception rare, tout
117 dialogue avec les autres responsables Debian se fera en anglais quel que soit le
124 Cette section liste les termes techniques qui ont un sens spécifique dans le
125 projet Debian. Pour chacune de ces expressions, vous trouverez la traduction
126 française utilisée dans ce manuel, une définition et une référence à la section
127 du manuel qui traite de ce sujet.
131 <item><em>Upload</em> : mise à jour, téléchargement (parfois
132 livraison). Opération qui consiste à télécharger un nouveau paquet ou
133 une nouvelle version de paquet dans l'archive Debian (<ref
136 <item><em>Non-maintainer upload (NMU)</em> : mise à jour
137 indépendante. Téléchargement d'une nouvelle version de paquet dans
138 l'archive Debian par une personne qui n'est pas officiellement
139 responsable de ce paquet (<ref id="nmu">).
141 <item><em>Source NMU</em> : mise à jour indépendante source. Il
142 s'agit d'une mise à jour indépendante pour un paquet source (<ref
145 <item><em>Binary NMU</em> : mise à jour indépendante binaire. Mise
146 à jour indépendante pour un paquet binaire (<ref id="nmu-terms">).
148 <item><em>Bug Tracking System (BTS)</em> : système de suivi des
149 bogues. Il s'agit du système utilisé par le projet Debian pour suivre
150 les bogues et leur correction (<ref id="bug-handling">).
152 <item><em>Bug submitter</em> : rapporteur du bogue. Personne qui
153 envoie un rapport de bogue au système de suivi des bogues (<ref
156 <item><em>Release critical bug</em> : bogue empêchant l'intégration
157 du paquet dans la distribution. Bogues de gravité <em>critique</em>,
158 <em>grave</em> et <em>sérieuse</em>. Ces bogues ne doivent pas
159 apparaître dans une distribution <em>stable</em>. Ils doivent être
160 corrigés ou bien les paquets en cause doivent être supprimés (<ref
163 <item><em>Package Tracking System (PTS)</em> : système de suivi des
164 paquets. Il s'agit du système utilisé par le projet Debian pour suivre
165 les paquets sources des différentes distributions (<ref
166 id="pkg-tracking-system">).
168 <item><em>Unstable</em> : nom de la distribution en cours
169 de développement. Cette distribution contient les paquets
170 envoyés par les développeurs. Ceux-ci n'étant que des êtres
171 humains, elle est parfois cassée (<ref id="sec-dists">).
173 <item><em>Testing</em> : nom de la distribution en test. Cette
174 distribution reçoit les paquets des développeurs qui ont passé une
175 période de deux semaines dans <em>unstable</em> et pour lesquels aucun
176 bogue remettant en cause la distribution (cf. <em>Release critical
177 bug</em>) n'a été découvert. Cette distribution n'a pas été testée en
178 profondeur. Elle est cependant censée être plus stable
179 qu'<em>unstable</em> (<ref id="sec-dists">).
181 <item><em>Stable</em> : nom de la distribution stable. Cette
182 distribution a été testée, validée et diffusée (<ref id="sec-dists">).
184 <item><em>Debian maintainer</em> : responsable Debian, développeur
185 Debian (parfois mainteneur). Personne qui fait officiellement partie du
186 projet Debian. Elle a accès aux serveurs Debian et participe au
187 développement — au sens large — de la distribution (<ref
188 id="developer-duties">). La plupart des responsables font de la mise en
189 paquet, mais il existe d'autres activités telles que la documentation,
190 la gestion du site web, la création des cédéroms, l'administration des
193 <item><em>Upstream version</em> : version amont. Il s'agit du
194 logiciel tel qu'il est fourni par le responsable amont — par
195 opposition à la version fournie par la distribution Debian. (Voir <ref
196 id="upstream-coordination">.)
198 <item><em>Upstream maintainer</em> : responsable amont ou
199 développeur amont. Personne responsable du développement ou de la
200 maintenance d'un logiciel. En général, le responsable amont n'a rien à
201 voir avec le projet Debian (<ref id="upstream-coordination">).
203 <item><em>Debian keyring</em> : porte-clés Debian. Le porte-clés
204 Debian contient les clés publiques de tous les responsables Debian (<ref
207 <item><em>Work-needing and prospective packages (WNPP)</em> :
208 paquets en souffrance et paquets souhaités. La liste des paquets en
209 souffrance indique les paquets qui n'ont plus de responsable. La liste
210 des paquets souhaités indique les logiciels que des utilisateurs
211 aimeraient bien voir dans la distribution (<ref id="upload">).
216 <chapt id="new-maintainer">Devenir responsable Debian
218 <sect id="getting-started">Pour commencer
220 Vous avez lu toute la documentation, vous avez examiné le <url
221 id="&url-newmaint-guide;" name="guide du nouveau responsable">, vous comprenez
222 l'intérêt de tout ce qui se trouve dans le paquet d'exemple
223 <package>hello</package> et vous vous apprêtez à mettre en paquet votre
224 logiciel préféré. Comment devenir responsable Debian et intégrer votre travail
227 Si vous ne l'avez pas encore fait, commencez par vous inscrire à la
228 liste &email-debian-devel;. Pour cela, envoyez un courrier à l'adresse
229 &email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne
230 <em>Objet</em><footnote><p><em>Subject</em> en anglais</footnote> de votre
231 message. En cas de problème, contactez l'administrateur de la liste
232 &email-listmaster;. Vous trouverez plus d'informations dans la section <ref
233 id="mailing-lists">. &email-debian-devel-announce; est une autre liste
234 incontournable pour qui veut suivre les développements de Debian.
236 Vous suivrez les discussions de cette liste (sans poster) pendant quelque temps
237 avant de coder quoi que ce soit et vous informerez la liste de votre intention
238 de travailler sur quelque chose pour éviter de dupliquer le travail d'un autre.
240 Une autre liste intéressante est &email-debian-mentors;. Voir la section <ref
241 id="mentors"> pour les détails. Le canal IRC <tt>#debian</tt> pourra aussi être
242 utile ; voir <ref id="irc-channels">.
245 Quand vous avez choisi la manière dont vous contribuerez au projet
246 &debian-formal;, prenez contact avec les responsables Debian qui travaillent
247 sur des tâches similaires. Ainsi, vous pourrez apprendre auprès de personnes
248 expérimentées. Si, par exemple, vous voulez mettre en paquet des logiciels
249 existants, trouvez-vous un parrain. Un parrain est une personne qui travaillera
250 sur vos paquets avec vous et les téléchargera dans l'archive Debian une fois
251 qu'il sera satisfait de votre mise en paquet. Pour trouver un parrain, envoyez
252 une demande de parrainage à la liste &email-debian-mentors; en vous présentant
253 et en décrivant votre paquet (voir <ref id="sponsoring"> et <url
254 id="&url-mentors;"> pour en savoir plus
255 sur le sujet). Si vous préférez porter Debian sur une architecture ou un noyau
256 alternatif, abonnez-vous aux listes dédiées au portage et demandez-y comment
257 démarrer. Finalement, si vous êtes intéressé par la documentation ou
258 l'assurance qualité (QA), vous pouvez contacter les responsables qui
259 travaillent déjà sur ces tâches et proposer des correctifs et des
263 <sect id="mentors">Mentors et parrains Debian
265 La liste de diffusion &email-debian-mentors; a été mise en place pour
266 les responsables débutants recherchant de l'aide avec l'empaquetage
267 initial et d'autres problèmes de développeur. Chaque nouveau développeur
268 est invité à s'abonner à cette liste (voir <ref id="mailing-lists"> pour
271 Ceux qui préfèrent recevoir une aide plus personnalisée (par exemple, par
272 courriels privés) devraient également envoyer des messages à cette liste
273 et un développeur expériementé se proposera de les aider.
275 De plus, si vous avez des paquets prêts à être inclus dans Debian, mais que
276 vous attendez que votre demande pour devenir responsable soit acceptée,
277 vous pouvez trouver un parrain pour envoyer vos paquets pour vous. Les
278 parrains sont des développeurs Debian officiels qui sont volontaires
279 pour critiquer et envoyer vos paquets pour vous.
280 <!-- FIXME - out of order
281 Those who are seeking a
282 sponsor can request one at <url id="&url-sponsors;">.
284 Veuillez lire en premier la FAQ non officielle de debian-mentors à <url
287 Si vous désirez être un mentor et/ou un parrain, vous pouvez trouver
288 plus d'informations à <ref id="newmaint">.
290 <sect id="registering">S'enregistrer comme responsable Debian
292 Avant de décider de devenir responsable Debian, il vous faudra lire toute la
293 documentation disponible dans le <url id="&url-newmaint;" name="coin du nouveau
294 responsable">. Elle décrit toutes les étapes préparatoires qu'il vous faudra
295 franchir avant de déposer votre candidature.
297 Par exemple, avant d'être candidat, il vous faudra lire le <url
298 id="&url-social-contract;" name="contrat social Debian">. Devenir responsable
299 Debian implique que vous adhériez à ce contrat social et que vous vous engagiez
300 à le soutenir ; il est très important que les responsables soient en
301 accord avec les principes fondamentaux qui animent le projet &debian-formal;.
302 Lire le <url id="&url-gnu-manifesto;" name="Manifeste GNU"> est aussi une bonne
305 Le processus d'enregistrement a pour but de vérifier votre identité, vos
306 intentions et vos compétences. Le nombre de personnes travaillant pour
307 &debian-formal; a atteint &number-of-maintainers; et notre système est utilisé
308 dans plusieurs endroits très importants : nous devons rester vigilants
309 pour éviter un acte malveillant. C'est pourquoi nous contrôlons les nouveaux
310 responsables avant de leur donner un compte sur nos serveurs et de les autoriser à
311 ajouter des paquets dans l'archive.
313 Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail
314 et que vous serez un bon contributeur. Pour cela, vous pourrez proposer des correctifs
315 par le système de suivi des bogues (BTS) et maintenir un paquet parrainé
316 pendant un temps. Nous attendons aussi des contributeurs qu'ils soient
317 intéressés par le projet dans son ensemble et pas uniquement par leurs propres
318 paquets. Si vous pouvez aider d'autres responsables en fournissant des
319 informations sur un bogue ou même avec un correctif, faites-le !
321 Pour votre candidature, vous devrez être familiarisé avec la philosophie du
322 projet Debian et avec sa documentation technique. Il vous faudra aussi une clé
323 GnuPG signée par un responsable Debian. Si votre clé GnuPG n'est pas encore
324 signée, vous devriez essayer de rencontrer un responsable Debian pour le faire.
325 La <url id="&url-gpg-coord;" name="page de coordination des signatures de clé
326 GnuPG"> devrait vous aider à trouver un responsable Debian près de chez vous.
327 (S'il n'y a pas de responsable près de chez vous, il peut y
328 avoir des moyens alternatifs pour valider votre identité en tant
329 qu'exception absolue étudiée au cas par cas. Veuillez vous
330 reporter à la <url id="&url-newmaint-id;" name="page
331 d'identification"> pour en savoir plus).
333 Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin d'une clé
334 OpenPGP pour signer et vérifier les mises à jour de paquets. Vous lirez la
335 documentation du logiciel de cryptographie que vous utiliserez car elle
336 contient des informations indispensables pour la sécurité de votre clé. Les
337 défaillances de sécurité sont bien plus souvent dues à des erreurs humaines
338 qu'à des problèmes logiciels ou à des techniques d'espionnage avancées. Voir
339 <ref id="key-maint"> pour plus d'informations sur la gestion de votre clé
342 Debian utilise <prgn>GNU Privacy Guard</prgn> (paquet <package>gnupg</package>
343 version 1 ou supérieure) comme standard de base. Vous pouvez aussi utiliser une
344 autre implémentation d'OpenPGP. OpenPGP est un standard ouvert basé sur la <url
345 id="&url-rfc2440;" name="RFC 2440">.
347 <!-- FIXME: DSS is not exactly equivalent to DSA, is it? -->
348 Vous avez besoin d'une clé de type 4 à utiliser pour le
349 développement Debian. La longueur de votre clé doit être au
350 minimum de 1024 bits ; il n'y a pas de raison d'utiliser une clé plus
351 courte et le faire serait beaucoup moins sûr. Votre clé doit être signée avec
352 votre propre identifiant ; cela évite les falsifications. <prgn>GNU
353 Privacy Guard</prgn> le fait automatiquement.
355 Si votre clé publique n'est pas sur un serveur public tel que &pgp-keyserv;,
356 reportez-vous à la documentation disponible localement dans &file-keyservs;.
357 Cette documentation explique comment mettre votre clé publique sur un serveur.
358 L'équipe <em>New maintainer</em> mettra votre clé publique sur les serveurs de
359 clés si elle n'y est pas déjà.
361 Certains pays limitent l'usage des logiciels de cryptographie. Cela ne devrait
362 cependant pas avoir d'impact sur l'activité d'un responsable de paquet car il
363 peut être tout à fait légal d'utiliser des logiciels de cryptographie pour
364 l'authentification plutôt que pour le chiffrement. Si vous vivez dans un pays où
365 l'utilisation de la cryptographie pour authentification est interdite,
366 contactez-nous pour que nous prenions des dispositions particulières.
368 Pour faire acte de candidature, il vous faut un responsable Debian qui vérifiera
369 votre candidature (un <em>avocat</em>). Après avoir contribué au projet Debian
370 pendant un temps, quand vous choisissez de devenir un responsable Debian
371 officiel, un responsable déjà enregistré avec qui vous aurez travaillé dans les
372 derniers mois devra exprimer que, d'après lui, vous pouvez contribuer avec
373 succès au projet Debian.
375 Quand vous avez trouvez un <em>avocat</em>, quand votre clé GnuPG est signée et
376 quand vous avez déjà contribué au projet, vous êtes prêt à faire
377 acte de candidature. Il vous suffit pour cela de vous enregistrer sur notre
378 <url id="&url-newmaint-apply;" name="page de candidature">. Ensuite, votre
379 avocat devra confirmer votre candidature. Quand il aura accompli cette tâche,
380 un responsable de candidature<footnote><p>Application manager</footnote> sera
381 désigné pour vous accompagner dans le processus d'enregistrement. Vous pouvez
382 toujours consulter le <url id="&url-newmaint-db;" name="tableau de bord des
383 candidatures"> pour connaître l'état de votre candidature.
385 Pour en savoir plus, consultez le <url id="&url-newmaint;" name="coin des
386 nouveaux responsables"> sur le site Debian. Assurez-vous de bien connaître les
387 étapes nécessaires au processus d'enregistrement avant de vous porter candidat.
388 Vous gagnerez beaucoup de temps si vous êtes bien préparé.
391 <chapt id="developer-duties">Les charges du responsable Debian
393 <sect id="user-maint">Mise à jour de vos références Debian
395 Il existe une base de données LDAP contenant des informations concernant les
396 développeurs Debian à <url id="&url-debian-db;">. Vous devriez y entrer vos
397 informations et les mettre à jour quand elles changent. Le plus important est de
398 vous assurer que l'adresse vers laquelle est redirigée votre adresse debian.org
399 est toujours à jour, de même que l'adresse à laquelle vous recevez votre
400 abonnement à debian-private si vous choisissez d'être abonné à cette liste.
402 Pour plus d'informations à propos de cette base de données, veuillez consulter
405 <sect id="key-maint">Gérer votre clé publique
407 Soyez très vigilant en utilisant votre clé privée. Ne la placez pas sur un
408 serveur public ou sur des machines multi-utilisateurs telles que les serveurs
409 Debian (voir <ref id="server-machines">). Sauvegardez vos clés et gardez-en une
410 copie hors connexion. Lisez la documentation fournie avec votre logiciel et la
411 <url id="&url-pgp-faq;" name="FAQ PGP">.
413 Vous devez vous assurer que non seulement votre clé est à l'abri des vols, mais
414 également à l'abri d'une perte. Générez et faites une copie (et également sur
415 papier) de votre certificat de révocation ; il est nécessaire si votre clé
418 Si vous ajoutez des signatures ou des identifiants à votre clé publique, vous
419 pouvez mettre à jour le porte-clés Debian en envoyant votre clé publique à
420 <tt>&keyserver-host;</tt>.
422 Si vous voulez ajouter une nouvelle clé ou supprimer une ancienne clé, vous
423 devez faire signer la nouvelle clé par un autre développeur. Si l'ancienne clé
424 est compromise ou invalide, vous devez également ajouter la certification de
425 révocation. S'il n'y pas de vraie raison pour une nouvelle clé, les responsables
426 du trousseau de clés peuvent rejeter la nouvelle clé. Vous pouvez trouver plus
427 de détails à <url id="http://keyring.debian.org/replacing_keys.html">.
429 Les mêmes routines d'extraction de clé décrites dans <ref id="registering"> s'appliquent.
431 Vous pouvez trouver une présentation approfondie de la gestion de clé Debian
432 dans la documentation du paquet <package>debian-keyring</package>.
434 <sect id="voting">Voter
436 Bien que Debian ne soit pas vraiment une démocratie, nous disposons d'un
437 processus démocratique pour élire nos chefs et pour approuver les résolutions
438 générales. Ces procédures sont définies par la <url id="&url-constitution;"
439 name="charte Debian">.
441 En dehors de l'élection annuelle du chef, les votes ne se tiennent pas
442 régulièrement et ils ne sont pas entrepris à la légère. Chaque proposition est
443 tout d'abord discutée sur la liste de diffusion &email-debian-vote; et elle a
444 besoin de plusieurs approbations avant que le secrétaire du projet n'entame la
447 Vous n'avez pas besoin de suivre les discussions précédant le vote car le
448 secrétaire enverra plusieurs appels au vote sur la liste
449 &email-debian-devel-announce; (et tous les développeurs devraient être inscrits
450 à cette liste). La démocratie ne fonctionne pas si les personnes ne prennent pas
451 part au vote, c'est pourquoi nous encourageons tous les développeurs à voter. Le
452 vote est conduit par messages signés ou chiffrés par GPG.
455 La liste de toutes les propositions (passées et présentes) est disponible à la
456 page <url id="&url-vote;" name="Informations sur les votes Debian">, ainsi que
457 des informations complémentaires sur la procédure à suivre pour effectuer une
458 proposition, la soutenir et voter pour elle.
460 <sect id="inform-vacation">Prendre des vacances courtoisement
462 Il est courant pour les développeurs de s'absenter, que ce
463 soit pour des vacances prévues ou parce qu'ils sont submergés de travail. La
464 chose importante à noter est que les autres développeurs ont besoin de savoir
465 que vous êtes en vacances pour qu'ils puissent agir en conséquence si un
466 problème se produit pendant vos vacances.
468 Habituellement, cela veut dire que les autres développeurs peuvent faire des NMU
469 (voir <ref id="nmu">) sur votre paquet si un gros problème (bogues empêchant
470 l'intégration dans la distribution, mise à jour de sécurité, etc.) se produit pendant que vous êtes en
471 vacances. Parfois, ce n'est pas très important, mais il est de
472 toute façon approprié d'indiquer aux autres que vous n'êtes pas disponible.
474 Il y a deux choses à faire pour informer les autres développeurs.
475 Premièrement, envoyez un courrier électronique à &email-debian-private; en
476 commençant le sujet de votre message par « [VAC] »<footnote>Ainsi, le
477 message peut être facilement filtré par les personnes qui ne veulent pas lire
478 ces annonces de vacances.</footnote> et donnez la période de vos
479 vacances. Vous pouvez également donner quelques instructions pour
480 indiquer comment agir si un problème survenait.
482 L'autre chose à faire est de vous signaler comme « en
483 vacances »<footnote><p><em>on vacation</em> en anglais</footnote> dans la
484 <qref id="devel-db">base de données Debian LDAP</qref> (l'accès à cette
485 information est réservé aux développeurs). N'oubliez pas de retirer votre
486 indicateur « en vacances » lorsque celles-ci sont terminées !
488 Idéalement, vous devriez vous connecter sur le
489 <url id="http://nm.debian.org/gpg.php" name="site de coordination GPG">
490 quand vous réservez pour des vacances et vérifier si quelqu'un recherche
491 un échange de signatures. Cela est particulièrement important quand des
492 personnes vont à des endroits exotiques où nous n'avons pas encore de
493 développeurs, mais où il y a des personnes intéressées pour poser leur
496 <sect id="upstream-coordination">Coordination avec les développeurs amont
498 Une grande part de votre travail de responsable Debian sera de rester en contact
499 avec les développeurs amont. Parfois, les utilisateurs établissent des
500 rapports de bogue qui ne sont pas spécifiques à Debian. Vous devez transmettre
501 ces rapports de bogue aux développeurs amont pour qu'ils soient corrigés dans
502 les prochaines versions.
504 Bien qu'il ne soit pas de votre responsabilité de corriger les
505 bogues non spécifiques à Debian, vous pouvez le faire si vous en êtes capable.
506 Quand vous faites de telles corrections, assurez-vous de les envoyer
507 également au développeur amont. Les utilisateurs et responsables
508 Debian proposent souvent des correctifs pour corriger des bogues amont, il
509 vous faudra alors évaluer ce correctif puis le transmettre aux développeurs
512 Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
513 paquet conforme à la charte Debian, alors vous devriez proposer un correctif
514 aux développeurs amont pour qu'il soit inclus dans leur version. Ainsi, vous
515 n'aurez plus besoin de modifier les sources lors des mises à jour amont
516 suivantes. Quels que soient les changements dont vous avez besoin, il faut
517 toujours essayer de rester dans la lignée des sources amont.
519 <sect id="rc-bugs">Comment gérer les bogues empêchant l'intégration du
520 paquet dans la distribution ?
522 Habituellement, vous devriez traiter les rapports de bogue sur vos paquets tel
523 que cela est décrit dans <ref id="bug-handling">. Cependant, il y a une
524 catégorie spéciale de bogues qui nécessite particulièrement votre
525 attention : les bogues empêchant l'intégration du paquet dans la
526 distribution<footnote>Traduction de l'anglais <em>Release-critical bug (RC
527 Bugs)</em></footnote>. Tous les rapports de bogue de gravité <em>critique</em>,
528 <em>grave</em> et <em>sérieuse</em><footnote>Respectivement <em>critical</em>,
529 <em>grave</em> et <em>serious</em> en anglais</footnote> sont considérés comme
530 ayant un impact sur la présence du paquet dans la prochaine version stable de
531 Debian. Ces bogues peuvent retarder la diffusion d'une distribution Debian
532 ou peuvent justifier la suppression d'un paquet d'une distribution gelée.
533 C'est pourquoi ces bogues doivent être corrigés au plus vite.
535 Les développeurs faisant partie de l'équipe d'<url id="&url-debian-qa;"
536 name="assurance qualité Debian"> surveillent ces bogues et essaient de vous
537 aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas corriger un bogue de
538 ce type dans les deux semaines, vous devriez soit demander de l'aide en
539 envoyant un courrier à l'équipe d'assurance qualité (<em>QA group</em>) à
540 &email-debian-qa;, soit expliquer vos difficultés et présenter un plan pour
541 corriger le problème en répondant au rapport de bogue concerné. Si rien n'est
542 fait, des personnes de l'équipe d'assurance qualité pourraient chercher à
543 corriger votre paquet (voir <ref id="nmu">) après avoir tenté de vous contacter
544 (ils pourraient attendre moins longtemps que d'habitude pour faire leur mise à
545 jour s'il n'y a pas trace d'activité récente de votre part dans le système de
551 Si vous choisissez de quitter le projet Debian, procédez comme suit :
552 <enumlist compact="compact">
553 <item><p>abandonnez tous vos paquets comme décrit dans <ref
554 id="orphaning"> ;</item>
555 <item><p>envoyez un courrier électronique à &email-debian-private; indiquant
556 pourquoi vous quittez le projet ;</item>
557 <item><p>signalez aux responsables du porte-clés Debian que vous quittez le
558 projet en écrivant à &email-debian-keyring;.</item>
563 <chapt id="resources">Ressources pour le responsable Debian
565 Dans ce chapitre, vous trouverez une brève description des listes de diffusion,
566 des machines Debian qui seront à votre disposition en tant que responsable
567 Debian ainsi que toutes les autres ressources à votre disposition pour vous
568 aider dans votre travail de responsable.
570 <sect id="mailing-lists">Les listes de diffusion
572 Une grande partie des discussions entre les développeurs Debian (et les
573 utilisateurs) est gérée par un vaste éventail de listes de diffusion que nous
574 hébergeons à <tt><url id="http://&lists-host;/" name="&lists-host;"></tt>.
575 Pour en savoir plus sur comment s'abonner ou se désabonner, comment envoyer un
576 message et comment ne pas en envoyer, comment retrouver d'anciens messages et
577 comment les rechercher, comment contacter les responsables des listes et pour
578 savoir d'autres informations sur les listes de diffusion, veuillez lire <url
579 id="&url-debian-lists;">. Cette section ne couvrira que les aspects des listes
580 de diffusion qui ont un intérêt particulier pour les développeurs.
582 <sect1 id="mailing-lists-rules">Règles de base d'utilisation
584 Lorsque vous répondez sur une liste de diffusion, veuillez ne pas envoyer de
585 copie (<tt>CC</tt>) à l'auteur d'origine sauf s'il le demande explicitement.
586 Toute personne envoyant un message à une liste de diffusion devrait la suivre
587 pour voir les réponses.
589 Le multi-postage (cross-posting) (envoyer le même message à plusieurs listes)
590 est découragé. Comme toujours sur le net, veuillez réduire la citation des
591 articles auxquels vous répondez. En général, veuillez adhérez aux conventions
592 usuelles d'envoi de messages.
594 Veuillez lire le <url name="code de conduite"
595 id="&url-debian-lists;#codeofconduct"> pour plus d'informations.
597 <sect1 id="core-devel-mailing-lists">Principales listes pour les
600 Les principales listes de diffusion de Debian que les développeurs
601 devraient suivre sont :
603 <item>&email-debian-devel-announce;, utilisée pour les annonces importantes
604 faites aux responsables. Tous les responsables Debian sont censés être
605 inscrits à cette liste,</item>
606 <item>&email-debian-devel;, utilisée pour discuter de diverses questions
607 techniques relatives au développement,</item>
608 <item>&email-debian-policy; où l'on discute et vote les modifications de la
609 charte Debian,</item>
610 <item>&email-debian-project;, utilisée pour discuter de questions non
614 Il existe d'autres listes de diffusion spécialisées dans différents thèmes.
615 Reportez-vous à la page <url id="http://&lists-host;/"> pour en obtenir
618 <sect1 id="mailing-lists-special">Listes spéciales
620 &email-debian-private; est une liste de diffusion destinée aux discussions
621 privées entre développeurs Debian. Elle doit être utilisée pour tout message
622 qui ne doit pas être publié, quelle qu'en soit la raison. C'est une liste à
623 faible trafic et les utilisateurs sont priés de ne l'utiliser qu'en cas de
624 réelle nécessité. De plus, il ne faut <em>jamais</em> faire suivre un courrier
625 de cette liste à qui que ce soit. Pour des raisons évidentes, les archives de
626 cette liste ne sont pas disponibles sur la toile. Vous pouvez les consulter en
627 visitant le répertoire <file>~debian/archive/debian-private</file> avec votre
628 compte sur <tt>lists.debian.org</tt>.
630 &email-debian-email; est une liste de diffusion fourre-tout. Elle est utilisée
631 pour les correspondances relatives à Debian qu'il serait utile d'archiver,
632 telles que des échanges avec les auteurs amont à propos de licences, de bogues
633 ou encore des discussions sur le projet avec d'autres personnes.
635 <sect1 id="mailing-lists-new">Demander une nouvelle liste relative au développement
637 Avant de demander une liste de diffusion liée au développement d'un paquet (ou
638 d'un petit groupe de paquets liés), veuillez considérer si l'utilisation d'un
639 alias (via un fichier .forward-aliasname sur master.debian.org, ce qui se
640 traduit en une adresse raisonnablement agréable
641 <var>you-aliasname@debian.org</var>) ou une liste de diffusion auto-gérée sur
642 <qref id="alioth">Alioth</qref> serait plus appropriée.
644 Si vous décidez qu'une liste de diffusion standard sur lists.debian.org est
645 vraiment ce que vous voulez, lancez-vous et faites une demande en suivant <url
646 name="le guide" id="&url-debian-lists-new;">.
649 <sect id="irc-channels">Canaux IRC
651 Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont
652 principalement hébergés sur le réseau <url id="&url-openprojects;"
653 name="freenode"> (anciennement connu sous le nom de Open Projects Network).
654 L'entrée DNS <tt>irc.debian.org</tt> est simplement un alias vers
655 <tt>irc.freenode.net</tt>.
657 Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un
658 canal important, généraliste, où les utilisateurs peuvent trouver des nouvelles
659 récentes dans le sujet et qui est administré par des robots. <em>#debian</em>
660 est destiné aux anglophones ; il existe également <em>#debian.de</em>,
661 <em>#debian-fr</em>, <em>#debian-br</em> et d'autres canaux avec des noms
662 semblables pour les personnes parlant d'autres langues.
664 Le canal principal pour le développement Debian est <em>#debian-devel</em>.
665 C'est un canal très actif avec habituellement plus de 150 personnes connectées
666 en permanence. C'est un canal pour les personnes qui travaillent sur Debian, ce
667 n'est pas un canal d'aide (il existe <em>#debian</em> pour cela). Il est
668 cependant ouvert à tous ceux qui veulent écouter (et apprendre). Le sujet est
669 toujours rempli d'informations intéressantes.
671 Comme <em>#debian-devel</em> est un canal ouvert, vous ne devriez pas y parler
672 de problèmes discutés sur &email-debian-private;. Il existe un canal protégé
673 par clé <em>#debian-private</em> dans ce but. La clé est disponible dans les
674 archives de debian-private à
675 <file>master.debian.org:&file-debian-private-archive;</file>, effectuez
676 simplement un <prgn>zgrep</prgn> avec <em>#debian-private</em> dans tous les
679 Il existe d'autres canaux dédiés à des sujets spécifiques. <em>#debian-bugs</em>
680 est utilisé pour la coordination des <em>chasses aux bogues</em>.
681 <em>#debian-boot</em> est utilisé pour la coordination du travail sur
682 l'installateur Debian. <em>#debian-doc</em> est utilisé
683 occasionnellement pour travailler sur la documentation comme celle que vous
684 lisez actuellement. D'autres canaux sont dédiés à une architecture ou un
685 ensemble de paquets : <em>#debian-bsd</em>, <em>#debian-kde</em>,
686 <em>#debian-jr</em>, <em>#debian-edu</em>, <em>#debian-sf</em> (paquet
687 SourceForge), <em>#debian-oo</em> (paquet OpenOffice), etc.
689 Certains canaux pour développeurs non anglophones existent, par exemple,
690 <em>#debian-devel-fr</em> pour les francophones intéressés dans le
691 développement de Debian.
693 Il existe également des canaux dédiés pour Debian sur d'autres réseaux IRC,
694 notamment sur le réseau IRC <url name="Open and free technology community
695 (OFTC)" id="http://www.oftc.net/">.
697 Pour obtenir un uniforme (« cloak ») sur freenode, vous devez
698 envoyer un courriel signé à Göran Weinholt
699 <weinholt@debian.org> dans lequel vous indiquez quel est votre
700 pseudonyme (« nick ». Mettez « cloak » quelque part
701 dans le sujet. Votre pseudonyme devrait être enregistré :
702 <url id="http://freenode.net/faq.shtml#nicksetup" name="Page de
703 configuration des pseudonymes">. Le courriel doit être signé par une clé
704 du porte-clés Debian. Veuillez consulter la
705 <url id="http://freenode.net/faq.shtml#projectcloak" name="documentation
706 de Freenode"> pour plus d'informations sur les uniformes.
709 <sect id="doc-rsrcs">Documentation
711 Ce document contient beaucoup d'informations très utiles aux développeurs
712 Debian, mais il ne peut pas tout contenir. La plupart des autres documents
713 intéressants sont référencés dans le <url id="&url-devel-docs;" name="coin
714 du développeur Debian">. Prenez le temps de parcourir tous les liens, vous
715 apprendrez encore beaucoup de choses.
718 <sect id="server-machines">Les serveurs Debian
720 Debian possède plusieurs ordinateurs employés comme serveurs, dont la plupart hébergent
721 les fonctions critiques du projet Debian. La plupart des machines sont
722 utilisées pour des activités de portage et elles ont toutes un accès permanent
725 La plupart des machines peuvent être utilisées par les développeurs
726 tant qu'ils respectent les règles définies dans la <url
727 id="&url-dmup;" name="charte d'utilisation des machines Debian">.
729 Dans l'ensemble, vous pouvez faire usage de ces machines pour des buts relatifs
730 à Debian comme vous l'entendez. Veuillez cependant être gentil avec les
731 administrateurs système et ne pas utiliser de grandes quantités d'espace
732 disque, de ressource réseau ou CPU sans obtenir auparavant l'accord des
733 administrateurs. Habituellement, ces machines sont administrées par des
736 Veuillez prendre soin de votre mot de passe Debian ainsi que des clés SSH
737 installées sur les machines Debian. Évitez les méthodes de connexion ou d'envoi
738 de données qui envoient les mots de passe en clair par l'Internet comme telnet,
741 Veuillez ne pas déposer de données non relatives à Debian sur les serveurs
742 Debian à moins que vous n'ayez préalablement obtenu la permission de le faire.
744 La liste actuelle des machines Debian est disponible à <url
745 id="&url-devel-machines;">. Cette page web contient les noms des machines, les
746 informations de contact, les informations sur qui peut s'y connecter, les clés
749 Si vous avez un problème en utilisant un serveur Debian et si vous estimez que
750 les administrateurs système devraient en être avertis, l'équipe des
751 administrateurs système peut être jointe à
752 <email>debian-admin@lists.debian.org</email>.
754 Si votre problème est lié à un certain service ou n'est pas lié au système
755 (paquet à supprimer de l'archive ou suggestion pour le site web par exemple),
756 il vous faudra en général ouvrir un rapport de bogue sur un
757 « pseudo-paquet ». Reportez-vous à la section <ref id="submit-bug">
758 pour connaître la procédure à suivre.
760 Certains des serveurs de base sont à accès restreint, mais les informations de
761 ceux-ci sont fournies par d'autres serveurs miroirs.
763 <sect1 id="servers-bugs">Le serveur pour les rapports de bogues
765 <tt>&bugs-host;</tt> est le serveur maître du système de suivi des bogues
766 (BTS<footnote><p>Système de suivi des bogues se dit <em>Bug Tracking
767 System</em> en anglais</footnote>).
769 Ce serveur est à accès restreint ; un miroir est disponible sur <tt>merkel</tt>.
771 Si vous envisagez de manipuler les rapports
772 de bogue ou d'en faire une analyse statistique, ce sera le bon endroit pour le
773 faire. Informez la liste &email-debian-devel; de votre intention avant
774 d'implémenter quoi que ce soit afin d'éviter un travail en double ou un
775 gaspillage de temps machine.
777 <sect1 id="servers-ftp-master">Le serveur ftp-master
779 Le serveur <tt>ftp-master.debian.org</tt> est le serveur maître de l'archive
780 Debian (exception faite des paquets non-US). En général, les mises à jour de
781 paquets se font sur ce serveur. Reportez-vous à la section <ref id="upload">
784 Ce serveur est à accès restreint ; un miroir est disponible sur <tt>merkel</tt>.
786 Les problèmes avec l'archive Debian FTP doivent généralement être rapportés
787 comme bogues sur le pseudo-paquet <package>ftp.debian.org</package> ou par
788 courrier électronique à &email-ftpmaster; ; reportez-vous à la section
789 <ref id="archive-manip"> pour connaître la procédure à suivre.
791 <sect1 id="servers-non-us">Le serveur non-US
794 Le serveur non-US <tt>non-us.debian.org</tt> est le serveur maître de la partie
795 non-US de l'archive Debian. Si vous avez besoin d'envoyer un paquet dans l'une
796 des sections non-US, envoyez-le vers ce serveur. Reportez-vous à la section
797 <ref id="upload-non-us"> pour en savoir plus.
799 Les problèmes avec l'archive de paquets non-US doivent généralement être
800 rapportés comme bogues sur le pseudo-paquet <package>nonus.debian.org</package>
801 (remarquez l'absence de trait d'union entre "non" et "us" dans le nom du
802 pseudo-paquet — c'est dû à la compatibilité descendante). Rappelez-vous
803 de vérifier si quelqu'un n'aurait pas déjà rempli un rapport de bogue
804 concernant le problème sur le <url id="http://&bugs-host;/nonus.debian.org"
805 name="système de suivi des bogues">.
807 Le serveur non-US <tt>non-us.debian.org</tt> a été interrompu avec la
808 publication de <em>Sarge</em>. Le pseudo-paquet
809 <package>nonus.debian.org</package> existe encore pour le moment.
811 <sect1 id="servers-www">Le serveur www-master
813 Le serveur web principal est <tt>www-master.debian.org</tt>. Il héberge les
814 pages web officielles, la façade de Debian pour la plupart des débutants.
816 Si vous rencontrez un problème avec un serveur web Debian, vous devez
817 généralement envoyer un rapport de bogue sur le pseudo-paquet
818 <package>www.debian.org</package>. Vérifiez d'abord sur le <url
819 id="http://&bugs-host;/www.debian.org" name="système de suivi des bogues">
820 que personne ne l'a déjà rapporté avant vous.
822 <sect1 id="servers-people">Le serveur web people
824 <tt>people.debian.org</tt> est le serveur utilisé par les développeurs pour
825 leurs pages concernant Debian.
827 Si vous avez des informations spécifiques Debian que vous voulez rendre
828 disponibles sur le web, vous pouvez le faire en les plaçant dans le répertoire
829 <file>public_html</file> de votre répertoire personnel sur
830 <tt>people.debian.org</tt>. Elles seront accessibles à l'adresse
831 <tt>http://people.debian.org/~<var>votre-user-id</var>/</tt>.
833 Vous ne devriez utiliser que cet emplacement particulier car il sera sauvegardé
834 alors que sur les autres serveurs, ce ne sera pas le cas.
836 Habituellement, la seule raison pour utiliser un serveur différent est que vous
837 avez besoin de publier des informations soumises aux restrictions d'exportation
838 américaines, dans ce cas, vous pouvez utiliser l'un des autres serveurs situés
839 en dehors des États-Unis.
841 Veuillez envoyer un courrier à &email-debian-devel; si vous avez une question.
843 <sect1 id="servers-cvs">Le serveur CVS
844 <!-- TODO: document svn.debian.org also, arch.debian.org also -->
846 Notre serveur CVS est situé sur <tt>cvs.debian.org</tt>.
848 Si vous avez besoin d'un serveur CVS accessible par tous pour, par exemple,
849 coordonner le travail de plusieurs développeurs sur un paquet, vous pouvez
850 demander un espace CVS sur ce serveur.
852 Le serveur <tt>cvs.debian.org</tt> autorise les accès CVS locaux, les accès en
853 lecture seule pour les connexions client-serveur anonymes et les accès
854 client-serveur complets pour les connexions <prgn>ssh</prgn>. L'espace CVS peut
855 aussi être consulté par la toile à l'adresse <url id="&url-cvsweb;">.
857 Pour obtenir un espace CVS, envoyez une demande à l'adresse &email-debian-admin;
858 en précisant le nom de l'espace, le compte Debian propriétaire du répertoire
859 racine et pourquoi vous en avez besoin.
861 <sect1 id="dchroot">Chroots de différentes distributions
863 Sur certaines machines, des chroots de différentes distributions sont
864 disponibles. Vous pouvez les utiliser comme ceci :
867 vore% dchroot unstable
868 Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
871 Dans tous les chroots, les répertoires normaux des utilisateurs sont disponibles.
872 Vous pouvez trouver quels chroots sont disponibles à
873 <tt>&url-devel-machines;</tt>.
876 <sect id="devel-db">La base de données des développeurs
878 La base de données des développeurs à <url id="&url-debian-db;"> est un annuaire
879 LDAP de gestion des informations des développeurs Debian. Vous pouvez utiliser
880 cette ressource pour rechercher la liste des développeurs Debian. Une partie de
881 ces informations est également disponible à travers le service <prgn>finger</prgn> sur les
882 serveurs Debian, essayez <prgn>finger yourlogin@debian.org</prgn> pour voir ce
885 Les développeurs peuvent <url name="se connecter à la base de données"
886 id="&url-debian-db-login;"> pour modifier différentes informations les
887 concernant, comme :
889 <item>l'adresse de suivi pour leur adresse debian.org,
890 <item>l'abonnement à debian-private,
891 <item>l'état en vacances ou non,
892 <item>des informations personnelles comme les adresse, pays, latitude et
893 longitude de l'endroit où ils vivent pour utilisation dans la <url
894 name="carte mondiale des développeurs Debian" id="&url-worldmap">,
895 numéros de téléphone et de fax, surnom IRC et page web,
896 <item>le mot de passe et le shell préféré sur les machines du projet Debian.
899 La plupart des informations ne sont naturellement pas accessibles publiquement.
900 Pour plus d'informations, veuillez lire la documentation en ligne que vous
901 pouvez trouver à <url id="&url-debian-db-doc;">.
904 Les développeurs peuvent également envoyer leurs clés SSH pour qu'elles soient utilisées pour
905 autorisation sur les machines Debian officielles et même ajouter de nouvelles
906 entrées DNS du type *.debian.net. Ces fonctionnalités sont documentées à <url
907 id="&url-debian-db-mail-gw;">.
910 <sect id="archive">L'archive Debian
912 La distribution &debian-formal; est composée d'un grand nombre de paquets
913 (fichiers <tt>.deb</tt> : actuellement, à peu près &number-of-pkgs;) et de
914 quelques autres fichiers (comme la documentation et des images des disquettes
917 Voici un exemple d'arborescence pour une archive Debian complète :
919 &sample-dist-dirtree;
921 Comme vous pouvez le voir, le répertoire racine contient deux répertoires,
922 <file>dists/</file> et <file>pool/</file>. Le second est un ensemble de
923 répertoires où sont stockés les paquets. Ceux-ci sont manipulés grâce à la base
924 de données de l'archive et aux logiciels qui l'accompagnent. Le premier
925 répertoire contient les distributions <em>stable</em>, <em>testing</em> et
926 <em>unstable</em>. Les fichiers <file>Packages</file> et <file>Sources</file>
927 qui se trouvent dans les répertoires de distribution peuvent faire référence à
928 des fichiers du répertoire <file>pool/</file>. Le découpage en sous-répertoires
929 est identique d'un répertoire de distribution à l'autre . Ce que nous
930 exposerons ci-dessous pour la distribution <em>stable</em> est également
931 applicable aux distributions <em>unstable</em> et <em>testing</em>.
933 Le répertoire <file>dists/stable</file> contient trois répertoires nommés
934 <file>main</file>, <file>contrib</file> et <file>non-free</file>.
936 Dans chacune de ces sections, se trouve un répertoire contenant les paquets
937 sources (<file>source/</file>) et un répertoire pour chaque architecture
938 acceptée (<file>binary-i386/</file>, <file>binary-m68k/</file>, etc.).
940 La section <em>main</em> contient d'autres répertoires destinés aux images de
941 disquettes et à plusieurs documents essentiels pour installer la distribution
942 Debian sur une architecture particulière (<file>disk-i386/</file>,
943 <file>disk-m68k/</file>, etc.).
945 <sect1 id="archive-sections">Les sections
947 La section <em>main</em> constitue la <strong>distribution &debian-formal;
948 officielle</strong>. Elle est officielle parce qu'elle est entièrement conforme
949 à toutes nos recommandations. Les deux autres sections divergent de ces
950 recommandations à différents degrés, elles <strong>ne</strong> font donc <strong>pas</strong>
951 officiellement partie de &debian-formal;.
953 Chaque paquet de la section <em>main</em> doit être conforme aux <url
954 id="&url-dfsg;" name="directives Debian pour le logiciel
955 libre"><footnote>Debian Free Software Guidelines</footnote> et à toutes les
956 autres recommandations décrites dans <url id="&url-debian-policy;" name="la
957 charte Debian"><footnote>Debian Policy Manual</footnote>. Les
958 DFSG<footnote><em>Debian Free Software Guidelines</em></footnote> constituent
959 notre définition de « logiciel libre ». Reportez-vous à la <em>charte
960 Debian</em> pour en savoir plus.
962 Les paquets de la section <em>contrib</em> doivent être conformes aux DFSG, mais
963 ne respectent pas d'autres contraintes. Ils peuvent, par exemple, dépendre de
964 paquets de la section <em>non-free</em>.
966 Les paquets qui ne sont pas conformes aux DFSG sont rangés dans la section
967 <em>non-free</em>. Bien que nous supportions l'usage de ces paquets et qu'ils
968 bénéficient de nos infrastructures (système de suivi des bogues, listes de
969 diffusion, etc.), ces paquets <em>non-free</em> ne font pas partie de la
972 La <em>charte Debian</em> donne des définitions plus précises pour ces trois
973 sections. Les paragraphes précédents ne constituent qu'une introduction.
975 La séparation de l'archive en trois sections est importante pour toute personne
976 qui désire distribuer Debian, que ce soit par serveur FTP ou sur cédérom. Il
977 suffit de distribuer les sections <em>main</em> et <em>contrib</em> pour éviter
978 tout problème légal. Certains paquets de la section <em>non-free</em>
979 interdisent leur distribution à titre commercial par exemple.
981 D'un autre côté, un distributeur de cédérom pourra facilement vérifier
982 la licence de chacun des paquets de la section <em>non-free</em> et
983 inclure tous les paquets qu'il lui sera autorisé (dans
984 la mesure où cela varie énormément d'un distributeur à l'autre, ce travail ne
985 peut être fait par les développeurs Debian).
987 Notez que le terme « section » est également utilisé pour faire
988 référence aux catégories qui simplifient l'organisation des paquets
989 disponibles et leur recherche, e.g. <em>admin</em>, <em>net</em>, <em>utils</em> etc. Il
990 fut un temps où ces sections (sous-sections, plutôt) existaient sous la forme
991 de sous-répertoires dans l'archive Debian. Actuellement, elles n'existent plus
992 que dans le champ en-tête « Section » des paquets.
994 <sect1>Les architectures
996 À ses débuts, le noyau Linux existait uniquement pour les architectures Intel
997 x86 ; il en était de même pour Debian. Linux devenant de plus en plus
998 populaire, il a été porté vers d'autres architectures.
1000 Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC,
1001 Motorola, 680x0 (Atari, Amiga, et Macintosh), MIPS et PowerPC. Le noyau 2.2
1002 reconnaît de nouvelles architectures, comme ARM et UltraSPARC. Puisque Linux
1003 reconnaît ces architectures, le projet Debian a décidé qu'il devait également les
1004 accepter. C'est pourquoi plusieurs portages sont en cours ; en fait, il y
1005 a aussi des portages vers d'autres noyaux non-Linux. À côté d'<em>i386</em> (notre nom
1006 pour Intel x86), nous avons, au moment où j'écris, <em>m68k</em>,
1007 <em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
1008 <em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>, <em>mips</em>,
1009 <em>mipsel</em> et <em>sh</em>.
1011 &debian-formal; 1.3 est disponible uniquement pour <em>i386</em>. Debian 2.0
1012 reconnaît les architectures <em>i386</em> et <em>m68k</em>. Debian 2.1 reconnaît
1013 les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et
1014 <em>sparc</em>. Debian 2.2 accepte en plus les architectures
1015 <em>powerpc</em> et <em>arm</em>. Debian 3.0 a ajouté cinq
1016 nouvelles architectures : <em>ia64</em>, <em>hppa</em>, <em>s390</em>,
1017 <em>mips</em> et <em>mipsel</em>.
1019 Pour chaque portage, vous trouverez des informations destinées aux développeurs
1020 et utilisateurs sur la page <url id="&url-debian-ports;" name="Portage
1025 Il existe deux types de paquets Debian : les paquets sources et les paquets
1028 Les paquets sources sont constitués de deux ou trois fichiers : un fichier
1029 <file>.dsc</file> et soit un fichier <file>.tar.gz</file>, soit un fichier
1030 <file>.orig.tar.gz</file> et un fichier <file>.diff.gz</file>.
1032 Si un paquet est développé spécifiquement pour le projet Debian et n'est pas
1033 distribué en dehors de Debian, il n'y a qu'un fichier <file>.tar.gz</file> qui
1034 contient les sources du programme. Si un paquet est distribué ailleurs, le
1035 fichier <file>.orig.tar.gz</file> contient ce que l'on appelle <em>code source
1036 amont</em>, c'est-à-dire, le code source distribué par le <em>mainteneur
1037 amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le fichier
1038 <file>.diff.gz</file> contient les modifications faites par le responsable
1041 Le fichier <file>.dsc</file> liste tous les fichiers sources avec leurs sommes
1042 de contrôle (<prgn>md5sums</prgn>) et quelques informations supplémentaires
1043 concernant le paquet (responsable, version, etc.).
1045 <sect1>Les distributions
1047 L'organisation des répertoires présentée précédemment est elle-même englobée par
1048 les <em>répertoires des distributions</em>. Chaque distribution est incluse
1049 dans le répertoire <file>pool</file> à la racine de l'archive Debian.
1051 Pour résumer, une archive Debian a un répertoire racine sur un serveur FTP. Par
1052 exemple, sur le site miroir <ftpsite>ftp.us.debian.org</ftpsite>, l'archive
1053 Debian se trouve dans <ftppath>/debian</ftppath> ce qui est un emplacement
1054 courant. Un autre emplacement courant est <file>/pub/debian</file>.
1056 Une distribution est composée de paquets sources et binaires et des
1057 fichiers <file>Sources</file> et <file>Packages</file> correspondants qui
1058 contiennent toutes les méta-informations sur les paquets. Les premiers sont
1059 conservés dans le répertoire <file>pool/</file> tandis que les seconds sont
1060 conservés dans le répertoire <file>dists/</file> de l'archive (pour
1061 compatibilité descendante).
1063 <sect2 id="sec-dists"><em>Stable</em>, <em>testing</em> et
1066 Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire
1067 <file>dists/stable</file>), une distribution appelée <em>testing</em> (dans le
1068 répertoire <file>dists/testing</file>) et une distribution appelée
1069 <em>unstable</em> (dans le répertoire <file>dists/unstable</file>). Ceci
1070 reflète le processus de développement du projet Debian.
1072 Les développements se font sur la distribution
1073 <em>unstable</em><footnote><p><em>unstable</em> signifie
1074 « instable »</footnote> (c'est pourquoi elle est aussi appelée
1075 <em>distribution de développement</em>). Chaque développeur Debian peut
1076 modifier ses paquets à tout moment dans cette distribution. Ainsi son contenu
1077 change tous les jours. Comme aucun effort particulier n'est fait pour s'assurer
1078 que tout fonctionne correctement dans cette distribution, elle est parfois
1079 littéralement « instable ».
1081 La distribution <qref id="testing">« testing »</qref> est générée
1082 automatiquement en prenant les paquets
1083 d'<em>unstable</em> s'ils satisfont à certains critères. Ces critères
1084 garantissent que les paquets de <em>testing</em> sont de bonne qualité. La
1085 mise à jour de <em>testing</em> est lancée chaque jour après que les
1086 nouveaux paquets ont été installés. Voir <ref id="testing">.
1088 Après une période de développement, quand le responsable de
1089 distribution<footnote><p><em>Release manager</em></footnote> le juge opportun,
1090 la distribution <em>testing</em> est gelée, ce qui signifie que les conditions
1091 à remplir pour qu'un paquet passe d'<em>unstable</em> à <em>testing</em> sont
1092 durcies. Les paquets trop bogués sont supprimés et les seules mises à jours
1093 autorisées concernent les corrections de bogues. Après quelque temps, selon
1094 l'avancement, la distribution <em>testing</em>
1096 entre dans une phase de « gel complet »
1097 où les seules modifications acceptées concernent la procédure d'installation.
1098 Cette phase s'appelle un « cycle de test » et cela peut durer jusqu'à
1099 deux semaines. Il peut y avoir plusieurs cycles de tests avant que le
1100 responsable de distribution ne la déclare prête pour la diffusion. À la fin du
1101 dernier cycle de test, la distribution <em>frozen</em> devient <em>stable</em>,
1102 remplaçant l'ancienne distribution <em>stable</em> qui est enlevée à cette
1103 occasion (elle peut être retrouvée à l'adresse <tt>&archive-host;</tt>).
1105 est gelée encore plus. Les détails de la gestion de la distribution
1106 <em>testing</em> sont publiées par l'équipe de publication sur la liste
1107 debian-devel-announce. Après la résolution des problèmes restants à la
1108 satisfaction de l'équipe de publication, la distribution est publiée.
1109 La publication veut dire que <em>testing</em> est renommée en
1110 <em>stable</em>, une nouvelle copie est créée pour la nouvelle
1111 <em>testing</em> et l'ancienne <em>stable</em> est renommée en
1112 <em>oldstable</em> et y reste jusqu'à ce qu'elle soit finalement
1113 archivée. Lors de l'archivage, son contenu est déplacé sur
1114 <tt>&archive-host;</tt>.
1116 Ce cycle de développement est basé sur l'idée que la distribution
1117 <em>unstable</em> devient <em>stable</em> après une période de test
1118 (<em>testing</em>). Une distribution contient inévitablement des bogues, même
1119 si elle est classée stable. C'est pourquoi les distributions stables sont mises
1120 à jour de temps en temps. Les corrections introduites sont testées avec une
1121 grande attention et sont ajoutées une à une à l'archive pour diminuer les
1122 risques d'introduire de nouveaux bogues. Vous pouvez trouver des paquets
1123 proposés pour les mises à jour de <em>stable</em> dans le répertoire
1124 <file>proposed-updates</file>. De temps en temps, les paquets de ce répertoire
1125 qui ne présentent pas de problème sont installés dans la distribution
1126 <em>stable</em> et le numéro de révision de cette distribution est incrémenté
1127 (« 3.0 » devient « 3.0r1 », « 2.2r4 » devient
1128 « 2.2r5 » et ainsi de suite). Veuillez vous référer aux
1129 <qref id="upload-stable">envois dans la distribution <em>stable</em></qref>
1130 pour plus de détails.
1132 Notez que, pendant la période de gel, les développements continuent sur la
1133 distribution <em>unstable</em> car cette distribution reste en place.
1136 <heading>Informations complémentaires sur la distribution
1137 « testing »</heading>
1139 Les paquets sont habituellement installés dans la distribution <em>testing</em>
1140 après avoir atteint un certain degré de test dans <em>unstable</em>.
1142 Pour plus de détails, veuillez consulter les <qref id="testing">informations à
1143 propos de la distribution <em>testing</em></qref>.
1145 <sect2 id="experimental">Experimental
1147 La distribution <em>experimental</em> est une distribution particulière. Ce n'est
1148 pas une distribution à part entière comme le sont <em>stable</em> et
1149 <em>unstable</em>. Elle est prévue pour servir de plate-forme de
1150 développement pour les projets expérimentaux qui risquent vraiment de
1151 détruire le système ou bien pour des logiciels qui sont vraiment trop
1152 instables pour être inclus dans la distribution <em>unstable</em> (mais pour
1153 lesquels une mise en paquet est justifiée). Les utilisateurs qui téléchargent
1154 et installent des paquets depuis <em>experimental</em> sont prévenus :
1155 on ne peut pas faire confiance à la distribution <em>experimental</em>.
1157 Voici les lignes de <manref name="sources.list" section="5"> pour
1158 <em>experimental</em> :
1160 deb http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
1161 deb-src http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
1164 Si un logiciel peut causer des dégâts importants, il sera sûrement
1165 préférable de le mettre dans la distribution <em>experimental</em>. Un
1166 système de fichiers compacté expérimental, par exemple, devrait probablement
1167 aller dans <em>experimental</em>.
1169 Une nouvelle version amont qui ajoute de nouvelles fonctions tout en supprimant
1170 de nombreuses autres ne devra pas être téléchargée dans l'archive Debian,
1171 elle pourra cependant être téléchargée dans <em>experimental</em>. Une
1172 nouvelle version non finalisée d'un logiciel qui utilise une méthode de
1173 configuration complètement différente pourrait aller dans
1174 <em>experimental</em> au gré du responsable. Si vous travaillez sur un cas de
1175 mise à jour complexe ou incompatible, vous pouvez aussi utiliser
1176 <em>experimental</em> comme plate-forme d'intégration et ainsi fournir un
1179 Quelques logiciels expérimentaux peuvent cependant aller dans <em>unstable</em>,
1180 avec un avertissement dans la description, mais ce n'est pas recommandé car
1181 les paquets d'<em>unstable</em> se propagent dans <em>testing</em> et
1182 aboutissent dans <em>stable</em>. Vous ne devriez pas avoir peur d'utiliser
1183 <em>experimental</em> car ceci ne cause aucun souci aux ftpmasters, les
1184 paquets expérimentaux sont automatiquement enlevés quand vous envoyez le
1185 paquet dans <em>unstable</em> avec un numéro de version supérieur.
1187 Un nouveau logiciel qui ne risque pas d'endommager le système ira directement
1188 dans <em>unstable</em>.
1190 Une solution de rechange à <em>experimental</em> consiste à utiliser vos pages
1191 personnelles sur le serveur <tt>people.debian.org</tt>.
1193 Veuillez considérer l'utilisation de l'option <tt>-v</tt> de
1194 <prgn>dpkg-buildpackage</prgn> si l'envoi d'un paquet dans <em>unstable</em> ferme
1195 finalement des bogues qui ont d'abord été corrigés dans <em>experimental</em>.
1197 Lors de l'envoi vers <em>unstable</em> d'un paquet contenant des bogues corrigés
1198 dans <em>experimental</em>, veuillez considérer l'utilisation de l'option
1199 <tt>-v</tt> de <prgn>dpkg-buildpackage</prgn> pour qu'ils soient finalement
1202 <sect1 id="codenames">Les noms de distribution
1204 Chaque distribution Debian diffusée a un <em>nom de code</em> : Debian 1.1
1205 s'appelle « buzz » ; Debian 1.2, « rex » ; Debian
1206 1.3, « bo » ; Debian 2.0, « hamm » ; Debian 2.1,
1207 « slink »; Debian 2.2, « potato » et Debian 3.0,
1208 « woody ». Il y a aussi une pseudo-distribution nommée
1209 « sid », il s'agit de la distribution <em>unstable</em> ; comme
1210 les paquets vont d'<em>unstable</em> à <em>testing</em> quand ils approchent
1211 de la stabilité, la distribution « sid » n'est jamais diffusée. En
1212 plus du contenu habituel d'une distribution Debian, « sid » contient
1213 des paquets pour des architectures qui ne sont pas encore officiellement
1214 reconnues ou pour lesquelles la distribution n'a pas encore été diffusée. Ces
1215 architectures seront intégrées ultérieurement à la distribution principale.
1217 Comme Debian est un projet de développement ouvert (i.e. tout le monde peut
1218 participer et suivre les développements), même les distributions
1219 <em>unstable</em> et <em>testing</em> sont disponibles sur les serveurs HTTP et
1220 FTP de Debian. Si nous avions nommé le répertoire qui contient la prochaine
1221 distribution à diffuser « testing », il aurait fallu changer son nom en
1222 « stable » au moment de la diffusion, ce qui aurait forcé les miroirs
1223 FTP à télécharger à nouveau la distribution complète (qui est plutôt volumineuse).
1225 D'un autre côté, si une distribution s'appelait <em>Debian-x.y</em> dès le
1226 départ, des personnes pourraient s'imaginer que la distribution Debian
1227 <em>x.y</em> est disponible. (Cela s'est produit par le passé, un distributeur
1228 avait gravé des cédéroms Debian 1.0 en utilisant une version de développement
1229 pré-1.0. C'est pour cette raison que la première version officielle était la
1230 version 1.1 et non la 1.0).
1232 En conséquence, les noms de répertoire des distributions dans l'archive sont
1233 déterminés par leur nom de code et non par leur statut (exemple :
1234 slink). Ces noms sont identiques pendant la période de développement et une
1235 fois la distribution diffusée ; des liens symboliques, qui peuvent être
1236 modifiés facilement, indiquent la distribution stable actuelle. Tout ceci
1237 explique pourquoi les répertoires des distributions sont nommés à partir des
1238 noms de code des distributions alors que <em>stable</em>, <em>testing</em> et
1239 <em>unstable</em> sont des liens symboliques qui pointent vers les répertoires
1243 <sect id="mirrors">Les miroirs Debian
1245 Les différentes archives de téléchargement et le site web disposent de plusieurs
1246 miroirs pour soulager les serveurs principaux d'une lourde charge. En fait,
1247 certains de ces serveurs ne sont pas publics — la charge est
1248 répartie sur une première série de serveurs. De cette façon, les
1249 utilisateurs ont toujours accès aux miroirs et s'y habituent, ce qui permet à
1250 Debian de mieux répartir les besoins en bande passante sur plusieurs serveurs et
1251 plusieurs réseaux différents et évitent aux utilisateurs de surcharger
1252 l'emplacement primaire. Notez que, dans cette première série, les serveurs sont aussi à jour
1253 que possible car la mise à jour est déclenchée par les sites maîtres internes.
1255 Toutes les informations sur les miroirs Debian peuvent être trouvées à <url
1256 id="&url-debian-mirrors;">, y compris une liste des miroirs publics disponibles
1257 FTP/HTTP. Cette page utile inclut également des informations et des outils pour
1258 créer son propre miroir, soit en interne soit pour un accès public.
1260 Les miroirs sont en général mis en œuvre par des tiers qui veulent aider
1261 Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces
1265 <sect id="incoming-system">
1266 <heading>Le système Incoming
1268 Le système Incoming est responsable de la collecte des paquets mis à jour et de
1269 leur installation dans l'archive Debian. Il est constitué d'un ensemble de
1270 répertoires et de scripts qui sont installés sur <tt>&ftp-master-host;</tt>.
1272 Les paquets sont envoyés par tous les responsables Debian dans un répertoire
1273 nommé <file>UploadQueue</file>. Ce répertoire est parcouru toutes les
1274 quelques minutes par un démon appelé <prgn>queued</prgn>, les fichiers
1275 <file>*.command</file> sont exécutés et les fichiers
1276 <file>*.changes</file> restants et correctement signés sont déplacés
1277 avec leurs fichiers correspondants dans le répertoire
1278 <file>unchecked</file>. Ce répertoire n'est pas visible de la plupart
1279 des développeurs car ftp-master est à accès restreint ;
1280 il est parcouru toutes les 15 minutes
1281 par le script <prgn>katie</prgn> qui vérifie l'intégrité des paquets envoyés et
1282 leurs signatures de chiffrage. Si le paquet est considéré comme prêt à être
1283 installé, il est déplacé dans le répertoire <file>accepted</file>. S'il s'agit
1284 du premier envoi du paquet (ou s'il a de nouveaux paquets binaire), il
1285 est déplacé dans le répertoire <file>new</file>
1286 où il attend l'approbation des ftpmasters. Si le paquet contient des fichiers
1287 devant être installés <em>à la main</em>, il est déplacé dans le répertoire
1288 <file>byhand</file> où il attend une installation manuelle par les ftpmasters.
1289 Sinon, si une erreur a été détectée, le paquet est refusé et il est déplacé
1290 dans le répertoire <file>reject</file>.
1292 Une fois que le paquet est accepté, le système envoie une confirmation par
1293 courrier au responsable et ferme les bogues corrigés par l'envoi, puis
1294 les compilateurs automatiques peuvent commencer la recompilation. Le paquet est
1295 maintenant accessible publiquement à <url id="&url-incoming;"> jusqu'à
1296 ce qu'il soit vraiment installé dans l'archive Debian. Cela se produit
1297 seulement une fois par jour (et c'est également appelé une
1298 « exécution dinstall » pour des raisons historiques) ;
1299 le paquet est alors supprimé de <file>Incoming</file> et
1300 installé dans le pool avec les autres paquets. Une fois que toutes les autres
1301 mises à jour (fabrication des nouveaux fichiers d'index <file>Packages</file> et
1302 <file>Sources</file> par exemple) ont été effectuées, un script spécial est
1303 appelé pour demander aux miroirs primaires de se mettre à jour.
1305 Le logiciel de maintenance de l'archive enverra également le fichier
1306 <file>.changes</file> signé avec OpenPGP/GnuPG que vous avez envoyé, à la liste
1307 de diffusion appropriée. Si un paquet est diffusé avec le champ
1308 <tt>Distribution:</tt> positionné à « stable », l'annonce sera envoyée
1309 à &email-debian-changes;. Si un paquet est diffusé avec le champ
1310 <tt>Distribution:</tt> positionné à « unstable » ou
1311 « experimental », l'annonce sera à la place envoyée à
1312 &email-debian-devel-changes;.
1314 Bien que ftp-master soit à accès restreint, une copie de l'installation
1315 est disponible à tous les développeurs sur <tt>&ftp-master-mirror;</tt>.
1316 <!-- FIXME: delete it or keep it for historical purposes?
1318 Tous les développeurs Debian ont un droit d'écriture dans le répertoire
1319 <file>unchecked</file> pour pouvoir y envoyer leurs paquets ; ils ont également
1320 accès au répertoire <file>reject</file> pour supprimer les mauvais envois ou
1321 déplacer certains fichiers dans le répertoire <file>unchecked</file>. Mais
1322 seuls les ftpmasters ont droit d'écriture dans les autres répertoires.
1323 C'est pourquoi vous ne pouvez pas supprimer un envoi une fois qu'il a été
1326 <sect1 id="delayed-incoming-broken">Incoming différé
1328 <em>Note :</em> la description présentée ici ne fonctionne pas
1329 car ftp-master est à accès restreint. Veuillez vous reporter à <ref
1330 id="delayed-incoming"> pour la façon actuelle de faire.
1332 Le répertoire <file>unchecked</file> comprend un sous-répertoire spécial,
1333 <file>DELAYED</file><footnote>Différé en anglais</footnote>. Celui-ci est
1334 lui-même subdivisé en neuf répertoires nommés <file>1-day</file> à
1335 <file>9-day</file>. Les paquets qui sont envoyés dans l'un de ces
1336 répertoires seront déplacés dans le vrai répertoire <file>unchecked</file>
1337 après le nombre correspondant de jours. Un script, exécuté chaque jour,
1338 déplace les paquets entre les répertoires. Ceux
1339 qui sont dans « 1-day » sont installés dans
1340 <file>unchecked</file> alors que les autres sont déplacés dans le
1341 répertoire adjacent (par exemple, un paquet dans <file>5-day</file> sera
1342 déplacé dans <file>4-day</file>). Cette fonctionnalité est particulièrement
1343 utile pour les personnes qui effectuent des mises à jour indépendantes
1344 (NMU, « non-maintainer uploads »). Au lieu d'attendre avant
1345 d'envoyer la NMU, elle est envoyée dès qu'elle est prête dans l'un de ces
1346 répertoires <file>DELAYED/<var>x</var>-day</file>. Ceci laisse le nombre
1347 correspondant de jours au responsable pour réagir et envoyer lui-même une
1348 autre correction s'il n'est pas complètement satisfait par la NMU. Il peut
1349 également enlever complètement la NMU.
1351 L'utilisation de ce délai peut être simplifiée en
1352 l'intégrant à votre outil d'envoi. Par exemple, si vous utilisez
1353 <prgn>dupload</prgn> (voir <ref id="dupload">), vous pouvez ajouter cette
1354 partie à votre fichier de configuration :
1356 $delay = ($ENV{DELAY} || 7);
1358 fqdn => "&ftp-master-host;",
1359 login => "yourdebianlogin",
1360 incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/",
1364 Une fois que vous avez fait ce changement, <prgn>dupload</prgn> peut être
1365 utilisé pour envoyer facilement dans l'un des répertoires de délai ainsi :
1366 <example>DELAY=5 dupload -X-to delayed <changes-file></example>
1369 <sect id="pkg-info">Informations sur un paquet
1372 <sect1 id="pkg-info-web">Sur le web
1374 Chaque paquet a plusieurs pages web dédiées.
1375 <tt>http://&packages-host;/<var>nom-paquet</var></tt> affiche chaque version
1376 du paquet disponible dans les différentes distributions. Les informations
1377 détaillées par version incluent la description du paquet, les dépendances et
1378 des liens pour télécharger le paquet.
1380 Le système de suivi des bogues trie les bogues par paquet. Vous pouvez regarder
1381 les bogues de chaque paquet à
1382 <tt>http://&bugs-host;/<var>nom-paquet</var></tt>.
1384 <sect1 id="madison">L'outil <prgn>madison</prgn>
1386 <prgn>madison</prgn> est un outil en ligne de commande qui est disponible sur
1387 <tt>&ftp-master-host;</tt> et sur le miroir
1388 <tt>&ftp-master-mirror;</tt>. Il utilise un seul
1389 argument qui correspond au nom du paquet. Il affiche comme résultat quelle
1390 version du paquet est disponible pour chaque combinaison d'architecture et de
1391 distribution. Un exemple l'expliquera mieux.
1394 $ madison libdbd-mysql-perl
1395 libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
1396 libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
1397 libdbd-mysql-perl | 1.2216-2.0.1| testing | alpha
1398 libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc</example>
1400 Dans cet exemple, vous pouvez voir que la version dans <em>unstable</em> diffère
1401 de celle de <em>testing</em> et qu'il y a eu une NMU binaire seulement pour
1402 l'architecture alpha. Chaque version du paquet a été recompilée sur la plupart
1405 <sect id="pkg-tracking-system">Système de suivi des paquets
1407 Le système de suivi des paquets (PTS)<footnote>« Package Tracking
1408 System »</footnote> est un outil pour suivre par courrier l'activité
1409 concernant un paquet source. Cela veut vraiment dire que vous pourrez recevoir
1410 les mêmes courriers que le responsable, simplement en vous inscrivant au paquet
1413 Chaque courrier envoyé par le PTS est classé sous l'un des mots-clés
1414 listés ci-dessous. Ceci vous permettra de sélectionner les courriers que vous
1417 Par défaut, vous recevrez :
1420 <item>Tous les rapports de bogue et les discussions qui
1423 <tag><tt>bts-control</tt>
1424 <item>Les courriers de notification de <email>control@bugs.debian.org</email>
1425 sur les changement d'état de l'un des rapports de bogue.
1427 <tag><tt>upload-source</tt>
1428 <item>Le courrier de notification de <prgn>katie</prgn> quand un paquet
1429 source envoyé a été accepté.
1431 <tag><tt>katie-other</tt>
1432 <item>Les autres courriers d'avertissement et d'erreur de
1433 <prgn>katie</prgn> (comme une incohérence de passage en force pour les champs
1434 section ou priorité).
1436 <tag><tt>default</tt>
1437 <item>Tout courrier non automatique envoyé au PTS par les personnes qui
1438 veulent contacter les inscrits au paquet. Ceci peut être fait en
1439 envoyant un courrier à <tt><var>paquet-source</var>@&pts-host;</tt>. Pour
1440 prévenir l'envoi de spam, tous les courriers envoyés à ces adresses doivent
1441 contenir l'en-tête <tt>X-PTS-Approved</tt> avec une valeur non vide.
1443 <tag><tt>summary</tt>
1444 <item>(Ceci est une extension prévue).
1445 Les courriers de résumé réguliers sur l'état du paquet (statistiques sur
1446 les bogues, vue générale du portage, progression dans <em>testing</em>,
1451 Vous pouvez également décider de recevoir des informations supplémentaires :
1453 <tag><tt>upload-binary</tt>
1454 <item>Le courrier d'information de <prgn>katie</prgn> quand un paquet
1455 binaire envoyé est accepté. En d'autres termes, à chaque fois qu'un
1456 démon de compilation ou un porteur envoie votre paquet pour une autre
1457 architecture, vous recevez un courrier pour suivre comment votre paquet
1458 est recompilé pour toutes les architectures.
1461 <item>Les notifications de modifications CVS<footnote><p><em>CVS
1462 commits</em></footnote> si le responsable a mis en place un système pour
1463 faire suivre les notifications de modifications vers le PTS.
1466 <item>Les traductions des descriptions ou des questionnaires debconf soumis
1467 au Projet de traduction des descriptions de paquets
1468 Debian<footnote><p><em>Debian Description Translation Project,
1469 DDTP</em></footnote>.
1473 <sect1 id="pts-commands">L'interface de courrier du PTS
1475 Vous pouvez contrôler votre (vos) inscription(s) au PTS en envoyant différents
1476 commandes à <email>pts@qa.debian.org</email>.
1479 <tag><tt>subscribe <paquet source> [<adresse>]</tt>
1480 <item>Inscrit <var>adresse</var> aux communications liées au paquet source
1481 <var>paquet source</var>. L'adresse de l'expéditeur est utilisée si le
1482 second argument n'est pas présent. Si <var>paquet source</var> n'est pas
1483 un paquet source valide, vous obtiendrez un avertissement. Cependant,
1484 s'il s'agit d'un paquet binaire valide, le PTS vous inscrira pour le
1485 paquet source correspondant.
1487 <tag><tt>unsubscribe <paquet source> [<adresse>]</tt>
1488 <item>Supprime une inscription précédente au paquet source
1489 <var>paquet source</var> en utilisant l'adresse spécifiée ou l'adresse de
1490 l'expéditeur si le second argument n'est pas rempli.
1492 <tag><tt>which [<adresse>]</tt>
1493 <item>Liste les inscriptions pour l'expéditeur ou pour l'adresse indiquée
1494 si elle est spécifiée.
1496 <tag><tt>keyword [<adresse>]</tt>
1497 <item>Donne les mots-clés que vous acceptez. Pour une explication des ces
1498 mots-clés, <qref id="pkg-tracking-system">voir ci-dessus</qref>. Voici
1499 un rapide résumé :
1501 <item><tt>bts</tt> : courriers venant du système de gestion de bogues (BTS) Debian
1502 <item><tt>bts-control</tt> : réponses aux courriers envoyés à
1503 &bugs-host;&email-bts-control;
1504 <item><tt>summary</tt> : courriers de résumé automatique sur l'état
1506 <item><tt>cvs</tt> : notifications de modifications CVS
1507 <item><tt>ddtp</tt> : traductions des descriptions et
1508 questionnaires debconf
1509 <item><tt>upload-source</tt> : annonce d'un nouvel envoi de paquet
1510 source qui a été accepté
1511 <item><tt>upload-binary</tt> : annonce d'un nouvel envoi de binaire
1513 <item><tt>katie-other</tt> : autres courriers des ftpmasters
1514 (incohérence de passage en force, etc.)
1515 <item><tt>default</tt> : tous les autres courriers (ceux qui ne sont
1519 <tag><tt>keyword <paquet source> [<adresse>]</tt>
1520 <item>Identique à l'élément précédent, mais pour un paquet source donné
1521 car vous pouvez sélectionner un ensemble de mots-clés différent pour
1522 chaque paquet source.
1524 <tag><tt>keyword [<adresse>] {+|-|=} <liste de mots-clés></tt>
1525 <item>Accepte (+) ou refuse (-) les courriers classés sous le(s) mot(s)-clé(s).
1526 Définit la liste (=) des mots-clés acceptés.
1528 <tag><tt>keyword <paquet source> [<adresse>] {+|-|=} <liste de mots-clés></tt>
1529 <item>Identique à l'élément précédent, mais remplace la liste des mots-clés
1530 pour le paquet source indiqué.
1532 <tag><tt>quit | thanks | --</tt>
1533 <item>Arrête le traitement des commandes. Toutes les lignes suivantes sont
1534 ignorées par le robot.
1537 <sect1 id="pts-mail-filtering">Filtrer les courriers du PTS
1539 Une fois que vous vous êtes inscrit à un paquet, vous recevrez les courriers
1540 envoyés à <tt><var>paquet source</var>@packages.qa.debian.org</tt>. Ces courriers
1541 ont des en-têtes spéciaux ajoutés pour vous permettre de les filtrer dans des
1542 boîtes aux lettres (par exemple, avec <prgn>procmail</prgn>). Les en-têtes ajoutés sont
1543 <tt>X-Loop</tt>, <tt>X-PTS-Package</tt>, <tt>X-PTS-Keyword</tt> et
1544 <tt>X-Unsubscribe</tt>.
1546 Voici un exemple d'en-têtes ajoutés pour une notification d'envoi de
1547 source sur le paquet <package>dpkg</package> :
1549 X-Loop: dpkg@&pts-host;
1551 X-PTS-Keyword: upload-source
1552 X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
1555 <sect1 id="pts-cvs-commit">Faire suivre les modifications de CVS vers le PTS
1557 Si vous utilisez un référentiel CVS accessible publiquement pour maintenir votre
1558 paquet Debian, vous pouvez vouloir faire suivre les notifications de
1559 modifications vers le PTS pour que les inscrits (ainsi que des possibles
1560 co-responsables) puissent suivre de près l'évolution du paquet.
1562 Une fois que votre référentiel génère des notifications de modifications, vous
1563 devez simplement vous assurer qu'il envoie une copie de tous ces courriers à
1564 <tt><var>paquet source</var>_cvs@&pts-host;</tt>. Seules les personnes qui ont
1565 accepté le mot-clé <em>cvs</em> recevront les notifications.
1567 <sect1 id="pts-web">L'interface web du PTS
1569 Le PTS possède une interface web à <url id="http://&pts-host;/"> qui réunit
1570 beaucoup d'informations au
1571 même endroit à propos de chaque paquet source. Il propose plusieurs liens utiles
1572 (BTS, statistiques QA, informations de contact, état de traduction DDTP,
1573 journaux de compilation automatique) et il regroupe beaucoup d'autres informations
1574 provenant de différents endroits (les 30 dernières entrées de changelog, l'état
1575 dans <em>testing</em>, etc.). Il s'agit d'un outil très pratique si vous désirez
1576 connaître ce qu'il en est d'un paquet source spécifique. De plus, il y a un
1577 formulaire qui permet de facilement s'inscrire au PTS par courrier.
1579 Vous pouvez aller directement à la page web concernant un paquet source avec une
1580 URL comme <tt>http://&pts-host;/<var>paquet source</var></tt>.
1582 Cette interface a été conçue comme un portail pour le développements des
1583 paquets : vous pouvez ajouter du contenu personnalisé aux pages de vos
1584 paquets. Vous pouvez ajouter des « informations
1585 statiques »<footnote><em>Static information</em></footnote> (des annonces
1586 qui sont destinées à rester disponibles indéfiniment) et des nouvelles dans la
1587 section « dernières nouvelles »<footnote><em>Latest
1588 news</em></footnote>.
1590 Les annonces statiques peuvent être utilisées pour indiquer :
1592 <item>la disponibilité d'un projet hébergé sur <qref id="alioth">Alioth</qref> pour la
1593 co-maintenance du paquet,
1594 <item>un lien vers le site web amont,
1595 <item>un lien vers le suivi de bogues amont,
1596 <item>l'existence d'un canal IRC dédié au logiciel,
1597 <item>toute autre ressource disponible qui peut être utile à la maintenance du paquet.
1599 Les nouvelles usuelle peuvent être utilisées pour annoncer que :
1601 <item>des paquets bêta sont disponibles pour test,
1602 <item>des paquets finaux sont attendus pour la semaine prochaine,
1603 <item>l'empaquetage est sur le point d'être intégralement refait,
1604 <item>des rétroportages sont disponibles,
1605 <item>le responsable est en vacance (s'il désire publier cette information),
1606 <item>une mise à jour indépendante (NMU) est en cours de réalisation,
1607 <item>quelque chose d'important va affecter le paquet.
1610 Les deux types d'informations sont fabriqués de façon similaire : il vous
1611 suffit d'envoyer un courrier soit à <email>pts-static-news@qa.debian.org</email>
1612 (pour les annonces statiques), soit à <email>pts-news@qa.debian.org</email>
1613 (pour les nouvelles usuelles). Le courrier devrait indiquer quel paquet est
1614 concerné par la nouvelle en donnant le nom du paquet source dans un en-tête de
1615 courrier <tt>X-PTS-Package</tt> ou dans un pseudo-en-tête <tt>Package</tt>
1616 (comme pour les rapports de bogue du BTS). Si une URL est disponible dans
1617 l'en-tête de courrier <tt>X-PTS-Url</tt> ou dans un pseudo-en-tête <tt>Url</tt>,
1618 le résultat est un lien vers cette URL au lieu d'une nouvelle complète.
1620 Voici quelques exemples de courriers valides utilisés pour générer des nouvelles dans
1621 le PTS. Le premier ajoute un lien vers l'interface cvsweb de debian-cd dans la
1622 section « Informations statiques » :
1624 From: Raphael Hertzog <hertzog@debian.org>
1625 To: pts-static-news@qa.debian.org
1626 Subject: Browse debian-cd CVS repository with cvsweb
1629 Url: http://cvs.debian.org/debian-cd/
1632 Le second est une annonce envoyée à une liste de diffusion et également
1633 envoyée au PTS pour qu'elle soit publiée sur la page web du PTS du paquet. Notez
1634 l'utilisation du champ BCC pour éviter que des réponses ne soient envoyées par
1637 From: Raphael Hertzog <hertzog@debian.org>
1638 To: debian-gtk-gnome@lists.debian.org
1639 Bcc: pts-news@qa.debian.org
1640 Subject: Galeon 2.0 backported for woody
1641 X-PTS-Package: galeon
1645 I'm glad to announce that galeon has been backported for woody. You'll find
1650 Réfléchissez-y à deux fois avant d'ajouter une nouvelle au PTS car vous ne
1651 pourrez pas l'enlever par la suite et vous ne pourrez pas non plus l'éditer. La
1652 seule chose que vous puissiez faire est d'envoyer une deuxième nouvelle qui va
1653 déprécier l'information contenue dans la précédente.
1655 <sect id="ddpo">Vue d'ensemble des paquets d'un développeur
1657 Un portail web pour l'Assurance Qualité (QA) est disponible à <url
1658 id="&url-ddpo;"> qui affiche un tableau de tous les paquets d'un
1659 développeur (y compris ceux pour lequel il est co-responsable). Le tableau donne
1660 un bon résumé sur les paquets d'un développeur : nombre de bogues par
1661 gravité, liste des versions disponibles, état des tests et des liens vers
1662 d'autres informations utiles.
1664 C'est une bonne idée de vérifier régulièrement vos données pour ne pas oublier
1665 de bogues ouverts et pour ne pas oublier quels paquets sont sous votre
1668 <sect id="alioth">Debian *Forge : Alioth
1670 Alioth est un service de Debian plutôt récent, basé sur une version
1671 légèrement modifiée du logiciel GForge (qui a évolué à partir de
1672 SourceForge). Ce logiciel offre aux développeurs l'accès à des outils
1673 faciles d'utilisation comme un gestionnaire de suivi de bogues, un
1674 gestionnaire de correctifs, un gestionnaire de tâches et de projets,
1675 un service d'hébergement de fichiers, des listes de diffusion, des
1676 dépôts CVS, etc. Tous ces outils sont gérés par une interface web.
1678 Alioth est destiné à fournir des facilités pour des projets de logiciels
1679 soutenus ou dirigés par Debian, à faciliter les contributions de développeurs
1680 externes aux projets initiés par Debian et à aider des projets dont les buts
1681 sont de promouvoir Debian ou ses dérivés.
1683 Tous les développeurs Debian ont automatiquement un compte sur Alioth. Ils
1684 peuvent l'activer en utilisant la fonctionnalité de récupération des mots de
1685 passe. Les développeurs externes peuvent demander un compte invité sur Alioth.
1687 Pour plus d'informations, veuillez visiter <url id="&url-alioth;">.
1689 <sect id="developer-misc">« Goodies » pour les développeurs
1691 <sect1 id="lwn">Abonnements LWN
1693 Depuis octobre 2002, HP parraine l'abonnement à LWN pour tous les
1694 développeurs Debian intéressés.
1696 Les détails sur les moyens d'accéder à cet avantage sont expliqués dans <url
1697 id="http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html">.
1700 <chapt id="pkgs">Gestion des paquets
1702 Ce chapitre contient des informations relatives à la création, l'envoi, la
1703 maintenance et le portage des paquets.
1706 <sect id="newpackage">Nouveaux paquets
1708 Si vous voulez créer un nouveau paquet pour la distribution Debian, vous devriez
1709 commencer par consulter la liste des <url id="&url-wnpp;" name="paquets en
1710 souffrance et paquets souhaités">. Vous pourrez ainsi vérifier que personne ne
1711 travaille déjà sur ce paquet et éviter un double travail. Consultez aussi cette
1712 page si vous voulez en savoir plus.
1714 Supposons que personne ne travaille sur le paquet que vous visez, vous devez
1715 alors envoyer un rapport de bogue (voir <ref id="submit-bug">) concernant le
1716 pseudo-paquet <package>wnpp</package>. Ce courrier devra décrire le paquet que
1717 vous projetez de créer, la licence de ce paquet et l'URL à laquelle le source
1718 peut être téléchargé. Cette liste n'est pas limitative.
1720 Le sujet de votre rapport de bogue devra être <ITP<footnote><p><em>Intent To
1721 Package</em> : intention d'empaquetage</footnote> :
1722 <var>NomDuPaquet</var> — <var>courte description</var>>, en remplaçant
1723 <var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera
1724 <em>wishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
1725 &email-debian-devel; en mettant cette adresse dans le champ
1726 <tt>X-Debbugs-CC:</tt> de l'en-tête du message. N'utilisez pas le champ
1727 <tt>CC:</tt> car de cette manière le sujet du message ne contiendrait pas le
1730 Il faudra aussi ajouter une entrée <tt>Closes: bug#<var>nnnnn</var></tt> dans le
1731 fichier <file>changelog</file> du nouveau paquet. Cette indication fermera
1732 automatiquement le rapport de bogue à l'installation du nouveau paquet sur les
1733 serveurs d'archivage (voir <ref id="upload-bugfix">).
1735 Plusieurs raisons nous poussent à demander aux responsables
1736 d'annoncer leur intention :
1738 <item>Les responsables ont ainsi la possibilité de puiser dans l'expérience
1739 des autres responsables et cela leur permet de savoir si une autre
1740 personne travaille déjà dessus.
1741 <item>D'autres personnes qui envisagent de travailler sur le même paquet
1742 apprendront ainsi qu'il existe déjà un volontaire, l'effort peut alors
1744 <item>Cela permet aux autres responsables de connaître le nouveau
1745 paquet mieux que ne le permettent la description d'une ligne et l'habituelle
1746 entrée de type changelog <em>Initial release</em> postée sur
1747 <tt>debian-devel-changes</tt>.
1748 <item>C'est une information utile pour
1749 les gens qui utilisent la distribution <em>unstable</em> et qui sont nos
1750 premiers testeurs. Nous devons faciliter la tâche de ces gens.
1751 <item>Avec ces annonces, les développeurs Debian et toutes les autres personnes
1752 intéressées peuvent se faire une meilleure idée des évolutions et des
1753 nouveautés du projet.
1757 <sect id="changelog-entries">Enregistrer les modifications dans le paquet
1759 Les modifications que vous apportez au paquet doivent être notifiées dans le
1760 fichier <file>debian/changelog</file>. Ces notes doivent donner une
1761 description concise des changements, expliquer les raisons de ceux-ci (si
1762 ce n'est pas clair) et indiquer si des rapports de bogue ont été clos. Il
1763 faut aussi indiquer quand le paquet a été terminé. Ce fichier sera
1765 <file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
1766 <file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un paquet
1769 Le fichier <file>debian/changelog</file> a une structure précise comportant
1770 différents champs. Le champ <em>distribution</em> est décrit dans <ref
1771 id="distribution">. Vous trouverez plus d'informations sur la structure de ce
1772 fichier dans la section « <file>debian/changelog</file> » de la
1773 <em>charte Debian</em>.
1775 Les entrées du fichier <file>changelog</file> peuvent être
1776 utilisées pour fermer des rapports de bogue au moment où le paquet est
1777 installé dans l'archive. Voir la section <ref id="upload-bugfix">.
1779 Par convention, l'entrée changelog d'un paquet contenant une nouvelle version
1780 amont ressemble à :
1782 * new upstream version
1785 Quelques outils peuvent vous aider à créer des entrées et à finaliser le fichier
1786 <file>changelog</file> pour une livraison — voir les sections <ref
1787 id="devscripts"> et <ref id="dpkg-dev-el">.
1789 Voir aussi <ref id="bpp-debian-changelog">.
1792 <sect id="sanitycheck">Tester le paquet
1794 Avant d'envoyer votre paquet, vous devriez faire quelques tests de base. Vous
1795 devriez au moins faire les tests suivants (il vous faut une ancienne version
1798 <item>Installez le paquet et vérifiez que le logiciel fonctionne. Si le
1799 paquet existait déjà dans une version plus ancienne, faites une mise à
1801 <item>Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
1802 <prgn>lintian</prgn> comme suit : <tt>lintian -v
1803 <var>version-paquet</var>.changes</tt>. Ce programme fera une
1804 vérification sur les paquets source et binaire. Si vous ne comprenez pas
1805 les messages retournés par <prgn>lintian</prgn>, essayez l'option
1806 <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
1807 bavard dans sa description du problème.
1809 En principe, un paquet pour lequel <prgn>lintian</prgn> renvoie des erreurs
1810 (elles commencent par <tt>E</tt>) <em>ne doit pas</em> être installé dans
1813 Pour en savoir plus sur <prgn>lintian</prgn>, reportez-vous à la section
1815 <item>Vous pouvez facultativement exécuter <ref id="debdiff"> pour analyser les
1816 modifications depuis une ancienne version si celle-ci existe.
1817 <item>Faites régresser le paquet vers sa version précédente si elle existe
1818 — cela permet de tester les scripts <file>postrm</file> et
1820 <item>Désinstallez le paquet et réinstallez-le.
1824 <sect id="sourcelayout">Disposition du paquet source
1826 Il existe deux types de paquets source Debian :
1828 <item>les paquets appelés <em>natifs</em> pour lesquels il
1829 n'y a pas de distinction entre les sources d'origine et les
1830 correctifs appliqués pour Debian
1831 <item>les paquets (plus courants) où il y a un fichier archive source
1832 d'origine accompagné par un autre fichier contenant les
1833 correctifs pour Debian.
1836 Pour les paquets natifs, le paquet source inclut un fichier de contrôle source
1837 Debian (<tt>.dsc</tt>) et l'archive source (<tt>.tar.gz</tt>). Un paquet source
1838 d'un paquet non natif inclut un fichier de contrôle source Debian, l'archive
1839 source d'origine (<tt>.orig.tar.gz</tt>) et les correctifs Debian
1840 (<tt>.diff.gz</tt>).
1842 Le caractère natif d'un paquet est déterminé lorsqu'il est construit par <manref
1843 name="dpkg-buildpackage" section="1">. Le reste de cette section ne se rapporte
1844 qu'aux paquets non natifs.
1847 La première fois qu'un paquet est installé dans l'archive pour une version amont
1848 donnée, le fichier <file>tar</file> de cette version amont doit être
1849 téléchargé et mentionné dans le fichier <file>.changes</file>. Par la suite,
1850 ce fichier <file>tar</file> sera utilisé pour générer les fichiers
1851 <file>diff</file> et <file>.dsc</file> et il ne sera pas nécessaire de le
1852 télécharger à nouveau.
1854 Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn>
1855 incluront le fichier <file>tar</file> amont si et seulement si le numéro de
1856 révision du paquet source est 0 ou 1, ce qui indique une nouvelle version
1857 amont. Ce comportement peut être modifié en utilisant <tt>-sa</tt> pour
1858 l'inclure systématiquement ou <tt>-sd</tt> pour ne jamais l'inclure.
1860 Si la mise à jour ne contient pas le fichier <file>tar</file> des sources
1861 originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
1862 fichiers <file>.dsc</file> et <file>diff</file> de la mise à jour, utiliser
1863 un fichier <tt>tar</tt> identique à l'octet près à celui déjà présent dans
1866 <sect id="distribution">Choisir une distribution
1868 Chaque envoi doit spécifier à quelle distribution le paquet est destiné. Le
1869 processus de construction de paquet extrait cette information à partir de la
1870 première ligne du fichier <file>debian/changelog</file> et la place dans le champ
1871 <tt>Distribution</tt> du fichier <tt>.changes</tt>.
1873 Il existe plusieurs valeurs possibles pour ce champ : « stable »,
1874 « unstable », « testing-proposed-updates » et
1875 « experimental ».
1877 En fait, il y a deux autres possibilités :
1878 « stable-security » et « testing-security », mais
1879 veuillez lire <ref id="bug-security"> pour plus d'informations sur celles-ci.
1881 Il n'est pas possible d'envoyer un paquet dans plusieurs distributions
1884 <sect1 id="upload-stable">Cas spécial : mise à jour d'un paquet de
1885 la distribution <em>stable</em>
1887 Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
1888 sera dirigé vers le répertoire <file>stable-proposed-updates</file> des
1889 archives Debian pour y être testé avant d'être effectivement inclus dans
1892 Une livraison pour la distribution <em>stable</em> requiert des soins
1893 supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
1894 que dans les cas suivants :
1896 <item>un problème fonctionnel vraiment critique,
1897 <item>un paquet devenu ininstallable,
1898 <item>un paquet indisponible pour une architecture.
1901 Par le passé, des envois vers <em>stable</em> étaient également utilisés pour
1902 corriger les problèmes de sécurité. Cependant, cette pratique est dépréciée car
1903 les envois utilisés pour les avis de sécurité Debian<footnote>Debian security
1904 advisory</footnote> sont automatiquement copiés dans l'archive
1905 <file>proposed-updates</file> appropriée quand l'avis est publié. Reportez-vous
1906 à <ref id="bug-security"> pour des informations plus détaillées sur la gestion
1907 des problèmes de sécurité.
1909 Il est fortement déconseillé de changer quoi que ce soit si ce
1910 n'est pas important car même une modification triviale peut provoquer un
1913 Les paquets livrés pour <em>stable</em> doivent être compilés avec la
1914 distribution <em>stable</em> pour que leurs dépendances se limitent aux
1915 bibliothèques (et autres paquets) disponibles dans <em>stable</em> ;
1916 un paquet livré pour la distribution <em>stable</em> qui dépend d'une
1917 bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté.
1918 Modifier les dépendances d'autres paquets (en manipulant le champ
1919 <tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
1920 ininstallables, est fortement déconseillé.
1922 L'équipe responsable de la distribution<footnote><em>the Release
1923 team</em></footnote> (joignable à l'adresse &email-debian-release;)
1924 évaluera régulièrement le contenu de <em>stable-proposed-updates</em> et
1925 décidera si votre paquet peut être inclus dans la distribution
1926 <em>stable</em>. Soyez précis (et, si nécessaire, prolixe) quand vous
1927 décrivez, dans le fichier changelog, vos changements pour une livraison
1928 vers <em>stable</em>, sinon le paquet ne sera pas pris en considération.
1930 Il est fortement conseillé de discuter avec le responsable de la version stable <em>avant</em>
1931 de réaliser un envoi dans <em>stable</em>/<em>stable-proposed-updates</em>, pour
1932 que le paquet envoyé corresponde aux besoins de la prochaine révision de <em>stable</em>.
1934 <sect1 id="upload-t-p-u">Cas spécial : mise à jour d'un paquet de la
1935 distribution <em>testing</em>/<em>testing-proposed-updates</em>
1937 Veuillez consulter les informations dans la <qref id="t-p-u">section sur
1938 <em>testing</em></qref> pour des détails.
1940 <sect id="upload">Mettre à jour un paquet
1942 <sect1 id="upload-ftp-master">Installer un paquet sur
1945 Pour installer un paquet, vous devez envoyer les fichiers (y compris les
1946 fichiers changes et dsc signés) par ftp anonyme sur
1947 <ftpsite>&ftp-master-host;</ftpsite> dans le répertoire &upload-queue;. Pour
1948 que les fichiers y soient traités, ils doivent être signés avec une clé du
1949 porte-clés (<em>keyring</em>) Debian.
1952 Attention, il est préférable de transférer le fichier
1953 <tt>changes</tt> en dernier. Dans le cas contraire, votre livraison pourrait
1954 être rejetée car l'outil de maintenance de l'archive pourrait lire le fichier
1955 <tt>changes</tt> et constater que les fichiers ne sont pas tous présents.
1957 <!-- FIXME: is this still topical? Explain the rationale? -->
1959 <em>Note :</em> ne téléchargez pas sur <tt>ftp-master</tt> de paquets
1960 concernant la cryptographie qui appartiendraient à <em>contrib</em> ou <em>non-free</em>.
1961 Ces logiciels doivent aller sur <tt>non-us</tt> (voir <ref
1962 id="upload-non-us">). De plus, les paquets contenant un logiciel protégé par
1963 des brevets américains ne peuvent pas être envoyés sur
1964 <tt>ftp-master</tt> ; selon le cas, ils peuvent peut-être pourtant être
1965 envoyés vers <file>non-US/non-free</file> (le paquet est dans
1966 <em>non-free</em> à cause de problèmes de distribution et non pas à cause de
1967 la licence du logiciel). Quand vous ne pouvez télécharger sur
1968 <tt>ftp-master</tt>, vous ne pouvez pas non plus télécharger sur
1969 les sites de repli qui arrivent finalement sur <tt>ftp-master</tt>. Si vous ne savez pas si votre paquet
1970 est protégé par un brevet ou s'il est soumis aux lois de contrôle des
1971 exportations américaines, posez la question sur la liste
1972 &email-debian-devel;.
1975 Les paquets <ref id="dupload"> ou <ref id="dput"> pourront vous faciliter le
1976 travail lors du téléchargement. Ces programmes, bien pratiques, aident à
1977 automatiser le processus d'envoi de paquets vers Debian
1979 Pour supprimer des paquets, veuillez lire le fichier README dans ce répertoire
1980 FTP et le paquet Debian <ref id="dcut">.
1982 <sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
1985 <em>Note :</em> non-us n'est plus traité actuellement.
1987 Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
1988 exportations américaines ne doivent pas être installés sur
1989 <tt>ftp-master</tt>. Installez le paquet par FTP anonyme sur
1990 <ftpsite>non-us.debian.org</ftpsite> dans le répertoire &upload-queue;
1991 (<ref id="dupload"> et <ref id="dput"> avec les options adéquates peuvent
1992 tous deux être utilisés pour cela).
1994 Attention, les personnes résidant aux États-Unis et les citoyens américains sont
1995 soumis à des restrictions sur l'exportation des logiciels de cryptographie.
1996 Au moment où j'écris, les citoyens américains peuvent exporter quelques
1997 logiciels de cryptographie soumis à une obligation de déclaration auprès du
1998 département du commerce américain. Toutefois, cette restriction a été
1999 abandonnée pour des logiciels qui sont déjà disponibles en dehors des
2000 États-Unis. En conséquence, tout logiciel de cryptographie de la section
2001 <em>main</em> de l'archive Debian qui ne dépend d'aucun paquet d'une autre
2002 section — il ne doit pas dépendre de <em>non-US/main</em> — peut
2003 être téléchargé sur <tt>ftp-master</tt> ou l'une de ses files d'attente
2006 La <em>charte Debian</em> n'empêche pas les résidents et citoyens américains de
2007 livrer des paquets sur <tt>non-US</tt> mais ils devront être vigilants en le
2008 faisant. Nous recommandons aux responsables concernés de prendre toutes les
2009 précautions nécessaires, <em>y compris la consultation d'un juriste</em>,
2010 pour s'assurer qu'ils n'enfreignent pas une loi américaine en livrant un
2011 paquet sur <tt>non-US</tt>.
2013 Pour les paquets des sections <em>non-US/main</em> et <em>non-US/contrib</em>,
2014 les responsables devraient au moins suivre la <url id="&url-u.s.-export;"
2015 name="procédure décrite par le gouvernement américain">. Les responsables de
2016 paquets <em>non-US/non-free</em> devront en plus consulter les <url
2017 id="&url-notification-of-export;" name="règles de déclaration d'exportation
2018 pour les logiciels commerciaux">.
2020 Cette section a pour seul but d'informer, elle n'a pas valeur de conseil
2021 juridique. Une fois encore, nous recommandons aux résidents et citoyens
2022 américains de consulter un juriste avant de livrer un paquet sur
2025 <em>Note :</em> non-us a été interrompu avec la publication de
2028 <sect1 id="delayed-incoming">Envois différés
2030 Les envois différés sont pour le moment réalisés <em>via</em> la file différée
2031 sur gluck. Le répertoire d'envoi est
2032 <ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>.
2033 0-day est envoyé approximativement une heure avant l'exécution de dinstall.
2035 Avec une version assez récente de dput, cette section
2039 fqdn = gluck.debian.org
2042 dans votre fichier ~/.dput.cf devrait fonctionner correctement pour réaliser des
2043 envois dans la file DELAYED.
2045 <em>Note :</em>
2046 Comme la file d'envoi va sur <tt>ftp-master</tt>, la
2047 prescription que l'on trouve dans <ref id="upload-ftp-master"> s'applique
2050 <sect1>Envois de sécurité
2052 N'envoyez PAS un paquet vers la file d'envoi de sécurité (<em>oldstable-security</em>,
2053 <em>stable-security</em>, etc.) sans avoir obtenu au préalable l'autorisation de l'équipe de
2054 sécurité. Si le paquet ne correspond pas tout à fait aux besoins de cette
2055 équipe, il entraînera beaucoup de problèmes et de délais dans la gestion de cet
2056 envoi non désiré. Pour plus de détails, consultez la section <ref id="bug-security">.
2058 <sect1>Les autres files d'envoi
2060 Les files scp sur ftp-master et security sont pratiquement inutilisables
2061 à cause des restrictions de connexion sur ces hôtes.
2063 Les files anonymes sur ftp.uni-erlangen.de et ftp.uk.debian.org sont
2064 actuellement arrêtées. Un travail est en cours pour les restaurer.
2066 Les files sur master.debian.org, samosa.debian.org, master.debian.or.jp
2067 et ftp.chiark.greenend.org.uk sont arrêtées de façon permanente et ne seront pas
2068 restaurées. La file du Japon sera remplacée par une nouvelle file sur
2069 hp.debian.or.jp un jour.
2071 À l'heure actuelle, la file en ftp anonyme sur auric.debian.org (le précédent
2072 ftp-master) fonctionne, mais elle est déconseillée et sera supprimée à un moment
2075 <sect1 id="upload-notification">
2076 <heading>Notification de l'installation d'un nouveau paquet</heading>
2078 Les administrateurs de l'archive Debian sont responsables de l'installation des
2079 mises à jour. La plupart des mises à jour sont gérées quotidiennement par le
2080 logiciel de gestion de l'archive <prgn>katie</prgn>. Les mises à jour de
2081 paquets sur la distribution <em>unstable</em> sont installées
2082 ainsi. Dans les autres cas et notamment dans le cas d'un nouveau paquet,
2083 celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois entre le
2084 téléchargement d'un paquet vers un serveur et son installation effective. Soyez
2087 Dans tous les cas, vous recevrez un accusé de réception par courrier
2088 électronique indiquant que votre paquet a été installé et quels rapports de
2089 bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous les
2090 rapports de bogue que vous vouliez clore sont bien dans cette liste.
2092 L'accusé de réception indique aussi la section dans laquelle le paquet a été
2093 installé. S'il ne s'agit pas de votre choix, vous recevrez un second courrier
2094 qui vous informera de cette différence (voir ci-dessous).
2096 Notez que si vous envoyez <em>via</em> les files, le logiciel de démon de file
2097 vous enverra également une notification par courriel.
2100 <sect id="override-file">Spécifier la section, la sous-section et la priorité d'un paquet
2102 Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
2103 <file>debian/control</file> n'indiquent ni où le paquet sera installé dans
2104 l'archive Debian, ni sa priorité. Afin de conserver la cohérence de
2105 l'archive, ce sont les administrateurs qui contrôlent ces champs. Les valeurs
2106 du fichier <file>debian/control</file> sont juste des indications.
2108 Les administrateurs de l'archive indiquent les sections et priorités des paquets
2109 dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le
2110 fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez
2111 informé par courrier électronique quand votre paquet sera installé dans
2112 l'archive. Vous pourrez corriger votre fichier <em>debian/control</em> avant
2113 votre prochain téléchargement ou alors vous pourrez vouloir modifier le
2114 fichier <em>override</em>.
2116 Pour modifier la section dans laquelle un paquet est archivé, vous devez d'abord
2117 vérifier que fichier <file>debian/control</file> est correct. Ensuite,
2118 envoyez un courrier à &email-override; ou un rapport de bogue sur le
2119 pseudo-paquet <package>ftp.debian.org</package> demandant la modification de
2120 la section ou de la priorité de votre paquet. Exposez bien les raisons qui
2121 vous amènent à demander ces changements.
2123 Pour en savoir plus sur les <em>fichiers override</em>, reportez-vous à <manref
2124 name="dpkg-scanpackages" section="1"> et <url
2125 id="&url-bts-devel;#maintincorrect">.
2127 Notez que le champ <tt>Section</tt> décrit à la fois la section et la
2128 sous-section, comme décrit dans <ref id="archive-sections">. Si la section est
2129 « main », elle devrait être omise. La liste des sous-sections
2130 autorisées peut être trouvée dans <url
2131 id="&url-debian-policy;ch-archive.html#s-subsections">.
2133 <sect id="bug-handling">Gérer les bogues
2135 Chaque développeur doit être capable de travailler avec le <url name="système de
2136 suivi des bogues" id="&url-bts;"> Debian. Il faut savoir comment remplir
2137 des rapports de bogue correctement (voir <ref id="submit-bug">), comment les
2138 mettre à jour et les réordonner et comment les traiter et les fermer.
2140 Les fonctionnalités du système de suivi des bogues sont décrites dans la <url id="&url-bts-devel;" name="documentation
2141 du BTS pour les développeurs">. Ceci inclut la fermeture des bogues, l'envoi des
2142 messages de suivi, l'assignation des niveaux de gravité et des marques,
2143 l'indication que les bogues ont été envoyés au développeur amont et autres
2146 Des opérations comme réassigner des bogues à d'autres paquets, réunir des
2147 rapports de bogues séparés traitant du même problème ou rouvrir des bogues
2148 quand ils ont été prématurément fermés, sont gérées en utilisant le serveur de
2149 courrier de contrôle. Toutes les commandes disponibles pour ce serveur sont
2150 décrites dans la <url id="&url-bts-control;" name="documentation du serveur de
2153 <sect1 id="bug-monitoring">Superviser les rapports de bogue
2155 Si vous voulez être un bon responsable, consultez régulièrement la page du <url
2156 id="&url-bts;" name="système de suivi des bogues">. Cette page contient tous
2157 les rapports de bogue qui concernent vos paquets. Vous pouvez les vérifier avec
2158 cette page : <tt>http://&bugs-host;/<var>votre_compte</var>@debian.org</tt>.
2160 Les responsables interagissent avec le système de suivi des bogues en utilisant
2161 l'adresse électronique <tt>&bugs-host;</tt>. Vous trouverez une documentation
2162 sur les commandes disponibles à l'adresse <url id="&url-bts;"> ou, si vous avez
2163 installé le paquet <package>doc-debian</package>, dans les fichiers locaux
2166 Certains trouvent utile de recevoir régulièrement une synthèse des rapports de
2167 bogues ouverts. Si vous voulez recevoir une synthèse hebdomadaire relevant tous
2168 les rapports de bogue ouverts pour vos paquets, vous pouvez configurer
2169 <prgn>cron</prgn> comme suit :
2171 # Synthèse hebdomadaire des rapports de bogue qui me concernent
2174 Remplacez <var>address</var> par votre adresse officielle de responsable Debian.
2176 <sect1 id="bug-answering">Répondre à des rapports de bogue
2178 Lorsque vous répondez à des rapports de bogue, assurez-vous que toutes vos
2179 discussions concernant les bogues sont envoyées au
2180 rapporteur du bogue et au bogue lui-même (<email>123@&bugs-host;</email>
2181 par exemple). Si vous rédigez un nouveau courrier et que vous ne vous souvenez
2182 plus de l'adresse du rapporteur de bogue, vous pouvez utiliser l'adresse
2183 <email>123-submitter@&bugs-host;</email> pour contacter le rapporteur
2184 <em>et</em> enregistrer votre courrier dans le journal du bogue (ce qui veut
2185 dire que vous n'avez pas besoin d'envoyer une copie du courrier à
2186 <email>123@&bugs-host;</email>).
2188 Si vous recevez un bogue mentionnant « FTBFS », cela veut dire
2189 « Fails To Build From Source » (Erreur de construction à partir du
2190 source). Les porteurs emploient fréquemment cet acronyme.
2192 Une fois que vous avez traité un rapport de bogue (i.e. que vous l'avez
2193 corrigé), marquez-le comme <em>done</em> (fermez-le) en envoyant un message
2194 d'explication à <email>123-done@&bugs-host;</email>. Si vous corrigez un
2195 bogue en changeant et en envoyant une nouvelle version du paquet, vous pouvez
2196 fermer le bogue automatiquement comme décrit dans <ref id="upload-bugfix">.
2198 Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la commande
2199 <tt>close</tt> à l'adresse &email-bts-control;.Si vous le faites, le rapporteur
2200 n'aura aucune information sur la clôture de son rapport.
2202 <sect1 id="bug-housekeeping">Gestion générale des bogues
2204 En tant que responsable de paquet, vous trouverez fréquemment des bogues dans
2205 d'autres paquets ou vous aurez des bogues sur vos paquets qui sont en fait des
2206 bogues sur d'autres paquets. Les fonctions intéressantes du système de suivi
2207 des bogues sont décrites dans la <url
2208 id="&url-bts-devel;" name="documentation du BTS pour les développeurs Debian">.
2209 Les <url id="&url-bts-control;" name="instructions du serveur de contrôle du
2210 BTS"> documentent les opérations techniques du BTS, telles que comment remplir,
2211 réassigner, regrouper et marquer des bogues. Cette section contient des lignes
2212 directrices pour gérer vos propres bogues, définies à partir de l'expérience
2213 collective des développeurs Debian.
2215 Remplir des rapports de bogue pour des problèmes que vous trouvez dans d'autres
2216 paquet est l'une des « obligations civiques » du responsable,
2217 reportez-vous à <ref id="submit-bug"> pour les détails. Cependant, gérer les
2218 bogues de vos propres paquets est encore plus important.
2220 Voici une liste des étapes que vous pouvez suivre pour gérer un rapport de
2224 Décider si le rapport correspond à un bogue réel ou non. Parfois, les
2225 utilisateurs exécutent simplement un programme de la mauvaise façon car
2226 ils n'ont pas lu la documentation. Si c'est votre diagnostic, fermez
2227 simplement le bogue avec assez d'informations pour laisser l'utilisateur
2228 corriger son problème (donnez des indications vers la bonne
2229 documentation et ainsi de suite). Si le rapport de bogue revient
2230 régulièrement, vous devriez vous demander si la documentation est assez
2231 bonne ou si le programme ne devrait pas détecter une mauvaise
2232 utilisation pour donner un message d'erreur informatif. Il s'agit d'un
2233 problème qui peut être discuté avec l'auteur amont.
2235 Si le rapporteur de bogue n'est pas d'accord avec votre décision de
2236 fermeture du bogue, il peut le ré-ouvrir jusqu'à ce que vous trouviez un
2237 accord sur la façon de le gérer. Si vous n'en trouvez pas, vous pouvez
2238 marquer le bogue avec <tt>wontfix</tt> pour indiquer aux personnes que
2239 le bogue existe, mais ne sera pas corrigé. Si cette situation n'est pas
2240 acceptable, vous (ou le rapporteur) pouvez vouloir demander une décision
2241 par le comité technique en réattribuant le bogue à
2242 <package>tech-ctte</package> (vous pouvez utiliser la commande
2243 <tt>clone</tt> du BTS si vous désirez garder le bogue comme rapporté sur
2244 votre paquet). Avant de faire cela, veuillez lire la <url
2245 id="&url-tech-ctte;" name="procédure recommandée">.
2248 Si le bogue est réel, mais est causé par un autre paquet,
2249 réattribuez simplement le bogue à l'autre paquet. Si vous ne savez pas à
2250 quel paquet il doit être réattribué, vous pouvez demander de l'aide sur
2251 <qref id="irc-channels">IRC</qref> ou sur &email-debian-devel;.
2252 Veuillez vous assurer que le (ou les) responsable(s) du paquet
2253 sur lequel est réattribué le paquet sait pourquoi vous l'avez
2256 Parfois, vous devez également ajuster la gravité du bogue pour qu'elle
2257 corresponde à notre définition de gravité des bogues. C'est dû au
2258 fait que les gens tendent à augmenter la gravité des bogues pour
2259 s'assurer que leurs bogues seront corrigés rapidement. La gravité de
2260 certains bogues peut même être rétrogradée en <em>wishlist</em> (souhait)
2261 quand le changement demandé est seulement d'ordre cosmétique.
2264 Si le bogue est réel, mais que le problème a déjà été rapporté
2265 par quelqu'un d'autre, les deux rapports de bogues pertinents
2266 devraient être fusionnés en un seul en utilisant la commande
2267 <tt>merge</tt> (fusion) du BTS. Ainsi, quand le bogue sera
2268 corrigé, tous les créateurs de rapport de bogue en seront
2269 informés (notez, cependant, que les courriels envoyés à l'un des
2270 créateurs de rapport de bogue ne seront pas automatiquement envoyés
2271 aux autres créateurs de rapport de bogue). Pour plus de
2272 détails sur les technicités de la commande de fusion et sa
2273 voisine, la commande <tt>unmerge</tt> (séparation), veuillez
2274 consulter la documentation du serveur de contrôle du BTS.
2277 Le rapporteur de bogue peut avoir oublié de fournir certaines
2278 informations. Dans ce cas, vous devez lui demander les informations
2279 nécessaires. Vous pouvez utiliser la marque <tt>moreinfo</tt> (plus
2280 d'information) sur le bogue. De plus, si vous ne pouvez pas reproduire le
2281 bogue, vous pouvez le marquer comme <tt>unreproducible</tt> (non
2282 reproductible). Une personne qui arriverait à reproduire le bogue est
2283 alors invitée à fournir plus d'informations sur la façon de le
2284 reproduire. Après quelques mois, si cette information n'a été envoyée
2285 par personne, le bogue peut être fermé.
2288 Si le bogue est lié à l'empaquetage, vous devez simplement le
2289 corriger. Si vous ne pouvez pas le corriger vous-même, marquez alors le
2290 bogue avec <tt>help</tt> (aide). Vous pouvez également demander de
2291 l'aide sur &email-debian-devel; ou &email-debian-qa;. S'il s'agit d'un
2292 problème amont, vous devez faire suivre le rapport à l'auteur amont.
2293 Faire suivre un bogue n'est pas suffisant, vous devez vérifier à chaque
2294 version si le bogue a été corrigé ou non. S'il a été corrigé, vous le
2295 fermez simplement, sinon vous devez le rappeler à l'auteur. Si vous avez
2296 les compétences nécessaires, vous pouvez préparer un correctif pour
2297 corriger le bogue et l'envoyer en même temps à l'auteur. Assurez-vous
2298 d'envoyer le correctif au BTS et marquez le bogue avec <tt>patch</tt>
2302 Si vous avez corrigé un bogue sur votre copie locale ou si un correctif
2303 a été inclus dans le référentiel CVS, vous pouvez marquer le bogue avec
2304 <tt>pending</tt> (en attente) pour informer que le bogue est corrigé et
2305 qu'il sera fermé lors du prochain envoi (ajoutez le <tt>closes:</tt>
2306 dans le <file>changelog</file>). C'est particulièrement utile si
2307 plusieurs développeurs travaillent sur le même paquet.
2310 Une fois que le paquet corrigé est disponible dans la distribution
2311 <em>unstable</em>, vous pouvez fermer le bogue. Ceci peut être fait
2312 automatiquement, pour cela, reportez-vous à <ref id="upload-bugfix">.
2316 <sect1 id="upload-bugfix">Quand les rapports de bogue sont-ils fermés par
2317 une mise à jour ?
2319 Au fur et à mesure que les bogues et problèmes sont corrigés dans vos paquets,
2320 il est de votre responsabilité de fermer le rapport de bogue associé.
2321 Cependant, vous ne devez pas le fermer avant que le paquet n'ait été accepté
2322 dans l'archive Debian. C'est pourquoi, vous pouvez et vous devez clore le
2323 rapport dans le système de suivi des bogues une fois que vous avez reçu l'avis
2324 indiquant que votre nouveau paquet a été installé dans l'archive.
2326 Cependant, il est possible d'éviter d'avoir à fermer manuellement les bogues
2327 après l'envoi — indiquez simplement les bogues corrigés dans le fichier
2328 <file>changelog</file> en suivant une syntaxe précise. Par exemple :
2331 acme-cannon (3.1415) unstable; urgency=low
2333 * Frobbed with options (closes: Bug#98339)
2334 * Added safety to prevent operator dismemberment, closes: bug#98765,
2336 * Added man page. Closes: #98725.
2339 Techniquement parlant, l'expression rationnelle Perl suivante décrit comment les
2340 lignes de <em>changelogs</em> de fermeture de bogues sont identifiées :
2343 /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
2346 Nous préférons la syntaxe <tt>closes: #<var>XXX</var></tt>, car c'est l'entrée
2347 la plus concise et la plus facile à intégrer dans le texte du fichier
2348 <file>changelog</file>.
2350 Si un envoi est identifié comme une <qref id="nmu">mise à jour indépendante
2351 (NMU)</qref> (et c'est le cas si le nom de
2352 la personne qui a réalisé ce changement n'est pas exactement le même que celui
2353 de l'un des responsables ou expéditeurs, sauf si le responsable est le groupe
2354 d'Assurance Qualité), le bogue est alors marqué <tt>fixed</tt> (corrigé) au lieu
2355 d'être fermé. Si un envoi de responsable a pour cible <em>experimental</em>,
2356 l'étiquette <tt>fixed-in-experimental</tt> est alors ajoutée au bogue ;
2357 pour les mises à jour indépendantes, l'étiquette <tt>fixed</tt> (corrigé) est
2358 utilisée (il est attendu que la règle spéciale pour <em>experimental</em> sera
2359 modifiée dès que le suivi des versions sera ajouté au système de suivi des
2362 Si vous entrez un numéro de bogue incorrect ou si vous oubliez un bogue dans les
2363 entrées du fichier <file>changelog</file>, n'hésitez pas à annuler tout dommage
2364 que l'erreur a entraîné. Pour rouvrir un bogue fermé par erreur, envoyez une
2365 commande <tt>reopen <var>XXX</var></tt> à l'adresse de contrôle du système de
2366 suivi des bogues, &email-bts-control;. Pour fermer tous les bogues restants qui
2367 ont été corrigés par votre envoi, envoyez le fichier <file>.changes</file> à
2368 <email>XXX-done@&bugs-host;</email> où <var>XXX</var> est le numéro du
2371 Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en utilisant le
2372 <file>changelog</file> tel que décrit ci-dessus. Si vous désirez simplement
2373 fermer les bogues qui n'ont rien à voir avec l'un de vos envois, faites-le
2374 simplement en envoyant une explication à
2375 <email>XXX-done@&bugs-host;</email>. Vous <strong>ne devez pas</strong> pas
2376 fermer des bogues dans une entrée de changelog d'une version si les
2377 changements dans cette version n'ont rien à voir avec le bogue.
2379 Pour une information plus générale sur ce qu'il faut mettre dans les entrées de
2380 changelog, veuillez vous reporter aux <ref id="bpp-debian-changelog">.
2382 <sect1 id="bug-security">Gérer les bogues de sécurité
2384 À cause de leur nature sensible, les bogues liés à la sécurité doivent être
2385 soigneusement traités. L'équipe de sécurité de Debian est là pour coordonner
2386 cette activité, pour faire le suivi des problèmes de sécurité en cours, pour
2387 aider les responsables ayant des problèmes de sécurité ou pour les corriger
2388 elle-même, pour envoyer les annonces de sécurité et pour maintenir le site
2389 security.debian.org.
2391 Si vous prenez connaissance d'un bogue lié à un problème de sécurité sur un
2392 paquet Debian, que vous soyez ou non le responsable, regroupez les
2393 informations pertinentes sur le problème et contactez rapidement l'équipe de
2394 sécurité à &email-security-team; dès que possible. <strong>N'ENVOYEZ
2395 PAS</strong> de paquet pour <em>stable</em> ; l'équipe de sécurité le
2398 Les informations utiles incluent, par exemple :
2402 les versions du paquet connues pour être affectées par le bogue. Vérifiez
2403 chaque version présente dans les distributions maintenues par Debian ainsi
2404 que dans <em>testing</em> et dans <em>unstable</em>,
2407 la nature d'une solution si elle est disponible (les correctifs sont
2408 particulièrement utiles),
2411 tout paquet corrigé que vous avez vous-même préparé (envoyez seulement les
2412 fichiers <file>.diff.gz</file> et <file>.dsc</file> et lisez d'abord <ref
2413 id="bug-security-building">),
2416 toute assistance que vous pouvez fournir pour aider les tests (exploits,
2417 tests de régression, etc.),
2420 toute information nécessaire pour l'annonce de sécurité (voir <ref
2421 id="bug-security-advisories">).
2425 <sect2 id="bug-security-confidentiality">Confidentialité
2427 À la différence de la plupart des autres activités au sein de Debian, les
2428 informations sur les problèmes de sécurité doivent parfois être gardées en
2429 privé pour un certain temps. Ceci permet les distributeurs de logiciels de
2430 coordonner leur dévoilement afin de minimiser l'exposition de leurs
2431 utilisateurs. Cette décision dépend de la nature du problème
2432 et de l'existence d'une solution correspondante et également s'il s'agit d'un
2433 fait connu publiquement.
2435 Il existe plusieurs façons pour un développeur de prendre connaissance d'un
2436 problème de sécurité :
2440 il le remarque sur un forum public (liste de diffusion, site web, etc.),
2443 quelqu'un remplit un rapport de bogue,
2446 quelqu'un l'informe par courrier privé.
2450 Dans les deux premiers cas, l'information est publique et il est important
2451 d'avoir une solution le plus vite possible. Dans le dernier cas, cependant, ce
2452 n'est peut-être pas une information publique. Dans ce cas, il existe quelques
2453 options possibles pour traiter le problème :
2457 si l'exposition de sécurité est mineure, il n'y a parfois pas besoin de
2458 garder le secret sur le problème et une correction devrait être effectuée
2462 si le problème est grave, il est préférable de partager cette
2463 information avec d'autres vendeurs et de coordonner une diffusion.
2464 L'équipe de sécurité garde des contacts avec les différentes organisations
2465 et individus et peut prendre soin des actions à mener.
2470 Dans tous les cas, si la personne qui indique le problème demande à ce que
2471 l'information ne soit pas diffusée, cela devrait être respecté avec l'évidente exception
2472 d'informer l'équipe de sécurité pour qu'une correction puisse être effectuée
2473 pour la version stable de Debian. Quand vous envoyez des informations
2474 confidentielles à l'équipe de sécurité, assurez-vous de bien mentionner ce fait.
2476 <p>Veuillez noter que si le secret est nécessaire, vous ne pourrez pas envoyer
2477 un correctif vers <em>unstable</em> (ou ailleurs) puisque les informations de
2478 changelog et de diff sont publiques pour <em>unstable</em>.
2480 <p>Il existe deux raisons pour diffuser l'information même si le secret est
2481 demandé : le problème est connu depuis un certain temps ou le problème ou
2482 son exploitation est devenu public.
2484 <sect2 id="bug-security-advisories">Annonces de sécurité
2486 Les annonces de sécurité ne sont émises que pour la distribution actuelle
2487 diffusée <em>stable</em>, <em>PAS</em> pour <em>testing</em> ou <em>unstable</em>.
2488 Quand elle est diffusée, l'annonce est envoyée à la liste de diffusion
2489 &email-debian-security-announce; et elle est postée sur <url
2490 id="&url-debian-security-advisories;" name="la page de sécurité">. Les
2491 annonces de sécurité sont écrites et postées par les membres de l'équipe de sécurité.
2492 Cependant, ils ne verront aucun inconvénient à ce qu'un responsable leur
2493 apporte des informations ou écrive une partie du texte. Les informations qui
2494 devraient être présentes dans une annonce incluent :
2497 une description du problème et de sa portée, y compris :
2500 le type du problème (usurpation de privilège, déni de service,
2504 quels sont les privilèges obtenus et par quels utilisateurs (si c'est le
2508 comment il peut être exploité,
2511 si le problème peut être exploité à distance ou localement,
2514 comment le problème a été corrigé,
2517 Ces informations permettent aux utilisateurs d'estimer la menace pesant
2522 les numéros de version des paquets affectés,
2525 les numéros de version des paquets corrigés,
2528 une information sur la façon de récupérer les paquets mis à jour
2529 (habituellement l'archive de sécurité Debian),
2532 des références à des annonces amont, des identifiants <url
2533 id="http://cve.mitre.org" name="CVE"> et toute autre information utile
2534 pour recouper les références de la vulnérabilité.
2538 <sect2 id="bug-security-building">
2539 <heading>Préparer les paquets pour corriger des problèmes de sécurité
2541 Une façon d'aider l'équipe de sécurité dans ses travaux est de leur fournir des
2542 paquets corrigés convenables pour une annonce de sécurité pour la version
2543 <em>stable</em> de Debian
2545 Quand une mise à jour de la version <em>stable</em> est effectuée, un soin
2546 particulier doit être apporté pour éviter de modifier le comportement du
2547 système ou d'introduire de nouveaux bogues. Pour cela, faites le moins de
2548 changements possibles pour corriger le bogue. Les utilisateurs et les
2549 administrateurs s'attendent à un comportement identique dans une version
2550 lorsque celle-ci est diffusée, donc tout changement qui est fait est
2551 susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour
2552 les bibliothèques : assurez-vous ne de jamais changer l'API ou l'ABI,
2553 quelque minimal que soit le changement.
2555 Cela veut dire que passer à une version amont supérieure n'est pas une bonne
2556 solution. À la place, les changements pertinents devraient être rétroportés
2557 vers la version présente dans la distribution <em>stable</em> de Debian.
2558 Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de
2559 sécurité Debian peut le faire.
2561 Dans certains cas, il n'est pas possible de rétroporter un correctif de
2562 sécurité, par exemple, quand de grandes quantités de code source doivent être
2563 modifiées ou récrites. Si cela se produit, il peut être nécessaire de passer à
2564 une nouvelle version amont. Cependant, ceci n'est fait que dans des situations
2565 extrêmes et vous devez toujours coordonner cela avec l'équipe de sécurité au
2568 Il existe une autre règle de conduite liée à cela : testez toujours vos
2569 changements. Si une exploitation du problème existe, essayez-la et
2570 vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet
2571 corrigé. Testez aussi les autres actions normales car parfois un correctif de
2572 sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas
2575 N'incluez <strong>PAS</strong> de changements dans votre paquet qui ne soient
2576 pas liés directement à la correction de la vulnérabilité. Ceux-ci devraient être
2577 ensuite enlevés et cela perd du temps. S'il y a d'autres bogues dans votre
2578 paquet que vous aimeriez corriger, faites un envoi vers
2579 proposed-updates de la façon habituelle, après l'envoi de l'alerte de sécurité.
2580 Le mécanisme de mise à jour de sécurité n'est pas un moyen d'introduire des
2581 changements dans votre paquet qui seraient sinon rejetés de la distribution
2582 stable, n'essayez donc pas de faire cela, s'il vous plaît.
2584 Examinez et testez autant que possible vos changements. Vérifiez les différences
2585 avec la version précédente de manière répétée (<prgn>interdiff</prgn> du
2586 paquet <package>patchutils</package> et <prgn>debdiff</prgn> du paquet
2587 <package>devscripts</package> sont des outils utiles pour cela, voir <ref
2590 Assurez-vous de conserver les points suivants à l'esprit :
2594 Ciblez la bonne distribution dans votre
2595 fichier <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de
2596 <tt>stable-security</tt> et pour <em>testing</em>, c'est
2597 <tt>testing-security</tt> et pour l'ancienne distribution stable, c'est
2598 <tt>oldstable-security</tt>. Ne ciblez ni
2599 <var>distribution</var>-proposed-updates, ni <tt>stable</tt> !
2601 <item>L'envoi devra avoir « urgency=high ».
2604 Fournissez des entrées de changelog descriptives et complètes. D'autres
2605 personnes se baseront dessus pour déterminer si un bogue particulier a été
2606 corrigé. Incluez toujours une référence externe, de préférence un
2607 identifiant CVE, pour qu'elle puisse être recoupée. Incluez la même
2608 information dans le changelog pour <em>unstable</em> pour qu'il soit clair
2609 que le même bogue a été corrigé car cela est très utile pour vérifier que
2610 le bogue a été corrigé pour la prochaine version stable. Si aucun
2611 identifiant CVE n'a encore été assigné, l'équipe de sécurité en demandera
2612 un pour qu'il puisse être inclus dans le paquet et dans le changelog.
2615 Assurez-vous que le numéro de version est correct. Il doit être plus élevé
2616 que celui du paquet actuel, mais moins que ceux des paquets des versions
2617 des distributions suivantes. En cas de doute, testez-le avec <tt>dpkg
2618 --compare-versions</tt>. Soyez attentif à ne pas ré-utiliser un numéro de
2619 version que vous auriez déjà utilisé pour un précédent envoi.
2620 Pour <em>testing</em>, il doit y avoir un numéro
2621 de version supérieur dans <em>unstable</em>. S'il n'y en a pas encore (par
2622 exemple, si <em>testing</em> et <em>unstable</em> ont la même version),
2623 vous devez envoyer une nouvelle version vers <em>unstable</em> en premier.
2626 Ne faites pas d'envoi de source seul si votre paquet possède un ou
2627 plusieurs paquets binary-all (n'utilisez pas l'option <tt>-S</tt> de
2628 <prgn>dpkg-buildpackage</prgn>). L'infrastructure <prgn>buildd</prgn> ne
2629 construira pas ceux-ci. Ce point s'applique aux envois de paquets normaux
2633 Sauf si la source amont a été envoyée auparavant à security.debian.org (par une
2634 précédente mise à jour de sécurité), construisez le paquet avec la source
2635 amont complète (<tt>dpkg-buildpackage -sa</tt>). S'il y a déjà eu un
2636 précédent envoi à security.debian.org, vous pouvez faire un envoi sans le
2637 paquet source (<tt>dpkg-buildpackage -sd</tt>).
2640 Assurez-vous d'utiliser exactement le même nom <file>*.orig.tar.gz</file>
2641 que celui utilisé dans l'archive normale, sinon il ne sera pas possible de
2642 déplacer plus tard le correctif de sécurité dans l'archive principale.
2645 Compilez le paquet sur un système
2646 propre, dont tous les paquets appartiennent à la distribution pour laquelle vous
2647 construisez le paquet. Si vous n'avez pas un tel système, vous pouvez
2648 utiliser l'une des machines de debian.org (voir <ref
2649 id="server-machines">) ou mettez en place un chroot (voir <ref id=
2650 "pbuilder"> et <ref id="debootstrap">).
2654 <sect2 id="bug-security-upload">Mettre à jour le paquet corrigé
2656 Vous <em>NE</em> devez <em>PAS</em> envoyer un paquet dans la file d'attente des envois de sécurité
2657 (oldstable-security, stable-security, etc.)
2658 sans l'accord préalable de l'équipe de sécurité. Si le paquet ne remplit pas
2659 exactement les exigences de l'équipe, il causera beaucoup de problèmes, ainsi
2660 que des délais dans la gestion de l'envoi indésirable.
2662 Vous <em>NE</em> devez <em>PAS</em> envoyer votre correction dans
2663 <em>proposed-updates</em> sans vous coordonner avec l'équipe de sécurité. Les
2664 paquets seront copiés de security.debian.org dans le répertoire
2665 <file>proposed-updates</file> automatiquement. Si un paquet avec le même numéro
2666 de version ou un numéro plus grand est déjà installé dans l'archive, la mise à
2667 jour de sécurité sera rejetée par le système d'archive. Ainsi, la distribution
2668 <em>stable</em> se retrouvera à la place sans la mise à jour de sécurité de ce
2671 Une fois que vous avez créé et testé le nouveau paquet et qu'il a été approuvé
2672 par l'équipe de sécurité, il doit être envoyé pour être installé dans les
2673 archives. Pour les envois de sécurité, l'adresse d'envoi est
2674 <tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt>.
2677 Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera
2678 automatiquement recompilé pour toutes les architectures et stocké pour
2679 vérification par l'équipe de sécurité.
2682 Les envois en attente d'acceptation ou de vérification ne sont accessibles que
2683 par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des
2684 correctifs pour des problèmes de sécurité qui ne peuvent pas encore être
2688 Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur
2689 security.debian.org ainsi que dans le répertoire
2690 <var>distribution</var>-proposed-updates qui convient sur ftp-master ou dans
2693 <sect id="archive-manip">
2694 <heading>Déplacer, effacer, changer le nom, adopter et abandonner des paquets
2696 Certaines manipulations de l'archive ne sont pas possibles avec le processus
2697 de mise à jour automatisé. Elles sont appliquées manuellement par les
2698 développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.
2700 <sect1 id="moving-pkgs">Déplacer des paquets
2702 Il se peut qu'un paquet puisse changer de section. Une nouvelle version d'un paquet
2703 de la section <tt>non-free</tt> pourrait, par exemple, être distribuée sous
2704 licence GNU GPL ; dans ce cas, le paquet doit être déplacé dans la section
2705 <tt>main</tt> ou <tt>contrib</tt><footnote><p>Reportez-vous à la <url
2706 id="&url-debian-policy;" name="charte Debian"> pour savoir dans quelle section
2707 un paquet doit être classé.</footnote>.
2709 Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez les
2710 informations de contrôle du paquet pour le placer dans la section désirée et
2711 téléchargez à nouveau votre paquet dans l'archive. Reportez-vous à la <url
2712 id="&url-debian-policy;" name="charte Debian"> pour en savoir plus. Si votre
2713 nouvelle section est valide, il sera déplacé automatiquement. Si ce n'est pas
2714 le cas, contactez les responsables ftp pour comprendre ce qui s'est passé.
2716 Si vous avez besoin de modifier la sous-section de l'un de vos paquets
2717 (<tt>devel</tt> ou <tt>admin</tt> par exemple), la procédure est légèrement
2718 différente. Modifiez la sous-section dans le fichier de contrôle de votre
2719 paquet et téléchargez-le. Il vous faudra ensuite demander la modification du
2720 fichier <em>override</em> comme décrit dans la section <ref
2721 id="override-file">.
2724 <sect1 id="removing-pkgs">Supprimer des paquets
2726 Si, pour une raison ou une autre, vous avez besoin de supprimer un paquet de
2727 l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile, que
2728 l'on conservait pour des raisons de compatibilité), il vous faudra envoyer un
2729 rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
2730 demander sa suppression. N'oubliez pas de préciser de quelle distribution le
2731 paquet doit être supprimé. Normalement, vous ne devriez avoir à supprimer que
2732 des paquets d'<em>unstable</em> ou de <em>experimental</em>. Les paquets de
2733 <em>testing</em> ne sont pas supprimés directement. Ils sont plutôt enlevés
2734 automatiquement après que le paquet a été supprimé d'<em>unstable</em> et
2735 si aucun paquet de <em>testing</em> n'en dépend.
2737 Vous devez également détailler les raisons justifiant cette demande. Ceci a pour
2738 but d'éviter les suppressions non désirées et de garder une trace de la raison
2739 pour laquelle un paquet a été supprimé. Par exemple, vous pouvez fournir le nom
2740 du paquet qui remplace celui à supprimer.
2742 Vous ne pouvez demander la suppression d'un paquet que si vous en
2743 êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez
2744 obtenir l'accord de son responsable.
2746 Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
2747 autres développeurs sur la liste &email-debian-devel;. Le programme
2748 <prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
2749 utile. La commande <tt>apt-cache showpkg <var>paquet</var> </tt> vous
2750 indiquera, entre autres, les paquets qui dépendent de <var>paquet</var>.
2751 Le retrait de paquets orphelins est discuté sur &email-debian-qa;.
2753 Une fois que le paquet a été supprimé, les bogues du paquet doivent être gérés.
2754 Soit ils sont réattribués à un autre paquet dans le cas où le code actuel a
2755 évolué en un autre paquet (par exemple, <tt>libfoo12</tt> a été supprimé parce
2756 que <tt>libfoo13</tt> le remplace) ou ils sont fermés si le logiciel ne fait
2757 simplement plus partie de Debian.
2759 <sect2>Supprimer des paquets dans <tt>Incoming</tt>
2761 Par le passé, il était possible de supprimer un paquet de <file>Incoming</file>.
2762 Cependant, ce n'est plus possible depuis la mise en place du nouveau système
2763 de file d'attente. Il vous faudra télécharger une nouvelle version de votre
2764 paquet avec un numéro de version plus élevé que celui que vous voulez
2765 remplacer. Les deux versions seront installées dans l'archive mais seule la
2766 plus récente sera accessible dans <em>unstable</em> car la précédente sera
2767 immédiatement remplacée par la nouvelle. Toutefois, si vous testez
2768 correctement vos paquets, le besoin d'en remplacer un ne devrait pas être
2771 <sect1>Remplacer un paquet ou changer son nom
2773 Si vous vous trompez en nommant un paquet, vous devrez intervenir en deux
2774 étapes pour changer son nom. D'abord, modifiez
2775 votre fichier <file>debian/control</file> pour que votre nouveau paquet
2776 remplace et entre en conflit avec l'ancien paquet que vous voulez remplacer
2777 (reportez-vous à la <url id="&url-debian-policy;" name="charte Debian"> pour
2778 les détails). Une fois que votre paquet est installé dans l'archive, faites un
2779 rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
2780 demandez la suppression du paquet mal nommé. N'oubliez pas de réattribuer
2781 correctement les bogues du paquet en même temps.
2783 D'autres fois, vous pouvez commettre une erreur en construisant le paquet et
2784 vous désirez le remplacer. La seule façon de faire est d'incrémenter le numéro de
2785 version et d'envoyer une nouvelle version. L'ancienne version expirera de la
2786 façon habituelle. Notez que ceci s'applique à chaque partie de votre paquet, y
2787 compris les sources : si vous désirez remplacer l'archive source amont de
2788 votre paquet, vous devez l'envoyer avec un numéro de version différent. Une
2789 possibilité simple est de remplacer <file>foo_1.00.orig.tar.gz</file> par
2790 <file>foo_1.00+0.orig.tar.gz</file>. Cette restriction donne à chaque fichier
2791 du site ftp un nom unique, ce qui aide à garantir la consistance dans le réseau
2794 <sect1 id="orphaning">Abandonner un paquet
2796 Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres et
2797 faire le nécessaire pour qu'il soit marqué <em>abandonné</em> (i.e.
2798 <em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
2799 Group &orphan-address;</tt> dans le champ <tt>maintainer</tt> du paquet et
2800 faire un rapport de bogue sur le pseudo-paquet <package>wnpp</package>. Le
2801 titre de votre rapport de bogue devrait être
2802 « <tt>O<footnote><p><em>Orphaned</em> : abandonné.</footnote>:
2803 <var>paquet</var> — <var>courte description</var></tt> » pour
2804 indiquer que le paquet est abandonné. La gravité du bogue sera
2805 <em>normale</em> ; si le paquet a une priorité standard ou supérieure,
2806 elle devrait être <em>importante</em>. Si vous le jugez nécessaire, envoyez une copie à
2807 &email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
2808 l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le sujet
2809 du message ne contiendra pas le numéro du bogue.
2811 Si vous avez simplement l'intention de donner le paquet, mais que vous pouvez
2812 conserver sa maintenance pour le moment, vous devriez à la place soumettre un
2813 rapport de bogue sur <package>wnpp</package> et l'intituler <tt>RFA: <var>paquet</var> --
2814 <var>description courte</var></tt>.
2815 <tt>RFA</tt> veut dire <em>Request For Adoption</em> (demande d'adoption).
2817 Vous pouvez trouver plus d'informations sur les <url id="&url-wnpp;" name="pages
2818 web WNPP"><footnote><p><em>Work-needing and prospective
2819 packages</em> : paquets en souffrance et paquets
2820 souhaités.</footnote>.
2822 <sect1 id="adopting">Adopter un paquet
2824 Une liste des paquets en attente de nouveau responsable est disponible à la page
2825 <url id="&url-wnpp;" name="paquets en souffrance et paquets souhaités">. Si
2826 vous voulez prendre en charge un paquet de cette liste, reportez-vous à la page
2827 mentionnée ci-dessus pour connaître la procédure à suivre.
2829 Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
2830 correct — ce serait un détournement de paquet. Vous pouvez prendre
2831 contact avec le responsable actuel et lui demander si vous pouvez prendre en
2832 charge ce paquet. Si vous avez le sentiment qu'un responsable est parti sans
2833 prévenir depuis un moment, veuillez vous reporter à <ref id="mia-qa">).
2835 Généralement, vous ne pouvez pas adopter un paquet sans l'accord du responsable
2836 actuel. Même s'il vous ignore, ce n'est pas une raison pour le faire. Les
2837 plaintes à propos des responsables devraient être portées sur la liste de
2838 diffusion des développeurs. Si la discussion ne se termine pas par une
2839 conclusion positive et que le problème est de nature technique, considérez de
2840 porter le cas à l'attention du comité technique (voir la <url name="page web du
2841 comité technique" id="&url-tech-ctte;"> pour plus d'information).
2843 Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de suivi
2844 des bogues indique que vous êtes le responsable du paquet. Cela se produira
2845 automatiquement une fois que vous aurez installé une nouvelle version du paquet
2846 dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut prendre
2847 quelques heures après le téléchargement. Si vous pensez ne pas avoir de mise à
2848 jour à faire pour un moment, vous pouvez utiliser le <ref
2849 id="pkg-tracking-system"> pour recevoir les rapports de bogue. Cependant,
2850 assurez-vous que cela ne pose aucun problème à l'ancien responsable de
2851 continuer à recevoir les bogues durant ce temps.
2853 <sect id="porting">Le portage
2855 Debian accepte un nombre croissant d'architectures. Même si vous n'êtes pas un
2856 porteur et même si vous n'utilisez qu'une architecture, il est de votre
2857 responsabilité de développeur d'être attentif aux questions de
2858 portabilité. C'est pourquoi il est important que vous lisiez ce chapitre
2859 même si vous n'êtes pas un porteur.
2861 Porter un paquet consiste à faire un paquet binaire pour des architectures
2862 différentes de celle du paquet binaire fait par le responsable du paquet.
2863 C'est une activité remarquable et essentielle. En fait, les porteurs sont
2864 à l'origine de la plupart des compilations de paquets Debian. Pour un
2865 paquet binaire <em>i386</em>, par exemple, il faut compter une
2866 recompilation pour chaque autre architecture, soit un total de
2867 &number-of-arches; recompilations.
2870 <sect1 id="kind-to-porters">Être courtois avec les porteurs
2872 Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un
2873 grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
2874 modification. Malheureusement, c'est rarement le cas. Cette section contient
2875 une liste d'erreurs commises régulièrement par les responsables Debian —
2876 problèmes courants qui bloquent souvent les porteurs et compliquent inutilement
2879 Ici, la première et la plus importante chose est de répondre rapidement aux rapports de bogues et
2880 remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
2881 étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine manière).
2882 Merci pour votre indulgence envers des rapports de bogue succincts ou peu
2883 clairs ; faites de votre mieux pour éliminer le problème.
2885 Les problèmes les plus couramment rencontrés par les porteurs sont causés par
2886 des erreurs de mise en paquet dans le paquet source. Voici un
2887 pense-bête pour les choses auxquelles vous devez être attentif :
2890 Vérifiez que les champs <tt>Build-Depends</tt> et
2891 <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
2892 corrects. Le meilleur moyen de le vérifier est d'utiliser le paquet
2893 <package>debootstrap</package> pour créer un environnement
2894 <em>unstable</em> <em>chrooté</em> (voir <ref id="debootstrap">). Dans
2895 cet environnement <em>chrooté</em>, il faudra installer le paquet
2896 <package>build-essential</package> et tous les paquets mentionnés dans
2897 les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
2898 Ensuite, vous essayerez de fabriquer votre paquet dans cet
2899 environnement. Ces étapes peuvent être automatisées en utilisant le
2900 programme <prgn>pbuilder</prgn> qui est fourni par le paquet de même
2901 nom (voir <ref id="pbuilder">).
2903 Si vous n'arrivez pas à installer un environnement <em>chrooté</em>,
2904 <prgn>dpkg-depcheck</prgn> pourra peut-être vous aider (voir <ref
2905 id="dpkg-depcheck">).
2907 Consultez la <url id="&url-debian-policy;" name="charte Debian"> pour en
2908 savoir plus sur les dépendances de fabrication.
2911 Ne choisissez pas d'autres valeurs que <em>all</em> ou <em>any</em> pour
2912 le champ architecture sans avoir de bonnes raisons pour le faire. Trop
2913 souvent, les développeurs ne respectent pas les instructions de la <url
2914 id="&url-debian-policy;" name="charte Debian">. Choisir la valeur
2915 « i386 » est la plupart du temps incorrect.
2918 Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
2919 <var>paquet</var>.dsc</tt> pour vous assurer que le paquet se
2920 décompresse correctement. En utilisant le résultat de ce test,
2921 construisez votre paquet binaire à l'aide de la commande
2922 <prgn>dpkg-buildpackage</prgn>.
2925 Vérifiez que les fichiers <file>debian/files</file> et
2926 <file>debian/substvars</file> ne sont pas dans votre paquet source. Ils
2927 doivent être effacés par la cible <em>clean</em> de
2928 <file>debian/rules</file>.
2931 Assurez-vous que vous ne vous appuyez pas sur des éléments de
2932 configuration ou des logiciels installés ou modifiés localement. Par
2933 exemple, vous ne devriez jamais appeler des programmes du répertoire
2934 <file>/usr/local/bin</file> ou de répertoires équivalents. Essayez de ne
2935 pas vous appuyer sur des logiciels configurés de manière spéciale.
2936 Essayez de construire votre paquet sur une autre machine, même s'il
2937 s'agit de la même architecture.
2940 Ne vous appuyez pas sur une installation préexistante de votre paquet
2941 (un sous-cas de la remarque précédente).
2944 Si possible, ne vous appuyez pas sur une particularité présente dans un
2945 compilateur précis ou dans une certaine version d'un compilateur. Si
2946 vous ne pouvez pas faire autrement, assurez-vous que les dépendances de
2947 fabrication reflètent bien cette restriction. Dans ce cas, vous cherchez
2948 sûrement les problèmes car quelques architectures pourraient choisir un
2949 compilateur différent.
2952 Vérifiez que votre fichier <file>debian/rules</file> distingue les
2953 cibles <em>binary-arch</em> et <em>binary-indep</em> comme l'exige la
2954 charte Debian. Vérifiez que ces cibles sont indépendantes l'une de
2955 l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer l'une de
2956 ces cibles avant d'invoquer l'autre. Pour vérifier cela, essayez
2957 d'exécuter <tt>dpkg-buildpackage -B</tt>.
2962 <sect1 id="porter-guidelines">Instructions pour les mises à jour des
2965 Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez
2966 de la chance et votre travail est facile. Cette section s'applique dans ce
2967 cas ; elle décrit comment construire et installer correctement votre
2968 paquet binaire dans l'archive Debian. Si vous devez modifier le paquet pour le
2969 rendre compilable sur votre architecture cible vous devez faire une mise à jour
2970 des sources, consultez la section <ref id="nmu-guidelines">.
2972 Pour un envoi de portage, ne faites pas de changement dans les sources. Vous
2973 n'avez pas besoin de modifier les fichiers du paquet source (cela inclut le
2974 fichier <file>debian/changelog</file>).
2976 La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante :
2977 <tt>dpkg-buildpackage -B -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
2978 <var>adresse-porteur</var> par votre adresse électronique. Cette commande
2979 construira les parties du paquet qui dépendent de l'architecture, en utilisant
2980 la cible <em>binary-arch</em> de <file>debian/rules</file>.
2982 Si vous travaillez sur une machine Debian pour vos efforts de portage et que
2983 vous devez signer votre envoi localement pour son acceptation dans l'archive,
2984 vous pouvez exécuter <prgn>debsign</prgn> sur votre fichier
2985 <file>.changes</file> pour qu'il soit signé de manière commode ou utilisez le
2986 mode de signature à distance de <prgn>dpkg-sig</prgn>.
2988 <sect2 id="binary-only-nmu">
2989 Mises à jour indépendantes binaires ou recompilations
2991 Parfois, l'envoi du portage initial pose problème car l'environnement dans lequel
2992 le paquet a été construit n'était pas bon (bibliothèques plus à jour ou
2993 obsolètes, mauvais compilateur, etc.). Il se peut que vous ayez à le recompiler
2994 dans un environnement mis à jour. Cependant, dans ce cas, vous devez changer
2995 le numéro de version pour que les mauvais anciens paquets soient remplacés dans
2996 l'archive Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
2997 s'ils n'ont pas un numéro de version supérieur à celui actuellement
3000 Vous devez vous assurez que votre mise à jour indépendante binaire ne rend pas
3001 le paquet non installable. Cela peut arriver si un paquet source génère des
3002 paquets dépendants et indépendants de l'architecture qui dépendent
3003 les uns des autres <em>via</em> $(Source-Version).
3006 Malgré les modifications nécessaires du changelog, ce type de mise
3007 à jour reste une mise à jour indépendante binaire — il n'est pas
3008 nécessaire de reconsidérer le statut des paquets binaires des autres
3009 architectures pour les marquer périmés ou à recompiler.
3011 Ces recompilations nécessitent des numéros de version « magiques »
3012 pour que le système de maintenance de l'archive comprennent que, bien qu'il y
3013 ait une nouvelle version, il n'y a pas eu de modification des sources. Si vous
3014 ne faites pas cela correctement, les administrateurs de l'archive rejetteront
3015 votre mise à jour (car il n'y aura pas de code source associé).
3017 Cette « magie » associée à une mise à jour par recompilation est déclenchée en
3018 utilisant un troisième nombre dans la partie debian du numéro de version. Si,
3019 par exemple, la dernière version du paquet que vous recompilez était
3020 « 2.9-3 », votre mise à jour portera le numéro
3021 « 2.9-3.0.1 ». Si cette version était « 3.4-2.1 » votre
3022 mise à jour portera le numéro « 3.4-2.1.1 ».
3024 De manière similaire aux envois du porteur initial, la façon correcte d'invoquer
3025 <prgn>dpkg-buildpackage</prgn> est <tt>dpkg-buildpackage -B</tt> pour ne
3026 construire que les parties dépendant de l'architecture du paquet.
3029 <sect2 id="source-nmu-when-porter">
3030 Quand faire une mise à jour indépendante source pour un portage ?
3032 Les porteurs qui font des mises à jour indépendantes sources suivent
3033 généralement les instructions de la section <ref id="nmu"> tout comme les
3034 non-porteurs. Les délais d'attente sont cependant plus courts car les
3035 porteurs doivent manipuler un grand nombre de paquets. À nouveau, la
3036 situation diffère selon la distribution visée. Elle varie également selon que
3037 l'architecture est candidate pour inclusion dans la prochaine version
3038 stable ; les responsables de diffusion décident et annoncent quelles
3039 architectures sont candidates.
3041 Si vous êtes porteur et faites une mise à jour pour <em>unstable</em>, les
3042 instructions précédentes sont applicables à deux différences près. Tout
3043 d'abord, le temps d'attente raisonnable — délai entre le moment où vous
3044 envoyez un rapport au système de suivi des bogues et le moment où vous pouvez
3045 faire une mise à jour indépendante <em>(NMU)</em> — est de sept jours.
3046 Ce délai peut être raccourci si le problème est crucial et met l'effort de
3047 portage en difficulté : c'est à la discrétion de l'équipe de portage.
3048 (Souvenez-vous, il ne s'agit pas d'un règlement, mais de recommandations
3049 communément acceptées). Pour les envois de <em>stable</em> ou
3050 <em>testing</em>, veuillez tout d'abord vous coordonner avec l'équipe de
3051 diffusion appropriée.
3054 Deuxième différence, les porteurs qui font des mises à jour indépendantes
3055 sources doivent choisir une gravité <em>sérieuse</em> (i.e. <em>serious</em>)
3056 ou supérieure quand ils envoient leur rapport au système de suivi des bogues.
3057 Ceci assure qu'un paquet source unique permet de produire un paquet binaire
3058 pour chaque architecture supportée au moment de la sortie de la distribution.
3059 Il est très important d'avoir un paquet source et un paquet binaire pour
3060 toutes les architectures pour être conforme à plusieurs licences.
3062 Les porteurs doivent éviter d'implémenter des contournements pour des bogues de
3063 l'environnement de compilation, du noyau ou de la libc. Quelques fois, ces
3064 contournements sont inévitables. Si vous devez faire quelque chose de ce
3065 genre, marquez proprement vos modifications avec des <tt>#ifdef</tt> et
3066 documentez votre contournement pour que l'on sache le retirer une fois que le
3067 problème aura disparu.
3069 Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de leur
3070 travail pendant le délai d'attente. Ainsi, d'autres personnes peuvent
3071 bénéficier du travail du porteur même pendant ce délai. Bien sûr, ces
3072 adresses n'ont rien d'officiel, alors soyez sur vos gardes si vous les
3076 <sect1 id="porter-automation">
3077 <heading>Infrastructure de portage et automatisation</heading>
3079 Il existe une infrastructure et plusieurs outils pour faciliter l'automatisation
3080 du portage des paquets. Cette section contient un bref aperçu de cette
3081 automatisation et du portage de ces outils ; veuillez vous reporter à la
3082 documentation des paquets ou les références pour une information complète.</p>
3085 <heading>Listes de diffusion et pages web</heading>
3087 Les pages web contenant l'état de chaque portage peuvent être trouvées à <url
3088 id="&url-debian-ports;">.
3090 Chaque portage de Debian possède sa propre liste de diffusion. La liste des
3091 listes de diffusion de portage peut être trouvée à <url
3092 id="&url-debian-port-lists;">. Ces listes sont utilisées pour coordonner les
3093 porteurs et pour mettre en relation les utilisateurs d'un portage donné avec les
3098 <heading>Outils pour les porteurs</heading>
3100 Les descriptions de plusieurs outils de portage peuvent être trouvées dans les
3101 <ref id="tools-porting">.</p>
3105 <heading><package>buildd</package></heading>
3107 Le système <package>buildd</package> est un système distribué pour la
3108 compilation d'une distribution. Il est habituellement utilisé en conjonction
3109 avec des automates de compilation ; ce sont des machines
3110 « esclaves » qui récupèrent des paquets sources et tentent de les
3111 compiler. Il est aussi possible d'interagir par courrier électronique avec ce
3112 système. Cette interface est utilisée par les porteurs pour récupérer un
3113 paquet source (en général, un paquet qui ne peut être compilé
3114 automatiquement) et travailler dessus.
3116 <package>buildd</package> n'est pas disponible sous forme de paquet ;
3117 pourtant, la plupart des équipes de porteurs l'utilisent aujourd'hui ou ont
3118 prévu de l'utiliser bientôt. L'outil de construction automatisé réel est dans
3119 le paquet <package>sbuild</package>, voir la description dans <ref
3120 id="sbuild">. Le système <package>buildd</package> regroupe également un
3121 ensemble de composants très utiles, continuellement utilisés, mais non encore
3122 mis en paquet, tels que <prgn>andrea</prgn> et <prgn>wanna-build</prgn>.
3124 Une partie des informations produites par <package>buildd</package>
3125 — utiles pour les porteurs — est disponible sur la
3126 toile à l'adresse <url id="&url-buildd;">. Ces informations
3127 incluent les résultats produits toutes les nuits par
3128 <prgn>andrea</prgn> (dépendances des sources) et
3129 <prgn>quinn-diff</prgn> (paquets à recompiler).
3131 Nous sommes très fiers de ce système car il a de nombreux usages potentiels. Des
3132 groupes de développeurs indépendants peuvent utiliser ce système pour créer
3133 différentes saveurs de Debian — qui peuvent être ou ne pas être
3134 intéressantes pour tous (par exemple, une version de Debian compilée avec des
3135 vérifications relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi
3136 de recompiler rapidement toute une distribution.
3138 Les administrateurs des buildds pour chaque architecture peuvent être
3139 contactés à l'adresse électronique $arch@buildd.debian.org.
3141 <sect1 id="packages-arch-specific">Quand votre paquet <em>n'est pas</em>
3144 Certains paquets ont encore des problèmes pour être construits et/ou pour
3145 fonctionner sur certaines des architectures prises en charge par Debian et ne
3146 peuvent pas du tout être portés, ou pas dans un laps de temps raisonnable. Un
3147 exemple est un paquet qui est spécifique SGVA (i386 seulement) ou qui utilise
3148 des fonctionnalités spécifiques au matériel qui ne sont pas gérées sur toutes
3151 Pour éviter que des paquets cassés soient envoyés dans l'archive et qu'ils fassent
3152 perdre du temps des buildd, vous devez faire plusieurs choses :
3157 Tout d'abord, assurez-vous que votre paquet <em>échoue</em> à la compilation
3158 sur les architectures qu'il ne gère pas. Il y a plusieurs moyens de faire
3159 cela. Le moyen préféré est d'avoir une petite suite de tests pendant la
3160 construction qui testera la fonctionnalité et qui échouera si cela ne
3161 fonctionne pas. C'est de toute façon une bonne idée et empêchera des
3162 (certains) envois cassés pour toutes les architectures, et cela permettra
3163 également au paquet d'être construit dès que la fonctionnalité nécessaire est
3166 De plus, si vous croyez que la liste des architectures gérées est plutôt
3167 constante, vous devriez changer « any » en une liste des
3168 architectures gérées dans le fichier <file>debian/control</file>. Ainsi, la
3169 construction échouera également et l'indiquera à un lecture humain sans
3173 Pour empêcher les compilateurs automatiques de tenter sans raison de
3174 construire votre paquet, il peut être inclus dans
3175 <file>packages-arch-specific</file>, une liste utilisée par le script
3176 <prgn>wanna-build</prgn>. La version actuelle est disponible à
3178 id="http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup"> ;
3179 veuillez consulter le début du fichier pour savoir qui contacter pour le
3183 Veuillez noter qu'il est insuffisant de simplement ajouter votre paquet à
3184 Packages-arch-specific sans le faire également échouer lors de compilation sur
3185 les architectures non gérées : un porteur ou toute autre personne
3186 essayant de construire votre paquet peut accidentellement l'envoyer sans
3187 remarquer qu'il ne fonctionne pas. Si dans le passé certains paquets binaires
3188 ont été envoyés pour des architectures non gérées, demandez leur suppression
3189 en remplissant un bogue sur <package>ftp.debian.org</package>.
3191 <sect id="nmu">Mise à jour indépendante
3193 Dans certaines circonstances, il est nécessaire qu'une personne autre que le
3194 responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de
3195 mise à jour est désigné en anglais par l'expression <em>non-maintainer
3196 upload (NMU)</em>. Dans le présent document, nous traduisons librement
3197 cette expression par « mise à jour indépendante ».
3199 Cette section ne traite que des mises à jour indépendantes de source, c.-à-d.,
3200 les mises à jour qui envoient une nouvelle version d'un paquet. Pour les
3201 mises à jour indépendantes par des porteurs ou des membres de la QA,
3202 veuillez consulter <ref id="binary-only-nmu">. Si un buildd construit et
3203 envoie un paquet, cela est également à strictement parler une NMU binaire.
3204 Veuillez consulter <ref id="buildd"> pour plus d'informations.
3206 La raison principale pour laquelle une mise à jour indépendante est réalisée est
3207 quand un développeur a besoin de corriger des paquets d'un autre
3208 développeur pour résoudre des problèmes sérieux ou des bogues paralysants
3209 ou quand le responsable d'un paquet ne peut pas
3210 fournir une correction dans un délai raisonnable.
3212 Tout d'abord, il est capital que ces mises à jour indépendantes soient aussi peu
3213 intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
3214 modules ou des fichiers, ne déplacez pas les répertoires ; plus
3215 généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi
3216 petit que possible. Si certaines choses froissent votre sens de l'esthétique,
3217 parlez-en au responsable du paquet, au responsable amont ou soumettez un
3218 rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
3219 pas</em> être effectués lors d'une mise à jour indépendante.
3222 Et souvenez-vous du Serment d'Hippocrate « Par dessus tout, ne pas
3223 faire de mal ». Il est préférable qu'un paquet ait un bogue ouvert grave
3224 plutôt qu'un correctif non fonctionnel soit appliqué et que le bogue devienne
3225 caché, mais toujours non résolu.
3227 <sect1 id="nmu-guidelines">Comment faire une mise à jour indépendante ?
3229 Les mises à jour indépendantes qui corrigent des bogues de gravité importante,
3230 sérieuse et plus élevée sont encouragées et acceptées. Vous devriez vous
3231 efforcer de contacter le responsable actuel du paquet : il est peut-être
3232 sur le point d'envoyer un correctif pour le problème ou il a peut-être une
3235 Les mises à jour indépendantes doivent être réalisées pour assister un
3236 responsable de paquet à résoudre des bogues. Les responsables devraient être
3237 reconnaissants pour cette aide et les personnes faisant la mise à jour
3238 indépendante devraient respecter les décisions du responsable et tenter
3239 d'aider personnellement le responsable dans son travail.
3241 Une mise à jour indépendante devrait suivre toutes les conventions décrites dans
3242 cette section. Pour un envoi vers <em>testing</em> ou <em>unstable</em>, l'ordre
3243 suivant des étapes est recommandé :
3247 <item>Vérifiez que les bogues du paquet qui devraient être corrigés par la
3248 mise à jour indépendante sont bien référencés dans le système de suivi des
3249 bogues. S'ils n'y sont pas, faites des rapports de bogue
3251 <item>Attendez la réponse du responsable quelques jours. Si vous n'obtenez
3252 aucune réponse, vous pouvez l'aider en lui envoyant le correctif qui
3253 corrige le bogue. N'oubliez pas de marquer le bogue avec le mot-clé
3254 « patch ».
3255 <item>Patientez quelques jours. Si vous n'avez toujours aucune réponse du
3256 responsable, envoyez-lui un courrier annonçant votre intention
3257 d'effectuer une mise à jour indépendante du paquet. Préparez la NMU comme
3258 décrit dans cette section et testez-la soigneusement sur votre
3259 machine (cf. <ref id="sanitycheck">). Re-vérifiez que votre correctif
3260 n'a aucun effet de bord inattendu. Assurez-vous que votre correctif est
3261 aussi minimaliste et non intrusif que possible.
3262 <item>Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file> (cf.
3263 <ref id="delayed-incoming">), envoyez le correctif final au responsable
3264 par le BTS et expliquez-lui qu'il a 7 jours pour réagir s'il veut annuler
3266 <item>Suivez ce qui se passe, vous êtes responsable pour tout bogue que vous
3267 auriez introduit avec votre NMU. Vous devriez probablement utiliser le
3268 <ref id="pkg-tracking-system"> (PTS) pour vous tenir informé de l'état du
3269 paquet après votre NMU.
3272 Parfois, le responsable de version ou un groupe organisé de
3273 développeurs peut annoncer une certaine période de temps au cours de laquelle
3274 les règles de mise à jour indépendante seront plus souples. Ceci implique
3275 habituellement une période plus courte d'attente avant d'envoyer des
3276 correctifs et une période de délai plus courte. Il est important de noter que,
3277 même au cours de ces « chasses aux bogues », la personne
3278 désirant faire la mise à jour indépendante doit remplir des bogues et
3279 contacter en premier le développeur, et ensuite seulement passer à
3282 Veuillez vous reporter à <ref id="qa-bsp"> pour des détails.
3284 Pour la distribution <em>testing</em>, les règles peuvent être changées par les
3285 responsables de diffusion. Veuillez porter une attention spéciale au fait que le
3286 moyen habituel pour un paquet d'entrer dans <em>testing</em> est de passer par
3289 Pour la distribution <em>stable</em>, veuillez y apporter une attention
3290 supplémentaire. Bien sûr, les responsables de version peuvent également modifier
3291 les règles ici. Veuillez vérifier avant l'envoi que tous vos changements sont
3292 acceptables pour inclusion dans la prochaine version stable par le responsable
3295 Quand un bogue de sécurité est détecté, l'équipe de sécurité peut effectuer une
3296 mise à jour indépendante en utilisant ses propres règles. Veuillez vous référer
3297 à <ref id="bug-security"> pour plus d'informations.
3299 Pour les différences pour les mises à jour indépendantes par les porteurs,
3300 veuillez voir <ref id="source-nmu-when-porter">.
3302 Bien sûr, il est toujours possible de s'accorder avec un responsable pour des
3303 règles spéciales (comme quand le responsable demande « merci d'envoyer le
3304 correctif directement pour moi et pas de diff nécessaire »).
3306 <sect1 id="nmu-version">Numéro de version pour les mises à jour
3309 Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
3310 changer, même pour la plus triviale des modifications. Notre système de
3311 gestion de paquets s'appuie sur ces numéros de version.
3313 Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
3314 un numéro de version mineur à la partie <var>révision-debian</var> du numéro
3315 de version (la partie qui suit le dernier trait d'union). Ce numéro
3316 supplémentaire débutera à « 1 ». Prenons pour exemple le paquet
3317 « foo » qui porte le numéro de version 1.1-3. Dans l'archive, le
3318 fichier de contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
3319 version amont est « 1.1 » et la révision Debian est
3320 « 3 ». La mise à jour indépendante suivante ajouterait le numéro de
3321 version mineur « .1 » au numéro de révision Debian ; le nouveau
3322 fichier de contrôle du paquet source serait alors
3323 <file>foo_1.1-3.1.dsc</file>.
3325 Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro de
3326 version au responsable officiel du paquet, ce qui pourrait perturber son
3327 travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas
3328 été livré par le responsable officiel.
3330 S'il n'y a pas de partie <var>révision-debian</var> dans le numéro de version du
3331 paquet, il faut en créer une en démarrant à « 0.1 ». S'il est
3332 absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
3333 fasse une livraison basée sur une nouvelle version amont, cette personne doit
3334 choisir « 0.1 » comme numéro de révision Debian. Le mainteneur du
3335 paquet doit, lui, démarrer sa numérotation à « 1 ».
3337 Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>, vous devrez
3338 parfois créer une branche (« fork ») dans l'arbre de numéro des version. Pour cela, vous
3339 pouvez utiliser des numéros de version comme 1.1-3sarge0.1.
3342 <sect1 id="nmu-changelog">
3343 <heading>Les mises à jour indépendantes sources doivent être
3344 mentionnées dans le fichier changelog</heading>
3346 Une personne qui fait une mise à jour indépendante source doit ajouter une
3347 entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
3348 et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
3349 comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
3352 Par convention, dans le cas d'une mise à jour indépendante source
3353 <em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne :
3356 * Non-maintainer upload
3360 <sect1 id="nmu-patch">Mise à jour indépendante source et système de
3363 Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
3364 modifications que possible et doit toujours envoyer ses modifications au
3365 système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).
3367 Et si vous recompilez simplement le paquet ? Si vous avez simplement besoin
3368 de recompiler le paquet pour une seule architecture, vous pouvez faire une
3369 NMU binaire seulement comme décrit dans <ref id="binary-only-nmu"> qui ne
3370 nécessite pas qu'un correctif soit envoyé. Si vous désirez que le paquet soit
3371 recompilé pour toutes les architectures, vous devez alors faire une NMU
3372 source et vous devrez envoyer un correctif.
3374 Si la mise à jour indépendante source (<em>source NMU</em>) corrige des bogues,
3375 ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système de
3376 suivi des bogues plutôt que clos. Par convention, seul le responsable du
3377 paquet et la personne qui a ouvert le rapport de bogue ferment les
3378 rapports. Heureusement, le système d'archivage Debian reconnaît les mises à
3379 jours indépendantes et positionne correctement le statut des bogues à
3380 <em>fixed</em> si la personne qui fait la mise à jour a listé tous les bogues
3381 dans le fichier changelog en utilisant la syntaxe <tt>Closes:
3382 bug#<var>nnnnn</var></tt> (voir <ref id="upload-bugfix"> pour en savoir plus
3383 sur la fermeture de bogue par le fichier <file>changelog</file>). Ce passage
3384 au statut <em>fixed</em> assure que chacun sait que le bogue est corrigé par
3385 une mise à jour indépendante tout en laissant le rapport de bogue ouvert
3386 jusqu'à ce que le responsable du paquet incorpore les modifications de cette
3387 mise à jour dans la version officielle du paquet.
3389 Après avoir fait une mise à jour indépendante, il vous faudra aussi envoyer
3390 cette information aux bogues existants que vous avez corrigés par votre NMU
3391 en incluant le diff unifié. Sinon, vous pouvez créer un nouveau rapport de
3392 bogue et inclure un correctif comprenant toutes les modifications que vous
3393 avez réalisées. Le responsable officiel
3394 pourra choisir d'appliquer le correctif, il pourra aussi employer une autre
3395 méthode pour régler le problème. Certains bogues sont corrigés dans la
3396 version amont, ce qui est une bonne raison pour annuler les modifications
3397 d'une mise à jour indépendante. Si le responsable choisit de mettre à jour le
3398 paquet plutôt que d'utiliser les correctifs de la mise à jour indépendante,
3399 il devra s'assurer que cette nouvelle version corrige effectivement chacun
3400 des bogues corrigés dans la mise à jour indépendante.
3402 De plus, le responsable officiel devrait <em>toujours</em> conserver les entrées
3403 documentant une mise à jour indépendante dans le fichier
3404 <file>changelog</file>.
3407 <sect1 id="nmu-build">Fabriquer une mise à jour indépendante source
3409 Les paquets faisant l'objet d'une mise à jour indépendante source sont
3410 construits comme les autres. Sélectionnez une distribution en utilisant les
3411 règles décrites dans la section <ref id="distribution"> en suivant toutes les
3412 prescriptions de la section <ref id="upload">.
3414 Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt> dans
3415 le fichier <file>debian/control</file>. Votre nom, mentionné dans l'entrée du
3416 fichier <file>debian/changelog</file> concernant la mise à jour, sera utilisé
3417 pour signer le fichier <file>.changes</file>.
3419 <sect1 id="ack-nmu">Valider une mise à jour indépendante
3421 Si l'un de vos paquets a subi une mise à jour indépendante, vous devez récupérer
3422 les changements dans votre copie des sources. Ceci est aisé, vous avez
3423 simplement à appliquer le correctif qui vous a été envoyé. Une fois ceci fait,
3424 vous devez fermer les bogues qui ont été marqués comme fixés par la mise à
3425 jour. Le moyen le plus simple est d'utiliser l'option <tt>-v</tt> de
3426 <prgn>dpkg-buildpackage</prgn> car cela vous permet d'inclure tous les
3427 changements depuis votre dernier envoi de responsable. Sinon, vous pouvez soit
3428 les fermer manuellement en envoyant les courriers
3429 nécessaires au BTS soit ajouter les <tt>closes: #nnnn</tt> nécessaires dans
3430 l'entrée du changelog de votre prochain envoi.
3432 Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une NMU n'est
3433 pas une attaque personnelle contre le responsable. C'est une preuve que le
3434 paquet est important pour quelqu'un et qu'il est désireux de vous aider dans
3435 votre travail, vous devriez donc lui être reconnaissant. Vous pouvez également
3436 lui demander s'il serait intéressé pour vous aider sur une base plus régulière
3437 comme co-responsable ou responsable de secours (cf. <ref
3438 id="collaborative-maint">).
3440 <sect1 id="nmu-vs-qa">Mise à jour indépendante ou envoi de QA ?
3442 Sauf si vous savez que le responsable est toujours actif, il est sage de
3443 vérifier le paquet pour voir s'il n'a pas été abandonné. La liste actuelle des
3444 paquets orphelins pour lesquels le champ responsable n'a pas été positionné
3445 correctement est disponible à <url id="&url-debian-qa-orphaned;">. Si vous
3446 effectuez une mise à jour indépendante sur un paquet incorrectement orphelin,
3447 veuillez positionner le responsable à « Debian QA Group
3448 <packages@qa.debian.org> ». Dans ce cas, les bogues du paquet sont
3449 fermés et pas simplement marqués comme corrigés.
3451 <sect1 id="nmu-who">Qui peut faire une mise à jour indépendante ?
3453 Seuls les responsables Debian officiels peuvent faire des mises à jour
3454 indépendantes binaire ou source. Un responsable officiel est une personne dont la clé est dans le
3455 porte-clés Debian. Tout autre personne est toutefois invitée à télécharger les paquets sources
3456 pour corriger des bogues ; au lieu de faire des mises à jour
3457 indépendantes, ils pourront soumettre les correctifs qui le méritent au système
3458 de suivi des bogues. Les responsables apprécient presque toujours les
3459 correctifs et les rapports de bogue soignés.
3461 <sect1 id="nmu-katie">Comment dak détecte les mises à jour indépendantes
3463 Le fait qu'un envoi soit traité par les scripts d'archive et par le
3464 système de suivi des bogues (voir <ref id="nmu-patch">) comme une mise
3465 à jour indépendante ou comme un envoi par le responsable <em>n'est
3466 pas</em> décidé en regardant le numéro de version (voir <ref
3467 id="nmu-version">). Au lieu de cela, un envoi est géré comme une mise à
3468 jour indépendante si l'adresse du responsable dans le fichier
3469 <tt>.changes</tt> n'est pas la même binairement que l'adresse du champ
3470 <tt>Maintainer</tt> ou que l'une des adresses du champ <tt>Uploaders</tt>
3471 du fichier <tt>dsc</tt> et également si l'adresse du responsable n'est
3472 pas spéciale (c.-à-d. elle n'est pas positionnée à l'adresse du groupe
3473 d'Assurance Qualité).
3475 <sect1 id="nmu-terms">Terminologie
3477 Deux nouvelles expressions sont introduites dans cette section :
3478 « mise à jour indépendante source » et « mise à jour
3479 indépendante binaire ». Ces deux expressions ont une signification
3480 technique précise dans ce document. Elles correspondent toutes deux au même type d'activité ;
3481 elles impliquent toutes deux qu'une personne fait une mise à jour d'un paquet
3482 alors qu'elle n'est pas officiellement responsable de ce paquet. C'est pourquoi
3483 nous qualifions ces mises à jours
3484 d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser
3485 entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas
3486 question d'agir sans prévenir le responsable au préalable (voir <ref
3487 id="nmu-guidelines">).</footnote>.
3489 Une mise à jour indépendante source est une livraison de paquet faite par une
3490 personne qui n'est pas le responsable officiel de ce paquet avec pour objectif
3491 de corriger un bogue dans le paquet. Une mise à jour indépendante source
3492 implique toujours une modification des sources du paquet, même s'il ne s'agit
3493 que d'un changement dans le fichier <file>debian/changelog</file>. Ce
3494 changement peut tout aussi bien concerner la partie amont du source que la
3495 partie spécifique à Debian. Une mise à jour indépendante source peut aussi
3496 inclure des paquets spécifiques à une architecture tout comme un fichier
3497 <em>diff</em> modifié.
3499 Une mise à jour indépendante binaire est constitué par la recompilation et
3500 l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du
3501 résultat d'un effort de portage. Une mise à jour indépendante binaire est la
3502 livraison d'un paquet compilé (souvent pour une autre architecture) à condition
3503 que cette compilation n'ait pas nécessité de modifications des sources. Dans de
3504 nombreux cas, les porteurs sont obligés de modifier les sources pour les rendre
3505 compilables sur leur architecture cible ; il s'agira alors d'une mise à
3506 jour indépendante source et non d'une mise à jour indépendante binaire. Comme
3507 vous pouvez le remarquer, nous ne faisons pas de distinction entre les mises à
3508 jour indépendantes faites par des porteurs et les autres mises à jour
3511 Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
3512 par l'expression « mise à jour indépendante »
3513 (NMU<footnote><p>Non-maintainer upload</footnote>). Pourtant, cela conduit
3514 souvent à des confusions car beaucoup associent « mise à jour
3515 indépendante » et « mise à jour indépendante source ». Il faut
3516 donc rester vigilant : utilisez toujours « mise à jour
3517 indépendante binaire » ou «NMU binaire » pour les mises à jour
3518 indépendantes de binaires seuls.
3521 <sect id="collaborative-maint">
3522 <heading>Maintenance collective</heading>
3524 « Maintenance collective » est un terme décrivant le partage des
3525 devoirs de la maintenance d'un paquet Debian par plusieurs personnes. Cette
3526 collaboration est presque toujours une bonne idée car il en résulte
3527 généralement une meilleure qualité et un temps de correction de bogues plus
3528 petit. Il est fortement recommandé que les paquets de priorité
3529 <tt>Standard</tt> ou qui font partie de la base aient des co-responsables.
3531 Habituellement, il y a un responsable principal et un ou plusieurs
3532 co-responsables. Le responsable principal est la personne dont le nom est indiqué
3533 dans le champ <tt>Maintainer</tt> du fichier <file>debian/control</file>. Les
3534 co-responsables sont tous les autres responsables.
3536 Dans sa forme la plus simple, ajouter un nouveau co-responsable est assez
3539 <item><p> Donner au co-responsable un accès aux sources à partir desquelles vous
3540 construisez le paquet. Habituellement, cela implique que vous utilisiez un
3541 système de contrôle de version comme <prgn>CVS</prgn> ou
3542 <prgn>Subversion</prgn>.
3544 <item><p> Ajouter les nom et adresse correctes du co-responsable au champ
3545 <tt>Uploaders</tt> dans la partie globale du fichier
3546 <file>debian/control</file>.
3548 Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
3552 En utilisant le PTS (<ref id="pkg-tracking-system">), les
3553 co-responsables devraient s'inscrire eux-mêmes aux paquets sources
3558 La maintenance collective peut souvent être facilitée par l'utilisation
3559 d'outils sur Alioth (voir <ref id="alioth">).
3563 <heading>La distribution <em>testing</em></heading>
3565 <sect1 id="testing-basics">
3566 <heading>Bases</heading>
3568 Les paquets sont habituellement installés dans la distribution <em>testing</em>
3569 après avoir atteint un certain degré de test dans <em>unstable</em>.
3571 Ils doivent être en synchronisation pour toutes les architectures et ne doivent
3572 pas avoir de dépendances qui les rendraient ininstallables ; ils doivent
3573 également n'avoir aucun bogue bloquant l'inclusion du paquet dans une version
3574 stable (« release-critical ») au moment où ils sont installés dans
3575 <em>testing</em>. Ainsi, <em>testing</em> devrait toujours être prête pour être
3576 une version candidate stable. Veuillez voir ci-dessous pour les détails.
3578 <sect1 id="testing-unstable">
3579 <heading>Mises à jour depuis <em>unstable</em></heading>
3581 Les scripts qui mettent à jour la distribution <em>testing</em> sont exécutés
3582 chaque jour après l'installation des paquets mis à jour ; ces
3583 scripts sont appelés <em>britney</em>. Ils fabriquent les
3584 fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils
3585 le font d'une manière intelligente pour éviter toute incohérence et essayer de
3586 n'utiliser que des paquets sans bogue.
3588 L'inclusion d'un paquet d'<em>unstable</em> est soumise aux conditions
3592 Le paquet doit avoir été disponible dans <em>unstable</em> depuis 2, 5 ou
3593 10 jours selon le champ d'urgence de l'envoi (élevée, moyenne ou basse).
3594 Veuillez noter que cette urgence est « collante » (« sticky »), ce qui
3595 veut dire que l'envoi avec l'urgence la plus élevée depuis la précédente
3596 transition dans <em>testing</em> est prise en compte. Ces délais peuvent être
3597 doublés lors d'un gel de distribution, ou les transitions dans <em>testing</em>
3598 peuvent être complètement désactivées ;
3600 Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
3601 version actuellement disponible dans <em>testing</em> ;
3603 Il doit être disponible pour toutes les architectures pour lesquelles
3604 il a été auparavant construit. <ref id="madison"> peut être
3605 intéressant pour vérifier cette information ;
3607 Il ne doit pas casser les dépendances d'un paquet qui est déjà
3608 disponible dans <em>testing</em> ;
3610 Les paquets dont il dépend doivent soit être déjà disponibles dans
3611 <em>testing</em> soit être acceptés dans <em>testing</em> au
3612 même moment (et ils doivent remplire tous les critères nécessaires).
3615 Pour savoir si un paquet a progressé ou non dans <em>testing</em>, veuillez voir la
3616 sortie du script de <em>testing</em> sur la <url name="page web de la distribution testing"
3617 id="&url-testing-maint;"> ou utilisez le programme <prgn>grep-excuses</prgn>
3618 inclus dans le paquet <package>devscripts</package>. Si vous voulez rester
3619 informé de la progression de vos paquets dans <em>testing</em>, vous pouvez
3620 facilement le mettre dans la <manref section="5" name="crontab">.
3622 Le fichier <file>update_excuses</file> ne donne pas toujours la raison précise
3623 pour laquelle un paquet est refusé ; on peut avoir à la chercher soi-même en
3624 regardant ce qui serait cassé avec l'inclusion du paquet. La <url
3625 id="&url-testing-maint;" name="page web de la distribution testing"> donne plus
3626 d'informations à propos des problèmes courants qui peuvent occasionner cela.
3628 Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce que le
3629 jeu des inter-relations est trop compliqué et ne peut être résolu par le
3630 script. Voir ci-dessous pour des détails.
3632 Des analyses de dépendances plus avancées sont présentées sur
3633 <url id="http://bjorn.haxx.se/debian/"> — mais, attention, cette page affiche
3634 également les dépendances de construction qui ne sont pas considérées par
3637 <sect2 id="outdated">
3638 <heading>Désynchronisation</heading>
3640 <!-- FIXME: better rename this file than document rampant professionalism? -->
3641 Pour le script de migration dans <em>testing</em>, « désynchronisé »
3642 (<em>outdated</em> veut dire ceci : il y a différentes versions dans
3643 <em>unstable</em> pour les architectures de version (à l'exception des
3644 architectures dans fuckedarches ; fuckedarches est une liste des
3645 architectures qui ne suivent pas le rythme (dans update_out.py), mais
3646 actuellement cette liste est vide). « Désynchronisé » n'a rien à voir
3647 avec les architectures que le paquet fournit pour <em>testing</em>.
3649 Considérons cet exemple :
3653 ---------+-------+----
3658 Le paquet est désynchronisé pour alpha dans <em>unstable</em> et n'entrera pas
3659 dans <em>testing</em>. Supprimer foo de <em>testing</em> n'aiderait en rien, le
3660 paquet serait toujours désynchronisé pour alpha et ne se propagerait pas dans
3663 Cependant, si ftp-master supprime un paquet d'<em>unstable</em> (ici pour arm) :
3666 foo | alpha | arm | hurd-i386
3667 ---------+-------+-----+----------
3669 unstable | 2 | - | 1
3672 Dans ce cas, le paquet est synchronisé pour toutes les architectures de version
3673 dans <em>unstable</em> (et l'architecture supplémentaire hurd-i386 ne compte pas
3674 car ce n'est pas une architecture de version).
3676 Quelquefois, la question est soulevée pour savoir s'il est possible de permettre
3677 à des paquets de passer dans <em>testing</em> qui ne sont pas encore construits
3678 pour toutes les architectures : non. Simplement non. (Excepté si vous êtes
3679 responsable de glibc ou équivalent).
3681 <sect2 id="removals">
3682 <heading>Suppressions de <em>testing</em></heading>
3684 Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre
3685 paquet : ceci ne se produit que pour permettre à un <em>autre</em> paquet
3686 d'entrer, ce dernier doit être prêt pour tous les autres critères.
3687 Considérons, par exemple, qu'un paquet <em>a</em> est en conflit avec la nouvelle version
3688 de <em>b</em> alors <em>a</em> peut être supprimé pour permettre l'entrée de <em>b</em>.
3690 Bien sûr, il existe une autre raison pour supprimer un paquet de
3691 <em>testing</em> : le paquet est trop bogué (et avoir un seul bogue RC est
3692 suffisant pour être dans cet état).
3694 <sect2 id="circular">
3695 <heading>Dépendances circulaires</heading>
3697 Une situation qui n'est pas très bien gérée par britney est si un paquet <em>a</em>
3698 dépend de la nouvelle version d'un paquet <em>b</em> et vice versa.
3700 Voici un exemple :
3703 | testing | unstable
3704 --+-----------------+------------
3705 a | 1; dépend: b=1 | 2; dépend: b=2
3706 b | 1; dépend: a=1 | 2; dépend: a=2
3709 Aucun des paquets <em>a</em> et <em>b</em> ne sera considéré pour mise à jour.
3711 Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de
3712 diffusion. Veuillez les contacter en envoyant un courrier électronique à
3713 debian-release@lists.debian.org si cela se produit pour l'un de vos paquets.
3717 <heading>Influence de paquet dans <em>testing</em></heading>
3719 Généralement, l'état d'un paquet dans <em>testing</em> ne change rien pour la
3720 transition de la prochaine version d'<em>unstable</em> vers <em>testing</em>,
3721 avec deux exceptions : si le nombre de bogues RC du paquet est réduit, le
3722 paquet peut migrer même s'il a encore des bogues RC. La seconde exception est
3723 que si la version du paquet dans <em>testing</em> est désynchronisée entre les
3724 différentes architectures, alors toute architecture peut être mise à jour vers
3725 la version du paquet source ; cependant, cela ne peut se produire que si le
3726 paquet a été précédemment forcé, si l'architecture est dans fuckedarches ou s'il
3727 n'y avait pas du tout de paquet binaire de cette architecture présent dans
3728 <em>unstable</em> lors de la migration dans <em>testing</em>.
3730 En résumé, cela veut dire : la seule influence qu'un paquet de
3731 <em>testing</em> a sur la nouvelle version du même paquet est que la nouvelle
3732 version peut rentrer plus facilement.
3734 <sect2 id="details">
3735 <heading>Détails</heading>
3737 Si vous êtes intéressé par les détails, voici comment fonctionne britney :
3739 Les paquets sont examinés pour savoir si ce sont des candidats valides. Cela
3740 donne le fichier « update excuses ». Les raisons les plus communes
3741 pour lesquelles un paquet n'est pas considéré sont la jeunesse du paquet, le
3742 nombre de bogues RC et la désynchronisation pour certaines architectures. Pour
3743 cette partie, les responsables de version ont des marteaux de toute taille pour
3744 forcer britney à considérer un paquet. (Le gel de la base est également codé
3745 dans cette partie de britney.) (Il y a une chose semblable pour les mises à jour
3746 binaires pures, mais cela n'est pas décrit ici. Si vous êtes intéressé par cela,
3747 veuillez étudier attentivement le code.)
3749 Maintenant, la partie la plus complexe se produit : britney tente de mettre
3750 à jour <em>testing</em> avec des candidats valides ; en premier, chaque
3751 paquet individuellement, puis des groupes de plus en plus larges de paquets
3752 ensemble. Chaque tentative est acceptée si <em>unstable</em> n'est pas moins
3753 ininstallable après la mise à jour qu'avant celle-ci. (Avant et après cette
3754 partie, certains coups de pouce sont traités ; mais, comme seuls les
3755 responsables de version peuvent positionner des coups de pouce, cela n'est
3756 probablement pas très important pour vous.)
3758 Si vous voulez voir plus de détails, vous pouvez le voir dans
3759 merkel:/org/ftp.debian.org/testing/update_out/ (ou dans
3760 ~aba/testing/update_out pour voir une configuration avec un fichier de paquets
3761 plus petit). Par le web, c'est à <url
3762 id="http://ftp-master.debian.org/testing/update_out_code/">.
3764 Les coups de pouce sont visibles sur <url
3765 id="http://ftp-master.debian.org/testing/hints/">.
3769 <heading>Mises à jour directes dans <em>testing</em></heading>
3771 La distribution <em>testing</em> est peuplée avec des paquets en provenance
3772 d'<em>unstable</em> selon des règles expliquées ci-dessus. Cependant, dans
3773 certains cas, il est nécessaire d'envoyer des paquets construits seulement pour
3774 <em>testing</em>. Pour cela, vous pouvez envoyer vos paquets vers
3775 <em>testing-proposed-updates</em>.
3777 Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement,
3778 ils doivent passer entre les mains du responsable de distribution. Vous devez
3779 donc avoir une bonne raison pour les y envoyer. Pour savoir ce que
3780 représente une bonne raison aux yeux des responsables de distribution, vous
3781 devriez lire les instructions données qu'ils envoient régulièrement sur
3782 &email-debian-devel-announce;.
3784 Vous ne devriez pas envoyer un paquet à <em>testing-proposed-updates</em> quand
3785 vous pouvez le mettre à jour par <em>unstable</em>. Si vous ne pouvez faire
3786 autrement (par exemple, parce que vous avez une nouvelle version de
3787 développement dans <em>unstable</em>), vous pouvez utiliser cette facilité, mais il est
3788 recommandé de demander l'autorisation du responsable de distribution auparavant.
3789 Même si un paquet est gelé, des mises à jour par <em>unstable</em> sont possibles
3790 si l'envoi dans <em>unstable</em> ne tire pas de nouvelles dépendances.
3792 Les numéros de version sont habituellement choisis en ajoutant le nom de
3793 code de la distribution <em>testing</em> et un numéro incrémenté, comme
3794 1.2sarge1 pour le premier envoi dans <em>testing-proposed-updates</em> du paquet
3795 en version 1.2.
3797 Veuillez vous assurer que vous n'oubliez aucun des éléments suivants lors de
3800 <item> vérifiez que votre paquet doit vraiment aller dans
3801 <em>testing-proposed-updates</em> et ne peut pas passer par
3802 <em>unstable</em> ;
3803 <item> vérifiez que vous n'incluez que le minimum de changements ;
3804 <item> vérifiez que vous incluez une explication appropriée dans le
3806 <item> vérifiez que vous avez bien indiqué <em>testing</em> ou
3807 <em>testing-proposed-updates</em> comme votre distribution cible ;
3808 <item> vérifiez que vous avez construit et testé votre paquet dans
3809 <em>testing</em> et non dans <em>unstable</em> ;
3810 <item> vérifiez que votre numéro de version est plus élevé que les versions de
3811 <em>testing</em> et de <em>testing-proposed-updates</em> et moins élevé que
3812 celle de <em>unstable</em> ;
3813 <item> après l'envoi et la construction réussie sur toutes les plates-formes,
3814 contactez l'équipe de diffusion à &email-debian-release; et demandez-leur
3815 d'approuver votre envoi.
3820 <heading>Questions fréquemment posées</heading>
3824 <heading>Qu'est-ce que sont les bogues bloquant l'intégration dans la
3825 version stable et comment sont-ils comptés ?</heading>
3827 Tous les bogues de gravité assez élevée sont par défaut considérés
3828 comme bloquant l'intégration du paquet dans la version stable ;
3829 actuellement, ce sont les bogues critiques, graves et sérieux.
3831 Certains bogues sont supposés avoir un impact sur les chances que le paquet a
3832 d'être diffusé dans la version stable de Debian : en général, si un paquet
3833 a des bogues bloquants, il n'ira pas dans <em>testing</em> et par conséquent,
3834 ne pourra pas être diffusé dans <em>stable</em>.
3836 Le compte des bogues d'<em>unstable</em> est effectué avec tous les bogues
3837 bloquants sans étiquette de version (comme <em>potato</em>, <em>woody</em>) ou
3838 avec une étiquette <em>sid</em> et également s'ils ne sont ni corrigés ou
3839 marqués avec <em>sarge-ignore</em>.
3840 Le compte des bogues de <em>testing</em> pour un paquet est condiséré comme à
3841 peu près le nombre de bogues d'<em>unstable</em> lors du dernier pointage quand
3842 la version <em>testing</em> a été égale à la version <em>unstable</em>.
3844 Cela changera après la sortie de <em>Sarge</em> dès que nous aurons des versions
3845 dans le système de suivi des bogues.
3848 <heading>Comment est-ce que l'installation d'un paquet dans
3849 <em>testing</em> peut casser d'autres paquets ?</heading>
3851 La structure des archives de la distribution est faite de telle façon qu'elles
3852 ne peuvent contenir qu'une version d'un paquet ; un paquet est défini par
3853 son nom. Donc, quand le paquet source acmefoo est installé dans
3854 <em>testing</em> avec ses paquets binaires acme-foo-bin, acme-bar-bin,
3855 libacme-foo1 et libacme-foo-dev, l'ancienne version est supprimée.
3858 Cependant, l'ancienne version pouvait fournir à un paquet binaire un vieux
3859 soname d'une bibliothèque, comme libacme-foo0. Supprimer l'ancien acmefoo va
3860 supprimer libacme-foo0, ce qui va casser tout paquet qui en dépend.
3862 Évidemment, cela touche principalement des paquets qui fournissent des jeux
3863 changeants de paquets binaires dans différentes version (par suite,
3864 principalement des bibliothèques). Cependant, cela va aussi toucher des paquets
3865 sur lesquels une dépendance versionnée a été déclarée du type ==, <= ou <<.
3867 Quand le jeu de paquets binaires fournis par un paquet source change de cette
3868 façon, tous les paquets qui dépendent des anciens binaires doivent être mis à
3869 jour pour dépendre de la nouvelle version à la place. Comme l'installation d'un
3870 tel paquet source dans <em>testing</em> casse tous les paquets qui en dépendent
3871 dans <em>testing</em>, une certaine attention doit y être portée : tous les
3872 paquets en dépendant doivent être mis à jour et prêts à être installés eux-même
3873 pour qu'ils ne cassent pas et, une fois que tout est prêt, une intervention
3874 manuelle du responsable de version ou d'un de ses assistants est normalement
3877 Si vous avez des problèmes avec des groupes compliqués de paquets comme ceci,
3878 contactez debian-devel ou debian-release en demandant de l'aide.
3882 <chapt id="best-pkging-practices">
3883 <heading>Les meilleurs pratiques pour la construction des paquets
3885 La qualité de Debian est principalement due à la <url id="&url-debian-policy;"
3886 name="charte Debian"> qui définit explicitement les obligations que tous les
3887 paquets doivent suivre. Mais c'est également grâce à une histoire partagée
3888 d'expériences qui va au-delà de la charte Debian, une accumulation d'années
3889 d'expérience pour la construction des paquets ; des développeurs de grand
3890 talent ont créé de bons outils qui vous aideront, vous, responsable Debian, à
3891 créer et maintenir d'excellents paquets.
3894 Ce chapitre fournit les meilleurs pratiques pour les développeurs Debian. Ce ne
3895 sont que des recommandations, non pas des obligations ou des règles. Ce sont
3896 seulement des astuces et conseils subjectifs et des liens collectés pour les
3897 développeurs Debian. Prenez et choisissez ce qui vous convient le mieux.
3899 <sect id="bpp-debian-rules">
3900 <heading>Les meilleures pratiques pour le fichier <file>debian/rules</file></heading>
3902 Les recommandations suivantes s'appliquent au fichier <file>debian/rules</file>.
3903 Comme ce fichier contrôle le processus de compilation et qu'il sélectionne les
3904 fichiers inclus dans le paquet (directement ou indirectement), il s'agit
3905 habituellement du fichier sur lequel les responsables passent le plus de temps.
3908 <sect1 id="helper-scripts">Scripts d'aide
3910 La raison sous-jacente à l'utilisation des scripts d'aide dans le fichier
3911 <file>debian/rules</file> est que cela permet aux responsables d'utiliser et de
3912 partager une logique commune pour un grand nombre de paquets. Prenez, par
3913 exemple, l'installation des entrées de menu : vous avez besoin de
3914 placer un fichier dans <file>/usr/lib/menu</file> et d'ajouter des commandes aux
3915 scripts de maintenance pour enregistrer et désenregistrer ces entrées de menu.
3916 Comme il s'agit d'une chose très commune, pourquoi chaque
3917 responsable devrait-il écrire sa propre version, parfois avec des bogues ?
3918 Supposons également que le répertoire de menu soit modifié, chaque paquet
3919 devrait être modifié.
3921 Les scripts d'aide peuvent résoudre ces problèmes. En supposant que vous vous
3922 conformiez aux conventions attendues par le script d'aide, celui-ci prend soin
3923 de tous les détails. Les changements dans la charte peuvent alors être faits
3924 dans le script d'aide ; les paquets ont alors simplement besoin d'être
3925 reconstruits avec la nouvelle version du script et sans aucun changement
3928 L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus
3929 courant et le meilleur (à notre avis) système est <package>debhelper</package>.
3930 Les précédents systèmes d'aide comme <package>debmake</package> étaient
3931 « monolithiques » : vous ne pouviez pas choisir quelles parties
3932 intéressantes vous pouviez utiliser, mais vous étiez obligé de choisir le
3933 système pour tout faire. <package>debhelper</package>, à l'inverse, consiste en
3934 un certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple,
3935 <prgn>dh_installman</prgn> installe et compacte les pages de manuel,
3936 <prgn>dh_installmenu</prgn> installe les fichiers de menu et ainsi de suite.
3937 Ainsi, il offre une flexibilité suffisante pour pouvoir utiliser les scripts
3938 d'aide quand ils sont utiles, en complément de commandes définies manuellement
3939 dans le fichier <file>debian/rules</file>.
3941 Vous pouvez débuter avec <package>debhelper</package> en lisant <manref
3942 name="debhelper" section="1"> et en regardant les exemples fournis avec le
3943 paquet. <prgn>dh_make</prgn> du paquet <package>dh-make</package> (voir <ref
3944 id="dh-make">) peut être utilisé pour convertir un paquet source
3945 « vierge » en une version utilisant <package>debhelper</package>. Ce
3946 raccourci ne devrait cependant pas vous faire croire que vous n'avez pas besoin
3947 de comprendre les scripts individuels <prgn>dh_*</prgn>. Si vous comptez
3948 utiliser un système d'aide, vous devez prendre le temps d'apprendre à utiliser
3949 ce système pour savoir ce que vous pouvez en attendre ainsi que son
3952 Plusieurs personnes pensent que des fichiers <file>debian/rules</file> vierges
3953 sont préférables car vous n'avez pas à apprendre les détails internes d'un
3954 quelconque système d'aide. La décision vous appartient complètement. Utilisez ce
3955 qui vous convient. Plusieurs exemples de fichiers <file>debian/rules</file> sont
3956 disponibles à <url id="&url-rules-files;">.
3958 <sect1 id="multiple-patches">
3959 <heading>Séparer vos correctifs en plusieurs fichiers</heading>
3961 Les gros paquets peuvent avoir plusieurs bogues que vous devez gérer. Si
3962 vous corrigez sans faire attention les bogues dans les sources, vous ne
3963 pourrez pas différencier facilement les nombreux correctifs que vous aurez
3964 appliqués. Cela peut devenir très compliqué de mettre à jour le paquet avec
3965 une nouvelle version amont qui intègre certains correctifs (mais pas tous).
3966 Vous ne pouvez pas prendre l'ensemble des correctifs (par exemple, dans les
3967 fichiers <file>.diff.gz</file>) et décider quels correctifs il vous faut
3968 enlever parce que les bogues ont été corrigés en amont.
3970 Malheureusement, le système de création des paquets tel qu'il est actuellement
3971 ne fournit pas de moyen de séparer les correctifs en plusieurs fichiers.
3972 Cependant, il existe des moyens de séparer les correctifs : les fichiers
3973 correctifs sont livrés dans le fichier correctif Debian
3974 (<file>.diff.gz</file>), habituellement dans le répertoire <file>debian/</file>.
3975 La seule différence est qu'ils ne sont pas appliqués immédiatement par
3976 dpkg-source, mais par la règle <tt>build</tt> du fichier
3977 <file>debian/rules</file>. Inversement, ils sont annulés par la règle
3980 <prgn>dbs</prgn> est l'une des approches les plus populaires pour cela. Il fait
3981 ce qui est décrit ci-dessus et fournit la possibilité de créer de nouveaux
3982 correctifs et de mettre à jour d'anciens correctifs. Veuillez vous reporter au
3983 paquet <package>dbs</package> pour plus d'informations et au paquet
3984 <package>hello-dbs</package> pour un exemple.
3986 <prgn>dpatch</prgn> fournit également ces fonctions, mais il est prévu pour être
3987 encore plus facile d'utilisation. Veuillez voir le paquet
3988 <package>dpatch</package> pour la documentation et des exemples (dans
3989 <file>/usr/share/doc/dpatch</file>).
3992 <sect1 id="multiple-binary">Paquets binaires multiples
3994 Un simple paquet source va souvent permettre de construire plusieurs paquets
3995 binaires différents, que ce soit pour fournir plusieurs saveurs du même
3996 paquet (par exemple, le paquet source <package>vim</package>) ou pour créer
3997 plusieurs petits paquets au lieu d'un seul gros (par exemple, si
3998 l'utilisateur peut n'installer que la partie nécessaire et ainsi
3999 économiser de l'espace disque).
4001 Le second cas peut facilement être géré dans le fichier
4002 <file>debian/rules</file>. Vous avez simplement besoin de déplacer les fichiers
4003 appropriés du répertoire de construction dans les arborescence temporaires du
4004 paquet. Vous pouvez le faire en utilisant <prgn>install</prgn>
4005 ou <prgn>dh_install</prgn> du paquet <package>debhelper</package>.
4006 Assurez-vous de vérifier les différentes permutations de paquets, en
4007 garantissant que vous avez bien défini les dépendances entre les paquets dans
4008 le fichier <file>debian/control</file>.
4010 Le premier cas est un peu plus difficile car il implique de multiples
4011 recompilations du même logiciel, mais avec différentes options de
4012 configuration. Le paquet source <package>vim</package> est un exemple de la
4013 façon de gérer cela avec un fichier <file>rules</file> écrit à la main.
4015 <!-- &FIXME; Find a good debhelper example with multiple configure/make cycles
4020 <sect id="bpp-debian-control">
4021 <heading>Les meilleures pratiques pour le fichier
4022 <file>debian/control</file></heading>
4024 Les pratiques suivantes sont relatives au fichier <file>debian/control</file>.
4025 Elles viennent en complément des <url
4026 id="&url-debian-policy;ch-binary.html#s-descriptions" name="règles pour
4027 les descriptions des paquets">.
4029 La description du paquet, telle qu'elle est définie par le champ correspondant
4030 dans le fichier <file>control</file>, contient à la fois le résumé du paquet et
4031 la description longue pour le paquet. <ref id="bpp-desc-basics"> décrit des
4032 lignes générales pour les deux parties de la description. Ensuite, <ref
4033 id="bpp-pkg-synopsis"> fournit des principes spécifiques pour le résumé et <ref
4034 id="bpp-pkg-desc"> contient des principes spécifiques pour la description
4037 <sect1 id="bpp-desc-basics">
4038 <heading>Les règles générales pour les descriptions des paquets</heading>
4040 La description du paquet devrait être écrite pour l'utilisateur moyen,
4041 l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple, les paquets
4042 de développement sont pour les développeurs et leur description peut utiliser un
4043 langage technique. Pour les applications à but plus général comme un éditeur, la
4044 description devrait être écrite pour un non-spécialiste.
4046 Notre critique des descriptions des paquets nous amène à conclure que la plupart
4047 des descriptions des paquets sont techniques, c'est-à-dire, qu'elles ne sont pas
4048 écrites pour être comprises par les non-spécialistes. À moins que
4049 votre paquet ne soit que pour les techniciens, c'est un problème.
4051 Comment écrire pour les non-spécialistes ? Évitez le jargon.
4052 Évitez de vous référer à d'autres applications et cadres de travail avec
4053 lesquels l'utilisateur n'est pas forcément familier — « GNOME »
4054 ou « KDE » sont corrects car les utilisateurs sont probablement
4055 familiers avec ces termes, mais « GTK+ » ne l'est probablement pas.
4056 Ne supposez aucune connaissance. Si vous devez utiliser des termes techniques,
4059 Soyez objectif. Les descriptions de paquet ne sont pas un endroit pour
4060 promouvoir votre paquet, quel que soit l'amour que vous lui portez.
4061 Rappelez-vous que le lecteur n'a pas forcément les mêmes priorités que vous.
4063 Des références aux noms de tout autre paquet de logiciels, noms de protocoles,
4064 standards ou spécifications devraient utiliser leurs formes canoniques si elles
4065 existent. Par exemple, utilisez « X Window System », « X11 »
4066 ou « X » et non « X Windows », « X-Windows » ou
4067 « X Window ». Utilisez « GTK+ » et non « GTK » ou
4068 « gtk ». Utilisez « GNOME » et non « Gnome ».
4069 Utilisez « PostScript » et non « Postscript » ou
4070 « postscript ».
4072 Si vous avez des problèmes pour écrire votre description, vous pouvez l'envoyer à
4073 &email-debian-l10n-english; et demander un retour d'informations.
4077 <sect1 id="bpp-pkg-synopsis">
4078 <heading>Le résumé du paquet ou description courte</heading>
4080 La ligne de résumé (la description courte) devrait être concise. Elle ne doit
4081 pas répéter le nom du paquet (c'est une règle).
4083 C'est une bonne idée de penser au résumé comme à une clause apposée et non une
4084 phrase complète. Une clause apposée est définie dans WordNet comme une relation
4085 grammaticale entre un mot et une phrase pronominale qui la suit, par exemple
4086 « Rudolph, le renne au nez rouge ». La clause apposée ici est
4087 « le renne au nez rouge ». Comme le résumé est une clause et non une
4088 phrase complète, nous recommandons de ne pas la commencer par une majuscule et
4089 de ne pas la finir par un point. Il ne doit pas non plus commencer avec un
4090 article, défini (« le ») ou indéfini (« un »).
4092 Cela peut vous aider d'imaginer le résumé combiné avec le nom du paquet de
4093 la façon suivante :
4095 <example><var>nom-paquet</var> est un <var>résumé</var>.</example>
4097 Sinon, il peut être plus compréhensible de le voir comme
4099 <example><var>nom-paquet</var> est <var>résumé</var>.</example>
4101 ou, si le nom du paquet est lui-même un pluriel (comme
4102 « developer-tools »)
4104 <example><var>nom-paquet</var> sont <var>résumé</var>.</example>
4106 Cette façon de former une phrase à partir du nom du paquet et du résumé devrait
4107 être considérée comme une heuristique et non comme une règle stricte. Il y a
4108 certains cas où cela n'a aucun sens de former une phrase.
4112 <sect1 id="bpp-pkg-desc">
4113 <heading>La description longue</heading>
4115 La description longue du paquet est la première information dont dispose
4116 l'utilisateur avant d'installer un paquet. Aussi, elle devrait fournir toutes
4117 les informations nécessaires pour le laisser décider de l'installation du
4118 paquet. Vous pouvez supposer que l'utilisateur a déjà lu le résumé du paquet.
4120 La description longue devrait toujours être constituée de phrases complètes.
4122 Le premier paragraphe de la description longue devrait répondre aux questions
4123 suivantes : qu'est-ce que fait le paquet ? Quelle tâche aide-t-il
4124 l'utilisateur à accomplir ? Il est important de décrire ceci d'une manière
4125 non technique, à moins que le paquet ne s'adresse qu'à un auditoire de techniciens.
4127 Les paragraphes suivants devraient répondre aux questions suivantes :
4128 Pourquoi, en tant qu'utilisateur, ai-je besoin de ce paquet ? Quelles
4129 sont les autres fonctionnalités dont dispose le paquet ? Quelles
4130 sont les fonctionnalités marquantes et les déficiences de ce paquet comparé à
4131 d'autres paquets (par exemple, « si vous avez besoin de X, utilisez Y à la
4132 place ») ? Est-ce que le paquet est lié à d'autres paquets d'une
4133 certaine façon qui n'est pas gérée par le gestionnaire de paquet (par exemple,
4134 « il s'agit d'un client pour le serveur foo ») ?
4136 Soyez attentif à éviter les fautes d'orthographe et de grammaire. N'oubliez
4137 pas votre vérificateur orthographique. <prgn>ispell</prgn> possède une option
4138 spéciale (<tt>-g</tt>) pour cela :
4140 <example>ispell -d american -g debian/control</example>
4143 Les utilisateurs s'attendent habituellement à ce que les réponses aux questions
4144 suivantes soient présentes dans la description du paquet :
4147 Qu'est-ce que fait le paquet ? Si c'est un ajout d'un autre paquet, la
4148 description courte du paquet dont c'est un ajout devrait le spécifier.
4150 Pourquoi est-ce qu'il voudrait installer ce paquet ? Ceci est lié à ce qui
4151 est ci-dessus, mais pas tout à fait (c'est un client de messagerie ; il
4152 est cool, rapide, s'interface avec PGP, LDAP et IMAP, a les fonctionnalités
4155 Si ce paquet ne devrait pas être installé directement, mais être tiré par un
4156 autre paquet, cela devrait être mentionné.
4158 Si le paquet est expérimental, ou s'il y a d'autres raisons pour lesquelles il
4159 ne devrait pas être utilisé, si un autre paquet devrait être utilisé à la place,
4160 cela devrait également être présent.
4162 En quoi le paquet est différent des paquets concurrents ? Est-ce que c'est
4163 une meilleure implémentation ? A-t-il plus de fonctionnalités, des
4164 fonctionnalités différentes ? Pourquoi devrait-il choisir ce paquet ?
4165 <!-- FIXME: what's this?
4166 (the second questions is about the class of packages, and
4167 this about this particular package, if you have information related to both).
4173 <sect1 id="bpp-upstream-info">
4174 <heading>Page d'accueil amont</heading>
4176 Nous vous recommandons d'ajouter l'adresse de la page d'accueil du paquet à la
4177 description du paquet dans le fichier <file>debian/control</file>. Cette
4178 information devrait être ajoutée à la fin de la description en utilisant le
4179 format suivant :
4182 Homepage: http://some-project.some-place.org/</example>
4184 Veuillez noter les espaces au début de la ligne, ils servent à séparer les
4185 lignes correctement. Pour voir un exemple de ce que cela affiche, veuillez vous
4186 reporter à <url id="&url-eg-desc-upstream-info;">.
4188 Ne mettez rien s'il n'existe pas de page pour le logiciel.
4191 Veuillez noter que nous espérons que ce champ sera remplacé par un
4192 vrai champ de <file>debian/control</file> que comprendraient <prgn>dpkg</prgn>
4193 et <tt>&packages-host;</tt>. Si vous ne voulez pas vous embêter à déplacer la
4194 page d'accueil depuis la description vers ce nouveau champ, vous devriez
4195 probablement attendre qu'il soit disponible.</p>
4200 <sect id="bpp-debian-changelog">
4201 <heading>Les meilleures pratiques pour le fichier <file>debian/changelog</file></heading>
4203 Les pratiques suivantes viennent en complément de la <url name="directive sur
4204 les fichiers changelog" id="&url-debian-policy;ch-docs.html#s-changelogs">.</p>
4206 <sect1 id="bpp-changelog-do">
4207 <heading>Écrire des entrées de changelog utiles</heading>
4209 L'entrée de changelog pour une révision de paquet documente les changements dans
4210 cette révision et seulement ceux-ci. Concentrez-vous sur la description des
4211 changements significatifs et visibles de l'utilisateur qui ont été effectués
4212 depuis la dernière version.
4214 Ciblez <em>ce</em> qui a été changé — qui, comment et quand cela a été fait
4215 est généralement de moindre importance. Ceci dit, rappelez-vous de nommer
4216 poliment les personnes qui ont fourni une aide notable pour réaliser le
4217 paquet (par exemple, ceux qui ont envoyé des correctifs).
4219 Vous n'avez pas besoin de détailler les changements triviaux et évidents. Vous
4220 pouvez également regrouper plusieurs de ces changements dans une seule entrée.
4221 D'un autre côté, ne soyez pas trop concis si vous avez entrepris un changement
4222 majeur. Soyez tout spécialement clair s'il y a des changements qui modifient le
4223 comportement du programme. Pour plus d'explications, utilisez le fichier
4224 <file>README.Debian</file>.
4226 Utilisez un langage anglais commun pour que la majorité des lecteur puissent le
4227 comprendre. Évitez les abréviations, le parler technique et le jargon quand
4228 vous expliquez des changements fermant un bogue, spécialement pour les rapports
4229 de bogue créés par des utilisateurs qui ne vous paraissent pas particulièrement
4230 à l'aise techniquement. Vous devez être poli et ne pas jurer.
4232 Il est parfois désirable de préfixer les entrées de changelog avec le nom des
4233 fichiers qui ont été modifiés. Cependant, il n'est pas besoin de lister
4234 explicitement tous les fichiers modifiés, particulièrement si la modification
4235 est petite ou répétitive. Vous pouvez utiliser les caractères génériques.
4237 Quand vous faites référence aux bogues, ne supposez rien a priori. Dites ce
4238 qu'était le problème, comment il a été résolu et ajoutez la chaîne de caractères
4239 « closes: #nnnnn ». Veuillez voir <ref id="upload-bugfix"> pour plus
4242 <sect1 id="bpp-changelog-misconceptions">
4243 <heading>idées fausses communes sur les entrées de changelog</heading>
4245 Les entrées de changelog <strong>ne devraient pas</strong> documenter des
4246 problèmes génériques d'empaquetage (« Hé, si vous cherchez foo.conf, il
4247 est dans /etc/blah/. ») car les administrateurs et utilisateurs sont
4248 supposés être au moins vaguement rompus à la façon dont les choses sont
4249 arrangées sur un système Debian. Mentionnez cependant tout changement
4250 d'emplacement d'un fichier de configuration.
4252 Les seuls bogues fermés par une entrée de changelog devraient être ceux qui sont
4253 vraiment corrigés dans la même révision du paquet. Fermer des bogues non liés
4254 par le fichier changelog est considéré comme une très mauvaise pratique.
4255 Veuillez voir <ref id="upload-bugfix">.
4257 Les entrées de changelog <strong>ne devraient pas</strong> être le lieu de
4258 discussions avec les émetteurs de bogues (« Je ne vois pas de segfaults
4259 lors du lancement de foo avec l'option bar ; envoyez-moi plus
4260 d'informations. »), ni celui de phrases génériques sur la vie, l'univers et
4261 tout le reste (« Désolé, cet envoi m'a pris du temps, mais j'avais attrapé
4262 la grippe ») ou celui de demandes d'aide (« La liste des bogues sur
4263 ce paquet est énorme, donnez-moi un coup de main »). Ceci ne sera
4264 généralement pas remarqué par les personnes ciblées, mais peut ennuyer les
4265 personnes qui désirent lire des informations sur les changements réels du
4266 paquet. Veuillez vous reporter à <ref id="bug-answering"> pour plus
4267 d'informations sur la façon d'utiliser le système de suivi des bogues.
4269 C'est une vieille tradition de valider les bogues fixés par une mise à jour
4270 indépendante dans la première entrée du changelog de l'envoi du vrai
4271 responsable, par exemple, dans une entrée de changelog comme ceci :
4273 * Maintainer upload, closes: #42345, #44484, #42444.
4275 Ceci fermera les bogues NMU marqués comme corrigé (« fixed ») quand le
4276 paquet arrivera dans l'archive. Le bogue pour le fait qu'une NMU a été faite
4277 peut être fermé de la même façon. Bien sûr, il est également parfaitement
4278 acceptable de fermer les bogues corrigés par NMU par d'autres moyens ; voir
4279 <ref id="bug-answering">.
4282 <sect1 id="bpp-changelog-errors">
4283 <heading>Erreurs communes dans les entrées de changelogs</heading>
4285 Les exemples suivants montrent des erreurs communes ou des exemples de mauvais
4286 style dans les entrées de changelog<footnote>NdT : Les entrées de
4287 changelog sont ici affichées en français pour faciliter la compréhension, mais
4288 vos entrées devront naturellement être rédigées en anglais.</footnote>.
4292 * Corrige tous les bogues restants.
4295 Ceci n'indique visiblement rien d'utile au lecteur.
4298 * Correctif de Jane Random appliqué.
4300 Sur quoi portait le correctif ?
4304 * Révision de cible d'installation la nuit dernière.
4306 Qu'a accompli la révision ? Est-ce que la mention de la nuit dernière
4307 est supposée nous rappeler que nous ne devons pas faire confiance à ce
4312 * Corrige MRD vsync av. anciens CRTs.
4314 Trop d'acronymes et il n'est pas très clair de ce qu'était vraiment cette...
4315 euh... merde (oups, un mot interdit !) ou comment cela a été corrigé.
4319 * Ceci n'est pas un bogue. Closes: #nnnnnn.
4321 Premièrement, il n'y a absolument pas besoin d'envoyer un paquet pour
4322 communiquer cette information ; à la place, utilisez le système de suivi des
4323 bogues. Deuxièmement, il n'y a aucune explication concernant la raison
4324 pour laquelle le rapport n'était pas un bogue.
4328 * A été fixé il y a longtemps, mais j'ai oublié de le fermer. Closes: #54321.
4330 Si, pour toute raison, vous n'aviez pas indiqué le numéro du bogue dans une
4331 précédente entrée de changelog, ceci n'est pas un problème, fermez simplement le
4332 bogue normalement dans le BTS. Il n'y a pas besoin de modifier le fichier
4333 changelog, en supposant que la description de la correction est déjà intégrée
4334 (ceci s'applique aux correctifs par les auteurs/responsables amont également,
4335 vous n'avez pas à suivre les bogues qui ont été corrigés il y a longtemps dans
4340 * Closes: #12345, #12346, #15432.
4342 Où est la description ?! Si vous n'arrivez pas à trouver un message
4343 descriptif, commencez par insérer le titre de chacun des différents bogues.
4347 <sect1 id="bpp-news-debian">
4348 <heading>Compléter les changelogs avec les fichiers NEWS.Debian</heading>
4350 Les nouvelles importantes à propos des changements dans un paquet peuvent
4351 également être placées dans les fichiers NEWS.Debian. Ces nouvelles seront
4352 affichées par des outils comme apt-listchanges, avant le reste des changelogs.
4353 Ceci est le moyen préféré pour informer les utilisateurs des changements
4354 significatifs dans un paquet. Il est préférable d'utiliser ce fichier plutôt que
4355 d'utiliser des notes debconf car c'est moins ennuyeux et l'utilisateur peut y
4356 revenir et se référer au fichier NEWS.Debian après l'installation. Et c'est
4357 mieux que de lister les changements principaux dans README.Debian car
4358 l'utilisateur peut facilement rater de telles notes.
4360 Le format du fichier est le même que pour un fichier de changelog Debian, mais
4361 il n'utilise pas d'astérisques et décrit chaque élément de nouvelle dans un
4362 paragraphe complet si nécessaire plutôt que les résumés concis qui iraient dans un
4363 changelog. C'est une bonne idée de passer votre fichier par dpkg-parsechangelog
4364 pour vérifier son formatage car il n'est pas vérifié automatiquement pendant la
4365 construction comme le changelog. Voici un exemple d'un vrai fichier NEWS.Debian :
4367 cron (3.0pl1-74) unstable; urgency=low
4369 The checksecurity script is no longer included with the cron package:
4370 it now has its own package, "checksecurity". If you liked the
4371 functionality provided with that script, please install the new
4374 -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
4377 Le fichier NEWS.Debian est installé comme
4378 /usr/share/doc/<package>/NEWS.Debian.gz. Il est compressé et a toujours ce
4379 nom même dans les paquets natifs Debian. Si vous utilisez debhelper,
4380 dh_installchangelogs installera les fichiers debian/NEWS pour vous.
4382 À la différence des fichiers changelog, vous n'avez pas besoin de mettre à jour
4383 les fichiers NEWS.Debian à chaque nouvelle version. Ne les mettez à jour que si
4384 vous avez quelque chose de particulièrement important que l'utilisateur a
4385 besoin de savoir. Si vous n'avez pas de nouvelles du tout, il n'est pas
4386 nécessaire de fournir de fichier NEWS.Debian dans votre paquet. Pas de
4387 nouvelles, bonne nouvelle !
4391 <!-- <sect1 id="pkg-mgmt-cvs">Managing a package with CVS
4393 &FIXME; presentation of cvs-buildpackage, updating sources
4394 via CVS (debian/rules refresh).
4395 <url id="http://www.debian.org/devel/cvs_packages">
4398 <sect id="bpp-debian-maint-scripts">
4399 <heading>Les meilleures pratiques pour les scripts de
4400 maintenance</heading>
4402 Les scripts de maintenance incluent les fichiers <file>debian/postinst</file>,
4403 <file>debian/preinst</file>, <file>debian/prerm</file> et
4404 <file>debian/postrm</file>. Ces scripts prennent soin de la configuration
4405 d'installation ou de désinstallation des paquets, ce qui n'est pas simplement créer ou
4406 supprimer des fichiers et des répertoires. Les instructions suivantes
4407 complètent la <url id="&url-debian-policy;" name="charte Debian">.
4409 Les scripts de maintenance doivent être idempotents. Cela veut dire que vous
4410 devez vous assurer que rien de grave ne se produit si un script est appelé deux
4411 fois là où il ne devrait habituellement être appelé qu'une fois.
4413 Les entrée et sortie standard peuvent être redirigées (par exemple, dans des
4414 tubes<footnote><p>pipes</p></footnote>) pour des besoins d'enregistrement
4415 d'activité, donc vous ne devez pas supposer que ce sont des tty.
4417 Tous les affichages et les configurations interactives devraient être
4418 minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet
4419 <package>debconf</package> pour l'interface. Rappelez-vous que, dans tous les
4420 cas, l'affichage ne doit se faire que dans l'étape de configuration,
4421 <tt>configure</tt> du script de post-installation, <file>postinst</file>.
4423 Gardez les scripts de maintenance aussi simples que possible. Nous vous
4424 suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que si vous
4425 avez besoin d'une fonctionnalité de Bash, le script de maintenance doit
4426 préciser bash dans sa première ligne. Un shell POSIX ou Bash sont préférés à
4427 Perl car ils permettent à <package>debhelper</package> d'ajouter facilement des
4428 parties aux scripts.
4430 Si vous modifiez les scripts de maintenance, assurez-vous de tester la
4431 suppression du paquet, la double installation et la purge complète. Assurez-vous
4432 qu'il ne reste rien d'un paquet purgé, c'est-à-dire, que la purge doit enlever
4433 tout fichier créé, directement ou indirectement, par les scripts de
4436 Si vous avez besoin de vérifier l'existence d'une commande, vous devriez
4437 utiliser quelque chose comme :
4438 <example>if [ -x /usr/sbin/install-docs ]; then ...</example>
4440 Si vous ne désirez pas mettre en dur le chemin d'une commande dans le script de
4441 maintenance, la fonction de shell suivante conforme à POSIX peut vous
4446 Vous pouvez utiliser cette fonction pour rechercher le <tt>$PATH</tt> pour un
4447 nom de commande passé en argument. Il renvoie vrai (zéro) si la commande a été
4448 trouvée et faux sinon. Il s'agit réellement de la façon la plus portable de faire
4449 car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn> ne sont pas
4452 Bien que <prgn>which</prgn> soit une alternative acceptable car il est
4453 présent dans le paquet classé <em>required</em> <package>debianutils</package>, il n'est pas
4454 présent dans la partition racine. Autrement dit, il est placé dans
4455 <file>/usr/bin</file> au lieu de <file>/bin</file>, il n'est donc pas possible
4456 de l'utiliser dans les scripts qui sont exécutés avant que la partition
4457 <file>/usr</file> soit montée. Cependant, la plupart des scripts n'auront pas ce
4461 <!-- Les 2 prochaines sections sont provisoirement commentées tant que
4462 le bogue 337086 n'est pas clos -->
4464 <sect id="bpp-debian-security-audit">
4465 <heading>Les meilleures pratiques en matière de sécurité</heading>
4467 <p>Si vous empaquetez un logiciel pour d'autres utilisateurs, vous devez
4468 vous efforcer de garantir que l'installation du logiciel et son
4469 utilisation n'introduisent pas de risques pour la sécurité du
4470 système sur lequel il est installé ou de ses utilisateurs.</p>
4472 <p>Vous devez vous efforcer d'examiner le code source du paquet
4473 et détecter les problèmes qui pourraient amener des bogues concernant la
4474 sécurité. Les erreurs de programmation qui entraînent des bogues concernant la sécurité
4475 sont généralement du type : <url
4476 id="http://en.wikipedia.org/wiki/Buffer_overflow" name="dépassement de
4478 id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="dépassement
4479 de chaînes de formatage">, <url
4480 id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="dépassement
4482 id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="dépassement
4483 d'entier"> (dans les programmes C/C++), <url
4484 id="http://en.wikipedia.org/wiki/Symlink_race" name="situation de
4485 concurrence entre liens symboliques"> temporaire (dans les scripts), <url
4486 id="http://en.wikipedia.org/wiki/Directory_traversal" name="traversée de
4487 répertoire"> et injection de commandes (dans les serveurs) et <url
4488 id="http://en.wikipedia.org/wiki/Cross_site_scripting"
4489 name="scripts intersites">, et <url
4490 id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="bogues
4491 d'injection SQL"> (dans le cas d'applications orientées web).</p>
4493 <p>Certains de ces problèmes peuvent ne pas être évidents à détecter à
4494 moins d'être un expert dans le langage de programmation utilisé par le
4495 programme, mais d'autres sont faciles à détecter et
4496 à corriger. Par exemple, il est facile de trouver des situations de concurrence
4497 temporaires dans un code source : on peut exécuter
4498 <tt>grep -r "/tmp/" .</tt> dans le code source et remplacer les noms
4499 de fichier codés en dur utilisant des répertoires temporaires par des
4500 appels soit à <prgn>mktemp</prgn> ou à <prgn>tempfile</prgn> dans les
4501 scripts shell, à <manref name="File::Temp" section="3perl"> dans les
4502 scripts Perl, et à <manref name="tmpfile" section="3"> pour du C/C++.
4503 Vous pouvez également utiliser des <url
4504 id="http://www.debian.org/security/audit/tools" name="outils
4505 spécifiques"> qui facilitent la phase d'étude du code du point de vue de la sécurité.</p>
4507 <p>Quand vous empaquetez un logiciel, assurez-vous que :
4511 <item>le logiciel fonctionne avec le minimum de privilèges :
4514 <item>le paquet installe des binaires setuid ou setgid.
4515 <prgn>Lintian</prgn> émettra un avertissement pour les binaires <url
4516 id="http://lintian.debian.org/reports/Tsetuid-binary.html"
4517 name="setuid">, <url id="http://lintian.debian.org/reports/Tsetgid-binary.html"
4518 name="setgid"> et <url
4519 id="http://lintian.debian.org/reports/Tsetuid-gid-binary.html"
4520 name="setuid et setgid">.
4522 <item>les démons fournis par le paquet s'exécutent avec un utilisateur à
4523 privilège réduit (voir <ref id="bpp-lower-privs">).
4527 <item>les tâches programmées (par exemple, <prgn>cron</prgn>)
4528 ne s'exécutent PAS en tant que root ou si
4529 elles le font, elles n'implémentent pas de tâches complexes.
4533 <p>Si votre paquet se trouve dans l'un des cas ci-dessus, assurez-vous que les programmes
4534 qui s'exécutent avec des privilèges plus élevés ont été audités pour les
4535 bogues de sécurité. Si vous n'en êtes pas certain ou si vous avez besoin
4536 d'aide, contactez l'<url
4537 id="http://www.debian.org/security/audit/" name="équipe d'audit de
4538 sécurité Debian">. Dans le cas de binaires setuid/setgid, suivez la
4539 charte Debian en ce qui concerne les
4540 <url id="http://www.debian.org/doc/debian-policy/ch-files.html#s10.9"
4541 name="permissions et propriétaires">.
4544 <p>Pour d'autres informations spécifiques à la programmation sécurisée,
4545 lisez (ou signalez au développeur amont) <url
4546 id="http://www.dwheeler.com/secure-programs/" name="Secure Programming
4547 for Linux and Unix HOWTO"> et le portail <url
4548 id="https://buildsecurityin.us-cert.gov/portal/" name="Build Security
4549 In">. Pour des informations spécifiques à la sécurité dans la distribution Debian, vous
4551 id="http://www.debian.org/doc/manuals/securing-debian-howto/"
4552 name="guide de sécurisation de Debian">.
4556 <!-- This should be explained here until #291177 gets fixed and this is
4560 <sect1 id="bpp-lower-privs">
4561 <heading>Créer des groupes et des utilisateurs pour des démons
4564 <p>Si votre logiciel exécute un démon qui n'a pas besoin des privilèges
4565 du superadministrateur, vous devez lui créer un utilisateur. Il existe
4566 deux types d'utilisateurs Debian pouvant être utilisés par des
4567 paquets : les identifiants statiques (assignés par
4568 <package>base-passwd</package>) et les identifiants dynamiques dans
4569 l'intervalle assigné aux utilisateurs système.
4571 <p>Dans le premier cas, vous devez demander un identifiant d'utilisateur
4572 ou de groupe à <package>base-passwd</package> et ajouter une dépendance
4573 versionnée correctement sur le paquet <package>base-passwd</package>
4574 fournissant cet utilisateur.
4576 <p>Dans le second cas, vous devez créer l'utilisateur système dans
4577 le script <em>preinst</em> ou <em>postinst</em> et rendre le paquet
4578 dépendant de <tt>adduser (>= 3.11)</tt>.
4580 <p>Le code exemple suivant crée l'utilisateur et le groupe du démon avec
4581 lequel le démon fonctionnera au moment de l'installation ou de la mise à
4582 jour du paquet :
4589 # Si le paquet a un fichier par défaut, il peut être sourcé afin
4590 # que l'administrateur local puisse écraser les valeurs par défaut
4592 [ -f "/etc/default/<var>packagename</var>" ] && .
4593 /etc/default/<var>packagename</var>
4596 # Valeurs par défaut saines :
4598 [ -z "$SERVER_HOME" ] && SERVER_HOME=<var>server_dir</var>
4599 [ -z "$SERVER_USER" ] && SERVER_USER=<var>server_user</var>
4600 [ -z "$SERVER_NAME" ] && SERVER_NAME="<var>Server description</var>"
4601 [ -z "$SERVER_GROUP" ] && SERVER_GROUP=<var>server_group</var>
4603 # Groupes auxquels l'utilisateur sera ajouté, si non défini, alors rien.
4607 # Crée l'utilisateur pour éviter d'exécuter le serveur en tant que root
4608 # 1. Création du groupe s'il n'existe pas
4609 if ! getent group | grep -q "^$SERVER_GROUP:" ; then
4610 echo -n "Adding group $SERVER_GROUP.."
4611 addgroup - -quiet - -system $SERVER_GROUP 2>/dev/null ||true
4614 # 2. Création du répertoire personnel s'il n'existe pas
4615 test -d $SERVER_HOME || mkdir $SERVER_HOME
4616 # 3. Création de l'utilisateur s'il n'existe pas
4617 if ! getent passwd | grep -q "^$SERVER_USER:"; then
4618 echo -n "Adding system user $SERVER_USER.."
4621 - -ingroup $SERVER_GROUP \
4623 - -disabled-password \
4624 $SERVER_USER 2>/dev/null || true
4627 # 4. Ajuste l'entrée du mot de passe
4628 usermod -c "$SERVER_NAME" \
4632 # 5. Ajuste les permissions de fichiers et répertoires
4633 if ! dpkg-statoverride - -list $SERVER_HOME >/dev/null
4635 chown -R $SERVER_USER:adm $SERVER_HOME
4636 chmod u=rwx,g=rxs,o= $SERVER_HOME
4638 # 6. Ajoute l'utilisateurs au groupe ADDGROUP
4639 if test -n $ADDGROUP
4641 if ! groups $SERVER_USER | grep -q $ADDGROUP; then
4642 adduser $SERVER_USER $ADDGROUP
4651 <p>Vous devez vous assurer que le fichier script d'init.d :
4654 <item>lance le démon en abandonnant les privilèges, si le logiciel ne
4655 fait pas les appels <manref name="setuid" section="2"> ou <manref
4656 name="seteuid" section="2"> lui-même, vous pouvez utiliser l'option
4657 <tt>- -chuid</tt> de <prgn>start-stop-daemon</prgn>.
4659 <item>arrête le démon seulement si l'identifiant utilisateur correspond,
4660 vous pouvez utiliser l'option <tt>- -user</tt> de
4661 <prgn>start-stop-daemon</prgn> pour cela.
4663 <item>ne s'exécute pas si l'utilisateur ou le groupe n'existe pas :
4665 if getent passwd | grep -q "^<var>server_user</var>:"; then
4666 echo "Server user does not exist. Aborting" >&2
4669 if getent group | grep -q "^<var>server_group</var>:" ; then
4670 echo "Server group does not exist. Aborting" >&2
4677 <p>Si le paquet crée l'utilisateur système, il peut l'enlever quand il
4678 est purgé dans son script <em>postrm</em>, cela a certains inconvénients
4679 <footnote>Par exemple, les fichiers créés par celui-ci seront sans
4680 propriétaire et peuvent être récupérés par un nouvel utilisateur système
4681 dans le futur si celui-ci reçoit le même identifiant utilisateur.
4682 Voir les fils de discussion suivants qui traitant de ces
4683 inconvénients : <url
4684 id="http://lists.debian.org/debian-mentors/2004/10/msg00338.html">
4686 <url id="http://lists.debian.org/debian-devel/2004/05/msg01156.html">
4688 ce n'est donc pas obligatoire et cela dépend des besoins du paquet. En
4689 cas de doute, cela peut être géré en demandant à l'administrateur son
4690 choix lors de l'installation du paquet (voir <ref
4691 id="debconf">). Le code exemple suivant supprime l'utilisateur et le
4692 groupe créés auparavant si et seulement si l'identifiant utilisateur est
4693 dans l'intervalle des identifiants d'utilisateur système assignés
4694 dynamiquement et si l'identifiant de groupe appartient à un groupe
4701 # Trouve les premier et dernier numéros SYSTEM_UID
4702 for LINE in `grep SYSTEM_UID /etc/adduser.conf | grep -v "^#"`; do
4705 FIST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
4708 LAST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
4714 # Supprime le compte système si nécessaire
4715 CREATEDUSER="<var>server_user</var>"
4716 if [ -n "$FIST_SYSTEM_UID" ] && [ -n "$LAST_SYSTEM_UID" ]; then
4717 if USERID=`getent passwd $CREATEDUSER | cut -f 3 -d ':'`; then
4718 if [ -n "$USERID" ]; then
4719 if [ "$FIST_SYSTEM_UID" -le "$USERID" ] && \
4720 [ "$USERID" -le "$LAST_SYSTEM_UID" ]; then
4721 echo -n "Removing $CREATEDUSER system user.."
4722 deluser - -quiet $CREATEDUSER || true
4728 # Supprime le groupe système si nécessaire
4729 CREATEDGROUP=<var>server_group</var>
4730 FIRST_USER_GID=`grep ^USERS_GID /etc/adduser.conf | cut -f2 -d '='`
4731 if [ -n "$FIST_USER_GID" ] then
4732 if GROUPGID=`getent group $CREATEDGROUP | cut -f 3 -d ':'`; then
4733 if [ -n "$GROUPGID" ]; then
4734 if [ "$FIST_USER_GID" -gt "$GROUPGID" ]; then
4735 echo -n "Removing $CREATEDGROUP group.."
4736 delgroup - -only-if-empty $CREATEDGROUP || true
4745 <p>Exécuter des programmes avec un utilisateur ayant des privilèges
4746 limités garantit que tout problème de sécurité du programme n'entraînera
4747 que des dommages limités au système et cela suit le principe du <em>moindre
4748 privilège</em>, vous pouvez limiter les privilèges dans les programmes
4749 par d'autres mécanismes en plus de le faire s'exécuter en tant que
4750 non-superutilisateur. Pour plus d'informations, lisez le chapitre <url
4751 id="http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/minimize-privileges.html"
4752 name="Minimize Privileges"> du livre <em>Secure Programming for Linux
4753 and Unix HOWTO</em>.
4760 <sect id="bpp-config-mgmt">
4761 <heading>Gestion de la configuration avec <package>debconf</package></heading>
4765 <package>Debconf</package> est un système de gestion de configuration qui
4766 peut être utilisé par les divers scripts de maintenance (principalement
4767 en post-installation dans le fichier <file>postinst</file>) pour demander à
4768 l'utilisateur des informations concernant la configuration du paquet. Il
4769 faut maintenant éviter les interactions directes avec l'utilisateur et
4770 préférer les interactions utilisant <package>debconf</package>. Ceci permettra
4771 à l'avenir des installations non interactives.
4773 Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs erreurs
4774 communes sont référencées dans la page de manuel <manref section="7"
4775 name="debconf-devel">. Vous devriez vraiment lire cette page si vous décidez
4776 d'utiliser debconf. Nous documentons également plusieurs des meilleures
4779 Ces lignes directives incluent plusieurs recommandations de style d'écriture et
4780 de typographie, des considérations générales à propos de l'utilisation de
4781 debconf ainsi que des recommandations plus spécifiques pour certaines parties de
4782 la distribution (par exemple, le système d'installation).
4784 <sect1>N'abusez pas de debconf
4786 Depuis que debconf est apparu dans Debian, il a été largement abusé et plusieurs
4787 critiques reçues par la distribution Debian proviennent d'utilisation abusive de
4788 debconf avec la nécessité de répondre à un grand nombre de questions avant
4789 d'avoir n'importe quel petit logiciel d'installé.
4791 Garder les notes d'utilisation à leur place : le fichier NEWS.Debian ou le
4792 fichier README.Debian. N'utilisez des notes que pour des notes importantes
4793 qui peuvent directement concerner l'utilisation du paquet. Rappelez-vous que les
4794 notes bloqueront toujours l'installation avant leur confirmation ou qu'elles
4795 embêtent l'utilisateur par un courriel.
4797 Choisissez avec soin les priorités des questions dans les scripts de
4798 responsable. Reportez-vous à <manref name="debconf-devel" section="7"> pour plus
4799 de détails sur les priorités. La plupart des questions devraient utiliser un
4800 priorité moyenne ou basse.
4802 <sect1>Recommandations générales pour les auteurs et traducteurs
4804 <sect2>Écrivez un anglais correct
4806 La plupart des responsables de paquets Debian n'ont pas l'anglais comme langue
4807 maternelle. Écrire des modèles correctement rédigés peut donc ne pas être facile
4810 Veuillez utiliser (et abuser de) la liste de discussions
4811 &email-debian-l10n-english;. Faites relire vos questionnaires.
4813 Des questionnaires écrits incorrectement donnent une pauvre image de votre paquet,
4814 de votre travail... ou même de Debian elle-même.
4816 Évitez le jargon technique autant que possible. Si certains termes vous semblent
4817 courants, ils peuvent être impossibles à expliquer à d'autres personnes. Si vous
4818 ne pouvez pas les éviter, essayez de les expliquer (en utilisant la description
4819 étendue). Quand vous faites cela, essayez d'équilibrer la verbosité et la
4822 <sect2>Être courtois avec les traducteurs
4824 Les questionnaires debconf peuvent être traduits. Debconf, avec son paquet-frêre
4825 <package>po-debconf</package>, offre un cadre de travail simple pour obtenir des questionnaires
4826 traduits par les équipes de traduction ou même par des individus isolés.
4828 Veuillez utiliser les questionnaires basés sur gettext. Installez <package>po-debconf</package> sur
4829 votre système de développement et lisez sa documentation (« man
4830 po-debconf » est un bon début).
4832 Évitez de changer vos questionnaires trop souvent. Modifier le texte des
4833 questionnaires entraîne plus de travail pour les traducteurs dont les
4834 traductions seront rendues « floues » (« fuzzy »). Si vous
4835 prévoyez des modifications dans vos questionnaires d'origine, veuillez contacter
4836 les traducteurs. La plupart des traducteurs actifs sont très réactifs et obtenir
4837 leur travail inclus avec vos questionnaires modifiés vous économisera des envois
4838 supplémentaires. Si vous utilisez des modèles basés sur gettext, le nom et
4839 l'adresse électronique du traducteur sont mentionnés dans les en-têtes des
4842 L'utilisation de <prgn>podebconf-report-po</prgn> du paquet
4843 <package>po-debconf</package> est hautement recommandée pour avertir les
4844 traducteurs qui ont des traductions incomplètes et pour leur demander
4847 En cas de doutes, vous pouvez également contacter l'équipe de traduction pour
4848 une langue donnée (debian-l10n-xxxxx@lists.debian.org) ou la liste de discussions
4849 &email-debian-i18n;.
4851 Les appels à traductions postés sur &email-debian-i18n; avec le fichier
4852 <file>debian/po/templates.pot</file> attaché ou référencé dans une URL
4853 sont encouragés. Assurez-vous de mentionner dans ces appels pour de
4854 nouvelles traductions quelles sont les langues pour lesquelles vous avez
4855 déjà des traductions existantes, pour éviter toute duplication de
4858 <sect2>« Dé-fuzzy-fiez » les traductions complètes lors des
4859 corrections de typos et d'orthographe
4861 Quand le texte d'un questionnaire debconf est corrigé et que vous êtes
4862 <strong>certain</strong> que les changements <strong>n'ont aucun</strong>
4863 effet sur les traductions, soyez courtois avec les traducteurs et
4864 dé-fuzzy-fiez leurs traductions.
4866 Si vous ne le faites pas, le questionnaire entier ne sera pas traduit
4867 jusqu'à ce qu'un traducteur vous envoie une mise à jour.
4869 Pour <strong>dé-fuzzy-fier</strong> les traductions, vous pouvez
4870 procéder ainsi :
4873 enlevez tous les fichiers PO incomplets. Vous pouvez vérifier si les
4874 fichiers sont complets en utilisant (il faut que le paquet
4875 <package>gettext</package> soit installé) :
4876 <example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done</example>
4878 déplacez tous les fichiers ayant des chaînes floues
4879 (« fuzzy ») dans un emplacement temporaire. Les fichiers
4880 n'ayant aucune chaîne floue (seulement des chaînes traduites et non
4881 traduites) seront conservées où ils sont placés,
4883 maintenant <strong>et seulement maintenant</strong>, corrigez les typos
4884 dans le questionnaire et vérifiez que les traductions ne sont pas
4885 impactées (les typos, les fautes d'orthographe et parfois les
4886 corrections de typographie sont généralement acceptables),
4888 exécutez <prgn>debconf-updatepo</prgn>. Cela va fuzzifier toutes les
4889 chaînes que vous avez modifiées dans les traductions. Vous pouvez
4890 constater cela en exécutant à nouveau la commande ci-dessus,
4892 utilisez la commande suivante :
4893 <example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
4895 déplacez dans debian/po les fichiers qui avaient des chaînes floues dans
4898 exécutez à nouveau <prgn>debconf-updatepo</prgn>.
4901 <sect2>Ne faites pas de suppositions à propos des interfaces
4903 Le texte des modèles ne doit pas faire référence aux composants appartenant à
4904 l'une des interfaces debconf. Des phrases comme « If you answer
4905 Yes... » n'a aucun sens pour les utilisateurs d'interfaces graphiques qui
4906 utilisent des cases à cocher pour les questions booléennes.
4908 Les modèles de chaînes de caractères devraient éviter de mentionner les
4909 valeurs par défaut dans leur description. Tout d'abord, parce que cela
4910 est redondant avec les valeurs lues par les utilisateurs. Ensuite, parce
4911 ces valeurs par défaut peuvent être différentes selon les choix du
4912 responsable (par exemple, quand la base de données debconf a été
4915 Plus généralement, essayez d'éviter de vous référer à toute action de
4916 l'utilisation. Donnez simplement des faits.
4918 <sect2>N'utilisez pas la première personne
4920 Vous devriez éviter d'utiliser la première personne (« I will do
4921 this... » ou « We recommend... »). L'ordinateur n'est pas une
4922 personne et les questionnaires debconf ne parlent pas pour les développeurs
4923 Debian. Vous devriez utiliser une construction neutre et souvent une forme
4924 passive. Pour ceux d'entre vous qui écrivent déjà des publications
4925 scientifiques, écrivez simplement vos questionnaires comme vous écriveriez un
4926 papier scientifique.
4928 <sect2>Soyez neutre dans le genre
4930 Le monde est fait d'hommes et de femmes. Veuillez utiliser des constructions
4931 neutres dans le genre dans votre texte. Ce n'est pas du politiquement correct,
4932 c'est simplement montrer du respect pour toute l'humanité.
4935 <sect1>Définition des champs de questionnaires
4937 Cette partie donne plusieurs informations qui sont principalement extraites de
4938 la page de manuel <manref name="debconf-devel" section="7">.
4943 <sect3>string: (chaîne de caractères)
4945 Résulte en un champ d'entrée libre dans lequel l'utilisateur peut écrire toute chaîne.
4947 <sect3>password: (mot de passe)
4949 Demande un mot de passe à l'utilisateur. Veuillez utiliser ce champ avec
4950 précaution ; soyez conscient que le mot de passe que l'utilisateur entre
4951 sera écrit dans la base de données debconf. Vous devriez probablement enlever
4952 cette valeur de la base de données dès que possible.
4954 <sect3>boolean: (booléen)
4956 Un choix vrai/faux. Rappelez-vous : vrai/faux, PAS OUI/NON...
4958 <sect3>select: (sélection)
4960 Un choix parmi un certain nombre de valeurs. Les choix doivent être spécifiés
4961 dans un champ nommé « Choices ». Séparez les valeurs possibles par des
4962 virgules et des espaces ainsi : Choices: yes, no, maybe
4964 <sect3>multiselect: (sélection multiple)
4966 Comme le type de données select, excepté que l'utilisateur peut choisir un
4967 nombre quelconque d'éléments dans la liste de choix (ou aucun d'entre eux).
4971 Plutôt que d'être une question en tant que telle, ce type de donnée indiqué une
4972 note qui peut être affichée à l'utilisateur. Il ne devrait être utilisé que
4973 pour des données importantes que l'utilisateur doit réellement voir, car debconf
4974 fera tout ce qu'il peut pour s'assurer que l'utilisateur le voit ; il
4975 stoppera l'installation en attendant que l'utilisateur appuie sur une touche ou
4976 il leur enverra même la note par courrier dans certains cas.
4978 <sect3>text: (texte)
4980 Ce type est maintenant considéré comme obsolète : ne l'utilisez pas.
4982 <sect3>error: (erreur)
4984 <strong>CE TYPE DE MODÈLE N'EST PAS ENCORE GÉRÉ PAR DEBCONF.</strong>
4986 Il a été ajouté à cdebconf, la version C de debconf, utilisé en premier dans
4987 l'installateur Debian.
4989 Veuillez ne pas l'utiliser à moins que debconf ne le prennent en charge.
4991 Ce type est conçu pour gérer des messages d'erreur. Il est presque semblable au
4992 type « note ». Des interfaces peuvent le présenter différemment (par
4993 exemple, l'interface dialog de cdebconf affiche un écran rouge au lieu de
4994 l'écran bleu habituel).
4997 <sect2>Description: description courte et étendue
4999 Les descriptions des modèles sont composées de deux parties : une courte et
5000 une étendue. La description courte est dans la ligne « Description: »
5003 La description courte devrait être gardée courte (50 caractères ou moins)
5004 pour qu'elle puisse être ajustée par la plupart des interfaces debconf. La
5005 garder courte aide également les traducteurs, car les traductions ont tendance à
5006 être plus longues que l'originale.
5008 La description courte devrait se suffire à elle-même. Certaines interfaces
5009 n'affichent pas la description longue par défaut ou seulement si l'utilisateur
5010 la demande explicitement ou même ne l'affichent pas du tout. Évitez des choses
5011 comme « What do you want to do ? ».
5013 Il n'est pas nécessaire que la description courte soit une phrase complète. Cela
5014 fait partie de la recommandation « gardez-la courte et efficace ».
5016 La description étendue ne devrait pas répéter la description courte mot pour mot.
5017 Si vous ne trouvez pas de description longue, commencez par à y réfléchir plus.
5018 Envoyez un message sur debian-devel. Demandez de l'aide. Suivez un cours
5019 d'écriture ! La description étendue est importante. Si, après tout cela,
5020 vous ne trouvez toujours rien, laissez-la vide.
5022 La description étendue devrait utiliser des phrases complètes. Des paragraphes
5023 devraient être gardés court pour améliorer la lisibilité. Ne mélangez pas deux
5024 idées dans le même paragraphe, mais utilisez plutôt un autre paragraphe.
5026 Ne soyez pas trop verbeux. Certaines interfaces debconf ne gèrent pas très bien
5027 les descriptions de plus de 20 lignes, essayez donc de les conserver sous
5030 Pour des règles spécifiques selon le type de questionnaire (chaîne de
5031 caractères, booléen, etc.), veuillez lire ci-dessous.
5033 <sect2>Choices (choix)
5035 Ce champ devrait utilisé pour des types Select et Multiselect. Il contient les
5036 choix possibles qui seront présentés aux utilisateurs. Ces choix devraient être
5037 séparés par des virgules.
5040 <sect2>Default (valeur par défaut)
5042 Ce champ est facultatif. Il contient la réponse par défaut pour les modèles
5043 chaîne de caractères, sélection et multi-sélection. Pour des questionnaires
5044 multi-sélection, il peut contenir une liste de choix séparés par des virgules.
5046 <sect1>Guide de style spécifique par champ de questionnaires
5051 Aucune indication spécifique excepté : utilisez le type approprié en vous
5052 référant à la section précédente.
5054 <sect2>Champ Description
5056 Voici ci-dessous des instructions spécifiques pour écrire correctement la
5057 description (courte et étendue) selon le type de questionnaire.
5059 <sect3>questionnaire chaîne de caractères/mot de passe
5062 <item> La description courte est une invite et NON un titre. Évitez des invites
5063 de style question (« IP Address? ») en faveur d'invites
5064 « ouvertes »à (« IP address: »). L'utilisation des
5065 deux-points est recommandée.
5067 <item> La description étendue est un complément à la description courte. Dans la
5068 partie étendue, expliquez ce qui est demandé, plutôt que de poser la même
5069 question à nouveau en utilisant des mots plus longs. Utilisez des phrases
5070 complètes. Un style d'écriture trop concis est fortement découragé.
5073 <sect3>modèles booléens
5076 <item> La description courte devrait être rédigée sous la forme d'une question
5077 qui devrait être gardée courte et devrait généralement se termier par un
5078 point d'interrogation. Un style d'écriture concis est permis et même
5079 encouragé si la question est plutôt longue (rappelez-vous que les
5080 traductions sont souvent plus longue que les versions d'origine)
5082 <item> La description étendue ne devrait PAS inclure de question.
5084 <item> À nouveau, veuillez éviter de vous référer à des composants d'interface
5085 spécifiques. Une erreur courante pour de telles questionnaires est les
5086 constructions du type « if you answer Yes ».
5089 <sect3>sélection/multi-sélection
5092 <item> La description courte est une invite et NON un titre. N'utilisez PAS des
5093 constructions inutiles du type « Please choose... ». Les
5094 utilisateurs sont assez intelligents pour réaliser qu'ils doivent choisir
5097 <item> La description étendue devra compléter la description courte. Elle peut se
5098 référer aux choix disponibles. Elle peut également mentionner que
5099 l'utilisateur peut choisir plus d'un des choix disponibles si le
5100 questionnaire est du type sélection multiple (bien que l'interface rende
5101 soivent cela clair).
5107 <item> La description courte devrait être considéré comme un *titre*.
5109 <item> La description étendue est ce qui sera affiché comme une description plus
5110 détaillée de la note. Faites de phrases, n'utilisez pas un style d'écriture
5113 <item> N'ABUSEZ PAS DE DEBCONF. Les notes sont le moyen le plus courant d'abus
5114 de debconf. Comme il est écrit dans la page de manuel de
5115 debconf-devel : il est préférable de ne les utiliser que pour des
5116 avertissements à propos de problèmes très sérieux. Les fichiers NEWS.Debian
5117 ou README.Debian sont les endroits appropriés pour un grand nombre de notes.
5118 Si, en lisant ceci, vous envisagez de convertir vos modèles de type note en
5119 entrées dans NEWS/Debian ou README.Debian, veuillez considérer de conserver
5120 les traductions existantes pour une utilisation future.
5124 <sect2>Champ de choix
5126 S'il est probable que les choix changent souvent, veuillez considérer
5127 l'utilisation de l'astuce « __Choices ». Cela séparera chaque choix
5128 individuel en une chaîne de caractères seule, ce qui aidera considérablement les
5129 traducteurs à faire leur travail.
5131 <sect2>Champ par défaut
5133 S'il est probable que la valeur par défaut d'un modèle « select »
5134 change selon la langue de l'utilisateur (par exemple, s'il s'agit d'un choix de
5135 langue), veuillez utiliser l'astuce « _DefaultChoice ».
5137 Ce champ spécial permet aux traducteurs de positionner le choix le plus
5138 approprié selon leur propre langue. Cela deviendra le choix par défaut quand
5139 leur langue sera sélectionné alors votre choix par défaut sera utilisé pour
5142 Un exemple tiré des modèles du paquet geneweb :
5144 Template: geneweb/lang
5146 __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)
5147 # This is the default choice. Translators may put their own language here
5148 # instead of the default.
5149 # WARNING : you MUST use the ENGLISH FORM of your language
5150 # For instance, the french translator will need to put "French (fr)" here.
5151 _DefaultChoice: English (en)[ translators, please see comment in PO files]
5152 _Description: Geneweb default language:
5155 Notez l'utilisation de crochets qui permettent des commentaires internes dans
5156 les champs debconf. Notez également l'utilisation de commentaires qui
5157 apparaîtront dans les fichiers sur lesquels travailleront les traducteurs.
5159 Les commentaires sont nécessaires car l'astuce DefaultChoice est un peu
5160 déroutante : les traducteurs peuvent y placer leur propre choix.
5162 <sect2>Champ par défaut
5164 N'utilisez PAS de champ par défaut vide. Si vous ne voulez pas utiliser de
5165 valeurs par défaut, n'utilisez pas simplement pas du tout Default.
5167 Si vous utilisez po-debconf (et vous DEVRIEZ le faire, voir 2.2), veuillez
5168 considérer de rendre ce champ traduisible, si vous pensez qu'il peut être
5171 Si la valeur par défaut peut varier selon la langue ou le pays (par exemple, la
5172 valeur par défaut pour un choix de langue), veuillez considérer l'utilisation du
5173 type spécial « _DefaultChoice » documenté dans <manref
5174 name="po-debconf" section="7">).
5178 <sect id="bpp-i18n">
5179 <heading>Internationalisation</heading>
5183 <sect1 id="bpp-i18n-debconf">Gestion des traductions de
5186 Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur
5187 un grand nombre de paquets et doivent donc collaborer avec plusieurs
5188 responsables différents. De plus, la plupart du temps, l'anglais n'est pas leur
5189 langue maternelle, il se peut que vous deviez être particulièrement patient
5192 Le but de <package>debconf</package> était de faciliter la configuration des
5193 paquets aux responsables et aux utilisateurs. À l'origine, les
5194 traductions des questionnaires debconf étaient gérées avec
5195 <prgn>debconf-mergetemplate</prgn>. Cependant, cette technique est maintenant
5196 déconseillée ; la meilleure façon pour l'internationalisation de
5197 <package>debconf</package> est d'utiliser le paquet
5198 <package>po-debconf</package>. Cette méthode est plus facile pour le
5199 responsable et pour les traducteurs ; des scripts de transition sont
5202 Lors de l'utilisation de <package>po-debconf</package>, la traduction est
5203 stockée dans des fichiers <file>po</file> (à l'instar des techniques de
5204 traduction de <prgn>gettext</prgn>). Des fichiers modèles contiennent les
5205 messages d'origine et indiquent quels sont les champs traduisibles. Quand vous
5206 modifiez l'état d'un champ traduisible en appelant
5207 <prgn>debconf-updatepo</prgn>, la traduction est marquée comme ayant besoin de
5208 l'attention des traducteurs. Puis, lors de la construction du paquet, le
5209 programme <prgn>dh_installdebconf</prgn> prendra soin de toute la magie
5210 nécessaire à l'ajout du modèle avec les traductions à jour dans les paquets
5211 binaires. Veuillez vous reporter à la page de manuel <manref name="po-debconf"
5212 section="7"> pour les détails.
5215 <sect1 id="bpp-i18n-docs">
5216 <heading>Documentation traduite</heading>
5218 La traduction de la documentation est cruciale pour les utilisateurs, mais elle
5219 représente un important travail. Il n'existe aucun moyen d'éliminer ce travail,
5220 mais vous pouvez faciliter les choses pour les traducteurs.
5222 Si vous êtes responsable d'une documentation quelle que soit sa taille, il est
5223 plus facile pour les traducteurs d'avoir accès à un système de contrôle de
5224 source. Ceci permet aux traducteurs de voir les différences entre deux versions
5225 de la documentation, pour, par exemple, qu'ils puissent voir ce qui a besoin
5226 d'être retraduit. Il est recommandé que le document traduit inclue une note à
5227 propos de la révision de contrôle du source sur laquelle la traduction est
5228 basée. Un système intéressant est fourni par <url id="&url-i18n-doc-check;"
5229 name="doc-check"> dans le paquet <package>boot-floppies</package> qui donne un
5230 aperçu de l'état de la traduction pour une langue donnée, en utilisant les
5231 commentaires structurés pour une révision donnée du fichier à traduire et, pour
5232 un fichier traduit, la révision du fichier d'origine sur laquelle la traduction
5233 est basée. Vous pouvez vouloir adapter et fournir ceci dans votre référentiel CVS.
5235 Si vous maintenez de la documentation au format XML ou SGML, nous vous suggérons
5236 d'isoler les informations indépendantes de la langue et de les définir
5237 comme des entités dans un fichier séparé qui sera inclus par les différentes
5238 traductions. Ceci aide, par exemple, à garder à jour les adresses pour
5244 <sect id="bpp-common-situations">
5245 <heading>Pratiques communes d'empaquetage</heading>
5248 <sect1 id="bpp-kernel">Kernel modules/patches
5251 &FIXME; Heavy use of kernel-package. provide files in
5252 /etc/modutils/ for module configuration.
5255 <sect1 id="bpp-autotools">
5256 <heading>Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
5258 Conserver à jour les fichiers d'<prgn>autoconf</prgn>, <file>config.sub</file>
5259 et <file>config.guess</file>, est critique pour les porteurs, spécialement pour
5260 les architectures plus changeantes. De très bonnes pratiques d'empaquetage
5261 utilisant <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été regroupées
5262 dans &file-bpp-autotools; du paquet <package>autotools-dev</package>. Vous êtes
5263 vivement encouragé à lire ce fichier et à suivre les recommandations indiquées.
5266 <sect1 id="bpp-libraries">Bibliothèques
5268 Pour diverses raisons, il a toujours été difficile d'empaqueter les
5269 bibliothèques. La charte impose plusieurs contraintes pour faciliter la maintenance
5270 et pour garantir que les mises à jour sont aussi simples que possible quand une
5271 nouvelle version amont est disponible. Une erreur dans une bibliothèque peut
5272 rendre défectueux une douzaine de paquets qui en dépendent.
5274 Les bonnes pratiques d'empaquetage des bibliothèques ont été regroupées dans
5275 <url id="&url-libpkg-guide;" name="le guide d'empaquetage des
5278 <sect1 id="bpp-docs">Documentation
5280 Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html"
5281 name="règles sur la documentation">.</p>
5283 Si votre paquet contient de la documentation construite à partir de XML ou SGML,
5284 nous vous recommandons de ne pas fournir le source XML ou SGML dans le(s)
5285 paquet(s) binaire(s). Si les utilisateurs désirent avoir le source de la
5286 documentation, ils peuvent récupérer le paquet source.</p>
5288 La charte spécifie que la documentation doit être fournie au format HTML.
5289 Nous vous recommandons également de la fournir au format PDF et texte simple si
5290 c'est adapté et qu'une sortie de qualité est possible. Cependant, il n'est
5291 généralement pas approprié de fournir des versions en texte simple pour la
5292 documentation dont le format source est du HTML.</p>
5294 Les principaux manuels fournis devraient être enregistrés par le paquet
5295 <package>doc-base</package> à l'installation. Reportez-vous à la documentation
5296 du paquet <package>doc-base</package> pour plus d'information.</p>
5300 <sect1 id="bpp-other">Types spécifiques de paquets
5302 Plusieurs types spécifiques de paquets ont des sous-chartes spéciales et des
5303 règles et pratiques d'empaquetage correspondantes :
5306 Les paquets liés à Perl ont leur <url id="&url-perl-policy;" name="charte
5307 Perl">, quelques exemples de paquets qui suivent cette charte sont
5308 <package>libdbd-pg-perl</package> (module perl binaire) ou
5309 <package>libmldbm-perl</package> (module perl indépendant de
5313 Les paquets liés à Python ont leur charte Python ; voir
5314 &file-python-policy; dans le paquet <package>python</package>.
5317 Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;"
5318 name="charte Emacs">.
5321 Les paquets liés à Java ont leur <url id="&url-java-policy;" name="charte
5325 Les paquets liés à Ocaml ont leur propre charte que l'on trouve dans
5326 &file-ocaml-policy; du paquet <package>ocaml</package>. Un bon exemple est
5327 le paquet source <package>camlzip</package>.
5330 Les paquets fournissant des DTDs XML ou SGML devraient se conformer aux
5331 recommandations que l'on peut trouver dans le paquet
5332 <package>sgml-base-doc</package>
5334 Les paquets Lisp devraient s'enregistrer avec le paquet
5335 <package>common-lisp-controller</package> pour lequel vous pouvez vous
5336 reporter au fichier &file-lisp-controller;.
5337 <!-- TODO: mozilla extension policy, once that becomes available -->
5342 <sect1 id="bpp-archindepdata">Données indépendantes de l'architecture
5344 Il n'est pas rare d'avoir une grande quantité de données indépendantes de
5345 l'architecture fournie avec un programme. Par exemple, des fichiers
5346 audio, une collection d'icônes, des motifs de papiers peints ou autres
5347 fichiers graphiques. Si la taille des données est négligeable par
5348 rapport à la taille du reste du paquet, il est probablement mieux de
5349 tout garder dans le même paquet.
5352 Cependant, si la taille des données est considérable, vous devez
5353 envisager de les partager dans un paquet séparé et indépendant de
5354 l'architecture (« _all.deb »). Ainsi, en faisant cela, vous
5355 évitez une duplication inutile des mêmes données dans onze fichiers
5356 .debs pour chaque architecture. Bien que ceci ajoute une surcharge
5357 supplémentaire aux fichiers <file>Packages</file>, ceci sauve beaucoup
5358 d'espace disque sur les miroirs Debian. Séparer les données
5359 indépendantes de l'architecture réduit également le temps de traitement
5360 de <prgn>lintian</prgn> ou de <prgn>linda</prgn> (voir <ref
5361 id="tools-lint">) quand ils sont exécutés sur l'ensemble de l'archive
5365 <sect1 id="bpp-locale">
5366 <heading>Avoir besoin d'une certaine locale pendant la construction</heading>
5368 Si vous avez besoin d'une certaine locale pendant la construction, vous pouvez
5369 créer un fichier temporaire par cette astuce :
5371 Si vous positionnez LOCPATH à l'équivalent de /usr/lib/locale, et LC_ALL au nom
5372 de la locale que vous générez, vous devriez obtenir ce que vous voulez sans être
5373 root. Quelque chose comme ceci :
5376 LOCALE_PATH=debian/tmpdir/usr/lib/locale
5378 LOCALE_CHARSET=UTF-8
5380 mkdir -p $LOCALE_PATH
5381 localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
5384 LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
5388 <sect1 id="bpp-transition">
5389 <heading>Rendre les paquets de transition conformes avec deborphan</heading>
5391 Deborphan est un programme pour aider les utilisateurs à détecter quels paquets
5392 peuvent être enlevés sans problème du système, i.e. ceux dont aucun paquet ne
5393 dépend. L'opération par défaut est de chercher seulement parmi les sections libs
5394 et oldlibs pour débusquer les bibliothèques inutilisées. Mais si l'on passe le
5395 bon argument, il tente d'attraper d'autres paquets inutiles.
5397 Par exemple, avec --guess-dummy, deborphan cherche tous les paquets de transition qui
5398 étaient nécessaires pour une mise à jour, mais qui peuvent sans problème être
5399 supprimés. Pour cela, il recherche la chaîne de caractères « dummy »
5400 ou « transitional » dans la description courte.
5402 Ainsi, quand vous créez un tel paquet, assurez-vous d'ajouter ce texte dans la
5403 description courte. Si vous cherchez des exemples, exécutez simplement :
5404 <example>apt-cache search .|grep dummy</example> or
5405 <example>apt-cache search .|grep transitional</example>.
5408 <sect1 id="bpp-origtargz">
5409 <heading>Les meilleures pratiques pour les fichiers <file>orig.tar.gz</file></heading>
5411 Il existe deux types d'archives tar (« tarball ») source
5412 d'origine : les sources vierges et les sources amont réempaquetées.
5414 <sect2 id="pristine source">
5415 <heading>Sources vierges</heading>
5417 La caractéristique définissant une archive source vierge est que le
5418 fichier .orig.tar.gz est identique octet-pour-octet à l'archive tar
5419 officielle distribuée par l'auteur amont.
5421 Nous ne pouvons pas empêcher les auteurs amont de changer l'archive tar
5422 qu'ils distribuent sans également incrémenter le numéro de version, il
5423 ne peut donc pas y avoir de garantie qu'une archive vierge est identique
5424 à ce que l'auteur amont distribue <em>actuellement</em> à tout moment.
5425 La seule chose à laquelle on peut s'attendre est que c'est identique à
5426 quelque chose que l'amont <em>a</em> un jour distribué.
5428 Si une différence se produit plus tard (par exemple, si l'amont remarque
5429 qu'il n'a pas utilisé la compression maximale pour sa distribution
5430 d'origine et qu'il la recompresse), c'est vraiment trop dommage.
5431 Comme il n'y a pas de bonne façon d'envoyer un nouveau .orig.tar.gz
5432 pour la même version, il n'y a même pas de raison de traiter cette
5433 situation comme un bogue.
5435 Cela rend possible d'utiliser des vérifications de somme pour vérifier
5436 facilement que tous les changements entre la version Debian et celle de
5437 l'amont sont contenus dans le fichier diff Debian. Également, si le source
5438 amont est énorme, les auteurs amont et d'autres qui ont déjà l'archive
5439 tar amont peuvent économiser du temps de téléchargement s'ils veulent
5440 inspecter votre empaquetage en détail.
5443 Il n'y a pas de règles universellement acceptées suivies par les auteurs
5444 amont concernant la structure des répertoires dans leur archive tar, mais
5445 <prgn>dpkg-source</prgn> est cependant capable de traiter la plupart des
5446 archives tar comme source vierge. Sa stratégie est équivalente à la
5452 Il décompacte l'archive tar dans un répertoire temporaire vide par
5455 zcat path/to/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf -
5459 Si, après cela, le répertoire temporaire ne contient qu'un
5460 répertoire et pas d'autres fichiers, <prgn>dpkg-source</prgn> renomme ce
5462 <tt><packagename>-<version-amont>(.orig)</tt>. Le nom du
5463 répertoire de premier niveau dans l'archive tar n'a pas d'importance et
5467 Sinon, l'archive tar a du être empaqueté sans répertoire de premier
5468 niveau commun (honte à l'auteur amont !). Dans ce cas,
5469 <prgn>dpkg-source</prgn> renomme le répertoire temporaire
5470 <em>lui-même</em> en
5471 <tt><packagename>-<version-amont>(.orig)</tt>.
5476 <sect2 id="repackaged origtargz">
5477 <heading>Réempaquetage des sources amonts</heading>
5479 Vous <strong>devriez</strong> envoyer des paquets sources avec une
5480 archive tar vierge si possible, mais il peut y avoir diverses raisons
5481 pour lesquelles cela n'est pas possible. C'est le cas si l'amont ne
5482 distribue pas le source comme un tar gzipé du tout ou si l'archive tar
5483 amont contient du matériel non libre au sens des DFSG que vous devez
5484 supprimer avant l'envoi.
5487 Dans tous ces cas, le développeur doit construire un fichier
5488 .orig.tar.gz convenable lui-même. Nous nous référérons à une telle
5489 archive tar comme un « source amont réempaqueté ». Notez qu'un
5490 « source amont réempaqueté » est différent d'un paquet natif
5491 Debian. Un source réempaqueté est toujours fourni avec des changements
5492 spécifiques Debian dans un fichier <tt>.diff.gz</tt> séparé et il a
5493 toujours un numéro de version composé de <tt><source-amont></tt>
5494 et de <tt><debian-revision></tt>.
5497 Il peut y avoir des cas où il est désirable de réempaqueter le source
5498 même si l'amont distribue un fichier <tt>.tar.gz</tt> qui pourrait en
5499 principe être utilisé dans sa forme vierge. Le plus évident est si des
5500 économies d'espaces <em>significatives</em> peuvent être réalisées en
5501 recompressant l'archive tar ou en supprimant des parties
5502 fondamentalement inutiles de l'archive source. Agissez à votre guise à
5503 cet endroit, mais soyez prêt à défendre votre décision si vous
5504 réempaquetez un source qui aurait pu être vierge.
5507 Un .orig.tar.gz réempaqueté :
5513 <strong>doit</strong> contenir des informations détaillées sur la façon
5514 dont a été obtenu le source réempaqueté et comment cela peut être
5515 reproduit dans le fichier <file>README.Debian-source</file> ou un
5516 fichier similaire. Ce fichier devrait être dans la partie
5517 <file>diff.gz</file> du paquet source Debian, habituellement dans le
5518 répertoire <file>debian</file>, <em>pas</em> dans le
5519 <file>orig.tar.gz</file> réempaqueté. C'est également une bonne idée de
5520 fournir une cible <tt>get-orig-source</tt> dans votre fichier
5521 <file>debian/rules</file> qui répète le processus, comme décrit dans la
5522 Charte, <url id="&url-debian-policy;ch-source.html#s-debianrules"
5523 name="debian/rules, le principal script de construction">.
5527 <strong>ne devrait pas</strong> contenir de fichiers qui ne viennent pas de
5528 l'auteur amont ou dont vous avez changé le contenu.
5530 Comme exception spéciale, si l'omission d'un fichier non libre
5531 entraînerait l'échec de la compilation du source sans assistance du diff
5532 Debian, il peut être approprié au lieu de cela d'éditer les fichiers, en
5533 omettant seulement les parties non libres de ceux-ci et/ou d'expliquer
5534 la situation dans un fichier README.Debian-source <!-- ou nommé de -->
5535 <!-- manière similaire --> à la racine de l'arborescence du source. Mais
5536 dans ce cas, veuillez également demander instamment à l'auteur amont de
5537 faciliter la séparation des composants non libres du reste du source.
5542 <strong>devrait</strong>, sauf cas impossible pour des raisons légales,
5543 préserver l'infrastructure de construction entière et de portabilité
5544 fournie par l'auteur amont. Par exemple, ce n'est pas une raison
5545 suffisante pour omettre un fichier qui n'est utilisé que pour la
5546 construction sur MS-DOS. De manière similaire, un Makefile fourni par
5547 l'amont ne devrait pas être réécrit en exécutant un script configure.
5550 (<em>Explication :</em> il est courant que les utilisateurs Debian qui
5551 ont besoin de reconstruire un logiciel pour des plates-formes non-Debian
5552 récupèrent le source d'un miroir Debian plutôt que de chercher à
5553 localiser un point de distribution amont).
5556 <strong>devrait</strong> utiliser
5557 <tt><nom-du-paquet>-<version-amont>.orig</tt> comme nom du
5558 répertoire de premier niveau dans son archive tar. Cela rend
5559 possible la distinction entre des archives tar vierges d'archives
5563 <strong>devrait</strong> être gzipé avec une compression maximale.
5568 La façon canonique de réaliser les deux derniers points est de laisser
5569 <tt>dpkg-source -b</tt> construire l'archive tar réempaquetée à partir
5570 du répertoire décompacté.
5573 <sect2 id="changed-binfiles">
5574 <heading>Changer des fichiers binaires dans le <tt>diff.gz</tt></heading>
5576 Il est parfois nécessaire de changer des fichiers binaires
5577 contenus dans l'archive tar d'origine ou d'ajouter des fichiers binaires
5578 qui ne sont pas dans celle-ci. Si cela est fait en copiant simplement les
5579 fichiers dans l'arborescence de l'archive debianisée,
5580 <prgn>dpkg-source</prgn> ne pourra pas gérer cela. D'un autre côté,
5581 selon les règles détaillées ci-dessus, vous ne pouvez pas inclure un tel
5582 fichier binaire modifié dans un fichier <file>orig.tar.gz</file>
5583 réempaqueté. Au lieu de cela, incluez le fichier dans le répertoire
5584 <file>debian</file> dans un format <prgn>uuencode</prgn> (ou semblable)
5586 Le fichier devrait avoir un nom qui indique clairement quel fichier
5587 binaire il encode. Habituellement, un postfixe indiquant le codage
5588 devrait être ajouté au nom du fichier d'origine.
5590 Le fichier sera ensuite décodé et copié à son emplacement pendant
5591 l'étape de construction. Le changement sera donc visible assez facilement.
5594 Certains paquets utilisent <prgn>dbs</prgn> pour gérer les correctifs à
5595 leur source amont et créent toujours un nouveau fichier
5596 <tt>orig.tar.gz</tt> contenant le vrai <tt>orig.tar.gz</tt> dans son
5597 répertoire de premier niveau. Cela est discutable concernant la
5598 préférence pour un source vierge. D'un autre côté, il est facile de
5599 modifier ou d'ajouter des fichiers binaires dans ce cas : placez
5600 les simplement dans le fichier <tt>orig.tar.gz</tt> nouvellement créé à
5601 côté du vrai et copiez les au bon endroit pendant l'étape de
5612 <chapt id="beyond-pkging">
5613 <heading>Au-delà de l'empaquetage
5615 Debian, c'est beaucoup plus que de l'empaquetage de logiciels et de
5616 la maintenance de paquets. Ce chapitre contient des informations sur les
5617 façons, souvent vraiment importantes, de contribuer à Debian au-delà de la
5618 simple création et maintenance de paquets.
5620 En tant qu'organisation de volontaires, Debian repose sur la liberté de
5621 choisir ce sur quoi l'on désire travailler et de choisir la
5622 partie la plus importante à laquelle on veut consacrer son temps.
5624 <sect id="submit-bug">
5625 <heading>Rapporter des bogues
5627 Nous vous encourageons à remplir des rapports de bogue quand vous trouvez des
5628 bogues dans les paquets Debian. En fait, les développeurs Debian sont souvent
5629 les testeurs de première ligne. Trouver et rapporter les bogues dans les
5630 paquets d'autres développeurs améliore la qualité de Debian.
5632 Lisez les <url name="instructions pour créer un rapport de bogue"
5633 id="&url-bts-report;"> dans le <url name="système de suivi des bogues"
5634 id="&url-bts;"> Debian.
5636 Essayez de soumettre le bogue à partir d'un compte utilisateur normal sur lequel
5637 vous pouvez recevoir des courriers, pour que les personnes puissent vous
5638 joindre s'ils ont besoin de plus d'informations à propos du bogue. Ne soumettez
5639 pas de bogues en tant que root.
5641 Vous pouvez utiliser un outil comme <manref name="reportbug" section="1"> pour
5642 soumettre des bogues. Il peut automatiser et dans l'ensemble faciliter le
5645 Assurez-vous que le bogue n'a pas déjà été rapporté. Chaque paquet dispose d'une
5646 liste de bogues facilement accessible à
5647 <tt>http://&bugs-host;/<var>nom_paquet</var></tt>. Des outils comme <manref
5648 name="querybts" section="1"> peuvent également vous fournir ces informations (et
5649 <prgn>reportbug</prgn> invoquera également habituellement <prgn>querybts</prgn>
5652 Essayez d'envoyer vos bogues au bon emplacement. Quand, par exemple, votre bogue
5653 concerne un paquet qui réécrit des fichiers d'un autre paquet, vérifiez les
5654 listes des bogues pour les <em>deux</em> paquets pour éviter de créer des
5655 rapports de bogues dupliqués.
5657 Vous pouvez également parcourir les bogues d'autres paquets, en les regroupant
5658 s'ils sont indiqués plus d'une fois, ou en les marquant avec
5659 « fixed » quand ils ont déjà été corrigés. Notez cependant que si
5660 vous n'êtes ni le rapporteur du bogue, ni le responsable du paquet, vous ne
5661 devriez pas fermer réellement le bogue (à moins que vous n'ayez obtenu la
5662 permission du responsable).
5664 De temps en temps, vous pourrez vouloir vérifier ce qui s'est passé à propos des
5665 bogues que vous avez rapportés. Saisissez cette occasion pour fermer les bogues
5666 que vous ne pouvez plus reproduire. Pour trouver tous les bogues que vous avez
5667 rapportés, vous avez simplement besoin d'aller à
5668 <tt>http://&bugs-host;/from:<var><votre-adresse-de-courrier></var></tt>.
5670 <sect1 id="submit-many-bugs">Ouvrir un grand nombre de rapports en
5671 une seule fois (« mass bug filing »)
5673 Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
5674 paquets — plus de dix — est une pratique que nous déconseillons.
5675 Prenez toutes les mesures possibles pour éviter cette situation. Si le problème
5676 peut être détecté automatiquement par exemple, ajoutez un nouveau test dans le
5677 paquet <package>lintian</package> pour générer une erreur ou un avertissement.
5679 Si vous ouvrez plus de dix rapports sur le même sujet, il est préférable
5680 d'indiquer votre intention sur la liste &email-debian-devel; et de
5681 mentionner le fait dans le sujet de votre message. Cela donnera à
5682 d'autres développeurs la possibilité de vérifier que le problème existe
5683 vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent
5684 les mêmes rapports de bogue simultanément.
5686 Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez
5687 les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils ne soient
5688 pas redirigés vers les listes de diffusion.
5691 <sect id="qa-effort">Effort d'assurance qualité
5693 <sect1 id="qa-daily-work">Travail journalier
5695 Bien qu'il y ait un groupe de personnes dédié à l'assurance qualité, les
5696 devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez participer à
5697 cet effort en conservant vos paquets aussi exempts de bogues que possible et
5698 aussi corrects que possible selon <prgn>lintian</prgn> (reportez-vous à <ref
5699 id="lintian">). Si cela vous paraît impossible, vous devriez alors envisager
5700 d'abandonner certains de vos paquets (reportez-vous à <ref id="orphaning">).
5701 Sinon, vous pouvez demander de l'aide à d'autres personnes pour qu'elles
5702 puissent rattraper votre retard dans la correction des bogues (vous pouvez
5703 demander de l'aide sur &email-debian-qa; ou &email-debian-devel;). En même
5704 temps, vous pouvez rechercher des co-responsables (reportez-vous à <ref
5705 id="collaborative-maint">).
5707 <sect1 id="qa-bsp">Les chasses aux bogues
5709 De temps en temps, le groupe d'assurance qualité organise des chasses aux
5710 bogues<footnote><em>Bug Squashing Party</em></footnote> pour essayer de
5711 supprimer le plus de problèmes possible. Elles sont annoncées sur
5712 &email-debian-devel-announce; et l'annonce explique quel domaine sera visé
5713 pendant la chasse : habituellement, il s'agit des bogues empêchant
5714 l'intégration du paquet dans la distribution (« Release Critical »),
5715 mais il peut arriver qu'ils décident d'aider à finir une transition majeure
5716 (comme une nouvelle version de Perl qui demande la recompilation de tous les
5719 Les règles pour les mises à jour indépendantes sont différentes au cours de la
5720 chasse parce que l'annonce de la chasse est considérée comme une annonce
5721 préalable pour les mises à jour indépendantes. Si vous avez des paquets qui
5722 peuvent être affectées par la chasse (parce qu'ils ont des bogues critiques par
5723 exemple), vous devriez envoyer une mise à jour pour chaque bogue correspondant
5724 pour expliquer leur état actuel et ce que vous attendez de la chasse. Si vous
5725 ne voulez pas d'une mise à jour indépendante ou si vous n'êtes intéressé que
5726 par un correctif ou si vous voulez gérer vous-même le bogue, veuillez l'expliquer
5729 Les personnes qui participent à la chasse ont des règles spécifiques pour les
5730 mises à jour indépendantes, ils peuvent en faire une sans avertissement
5731 préalable s'ils envoient leur paquet avec un délai d'au moins 3 jours dans
5732 DELAYED/3-day. Toutes les autres règles de mise à jour indépendante
5733 s'appliquent comme d'habitude ; ils devraient envoyer le correctif de la
5734 mise à jour dans le BTS (pour l'un des bogues ouverts corrigé par la mise à
5735 jour ou pour un nouveau bogue marqué comme fixé). Ils devraient également
5736 respecter tout souhait du responsable s'il en a exprimé.
5738 Si vous ne vous sentez pas à l'aise avec une mise à jour indépendante, envoyez
5739 simplement un correctif au BTS. C'est de loin meilleur qu'une mise à jour
5742 <sect id="contacting-maintainers">Contacter d'autres responsables
5744 Pendant vos activités dans Debian, vous aurez à contacter d'autres responsables
5745 pour différentes raisons. Vous pourrez vouloir discuter d'une nouvelle
5746 façon de coopérer au sein d'un ensemble de paquets liés, ou vous pouvez
5747 simplement rappeler à quelqu'un qu'une nouvelle version est disponible et
5748 que vous en avez besoin.
5750 Chercher l'adresse d'un responsable d'un paquet peut être fastidieux.
5751 Heureusement, il existe un alias de courrier simple,
5752 <tt><paquet>@&packages-host;</tt>, qui fournit un moyen d'envoyer
5753 un courrier à un responsable, quelle que soit son adresse (ou ses
5754 adresses). Remplacez <tt><paquet></tt> par le nom du paquet source
5757 Vous pouvez également vouloir contacter les personnes qui sont inscrites à un
5758 paquet de source donné par le <ref id="pkg-tracking-system">. Vous pouvez le
5759 faire en utilisant l'adresse <tt><nom-paquet>@&pts-host;</tt>.
5761 <!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
5763 <sect id="mia-qa">Gérer les responsables non joignables
5765 Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer
5766 que le responsable est toujours actif et qu'il continue à travailler sur
5767 ses paquets. Il est possible qu'il ne soit plus actif, mais qu'il ne se
5768 soit pas désenregistré du système. D'un autre côté, il est possible qu'il
5769 ait simplement besoin d'un rappel.
5771 Il y a un système simple (la base de données MIA) dans laquelle les informations
5772 sur les responsables supposés Absents En Exercice (« Missing In Action) sont enregistrées. Quand un
5773 membre du groupe QA contacte un responsable inactif ou trouve plus d'informations
5774 sur celui-ci, c'est enregistré dans la base de données MIA. Ce système
5775 est disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut être
5776 interrogé avec un outil de nom <prgn>mia-history</prgn>. Par défaut,
5777 <prgn>mia-history</prgn> affiche des informations sur toutes les personnes qu'il
5778 connaît, mais il accepte des expressions rationnelles comme paramètre qu'il
5779 utilise comme correspondance de noms d'utilisateur. <example>mia-history
5780 --help</example> affiche quels paramètres sont acceptés. Si vous déterminez
5781 qu'aucune information n'a encore été enregistrée pour un responsable inactif ou
5782 que vous voulez ajouter plus d'informations, vous deviez utiliser la procédure
5785 La première étape est de contacter poliment le responsable et d'attendre une
5786 réponse pendant un temps raisonnable. Il est assez difficile de définir le
5787 « temps raisonnable », mais il est important de prendre en compte que
5788 la vraie vie est parfois assez mouvementée. Une façon de gérer cela pourrait
5789 être d'envoyer un rappel après deux semaines.
5791 Si le responsable ne répond pas après quatre semaines (un mois), on peut
5792 supposer qu'il n'y aura probablement pas de réponse. Si ceci se produit, vous
5793 devriez poursuivre vos investigations et essayer de réunir toutes les
5794 informations utiles sur ce responsable. Ceci inclut :
5797 <item>Les informations « echelon » disponibles dans la <url
5798 id="&url-debian-db;" name="base de données LDAP des
5799 développeurs">, qui indiquent quand le développeur a envoyé un
5800 message pour la dernière fois sur une liste de diffusion Debian
5801 (cela inclut les envois via les listes debian-*-changes).
5802 Rappelez-vous également de vérifier si le responsable est indiqué
5803 comme en vacances dans la base de données.
5805 <item>Le nombre de paquets de ce responsable et les conditions de ces
5806 paquets. En particulier, restent-ils des bogues empêchant
5807 l'intégration du paquet dans la distribution qui sont ouverts
5808 depuis des lustres ? De plus, combien de bogues y a-t-il en
5809 général ? Un autre point d'information important est si les
5810 paquets ont subi des mises à jour indépendantes et si oui, par
5813 <item>Est-ce que le responsable est actif en dehors de Debian ? Par
5814 exemple, il peut avoir envoyé des messages récemment à des
5815 listes de diffusion non-Debian ou des groupes de discussion.
5818 Un gros problème est représenté par les paquets parrainés — le responsable
5819 n'est pas un développeur Debian officiel. Les informations « echelon »
5820 ne sont pas disponibles pour les personnes parrainées, par exemple, vous devez
5821 donc trouver et contacter le responsable Debian qui a réellement envoyé le
5822 paquet. Étant donné qu'il a signé le paquet, il est responsable de l'envoi de
5823 toute façon et il devrait savoir ce qui s'est passé avec la personne qu'il
5826 Il est également permis d'envoyer une demande à &email-debian-devel; demandant
5827 si quelqu'un est au courant d'information sur le responsable manquant.
5829 Une fois que vous avez réuni toutes ces informations, vous pouvez contacter
5830 &email-debian-qa;. Les personnes de cet alias utiliseront les informations que
5831 vous aurez fournies pour décider comment procéder. Par exemple, ils peuvent
5832 abandonner un ou tous les paquets du responsable. Si un paquet a subi une mise à
5833 jour indépendante, ils peuvent préférer contacter le responsable ayant fait cette
5834 mise à jour — il est peut-être intéressé par le paquet.
5836 Un dernier mot : veuillez vous souvenir d'être poli. Nous sommes tous des
5837 volontaires et nous ne pouvons dédier l'intégralité de notre temps à Debian.
5838 Vous n'êtes pas non plus au courant des circonstances de la personne impliquée.
5839 Elle est peut-être sérieusement malade ou pourrait même nous avoir quitté
5840 — vous ne savez pas qui recevra vos courriers. Imaginez comme un
5841 proche se sentira s'il lit un courrier pour la personne décédée et trouve un
5842 message très impoli, en colère et accusateur !
5844 D'un autre côté, bien que nous soyons tous volontaires, nous avons une
5845 responsabilité. Vous pouvez donc insister sur l'importance du plus grand intérêt
5846 — si un responsable n'a plus le temps ou l'envie, il devrait
5847 « laisser filer » et donner le paquet à quelqu'un ayant plus de temps.
5849 <sect id="newmaint">
5850 <heading>Interagir avec de futurs développeurs Debian
5852 Le succès de Debian dépend de sa capacité à attirer et retenir de nouveaux et
5853 talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous
5854 recommandons de vous impliquer dans le processus d'apport des nouveaux
5855 responsables. Cette section décrit comment aider les futurs développeurs.
5858 <sect1 id="sponsoring">Parrainer des paquets
5860 Parrainer un paquet veut dire envoyer un paquet pour un responsable qui n'est
5861 pas encore autorisé à le faire lui-même, un candidat nouveau responsable.
5862 Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité.
5864 <!-- FIXME: service down
5865 Si vous désirez être volontaire pour être parrain, vous pouvez vous inscrire à
5866 <url id="&url-sponsors;">.
5869 Les nouveaux responsables ont habituellement certaines difficultés à créer des
5870 paquets Debian — ceci est bien compréhensible. C'est pourquoi le parrain
5871 est là pour vérifier que le paquet parrainé est assez bon pour être inclus
5872 dans Debian. (Notez que si le paquet parrainé est nouveau, les ftpmasters
5873 devront également l'inspecter avant de l'intégrer)
5875 Effectuer un parrainage en signant simplement l'envoi ou en recompilant le
5876 paquet <strong>n'est définitivement pas recommandé</strong>. Vous devez
5877 construire le paquet source comme si vous vouliez construire l'un de vos
5878 paquets. Rappelez-vous que cela ne change rien si vous avez laissé le nom du
5879 candidat développeur dans le changelog et dans le fichier de
5880 contrôle, il est toujours possible de savoir que c'est vous qui avez fait l'envoi.
5882 Si vous êtes un gestionnaire de candidature pour un futur développeur, vous
5883 pouvez également être son parrain. Ainsi, vous pourrez vérifier comment le
5884 candidat gère la partie « Tâches et Capacités »<footnote>Tasks and
5885 Skills</footnote> de sa candidature.
5887 <sect1>Gérer les paquets parrainés
5889 En envoyant un paquet sponsorisé vers Debian, vous certifiez que le paquet
5890 atteint les standards minimum de Debian. Ceci implique que vous devez
5891 construire et tester le paquet sur votre propre système avant l'envoi.
5893 Vous ne pouvez pas simplement envoyer un fichier <file>.deb</file> binaire d'un
5894 filleul. En théorie, vous devriez seulement demander le fichier diff et
5895 l'emplacement de l'archive source d'origine et ensuite vous devriez récupérer
5896 le source et appliquer le diff vous-même. En pratique, vous pouvez vouloir
5897 utiliser le paquet source construit par votre filleul. Dans ce cas, vous devez
5898 vérifier qu'il n'a pas modifié les fichiers sources du fichier
5899 <file>.orig.tar.gz</file> qu'il fournit.
5901 N'ayez pas peur de répondre au filleul et de lui indiquer les changements qu'il
5902 doit faire. Cela prend souvent plusieurs échanges de courriers avant que le
5903 paquet ne soit dans un état acceptable. Être un parrain veut dire être un
5906 Une fois que le paquet a atteint les standards Debian, construisez et signez le
5909 dpkg-buildpackage -k<var>KEY-ID</var>
5911 avant de l'envoyer dans le répertoire incoming. Bien sûr, vous pouvez également
5912 utiliser toute partie de votre <var>KEY-ID</var>, tant qu'elle est unique dans
5913 votre porte-clés secret.
5915 Le champ Maintainer du fichier <file>control</file> et le fichier
5916 <file>changelog</file> devraient afficher la personne qui a fait l'empaquetage,
5917 c'est-à-dire, le filleul. Celui-ci recevra donc tous les courriers du système
5918 de suivi des bogues (BTS) à propos de son paquet.
5920 Si vous préférez laisser une trace plus visible de votre travail de parrainage,
5921 vous pouvez ajouter une ligne l'indiquant dans la plus récente entrée du
5924 Vous êtes encouragé à garder un œil sur le suivi des paquets que vous parrainez
5925 en utilisant le <ref id="pkg-tracking-system">.
5927 <sect1>Recommander un nouveau développeur
5929 Reportez-vous à la page sur les <url id="&url-newmaint-advocate;"
5930 name="recommandations pour un développeur prospectif"> sur le site web Debian.
5932 <sect1>Gérer les candidatures des nouveaux candidats
5934 Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;" name="liste à
5935 vérifier pour les responsables de candidatures"> sur le site web Debian.
5937 <chapt id="l10n">Internationalisation, traduction, être internationalisé et
5940 Debian prend en charge un nombre toujours croissant de langues naturelles. Même
5941 si l'anglais est votre langue maternelle et que vous ne parlez pas d'autre
5942 langue, il est de votre devoir de responsable d'être conscient des problèmes
5943 d'internationalisation (abrégé en i18n à cause des 18 lettres entre le i et
5944 le n dans internationalisation). C'est pourquoi, même si des programmes
5945 seulement en anglais vous suffisent, vous devriez lire la plupart de ce chapitre.
5947 Selon l'<url id="http://www.debian.org/doc/manuals/intro-i18n/"
5948 name="introduction à l'i18n"> de Tomohiro KUBOTA, « I18N
5949 (internationalisation) veut dire la modification d'un logiciel ou de
5950 technologies liées pour qu'un logiciel puisse potentiellement gérer des langues
5951 multiples, des conventions multiples et ainsi de suite dans le monde
5952 entier » alors que « L10N (localisation) veut dire l'implémentation dans
5953 une langue spécifique pour un logiciel déjà internationalisé ».
5955 La l10n et l'i18n sont interconnectées, mais les difficultés liées à chacune sont très
5956 différentes. Il n'est pas vraiment difficile de permettre à un programme de
5957 changer la langue dans laquelle sont affichés les textes selon les paramètres de
5958 l'utilisateur, mais il est très coûteux en temps de traduire réellement ces
5959 messages. D'un autre côté, définir le codage des caractères est trivial, mais
5960 adapter le code pour utiliser des codages de caractères différents est un
5961 problème vraiment difficile.
5963 En laissant de côté les problèmes d'i18n pour lesquels il n'existe pas de règle
5964 générale, il n'y a pas actuellement d'infrastructure centralisée pour la l10n
5965 dans Debian qui puisse être comparée au mécanisme dbuild pour le portage. Le
5966 plus gros du travail doit donc être réalisé manuellement.
5969 <sect id="l10n-handling">Comment sont gérées les traductions au sein de Debian
5971 La gestion des traductions des textes contenus dans un paquet est encore une
5972 tâche manuelle et le processus dépend du type de texte que vous désirez voir traduit.
5974 Pour les messages des programmes, l'infrastructure gettext est utilisée pour la
5975 plupart d'entre eux. La plupart du temps, la traduction est gérée en amont dans
5976 des projets comme le
5977 <url id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="projet de traduction
5978 libre">, le <url id="http://developer.gnome.org/projects/gtp/"
5979 name="projet de traduction de Gnome"> ou <url
5980 id="http://i18n.kde.org/" name="celui de KDE">.
5981 La seule ressource centralisée dans Debian est les <url
5982 id="http://www.debian.org/intl/l10n/" name="statistiques de traduction Debian
5983 centralisées"> où vous pouvez trouver des statistiques sur les
5984 fichiers de traduction trouvés dans les paquets, mais il n'y a aucune
5985 infrastructure pour faciliter le processus de traduction.
5987 Un effort pour traduire les descriptions de paquet a démarré il y a longtemps,
5988 même si les outils fournissent très peu de prise en charge pour les utiliser
5989 vraiment (i.e., seul APT peut les utiliser quand il est configuré
5990 convenablement). Les responsables n'ont rien à faire de particulier pour gérer
5991 les traductions des descriptions de paquets ; les traducteurs devraient
5992 utiliser le <url id="http://ddtp.debian.org/" name="DDTP">.
5994 Pour les questionnaires debconf, les responsable devraient utiliser le paquet
5995 po-debconf pour faciliter le travail des traducteurs, qui peuvent utiliser le
5996 DDTP pour faire leur travail (mais les équipes française et brésilienne ne le
5997 font pas). On peut trouver certaines statistiques à la fois sur le site du
5998 DDTP (à propos de ce qui est vraiment traduit) et sur le site des <url
5999 id="http://www.debian.org/intl/l10n/" name="statistiques de traduction
6000 Debian centralisées"> (à propos de ce qui est intégré dans les paquets).
6002 Pour les pages web, chaque équipe l10n a accès au CVS correspondant et les
6003 statistiques sont disponibles sur le site des statistiques de traduction Debian
6006 Pour la documentation générale à propos de Debian, le processus est plus ou
6007 moins le même que pour les pages web (les traducteurs ont accès au CVS), mais
6008 il n'y a pas de page de statistiques.
6010 Pour la documentation spécifique aux paquets (pages de manuel, documents info,
6011 autres formats), presque tout est encore à faire.
6013 Le plus notablement, le projet KDE gère la traduction de ses documentations de la
6014 même façon que ses messages de programme.
6016 Il existe un effort pour gérer les pages de manuel spécifiques Debian au sein
6017 d'un <url id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="dépôt
6020 <sect id="l10n-faqm">FAQ I18N & L10N pour les responsables
6022 Voici une liste des problèmes que les responsables peuvent rencontrer concernant
6023 l'i18n et la l10n. Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de
6024 consensus sur ces points au sein de Debian et que ce ne sont que des conseils.
6025 Si vous avez une meilleure idée pour un problème donné ou si vous êtes en
6026 désaccord avec certains points, vous êtes libre de fournir vos impressions pour
6027 que ce document puisse être amélioré.
6029 <sect1 id="l10n-faqm-tr">Comment faire en sorte qu'un texte soit traduit
6031 Pour traduire des descriptions de paquet ou des questionnaires debconf, vous n'avez
6032 rien à faire, l'infrastructure du DDTP répartira le matériel à traduire aux
6033 volontaires sans besoin d'interaction de votre part.
6035 Pour tous les autres matériels (fichiers gettext, pages de manuel ou autre
6036 documentation), la meilleure solution est de placer votre texte quelque part sur
6037 l'Internet et de demander sur debian-i18n la traduction dans différentes
6038 langues. Certains membres des équipes de traduction sont abonnés à cette liste
6039 et ils prendront soin de la traduction et du processus de relecture. Une fois
6040 qu'ils ont fini, vous recevrez de leur part votre document traduit dans votre
6043 <sect1 id="l10n-faqm-rev">Comment faire en sorte qu'une traduction
6046 De temps en temps, des personnes indépendantes traduiront certains textes
6047 inclus dans votre paquet et vous demanderont d'inclure la traduction dans le paquet.
6048 Cela peut devenir problématique si vous n'êtes pas familier avec la langue
6049 donnée. C'est une bonne idée d'envoyer le document à la liste de diffusion l10n
6050 correspondante en demandant une relecture. Une fois celle-ci faite, vous devriez
6051 avoir plus confiance dans la qualité de la traduction et l'inclure sans crainte
6054 <sect1 id="l10n-faqm-update">Comment faire en sorte qu'une traduction
6055 donnée soit mise à jour
6057 Si vous avez certaines traductions d'un texte donné qui traînent, chaque fois
6058 que vous mettez à jour l'original, vous devriez demander au précédent
6059 traducteur de mettre à jour sa traduction avec vos nouveaux changements. Gardez à
6060 l'esprit que cette tâche demande du temps ; au moins une semaine pour
6061 obtenir une mise à jour relue.
6063 Si votre traducteur ne répond pas, vous pouvez demander de l'aide sur la liste de
6064 diffusion correspondante. Si tout échoue, n'oubliez pas de mettre un
6065 avertissement dans le document traduit, indiquant que la traduction est un peu
6066 obsolète et que le lecteur devrait se référer au document d'origine si possible.
6068 Évitez de supprimer complètement une traduction à cause de son obsolescence. Un
6069 vieux document est souvent mieux que pas de documentation du tout pour les
6070 personnes non anglophones.
6072 <sect1 id="l10n-faqm-bug">Comment gérer un rapport de bogue concernant
6075 La meilleure solution peut être de marquer le bogue comme « suivi au développeur
6076 amont » (<em>forwarded to upstream</em>) et de faire suivre le bogue à la
6077 fois au précédent traducteur et à son équipe (en utilisant la liste de diffusion
6078 debian-l10n-XXX correspondante).
6079 <!-- TODO: add the i18n tag to the bug? -->
6081 <sect id="l10n-faqtr">FAQ I18N & L10N pour les traducteurs
6083 Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de
6084 procédure générale dans Debian concernant ces points et que, dans tous les cas,
6085 vous devriez collaborer avec votre équipe et les responsables des paquets.
6087 <sect1 id="l10n-faqtr-help">Comment aider l'effort de traduction
6089 Choisissez ce que vous désirez traduire, assurez-vous que personne ne travaille
6090 déjà dessus (en utilisant votre liste de diffusion debian-l10n-XXX),
6091 traduisez-le, faites-le relire par d'autres personnes dont c'est également la
6092 langue maternelle sur votre liste de diffusion l10n et fournissez-le au
6093 responsable du paquet (voir le point suivant).
6095 <sect1 id="l10n-faqtr-inc">Comment fournir une traduction pour
6096 inclusion dans un paquet
6098 Assurez-vous que votre traduction est correcte (en demandant une relecture sur
6099 votre liste de discussion l10n) avant de la fournir pour inclusion. Cela
6100 gagnera du temps à tout le monde et évitera le chaos qui résulterait d'avoir
6101 plusieurs versions du même document dans les rapports de bogue.
6103 La meilleure solution est de remplir un bogue standard contenant la traduction
6104 sur le paquet. Assurez-vous d'utiliser l'étiquette « patch » et
6105 n'utilisez pas une gravité supérieure à « wishlist » car l'absence de
6106 traduction n'empêche jamais un programme de fonctionner.
6108 <sect id="l10n-best">Meilleures pratiques actuelles concernant la l10n
6112 En tant que responsable, ne modifiez jamais les traductions en aucune façon (même
6113 pour reformater l'affichage) sans demander à la liste de diffusion l10n
6114 correspondante. Vous risquez, par exemple, de casser le codage du fichier en
6115 agissant ainsi. De plus, ce que vous considérez comme une erreur peut être
6116 correct (ou même nécessaire) pour une langue donnée.
6118 En tant que traducteur, si vous trouvez une erreur dans le texte d'origine,
6119 assurez-vous de l'indiquer. Les traducteurs sont souvent les lecteurs les plus
6120 attentifs d'un texte donné et s'ils ne rendent pas compte des erreurs qu'ils
6121 trouvent, personne ne le fera.
6123 Dans tous les cas, rappelez-vous que le problème principal avec la l10n est
6124 qu'elle demande la coopération de plusieurs personnes et qu'il est très facile
6125 de démarrer une guerre incendiaire à propos de petits problèmes dûs à des
6126 incompréhensions. Donc, si vous avez des problèmes avec votre interlocuteur,
6127 demandez de l'aide sur la liste de diffusion l10n correspondante, sur
6128 debian-i18n ou même sur debian-devel (attention, cependant, les discussions sur
6129 la l10n tournent très souvent à l'incendie sur cette liste :)
6131 Dans tous les cas, la coopération ne peut être atteinte qu'avec un
6132 <strong>respect mutuel</strong>.
6136 <appendix id="tools">Aperçu des outils du responsable Debian
6138 Cette section contient un aperçu rapide des outils dont dispose le responsable.
6139 Cette liste n'est ni complète, ni définitive, il s'agit juste d'un guide
6140 des outils les plus utilisés.
6142 Les outils du responsable Debian sont destinés à aider les
6143 responsables et libérer leur temps pour des tâches plus cruciales. Comme le dit
6144 Larry Wall, il y a plus d'une manière de le faire.
6146 Certaines personnes préfèrent utiliser des outils de haut niveau, d'autres pas.
6147 Debian n'a pas de position officielle sur la question ; tout outil
6148 conviendra du moment qu'il fait le boulot. C'est pourquoi cette section
6149 n'a pas été conçue pour indiquer à chacun quel outil il doit utiliser ou
6150 comment il devrait faire pour gérer sa charge de responsable Debian. Elle
6151 n'est pas non plus destinée à favoriser l'utilisation d'un outil aux
6154 La plupart des descriptions de ces outils proviennent des descriptions de leurs
6155 paquets. Vous trouverez plus d'informations dans les documentations de ces
6156 paquets. Vous pouvez aussi obtenir plus d'informations avec la commande
6157 <tt>apt-cache show <nom_paquet></tt>.</p>
6160 <sect id="tools-core">
6161 <heading>Outils de base</heading>
6163 Les outils suivants sont pratiquement nécessaires à tout responsable.</p>
6166 <sect1 id="dpkg-dev">
6167 <heading><package>dpkg-dev</package></heading>
6169 Le paquet <package>dpkg-dev</package> contient les outils (y compris
6170 <prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des
6171 paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas
6172 niveau indispensables pour créer et manipuler les paquets ; en tant que
6173 tels, ils sont essentiels à tout responsable Debian.
6175 <sect1 id="debconf">
6176 <heading><package>debconf</package></heading>
6178 Le paquet <package>debconf</package> fournit une interface unifiée pour
6179 configurer les paquets interactivement. Il est indépendant de l'interface et
6180 permet une configuration en mode texte, par une interface HTML ou par boîtes de
6181 dialogue. D'autres types d'interface peuvent être ajoutés sous forme de
6184 Vous trouverez la documentation de ce paquet dans le paquet
6185 <package>debconf-doc</package>.
6187 Beaucoup pensent que ce système devrait être utilisé pour tout paquet
6188 nécessitant une configuration interactive ; reportez-vous à la <ref
6189 id="bpp-config-mgmt">. <package>debconf</package> n'est pas requis par la
6190 <em>charte Debian</em> pour le moment ; cependant, cela pourra changer.
6193 <sect1 id="fakeroot">
6194 <package>fakeroot</package>
6196 <package>fakeroot</package> simule les privilèges <em>root</em>. Cela permet de
6197 fabriquer un paquet sans être root (en général, les paquets installent des
6198 fichiers appartenant à <em>root</em>). Si vous avez installé
6199 <package>fakeroot</package>, vous pouvez construire un paquet en tant que
6200 simple utilisateur avec : <tt>dpkg-buildpackage -rfakeroot</tt>.
6203 <sect id="tools-lint">
6204 <heading>Outils du paquet lint</heading>
6206 Selon le « Free On-line Dictionary of Computing » (FOLDOC),
6207 « lint » est « un outil de traitement de langage C qui contient
6208 beaucoup plus de tests complets sur le code que n'en font habituellement les
6209 compilateurs C. ». Les outils du paquet lint aide les responsables de
6210 paquet à trouver automatiquement des problèmes habituels et des violations de
6211 charte dans leurs paquets</p>
6213 <sect1 id="lintian">
6214 <heading><package>lintian</package></heading>
6216 <package>lintian</package> dissèque les paquets pour y repérer des bogues et des
6217 manquements aux règles de développement. Il contient des tests automatisés pour
6218 vérifier de nombreuses règles et quelques erreurs courantes.
6220 Vous devriez récupérer la dernière version de <package>lintian</package> depuis
6221 <em>unstable</em> régulièrement et vérifier tous vos paquets. Notez que
6222 l'option <tt>-i</tt> donne des explications détaillées sur la signification de
6223 chaque erreur, la partie concernée dans la charte et le moyen habituel de
6226 Veuillez vous reporter à <ref id="sanitycheck"> pour plus d'informations sur
6227 comment et quand utiliser Lintian.
6229 Vous pouvez aussi obtenir un résumé de tous les problèmes reportés par Lintian
6230 sur vos paquets à <url id="&url-lintian;">. Ces rapports contiennent la sortie
6231 de la dernière version de <prgn>lintian</prgn> pour l'ensemble de la
6232 distribution de développement (<em>unstable</em>).
6236 <heading><package>linda</package></heading>
6238 <package>linda</package> est un autre vérificateur de paquet. Il est semblable à
6239 <package>lintian</package>, mais il a un ensemble de tests différents. Il est écrit
6240 en Python plutôt qu'en Perl.</p>
6244 <sect1 id="debdiff">
6245 <heading><package>debdiff</package></heading>
6247 <prgn>debdiff</prgn> (du paquet <package>devscripts</package>, <ref
6248 id="devscripts">) compare des listes de fichiers et des fichiers de contrôle de
6249 deux paquets. C'est un simple test de régression qui peut vous aider à remarquer
6250 si le nombre de paquets binaires a changé depuis le dernier envoi ou si autre
6251 chose a changé dans le fichier de contrôle. Bien sûr, certains des changements
6252 qu'il indique sont normaux, mais il peut aider à empêcher différents accidents.
6254 Vous pouvez l'exécuter sur un couple de paquets binaires :
6256 debdiff package_1-1_arch.deb package_2-1_arch.deb
6259 Ou même sur un couple de fichiers de changements :
6261 debdiff package_1-1_arch.changes package_2-1_arch.changes
6264 Pour plus d'informations, veuillez voir <manref name="debdiff" section="1">.
6270 <sect id="tools-helpers">
6271 <heading>Aides pour le fichier <file>debian/rules</file></heading>
6273 Des outils de construction de paquets rendent le processus d'écriture du fichier
6274 <file>debian/rules</file> plus facile. Veuillez voir les <ref
6275 id="helper-scripts"> pour plus d'informations sur les raisons pour lesquelles
6276 ils peuvent être désirables ou non.
6278 <sect1 id="debhelper">
6279 <heading><package>debhelper</package></heading>
6281 Le paquet <package>debhelper</package> regroupe un ensemble de programmes qui
6282 peuvent être utilisés dans <file>debian/rules</file> pour automatiser les
6283 tâches courantes relatives à la fabrication des paquets Debian binaires.
6284 <package>debhelper</package> inclut des programmes pour installer différents
6285 fichiers, les compresser, ajuster leurs droits et intégrer votre paquet dans le
6286 système de menu Debian.
6288 À la différence d'autres approches, <package>debhelper</package> est divisé en
6289 plusieurs petits utilitaires simples qui agissent de manière cohérente. Ce découpage
6290 permet un contrôle des opérations plus fin que certains des autres « <em>outils
6291 debian/rules</em> ».
6293 Il existe aussi un certain nombre de petites extensions
6294 <package>debhelper</package> trop éphémères pour être documentées. Vous en
6295 listerez la plupart en faisant <tt>apt-cache search ^dh-</tt>.
6299 <sect1 id="debmake">
6300 <heading><package>debmake</package></heading>
6302 <package>debmake</package> — un précurseur de <package>debhelper</package>
6303 — est un assistant moins modulaire pour manipuler le fichier
6304 <file>debian/rules</file>. Il inclut deux programmes principaux :
6305 <prgn>deb-make</prgn>, utile au développeur Debian pour convertir un paquet
6306 source normal (non-Debian) en paquet source Debian, et <prgn>debstd</prgn> qui
6307 regroupe le type de fonction que l'on trouve dans <package>debhelper</package>.
6309 Le consensus actuel est que l'usage de <package>debmake</package> est
6310 déconseillé au profit de <package>debhelper</package>, mais ce n'est pas une
6311 erreur d'utiliser <package>debmake</package>.
6314 <sect1 id="dh-make">
6315 <heading><package>dh-make</package>
6317 Le paquet <package/dh-make/ contient <prgn/dh_make/, un programme qui crée un
6318 squelette de fichiers nécessaires à la construction d'un paquet Debian à partir
6319 d'une arborescence source. Comme le nom le suggère, <prgn/dh_make/ est une
6320 réécriture de <package/debmake/ et ses fichiers modèles utilisent les
6321 programmes dh_* de <package/debhelper/.
6323 Quoique les fichiers de règles fabriqués par <prgn/dh_make/ constituent en général
6324 une base suffisante pour un paquet fonctionnel, ce ne sont que les
6325 fondations : la charge incombe toujours au responsable d'affiner
6326 les fichiers générés et de rendre le paquet complètement fonctionnel et
6327 en conformité avec la charte.
6331 <heading><package>yada</package></heading>
6333 Le paquet <package>yada</package> est un autre assistant pour la création de
6334 paquets. Il utilise un fichier <file>debian/packages</file> pour générer
6335 <file>debian/rules</file> et d'autres fichiers nécessaires dans le
6336 sous-répertoire <file>debian/</file>. Le fichier <file>debian/packages</file>
6337 contient des instructions pour construire les paquets et il n'y a pas besoin de
6339 <file>Makefile</file>. Il existe la possibilité d'utiliser un moteur de macros
6340 semblable à celui utilisé dans les fichiers SPECS des paquets source RPM.</p>
6342 Pour plus d'informations, voir le
6343 <tt><url id="http://yada.alioth.debian.org/" name="site de YADA"></tt>.</p>
6348 <heading><package>equivs</package></heading>
6350 <package>equivs</package> est un autre paquet pour faire des paquets. Il est
6351 souvent conseillé pour un usage local, si vous avez besoin de faire un paquet
6352 pour satisfaire des dépendances. Il est aussi parfois utilisé pour faire des
6353 « méta-paquets » qui sont des paquets dont l'unique objet est de
6354 dépendre d'autres paquets.</p>
6359 <sect id="tools-builders">
6360 <heading>Constructeurs de paquets</heading>
6362 Les paquets suivants aident le processus de construction des paquets, en général
6363 en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que la gestion du support de
6366 <sect1 id="cvs-buildpackage">
6367 <heading><package>cvs-buildpackage</package></heading>
6369 Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou de
6370 récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer
6371 un paquet Debian depuis le référentiel CVS et il assiste le développeur lors de
6372 l'intégration de modifications amont dans le référentiel.
6374 Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS pour le
6375 responsable Debian. Il permet de conserver des branches CVS distinctes pour les
6376 distributions <em>stable</em>, <em>unstable</em> et probablement
6377 <em>experimental</em> et de bénéficier des avantages d'un système de contrôle
6381 <sect1 id="debootstrap">
6382 <heading><package>debootstrap</package></heading>
6384 Le paquet <package>debootstrap</package> vous permet d'amorcer un système Debian
6385 de base à n'importe quel endroit dans votre système de fichiers. Par
6386 « système de base », nous entendons le strict minimum nécessaire pour
6387 fonctionner et installer le reste du système.
6389 Avoir un système comme celui-ci peut vous servir de différentes manières. Vous
6390 pouvez, par exemple, déplacer votre racine dans ce système avec
6391 <prgn>chroot</prgn> pour tester vos dépendances de construction. Vous pouvez
6392 aussi l'utiliser pour voir comment se comporte votre paquet quand il est
6393 installé dans un environnement minimum.
6396 <sect1 id="pbuilder">
6397 <heading><package>pbuilder</package></heading>
6399 <package>pbuilder</package> construit un système « chrooté » et
6400 compile des paquets dans ce système. Ceci est très utile pour vérifier que les
6401 dépendances de compilation de votre paquet sont correctes et pour vous assurer
6402 qu'aucune dépendance de construction inutile ou incorrecte n'existe dans le
6405 Un paquet lié est <package>pbuilder-uml</package>, qui va même plus loin en
6406 réalisant la construction au sein d'un environnement « User Mode Linux ».</p>
6410 <heading><package>sbuild</package></heading>
6412 <package>sbuild</package> est un autre compilateur automatique. Il peut aussi
6413 être utilisé dans un environnement « chrooté ». Il peut être utilisé
6414 seul ou comme partie d'un environnement de compilation distribué en réseau.
6415 Comme le précédent, c'est une partie du système utilisé par les porteurs pour
6416 construire des paquets binaires pour toutes les architectures disponibles.
6417 Veuillez vous reporter à <ref id="buildd"> pour plus d'informations et à <url
6418 id="&url-buildd;"> pour voir le système en fonctionnement.</p>
6422 <sect id="uploaders">
6423 <heading>Téléchargeurs de paquets</heading>
6425 Les paquets suivants aident à automatiser ou à simplifier le processus d'envoi
6426 de paquets dans l'archive officielle.</p>
6428 <sect1 id="dupload">
6429 <heading><package>dupload</package></heading>
6431 Le paquet <package>dupload</package> contient un script du même nom pour mettre
6432 à jour des paquets dans l'archive Debian, tracer les mises à jour et les
6433 annoncer par courrier électronique automatiquement. Vous pouvez le configurer
6434 pour faire des mises à jour à d'autres endroits et avec d'autres méthodes.
6438 <heading><package>dput</package></heading>
6440 Le script <package>dput</package> fait à peu près la même chose que
6441 <package>dupload</package>, mais il le fait différemment. Il a aussi quelques
6442 fonctions supplémentaires telles que la possibilité de vérifier la signature
6443 GnuPG et les sommes de contrôles avant le téléchargement et la possibilité de
6444 démarrer <prgn>dinstall</prgn> en mode simulation (<em>dry-run</em>) après le
6448 <heading><package>dcut</package></heading>
6450 Le script <package>dcut</package> (faisant partie du paquet <ref id="dput">)
6451 aide à la suppression de fichiers du répertoire d'envoi ftp.
6456 <sect id="tools-maint-automate">
6457 <heading>Automatisation de la maintenance</heading>
6459 Les outils suivants aident à automatiser les différentes tâches de maintenance
6460 par l'ajout des entrées de changelog ou de lignes de signatures, par la
6461 recherche de bogues à partir d'Emacs et par l'utilisation du fichier officiel
6462 <file>config.sub</file> le plus récent.</p>
6465 <sect1 id="devscripts">
6466 <heading><package>devscripts</package></heading>
6468 Le paquet <package>devscripts</package> contient des scripts et outils qui sont
6469 très utiles pour maintenir vos paquets Debian. Parmi ces scripts, vous
6470 trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui manipulent votre
6471 fichier <file>debian/changelog</file> depuis la ligne de commande et
6472 <prgn>debuild</prgn> qui est construit au-dessus de
6473 <prgn>dpkg-buildpackage</prgn>. L'outil <prgn>bts</prgn> est également très
6474 utile pour mettre à jour l'état des rapports de bogue depuis la ligne de
6475 commande. Le programme <prgn>uscan</prgn> peut être utilisé pour suivre les
6476 nouvelles versions amont de vos paquets. Le programme <prgn>debrsign</prgn>
6477 peut être utilisé pour signer à distance un paquet avant de l'envoyer, ce qui
6478 est agréable quand la machine sur laquelle vous construisez le paquet est
6479 différente de celle où résident vos clés GPG.</p>
6481 Vérifiez la page de manuel <manref section="1" name="devscripts"> pour une liste
6482 complète des scripts disponibles.
6484 <sect1 id="autotools-dev">
6485 <heading><package>autotools-dev</package></heading>
6487 <package>autotools-dev</package> contient les meilleurs pratiques pour des personnes assurant la maintenance de
6488 paquets qui utilisent <prgn>autoconf</prgn> et/ou <prgn>automake</prgn>.
6489 Contient également des fichiers canoniques <file>config.sub</file> et
6490 <file>config.guess</file> qui sont connus pour fonctionner avec tous les
6491 portages Debian.</p>
6494 <sect1 id="dpkg-repack">
6495 <heading><package>dpkg-repack</package></heading>
6497 <prgn>dpkg-repack</prgn> crée un paquet Debian à partir d'un paquet qui
6498 a déjà été installé. Si des changements ont été effectués sur le paquet quand il
6499 a été décompacté (par exemple, des fichiers dans <file>/etc</file> ont été
6500 modifiés), le nouveau paquet héritera de ces changements.</p>
6502 Cet utilitaire peut faciliter la copie de paquet d'un ordinateur vers un autre
6503 ou la re-création de paquets installés sur un système, mais qui ne sont plus
6504 disponibles ailleurs ou pour sauvegarder l'état actuel d'un paquet avant de le
6509 <heading><package>alien</package></heading>
6511 <prgn>alien</prgn> convertit des paquets binaires entre différents formats de
6512 paquets, y compris des paquets Debian, RPM (RedHat), LSB (Linux Standard Base),
6513 Solaris et Slackware.</p>
6516 <sect1 id="debsums">
6517 <heading><package>debsums</package></heading>
6519 <prgn>debsums</prgn> vérifie des paquets installés par rapport à leur somme de
6520 hachage MD5. Veuillez noter que tous les paquets n'ont pas de sommes MD5 car
6521 elles ne sont pas requises par la charte.</p>
6524 <sect1 id="dpkg-dev-el">
6525 <heading><package>dpkg-dev-el</package></heading>
6527 <package>dpkg-dev-el</package> fournit des macros Emacs Lisp qui apportent une
6528 aide lors de l'édition des fichiers du répertoire <file>debian</file> de votre
6529 paquet. Par exemple, il y a des fonctions pratiques pour lister les bogues
6530 actuels d'un paquet et pour finaliser la dernière entrée d'un fichier
6531 <file>debian/changelog</file> file.
6535 <sect1 id="dpkg-depcheck">
6536 <heading><package>dpkg-depcheck</package></heading>
6538 <prgn>dpkg-depcheck</prgn> (du paquet <package>devscripts</package>, <ref
6539 id="devscripts">) exécute une commande sous <prgn>strace</prgn> pour déterminer
6540 tous les paquets utilisés par la commande.
6542 Pour les paquets Debian, c'est utile quand vous devez créer une ligne
6543 <tt>Build-Depends</tt> pour votre nouveau paquet : exécuter le processus de
6544 compilation avec <prgn>dpkg-depcheck</prgn> vous fournira une bonne première
6545 approximation des dépendances de compilation. Par exemple :
6547 dpkg-depcheck -b debian/rules build
6550 <prgn>dpkg-depcheck</prgn> peut aussi être utilisé pour vérifier les dépendances
6551 d'exécution, particulièrement si votre paquet utilise exec(2) pour exécuter
6552 d'autres programmes.
6554 Pour plus d'informations, veuillez voir <manref name="dpkg-depcheck" section="1">.
6558 <sect id="tools-porting">
6559 <heading>Outils de portage</heading>
6561 Les outils suivants facilitent le travail des porteurs et la compilation
6564 <sect1 id="quinn-diff">
6565 <heading><package>quinn-diff</package></heading>
6567 <package>quinn-diff</package> est utilisé pour localiser les différences d'une
6568 architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de
6569 l'architecture <var>X</var> doivent être portés sur l'architecture
6572 <sect1 id="dpkg-cross">
6573 <heading><package>dpkg-cross</package></heading>
6575 <package>dpkg-cross</package> est un outil qui installe les bibliothèques et les
6576 en-têtes nécessaires à une compilation
6577 croisée<footnote><p><em>cross-compilation</em></footnote> d'une manière
6578 similaire à <package>dpkg</package>. De plus, les paquets
6579 <prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
6580 améliorés pour accepter les compilations croisées.
6582 <sect id="tools-doc">
6583 <heading>Documentation et information</heading>
6585 Les paquets suivants fournissent des informations pour les responsables ou de
6586 l'aide pour construire de la documentation
6588 <sect1 id="debiandoc-sgml">
6589 <heading><package>debiandoc-sgml</package></heading>
6591 <package>debiandoc-sgml</package> fournit la DTD DebianDoc SGML qui est
6592 habituellement utilisée pour la documentation Debian. Ce manuel, par exemple,
6593 est écrit en DebianDoc. Il fournit également des scripts pour construire et
6594 décliner le source en de multiples formats de sortie.</p>
6596 La documentation sur la DTD peut être trouvée dans le paquet
6597 <package>debiandoc-sgml-doc</package>.</p>
6600 <sect1 id="debian-keyring">
6601 <heading><package>debian-keyring</package></heading>
6603 Contient les clés publiques GPG et PGP des développeurs Debian. Voir <ref
6604 id="key-maint"> et la documentation du paquet pour plus d'informations.</p>
6607 <sect1 id="debview">
6608 <heading><package>debview</package></heading>
6610 <package>debview</package> fournit un mode Emacs pour voir les paquets binaires
6611 Debian. Il vous permet d'examiner un paquet sans le décompresser.</p>
6616 <!-- FIXME: add the following
6619 dbs (referred to above)
6620 dpatch (referred to above)
6637 debaux: too new, unmaintained?
6638 dh-make-perl: too new, unmaintained?
6645 <!-- Keep this comment at the end of the file
6650 sgml-minimize-attributes:nil
6651 sgml-always-quote-attributes:t
6653 sgml-indent-data:nil
6654 sgml-parent-document:nil
6655 sgml-exposed-tags:nil
6656 sgml-declaration:nil
6657 sgml-local-catalogs:nil
6658 sgml-local-ecat-files:nil