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 independant entities -->
6 <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
8 <!-- CVS revision of this document -->
9 <!ENTITY cvs-rev "$Revision: 1.38 $">
10 <!-- if you are translating this document, please notate the CVS
11 revision of the developers reference here -->
13 <!ENTITY cvs-en-rev "1.216">
16 <!-- how to mark a section that needs more work -->
17 <!ENTITY FIXME "<em>FIXME:</em> ">
23 <title>Référence du développeur Debian
25 <author>L'équipe de la Référence du développeur &email-devel-ref;
26 <author>Adam Di Carlo, éditeur
27 <author>Raphaël Hertzog
28 <author>Christian Schwarz
31 <translator>version française par Antoine Hulin</translator>
32 <translator>et Frédéric Bothamy (traducteur actuel)</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 20030718).</version>
37 <copyrightsummary>Copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
38 <copyrightsummary>Copyright © 2002—2003 Raphaël Hertzog</copyrightsummary>
39 <copyrightsummary>Copyright © 1997, 1998 Christian Schwarz.</copyrightsummary>
41 Ce manuel est un logiciel libre ; il peut être redistribué et/ou modifié
42 selon les termes de la licence publique générale du projet GNU (GNU GPL), telle
43 que publiée par la « Free Software Foundation » (version 2 ou toute
47 Il est distribué dans l'espoir qu'il sera utile, mais <em>sans aucune
48 garantie</em>, sans même la garantie implicite d'une possible valeur marchande
49 ou d'une adéquation à un besoin particulier. Consultez la licence publique
50 générale du projet GNU pour plus de détails.
52 <p>Une copie de la licence publique générale du projet GNU est disponible dans
53 le fichier &file-GPL; de la distribution &debian-formal; ou sur la toile :
54 <url id="&url-gpl" name="la licence publique générale du projet GNU">. Vous
55 pouvez également l'obtenir en écrivant à la &fsf-addr;.
59 <chapt id="scope">Portée de ce document
62 Le but de ce document est de donner une vue d'ensemble des procédures à suivre
63 et des ressources mises à la disposition des développeurs Debian.
65 <!-- FIXME: rewrites -->
67 Les procédures décrites ci-après expliquent comment devenir responsable Debian
68 (<ref id="new-maintainer">), comment créer de nouveaux paquets (<ref
69 id="newpackage">) et comment les installer dans l'archive (<ref id="upload">),
70 comment gérer les rapports de bogues (<ref id="bug-handling">), comment
71 déplacer, effacer ou abandonner un paquet (<ref id="archive-manip">), comment
72 faire le portage d'un paquet (<ref id="porting">), quand et comment faire la
73 mise à jour du paquet d'un autre responsable (<ref id="nmu">).
76 Les ressources présentées dans ce manuel incluent les listes de diffusion (<ref
77 id="mailing-lists">) et les serveurs (<ref id="server-machines">), une
78 présentation de la structure de l'archive Debian (<ref id="archive">), des
79 explications sur les serveurs qui acceptent les mises à jour de paquets (<ref
80 id="upload-ftp-master">) et une présentation des outils qui peuvent aider un
81 responsable à améliorer la qualité de ses paquets (<ref id="tools">).
84 Ce manuel de référence ne présente pas les aspects techniques liés aux paquets
85 Debian, ni comment les créer. Il ne décrit pas non plus les règles que doivent
86 respecter les paquets Debian. Cette information est disponible dans la <url
87 id="&url-debian-policy;" name="charte Debian">.
90 De plus ce document <em>n'est pas l'expression d'une politique officielle</em>.
91 Il contient de la documentation sur le système Debian et des conseils pratiques
92 largement suivis. C'est une sorte de guide pratique.
94 <sect>Introduction à la version française
99 Bien que ce document soit en français, l'activité de responsable Debian implique
100 une maîtrise de la langue anglaise. Le projet Debian est un projet international
101 auquel participent des japonais, néo-zélandais, américains, allemands,
102 finlandais, français, espagnols, danois, etc.
105 En conséquence, la langue utilisée dans toutes les listes de diffusion destinées
106 aux développeurs (à l'exception de la liste
107 <email>debian-devel-french@&lists-host;</email>) est l'anglais et les rapports
108 de bogue doivent être rédigés en anglais. En fait, sauf exception rare, tout
109 dialogue avec les autres responsables Debian se fera en anglais quel que soit le
116 Cette section liste les termes techniques qui ont un sens spécifique dans le
117 projet Debian. Pour chacune de ces expressions, vous trouverez la traduction
118 française utilisée dans ce manuel, une définition et une référence à la section
119 du manuel qui traite de ce sujet.
123 <item><em>Upload</em> : mise à jour, téléchargement (parfois
124 livraison). Opération qui consiste à télécharger un nouveau paquet ou
125 une nouvelle version de paquet dans l'archive Debian (<ref
128 <item><em>Non-maintainer upload (NMU)</em> : mise à jour
129 indépendante. Téléchargement d'une nouvelle version de paquet dans
130 l'archive Debian par une personne qui n'est pas officiellement
131 responsable de ce paquet (<ref id="nmu">).
133 <item><em>Source NMU</em> : mise à jour indépendante source. Il
134 s'agit d'une mise à jour indépendante pour un paquet source (<ref
137 <item><em>Binary NMU</em> : mise à jour indépendante binaire. Mise
138 à jour indépendante pour un paquet binaire (<ref id="nmu-terms">).
140 <item><em>Bug Tracking System (BTS)</em> : système de suivi des
141 bogues. Il s'agit du système utilisé par le projet Debian pour suivre
142 les bogues et leur correction (<ref id="bug-handling">).
144 <item><em>Bug submitter</em> : rapporteur du bogue. Personne qui
145 envoie un rapport de bogue au système de suivi des bogues (<ref
148 <item><em>Release critical bug</em> : bogue empêchant l'intégration
149 du paquet dans la distribution. Bogues de gravité <em>critique</em>,
150 <em>grave</em> et <em>sérieuse</em>. Ces bogues ne doivent pas
151 apparaître dans une distribution <em>stable</em>. Ils doivent être
152 corrigés ou bien les paquets en cause doivent être supprimés (<ref
155 <item><em>Package Tracking System (PTS)</em> : système de suivi des
156 paquets. Il s'agit du système utilisé par le projet Debian pour suivre
157 les paquets sources des différentes distributions (<ref
158 id="pkg-tracking-system">).
160 <item><em>Unstable</em> : nom de la distribution en cours
161 de développement. Cette distribution contient les paquets
162 envoyés par les développeurs. Ceux-ci n'étant que des êtres
163 humains, elle est parfois cassée (<ref id="sec-dists">).
165 <item><em>Testing</em> : nom de la distribution en test. Cette
166 distribution reçoit les paquets des développeurs qui ont passé une
167 période de deux semaines dans <em>unstable</em> et pour lesquels aucun
168 bogue remettant en cause la distribution (cf. <em>Release critical
169 bug</em>) n'a été découvert. Cette distribution n'a pas été testée en
170 profondeur. Elle est cependant censée être plus stable
171 qu'<em>unstable</em> (<ref id="sec-dists">).
173 <item><em>Stable</em> : nom de la distribution stable. Cette
174 distribution a été testée, validée et diffusée (<ref id="sec-dists">).
176 <item><em>Debian maintainer</em> : responsable Debian, développeur
177 Debian (parfois mainteneur). Personne qui fait officiellement partie du
178 projet Debian. Elle a accès aux serveurs Debian et participe au
179 développement — au sens large — de la distribution (<ref
180 id="developer-duties">). La plupart des responsables font de la mise en
181 paquet, mais il existe d'autres activités telles que la documentation,
182 la gestion du site web, la création des cédéroms, l'administration des
185 <item><em>Upstream version</em> : version amont. Il s'agit du
186 logiciel tel qu'il est fourni par le responsable amont — par
187 opposition à la version fournie par la distribution Debian. (Voir <ref
188 id="upstream-coordination">.)
190 <item><em>Upstream maintainer</em> : responsable amont ou
191 développeur amont. Personne responsable du développement ou de la
192 maintenance d'un logiciel. En général, le responsable amont n'a rien à
193 voir avec le projet Debian (<ref id="upstream-coordination">).
195 <item><em>Debian keyring</em> : porte-clés Debian. Le porte-clés
196 Debian contient les clés publiques de tous les responsables Debian (<ref
199 <item><em>Work-needing and prospective packages (WNPP)</em> :
200 paquets en souffrance et paquets souhaités. La liste des paquets en
201 souffrance indique les paquets qui n'ont plus de responsable. La liste
202 des paquets souhaités indique les logiciels que des utilisateurs
203 aimeraient bien voir dans la distribution (<ref id="upload">).
208 <chapt id="new-maintainer">Devenir responsable Debian
210 <sect id="getting-started">Pour commencer
212 Vous avez lu toute la documentation, vous avez examiné le <url
213 id="&url-newmaint-guide;" name="guide du nouveau responsable">, vous comprenez
214 l'intérêt de tout ce qui se trouve dans le paquet d'exemple
215 <package>hello</package> et vous vous apprêtez à mettre en paquet votre
216 logiciel préféré. Comment devenir responsable Debian et intégrer votre travail
219 Si vous ne l'avez pas encore fait, commencez par vous inscrire à la
220 liste &email-debian-devel;. Pour cela, envoyez un courrier à l'adresse
221 &email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne
222 <em>Objet</em><footnote><p><em>Subject</em> en anglais</footnote> de votre
223 message. En cas de problème, contactez l'administrateur de la liste
224 &email-listmaster;. Vous trouverez plus d'informations dans la section <ref
225 id="mailing-lists">. &email-debian-devel-announce; est une autre liste
226 incontournable pour qui veut suivre les développements de Debian.
228 Vous suivrez les discussions de cette liste (sans poster) pendant quelque temps
229 avant de coder quoi que ce soit et vous informerez la liste de votre intention
230 de travailler sur quelque chose pour éviter de dupliquer le travail d'un autre.
232 Une autre liste intéressante est &email-debian-mentors;. Voir la section <ref
233 id="mentors"> pour les détails. Le canal IRC <tt>#debian</tt> pourra aussi être
237 Quand vous avez choisi la manière dont vous contribuerez au projet
238 &debian-formal;, prenez contact avec les responsables Debian qui travaillent
239 sur des tâches similaires. Ainsi, vous pourrez apprendre auprès de personnes
240 expérimentées. Si, par exemple, vous voulez mettre en paquet des logiciels
241 existants, trouvez-vous un parrain. Un parrain est une personne qui travaillera
242 sur vos paquets avec vous et les téléchargera dans l'archive Debian une fois
243 qu'il sera satisfait de votre mise en paquet. Pour trouver un parrain, envoyez
244 une demande de parrainage à la liste &email-debian-mentors; en vous présentant
245 et en décrivant votre paquet (voir <ref id="sponsoring"> pour en savoir plus
246 sur le sujet). Si vous préférez porter Debian sur une architecture ou un noyau
247 alternatif, abonnez-vous aux listes dédiées au portage et demandez-y comment
248 démarrer. Finalement, si vous êtes intéressé par la documentation ou
249 l'assurance qualité (QA), vous pouvez contacter les responsables qui
250 travaillent déjà sur ces tâches et proposer des correctifs et des
254 <sect id="registering">S'enregistrer comme responsable Debian
256 Avant de décider de devenir responsable Debian, il vous faudra lire toute la
257 documentation disponible dans le <url id="&url-newmaint;" name="coin du nouveau
258 responsable">. Elle décrit toutes les étapes préparatoires qu'il vous faudra
259 franchir avant de déposer votre candidature.
261 Par exemple, avant d'être candidat, il vous faudra lire le <url
262 id="&url-social-contract;" name="contrat social Debian">. Devenir responsable
263 Debian implique que vous adhériez à ce contrat social et que vous vous engagiez
264 à le soutenir ; il est très important que les responsables soient en
265 accord avec les principes fondamentaux qui animent le projet &debian-formal;.
266 Lire le <url id="&url-gnu-manifesto;" name="Manifeste GNU"> est aussi une bonne
269 Le processus d'enregistrement a pour but de vérifier votre identité, vos
270 intentions et vos compétences. Le nombre de personnes travaillant pour
271 &debian-formal; a atteint &number-of-maintainers; et notre système est utilisé
272 dans plusieurs endroits très importants : nous devons rester vigilants
273 pour éviter un acte malveillant. C'est pourquoi nous contrôlons les nouveaux
274 responsables avant de leur donner un compte sur nos serveurs et de les autoriser à
275 ajouter des paquets dans l'archive.
277 Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail
278 et que vous serez un bon contributeur. Pour cela, vous pourrez proposer des correctifs
279 par le système de suivi des bogues (BTS) ou maintenir un paquet parrainé
280 pendant un temps. Nous attendons aussi des contributeurs qu'ils soient
281 intéressés par le projet dans son ensemble et pas uniquement par leurs propres
282 paquets. Si vous pouvez aider d'autres responsables en fournissant des
283 informations sur un bogue ou même avec un correctif, faites-le !
285 Pour votre candidature, vous devrez être familiarisé avec la philosophie du
286 projet Debian et avec sa documentation technique. Il vous faudra aussi une clé
287 GnuPG signée par un responsable Debian. Si votre clé GnuPG n'est pas encore
288 signée, vous devriez essayer de rencontrer un responsable Debian pour le faire.
289 La <url id="&url-gpg-coord;" name="page de coordination des signatures de clé
290 GnuPG"> devrait vous aider à trouver un responsable Debian près de chez vous.
291 (Si vous ne trouvez pas de responsable près de chez vous, il existe un second
292 moyen pour valider votre identité. Vous pouvez envoyer une photo d'identité
293 signée avec votre clé GnuPG. Privilégiez tout de même la clé GnuPG signée pour
294 valider une identité. Reportez-vous à la <url id="&url-newmaint-id;" name="page
295 d'identification"> pour en savoir plus sur ces deux options).
298 Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin d'une clé
299 OpenPGP pour signer et vérifier les mises à jour de paquets. Vous lirez la
300 documentation du logiciel de cryptographie que vous utiliserez car elle
301 contient des informations indispensables pour la sécurité de votre clé. Les
302 défaillances de sécurité sont bien plus souvent dues à des erreurs humaines
303 qu'à des problèmes logiciels ou à des techniques d'espionnage avancées. Voir
304 <ref id="key-maint"> pour plus d'informations sur la gestion de votre clé
307 Debian utilise <prgn>GNU Privacy Guard</prgn> (paquet <package>gnupg</package>
308 version 1 ou supérieure) comme standard de base. Vous pouvez aussi utiliser une
309 autre implémentation d'OpenPGP. OpenPGP est un standard ouvert basé sur la <url
310 id="&url-rfc2440;" name="RFC 2440">.
312 L'algorithme à clé publique recommandé pour les développements Debian est DSA
313 (parfois appelé « DSS » ou « DH\ElGamal »). Vous pouvez
314 aussi utiliser d'autres types de clés. La longueur de votre clé doit être au
315 minimum de 1024 bits ; il n'y a pas de raison d'utiliser une clé plus
316 courte et le faire serait beaucoup moins sûr. Votre clé doit être signée avec
317 votre propre identifiant ; cela évite les falsifications. <prgn>GNU
318 Privacy Guard</prgn> le fait automatiquement.
320 Si votre clé publique n'est pas sur un serveur public tel que &pgp-keyserv;,
321 reportez-vous à la documentation disponible localement dans &file-keyservs;.
322 Cette documentation explique comment mettre votre clé publique sur un serveur.
323 L'équipe <em>New maintainer</em> mettra votre clé publique sur les serveurs de
324 clés si elle n'y est pas déjà.
326 Certains pays limitent l'usage des logiciels de cryptographie. Cela ne devrait
327 cependant pas avoir d'impact sur l'activité d'un responsable de paquet car il
328 peut être tout à fait légal d'utiliser des logiciels de cryptographie pour
329 l'authentification plutôt que pour le chiffrement. &debian-formal; ne nécessite
330 en aucune façon l'utilisation de chiffrement. Si vous vivez dans un pays où
331 l'utilisation de la cryptographie pour authentification est interdite,
332 contactez-nous pour que nous prenions des dispositions particulières.
334 Pour faire acte de candidature, il vous faut un responsable Debian qui vérifiera
335 votre candidature (un <em>avocat</em>). Après avoir contribué au projet Debian
336 pendant un temps, quand vous choisissez de devenir un responsable Debian
337 officiel, un responsable déjà enregistré avec qui vous aurez travaillé dans les
338 derniers mois devra exprimer que, d'après lui, vous pouvez contribuer avec
339 succès au projet Debian.
341 Quand vous avez trouvez un <em>avocat</em>, quand votre clé GnuPG est signée et
342 quand vous avez déjà contribué au projet, vous êtes prêt à faire
343 acte de candidature. Il vous suffit pour cela de vous enregistrer sur notre
344 <url id="&url-newmaint-apply;" name="page de candidature">. Ensuite, votre
345 avocat devra confirmer votre candidature. Quand il aura accompli cette tâche,
346 un responsable de candidature<footnote><p>Application manager</footnote> sera
347 désigné pour vous accompagner dans le processus d'enregistrement. Vous pouvez
348 toujours consulter le <url id="&url-newmaint-db;" name="tableau de bord des
349 candidatures"> pour connaître l'état de votre candidature.
351 Pour en savoir plus, consultez le <url id="&url-newmaint;" name="coin des
352 nouveaux responsables"> sur le site Debian. Assurez-vous de bien connaître les
353 étapes nécessaires au processus d'enregistrement avant de vous porter candidat.
354 Vous gagnerez beaucoup de temps si vous êtes bien préparé.
357 <sect id="mentors">Mentors et parrains Debian
359 La liste de diffusion &email-debian-mentors; a été créée pour les responsables
360 débutants qui cherchent de l'aide pour leur première création de paquet ainsi
361 que pour des problèmes spécifiques aux développeurs. Tout responsable débutant
362 est invité à s'y inscrire (voir <ref id="mailing-lists"> pour plus de détails).
364 Ceux qui préfèrent une aide personnalisée (via une correspondance privée)
365 doivent aussi poster dans cette liste, un développeur expérimenté se portera
366 volontaire pour les aider.
368 Si vos paquets sont prêts à être intégrés mais que vous attendiez le
369 résultat de votre candidature, vous pouvez chercher un parrain qui téléchargera
370 les paquets à votre place. Les parrains sont des responsables Debian officiels
371 volontaires pour examiner et télécharger vos paquets. Vous pouvez
372 demander un parrainage à l'adresse <url id="&url-sponsors;">.
374 Si vous désirez être mentor ou parrain, reportez-vous à <ref id="newmaint">.
377 <chapt id="developer-duties">Les charges du responsable Debian
379 <sect id="user-maint">Mise à jour de vos références Debian
381 Il existe une base de données LDAP contenant des informations concernant les
382 développeurs Debian à <url id="&url-debian-db;">. Vous devriez y entrer vos
383 informations et les mettre à jour quand elles changent. Le plus important est de
384 vous assurer que l'adresse vers laquelle est redirigée votre adresse debian.org
385 est toujours à jour, de même que l'adresse à laquelle vous recevez votre
386 abonnement à debian-private si vous choisissez d'être abonné à cette liste.
388 Pour plus d'informations à propos de cette base de données, veuillez consulter
391 <sect id="key-maint">Gérer votre clé publique
393 Soyez très vigilant en utilisant votre clé privée. Ne la placez pas sur un
394 serveur public ou sur des machines multi-utilisateurs telles que les serveurs
395 Debian (voir <ref id="server-machines">). Sauvegardez vos clés et gardez-en une
396 copie hors connexion. Lisez la documentation fournie avec votre logiciel et la
397 <url id="&url-pgp-faq;" name="FAQ PGP">.
399 Si vous ajoutez des signatures ou des identifiants à votre clé publique, vous
400 pouvez mettre à jour le porte-clés Debian en envoyant votre clé publique à
401 <tt>&keyserver-host;</tt>. Si vous voulez ajouter ou supprimer une clé, envoyez
402 un courrier à &email-debian-keyring;. Les procédures d'extraction de clé
403 décrites dans <ref id="registering"> s'appliquent ici.
405 Vous pouvez trouver une présentation approfondie de la gestion de clé Debian
406 dans la documentation du paquet <package>debian-keyring</package>.
408 <sect id="voting">Voter
410 Bien que Debian ne soit pas vraiment une démocratie, nous disposons d'un
411 processus démocratique pour élire nos chefs et pour approuver les résolutions
412 générales. Ces procédures sont définies par la <url id="&url-constitution;"
413 name="charte Debian">.
415 En dehors de l'élection annuelle du chef, les votes ne se tiennent pas
416 régulièrement et ils ne sont pas entrepris à la légère. Chaque proposition est
417 tout d'abord discutée sur la liste de diffusion &email-debian-vote; et elle a
418 besoin de plusieurs approbations avant que le secrétaire du projet n'entame la
421 Vous n'avez pas besoin de suivre les discussions précédant le vote car le
422 secrétaire enverra plusieurs appels au vote sur la liste
423 &email-debian-devel-announce; (et tous les développeurs devraient être inscrits
424 à cette liste). La démocratie ne fonctionne pas si les personnes ne prennent pas
425 part au vote, c'est pourquoi nous encourageons tous les développeurs à voter. Le
426 vote est conduit par messages signés ou chiffrés par GPG.
429 La liste de toutes les propositions (passées et présentes) est disponible à la
430 page <url id="&url-vote;" name="Informations sur les votes Debian">, ainsi que
431 des informations complémentaires sur la procédure à suivre pour effectuer une
432 proposition, la soutenir et voter pour elle.
434 <sect id="inform-vacation">Prendre des vacances courtoisement
436 Il est courant pour les développeurs de s'absenter, que ce
437 soit pour des vacances prévues ou parce qu'ils sont submergés de travail. La
438 chose importante à noter est que les autres développeurs ont besoin de savoir
439 que vous êtes en vacances pour qu'ils puissent agir en conséquence si un
440 problème se produit pendant vos vacances.
442 Habituellement, cela veut dire que les autres développeurs peuvent faire des NMU
443 (voir <ref id="nmu">) sur votre paquet si un gros problème (bogues empêchant
444 l'intégration dans la distribution, mise à jour de sécurité, etc.) se produit pendant que vous êtes en
445 vacances. Parfois, ce n'est pas très important, mais il est de
446 toute façon approprié d'indiquer aux autres que vous n'êtes pas disponible.
448 Il y a deux choses à faire pour informer les autres développeurs.
449 Premièrement, envoyez un courrier électronique à &email-debian-private; en
450 commençant le sujet de votre message par « [VAC] »<footnote>Ainsi, le
451 message peut être facilement filtré par les personnes qui ne veulent pas lire
452 ces annonces de vacances.</footnote> et donnez la période de vos
453 vacances. Vous pouvez également donner quelques instructions pour
454 indiquer comment agir si un problème survenait.
456 L'autre chose à faire est de vous signaler comme « en
457 vacances »<footnote><p><em>on vacation</em> en anglais</footnote> dans la
458 <qref id="devel-db">base de données Debian LDAP</qref> (l'accès à cette
459 information est réservé aux développeurs). N'oubliez pas de retirer votre
460 indicateur « en vacances » lorsque celles-ci sont terminées !
462 <sect id="upstream-coordination">Coordination avec les développeurs amont
464 Une grande part de votre travail de responsable Debian sera de rester en contact
465 avec les développeurs amont. Parfois, les utilisateurs établissent des
466 rapports de bogue qui ne sont pas spécifiques à Debian. Vous devez transmettre
467 ces rapports de bogue aux développeurs amont pour qu'ils soient corrigés dans
468 les prochaines versions.
470 Bien qu'il ne soit pas de votre responsabilité de corriger les
471 bogues non spécifiques à Debian, vous pouvez le faire si vous en êtes capable.
472 Quand vous faites de telles corrections, assurez-vous de les envoyer
473 également au développeur amont. Les utilisateurs et responsables
474 Debian proposent souvent des correctifs pour corriger des bogues amont, il
475 vous faudra alors évaluer ce correctif puis le transmettre aux développeurs
478 Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
479 paquet conforme à la charte Debian, alors vous devriez proposer un correctif
480 aux développeurs amont pour qu'il soit inclus dans leur version. Ainsi, vous
481 n'aurez plus besoin de modifier les sources lors des mises à jour amont
482 suivantes. Quels que soient les changements dont vous avez besoin, il faut
483 toujours essayer de rester dans la lignée des sources amont.
485 <sect id="rc-bugs">Comment gérer les bogues empêchant l'intégration du
486 paquet dans la distribution ?
488 Habituellement, vous devriez traiter les rapports de bogue sur vos paquets tel
489 que cela est décrit dans <ref id="bug-handling">. Cependant, il y a une
490 catégorie spéciale de bogues qui nécessite particulièrement votre
491 attention : les bogues empêchant l'intégration du paquet dans la
492 distribution<footnote>Traduction de l'anglais <em>Release-critical bug (RC
493 Bugs)</em></footnote>. Tous les rapports de bogue de gravité <em>critique</em>,
494 <em>grave</em> et <em>sérieuse</em><footnote>Respectivement <em>critical</em>,
495 <em>grave</em> et <em>serious</em> en anglais</footnote> sont considérés comme
496 ayant un impact sur la présence du paquet dans la prochaine version stable de
497 Debian. Ces bogues peuvent retarder la diffusion d'une distribution Debian
498 ou peuvent justifier la suppression d'un paquet d'une distribution gelée.
499 C'est pourquoi ces bogues doivent être corrigés au plus vite.
501 Les développeurs faisant partie de l'équipe d'<url id="&url-debian-qa;"
502 name="assurance qualité Debian"> surveillent ces bogues et essaient de vous
503 aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas corriger un bogue de
504 ce type dans les deux semaines, vous devriez soit demander de l'aide en
505 envoyant un courrier à l'équipe d'assurance qualité (<em>QA group</em>) à
506 &email-debian-qa;, soit expliquer vos difficultés et présenter un plan pour
507 corriger le problème en répondant au rapport de bogue concerné. Si rien n'est
508 fait, des personnes de l'équipe d'assurance qualité pourraient chercher à
509 corriger votre paquet (voir <ref id="nmu">) après avoir tenté de vous contacter
510 (ils pourraient attendre moins longtemps que d'habitude pour faire leur mise à
511 jour s'il n'y a pas trace d'activité récente de votre part dans le système de
517 Si vous choisissez de quitter le projet Debian, procédez comme suit :
518 <enumlist compact="compact">
519 <item><p>abandonnez tous vos paquets comme décrit dans <ref
520 id="orphaning"> ;</item>
521 <item><p>envoyez un courrier électronique à &email-debian-private; indiquant
522 pourquoi vous quittez le projet ;</item>
523 <item><p>signalez aux responsables du porte-clés Debian que vous quittez le
524 projet en écrivant à &email-debian-keyring;.</item>
529 <chapt id="resources">Ressources pour le responsable Debian
531 Dans ce chapitre, vous trouverez une brève description des listes de diffusion,
532 des machines Debian qui seront à votre disposition en tant que responsable
533 Debian ainsi que toutes les autres ressources à votre disposition pour vous
534 aider dans votre travail de responsable.
536 <sect id="mailing-lists">Les listes de diffusion
538 Une grande partie des discussions entre les développeurs Debian (et les
539 utilisateurs) est gérée par un vaste éventail de listes de diffusion que nous
540 hébergeons à <tt><url id="http://&lists-host;/" name="&lists-host;"></tt>.
541 Pour en savoir plus sur comment s'abonner ou se désabonner, comment envoyer un
542 message et comment ne pas en envoyer, comment retrouver d'anciens messages et
543 comment les rechercher, comment contacter les responsables des listes et pour
544 sevoir d'autres informations sur les listes de diffusion, veuillez lire <url
545 id="&url-debian-lists;">. Cette section ne couvrira que les aspects des listes
546 de diffusion qui ont un intérêt particulier pour les développeurs.
548 <sect1 id="mailing-lists-rules">Rêgles de base d'utilisation
550 Lorsque vous répondez sur une liste de diffusion, veuillez ne pas envoyer de
551 copie (<tt>CC</tt>) à l'auteur d'origine sauf s'il le demande explicitement.
552 Toute personne envoyant un message à une liste de diffusion devrait la suivre
553 pour voir les réponses.
555 Le multi-postage (cross-posting) (envoyer le même message à plusieurs listes)
556 est découragé. Comme toujours sur le net, veuillez réduire la citation des
557 articles auxquels vous répondez. En général, veuillez adhérez aux conventions
558 usuelles d'envoi de messages.
560 Veuillez lire le <url name="code de conduite"
561 id="&url-debian-lists;#codeofconduct"> pour plus d'informations.
563 <sect1 id="core-devel-mailing-lists">Principales listes pour les
566 Les principales listes de diffusion de Debian que les développeurs
567 devraient suivre sont :
569 <item>&email-debian-devel-announce;, utilisée pour les annonces importantes
570 faites aux responsables. Tous les responsables Debian sont censés être
571 inscrits à cette liste,</item>
572 <item>&email-debian-devel;, utilisée pour discuter de diverses questions
573 techniques relatives au développement,</item>
574 <item>&email-debian-policy; où l'on discute et vote les modifications de la
575 charte Debian,</item>
576 <item>&email-debian-project;, utilisée pour discuter de questions non
580 Il existe d'autres listes de diffusion spécialisées dans différents thèmes.
581 Reportez-vous à la page <url id="http://&lists-host;/"> pour en obtenir
584 <sect1 id="mailing-lists-special">Listes spéciales
586 &email-debian-private; est une liste de diffusion destinée aux discussions
587 privées entre développeurs Debian. Elle doit être utilisée pour tout message
588 qui ne doit pas être publié, quelle qu'en soit la raison. C'est une liste à
589 faible trafic et les utilisateurs sont priés de ne l'utiliser qu'en cas de
590 réelle nécessité. De plus, il ne faut <em>jamais</em> faire suivre un courrier
591 de cette liste à qui que ce soit. Pour des raisons évidentes, les archives de
592 cette liste ne sont pas disponibles sur la toile. Vous pouvez les consulter en
593 visitant le répertoire <file>~debian/archive/debian-private</file> avec votre
594 compte sur <tt>lists.debian.org</tt>.
596 &email-debian-email; est une liste de diffusion fourre-tout. Elle est utilisée
597 pour les correspondances relatives à Debian qu'il serait utile d'archiver,
598 telles que des échanges avec les auteurs amont à propos de licences, de bogues
599 ou encore des discussions sur le projet avec d'autres personnes.
601 <sect1 id="mailing-lists-new">Demander une nouvelle liste relative au développement
603 Avant de demander un liste de diffusion liée au développement d'un paquet (ou
604 d'un petit groupe de paquets liés), veuillez considérer si l'utilisation d'un
605 alias (via un fichier .forward-aliasname sur master.debian.org, ce qui se
606 traduit en une adresse raisonnablement agréable
607 <var>you-aliasname@debian.org</var>) ou une liste de diffusion auto-gérée sur
608 <qref id="alioth">Alioth</qref> serait plus appropriée.
610 Si vous décidez qu'une liste de diffusion standard sur lists.debian.org est
611 vraiment ce que vous voulez, lancez-vous et faites une demande en suivant <url
612 name="le guide" id="&url-debian-lists-new;">.
615 <sect id="irc-channels">Canaux IRC
617 Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont
618 principalement hébergés sur le réseau <url id="&url-openprojects;"
619 name="freenode"> (anciennement connu sous le nom de Open Projects Network).
620 L'entrée DNS <tt>irc.debian.org</tt> est simplement un alias vers
621 <tt>irc.freenode.net</tt>.
623 Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un
624 canal important, généraliste, où les utilisateurs peuvent trouver des nouvelles
625 récentes dans le sujet et qui est administré par des robots. <em>#debian</em>
626 est destiné aux anglophones ; il existe également <em>#debian.de</em>,
627 <em>#debian-fr</em>, <em>#debian-br</em> et d'autres canaux avec des noms
628 semblables pour les personnes parlant d'autres langues.
630 Le canal principal pour le développement Debian est <em>#debian-devel</em>.
631 C'est un canal très actif avec habituellement plus de 150 personnes connectées
632 en permanence. C'est un canal pour les personnes qui travaillent sur Debian, ce
633 n'est pas un canal d'aide (il existe <em>#debian</em> pour cela). Il est
634 cependant ouvert à tous ceux qui veulent écouter (et apprendre). Le sujet est
635 toujours rempli d'informations intéressantes.
637 Comme <em>#debian-devel</em> est un canal ouvert, vous ne devriez pas y parler
638 de problèmes discutés sur &email-debian-private;. Il existe un canal protégé
639 par clé <em>#debian-private</em> dans ce but. La clé est disponible dans les
640 archives de debian-private à
641 <file>master.debian.org:&file-debian-private-archive;</file>, effectuez
642 simplement un <prgn>zgrep</prgn> avec <em>#debian-private</em> dans tous les
645 Il existe d'autres canaux dédiés à des sujets spécifiques. <em>#debian-bugs</em>
646 est utilisé pour la coordination des <em>chasses aux bogues</em>.
647 <em>#debian-boot</em> est utilisé pour la coordination du travail sur les
648 disquettes de démarrage (i.e., l'installeur). <em>#debian-doc</em> est utilisé
649 occasionnellement pour travailler sur la documentation comme celle que vous
650 lisez actuellement. D'autres canaux sont dédiés à une architecture ou un
651 ensemble de paquets : <em>#debian-bsd</em>, <em>#debian-kde</em>,
652 <em>#debian-jr</em>, <em>#debian-edu</em>, <em>#debian-sf</em> (paquet
653 SourceForge), <em>#debian-oo</em> (paquet OpenOffice), etc.
655 Certains canaux pour développeurs non anglophones existent, par exemple,
656 <em>#debian-devel-fr</em> pour les francophones intéressés dans le
657 développement de Debian.
659 Il existe également des canaux dédiés pour Debian sur d'autres réseaux IRC,
660 notamment sur le réseau IRC <url name="Open and free technology community
661 (OFTC)" id="http://www.oftc.net/">.
664 <sect id="doc-rsrcs">Documentation
666 Ce document contient beaucoup d'informations très utiles aux développeurs
667 Debian, mais il ne peut pas tout contenir. La plupart des autres documents
668 intéressants sont référencés dans le <url id="&url-devel-docs;" name="coin
669 du développeur Debian">. Prenez le temps de parcourir tous les liens, vous
670 apprendrez encore beaucoup de choses.
673 <sect id="server-machines">Les serveurs Debian
675 Debian possède plusieurs ordinateurs employés comme serveurs, dont la plupart hébergent
676 les fonctions critiques du projet Debian. La plupart des machines sont
677 utilisées pour des activités de portage et elles ont toutes un accès permanent
680 La plupart des machines peuvent être utilisées par les développeurs
681 tant qu'ils respectent les règles définies dans la <url
682 id="&url-dmup;" name="charte d'utilisation des machines Debian">.
684 Dans l'ensemble, vous pouvez faire usage de ces machines pour des buts relatifs
685 à Debian comme vous l'entendez. Veuillez cependant être gentil avec les
686 administrateurs système et ne pas utiliser de grandes quantités d'espace
687 disque, de ressource réseau ou CPU sans obtenir auparavant l'accord des
688 administrateurs. Habituellement, ces machines sont administrées par des
691 Veuillez prendre soin de votre mot de passe Debian ainsi que des clés SSH
692 installées sur les machines Debian. Évitez les méthodes de connexion ou d'envoi
693 de données qui envoient les mots de passe en clair par l'Internet comme telnet,
696 Veuillez ne pas déposer de données non relatives à Debian sur les serveurs
697 Debian à moins que vous n'ayez préalablement obtenu la permission de le faire.
699 La liste actuelle des machines Debian est disponible à <url
700 id="&url-devel-machines;">. Cette page web contient les noms des machines, les
701 informations de contact, les informations sur qui peut s'y connecter, les clés
704 Si vous avez un problème en utilisant un serveur Debian et si vous estimez que
705 les administrateurs système devraient en être avertis, l'équipe des
706 administrateurs système peut être jointe à
707 <email>debian-admin@lists.debian.org</email>.
709 Si votre problème est lié à un certain service ou n'est pas lié au système
710 (paquet à supprimer de l'archive ou suggestion pour le site web par exemple),
711 il vous faudra en général ouvrir un rapport de bogue sur un
712 « pseudo-paquet ». Reportez-vous à la section <ref id="submit-bug">
713 pour connaître la procédure à suivre.
715 <sect1 id="servers-bugs">Le serveur pour les rapports de bogues
717 <tt>&bugs-host;</tt> est le serveur maître du système de suivi des bogues
718 (BTS<footnote><p>Système de suivi des bogues se dit <em>Bug Tracking
719 System</em> en anglais</footnote>). Si vous envisagez de manipuler les rapports
720 de bogue ou d'en faire une analyse statistique, ce sera le bon endroit pour le
721 faire. Informez la liste &email-debian-devel; de votre intention avant
722 d'implémenter quoi que ce soit afin d'éviter un travail en double ou un
723 gaspillage de temps machine.
725 Tous les développeurs Debian ont un compte sur
726 <tt>&bugs-host;</tt>.
728 <sect1 id="servers-ftp-master">Le serveur ftp-master
730 Le serveur <tt>ftp-master.debian.org</tt> est le serveur maître de l'archive
731 Debian (exception faite des paquets non-US). En général, les mises à jour de
732 paquets se font sur ce serveur. Reportez-vous à la section <ref id="upload">
735 Les problèmes avec l'archive Debian FTP doivent généralement être rapportés
736 comme bogues sur le pseudo-paquet <package>ftp.debian.org</package> ou par
737 courrier électronique à &email-ftpmaster; ; reportez-vous à la section
738 <ref id="archive-manip"> pour connaître la procédure à suivre.
740 <sect1 id="servers-non-us">Le serveur non-US
742 Le serveur non-US <tt>non-us.debian.org</tt> est le serveur maître de la partie
743 non-US de l'archive Debian. Si vous avez besoin d'envoyer un paquet dans l'une
744 des sections non-US, envoyez-le vers ce serveur. Reportez-vous à la section
745 <ref id="upload-non-us"> pour en savoir plus.
747 Les problèmes avec l'archive de paquets non-US doivent généralement être
748 rapportés comme bogues sur le pseudo-paquet <package>nonus.debian.org</package>
749 (remarquez l'absence de trait d'union entre "non" et "us" dans le nom du
750 pseudo-paquet — c'est dû à la compatibilité descendante). Rappelez-vous
751 de vérifier si quelqu'un n'aurait pas déjà rempli un rapport de bogue
752 concernant le problème sur le <url id="http://&bugs-host;/nonus.debian.org"
753 name="système de suivi des bogues">.
755 <sect1 id="servers-www">Le serveur www-master
757 Le serveur web principal est <tt>www-master.debian.org</tt>. Il héberge les
758 pages web officielles, la façade de Debian pour la plupart des débutants.
760 Si vous rencontrez un problème avec un serveur web Debian, vous devez
761 généralement envoyer un rapport de bogue sur le pseudo-paquet
762 <package>www.debian.org</package>. Vérifiez d'abord sur le <url
763 id="http://&bugs-host;/www.debian.org" name="système de suivi des bogues">
764 que personne ne l'a déjà rapporté avant vous.
766 <sect1 id="servers-people">Le serveur web people
768 <tt>people.debian.org</tt> est le serveur utilisé par les développeurs pour
769 leurs pages concernant Debian.
771 Si vous avez des informations spécifiques Debian que vous voulez rendre
772 disponibles sur le web, vous pouvez le faire en les plaçant dans le répertoire
773 <file>public_html</file> de votre répertoire personnel sur
774 <tt>people.debian.org</tt>. Elles seront accessibles à l'adresse
775 <tt>http://people.debian.org/~<var>votre-user-id</var>/</tt>.
777 Vous ne devriez utiliser que cet emplacement particulier car il sera sauvegardé
778 alors que sur les autres serveurs, ce ne sera pas le cas.
780 Habituellement, la seule raison pour utiliser un serveur différent est que vous
781 avez besoin de publier des informations soumises aux restrictions d'exportation
782 américaines, dans ce cas, vous pouvez utiliser l'un des autres serveurs situés
783 en dehors des États-Unis, comme le serveur mentionné ci-dessus
784 <tt>non-us.debian.org</tt>.
786 Veuillez envoyer un courrier à &email-debian-devel; si vous avez une question.
788 <sect1 id="servers-cvs">Le serveur CVS
790 Notre serveur CVS est situé sur <tt>cvs.debian.org</tt>.
792 Si vous avez besoin d'un serveur CVS accessible par tous pour, par exemple,
793 coordonner le travail de plusieurs développeurs sur un paquet, vous pouvez
794 demander un espace CVS sur ce serveur.
796 Le serveur <tt>cvs.debian.org</tt> autorise les accès CVS locaux, les accès en
797 lecture seule pour les connexions client-serveur anonymes et les accès
798 client-serveur complets pour les connexions <prgn>ssh</prgn>. L'espace CVS peut
799 aussi être consulté par la toile à l'adresse <url id="&url-cvsweb;">.
801 Pour obtenir un espace CVS, envoyez une demande à l'adresse &email-debian-admin;
802 en précisant le nom de l'espace, le compte Debian propriétaire du répertoire
803 racine et pourquoi vous en avez besoin.
806 <sect id="devel-db">La base de données des développeurs
808 La base de données des développeurs à <url id="&url-debian-db;"> est un annuaire
809 LDAP de gestion des informations des développeurs Debian. Vous pouvez utiliser
810 cette ressource pour rechercher la liste des développeurs Debian. Une partie de
811 ces informations est également disponible à travers le service <prgn>finger</prgn> sur les
812 serveurs Debian, essayez <prgn>finger yourlogin@debian.org</prgn> pour voir ce
815 Les développeurs peuvent <url name="se connecter à la base de données"
816 id="&url-debian-db-login;"> pour modifier différentes informations les
817 concernant, comme :
819 <item>l'adresse de suivi pour leur adresse debian.org,
820 <item>l'abonnement à debian-private,
821 <item>l'état en vacances ou non,
822 <item>des informations personnelles comme les adresse, pays, latitude et
823 longitude de l'endroit où ils vivent pour utilisation dans la <url
824 name="carte mondiale des développeurs Debian" id="&url-worldmap">,
825 numéros de téléphone et de fax, surnom IRC et page web,
826 <item>le mot de passe et le shell préféré sur les machines du projet Debian.
829 La plupart des informations ne sont naturellement pas accessibles publiquement.
830 Pour plus d'informations, veuillez lire la documentation en ligne que vous
831 pouvez trouver à <url id="&url-debian-db-doc;">.
834 Il est également possible d'envoyer ses clés SSH pour les utiliser pour
835 autorisation sur les machines Debian officielles et même d'ajouter de nouvelles
836 entrées DNS du type *.debian.net. Ces fonctionnalités sont documentées à <url
837 id="&url-debian-db-mail-gw;">.
840 <sect id="archive">L'archive Debian
842 La distribution &debian-formal; est composée d'un grand nombre de paquets
843 (fichiers <tt>.deb</tt> : actuellement, à peu près &number-of-pkgs;) et de
844 quelques autres fichiers (comme la documentation et des images des disquettes
847 Voici un exemple d'arborescence pour une archive Debian complète :
849 &sample-dist-dirtree;
851 Comme vous pouvez le voir, le répertoire racine contient deux répertoires,
852 <file>dists/</file> et <file>pool/</file>. Le second est un ensemble de
853 répertoires où sont stockés les paquets. Ceux-ci sont manipulés grâce à la base
854 de données de l'archive et aux logiciels qui l'accompagnent. Le premier
855 répertoire contient les distributions <em>stable</em>, <em>testing</em> et
856 <em>unstable</em>. Les fichiers <file>Packages</file> et <file>Sources</file>
857 qui se trouvent dans les répertoires de distribution peuvent faire référence à
858 des fichiers du répertoire <file>pool/</file>. Le découpage en sous-répertoires
859 est identique d'un répertoire de distribution à l'autre . Ce que nous
860 exposerons ci-dessous pour la distribution <em>stable</em> est également
861 applicable aux distributions <em>unstable</em> et <em>testing</em>.
863 Le répertoire <file>dists/stable</file> contient trois répertoires nommés
864 <file>main</file>, <file>contrib</file> et <file>non-free</file>.
866 Dans chacune de ces sections, se trouve un répertoire contenant les paquets
867 sources (<file>source/</file>) et un répertoire pour chaque architecture
868 acceptée (<file>binary-i386/</file>, <file>binary-m68k/</file>, etc.).
870 La section <em>main</em> contient d'autres répertoires destinés aux images de
871 disquettes et à plusieurs documents essentiels pour installer la distribution
872 Debian sur une architecture particulière (<file>disk-i386/</file>,
873 <file>disk-m68k/</file>, etc.).
877 La section <em>main</em> constitue la <strong>distribution &debian-formal;
878 officielle</strong>. Elle est officielle parce qu'elle est entièrement conforme
879 à toutes nos recommandations. Les deux autres sections divergent de ces
880 recommandations à différents degrés, elles <strong>ne</strong> font donc <strong>pas</strong>
881 officiellement partie de &debian-formal;.
883 Chaque paquet de la section <em>main</em> doit être conforme aux <url
884 id="&url-dfsg;" name="directives Debian pour le logiciel
885 libre"><footnote>Debian Free Software Guidelines</footnote> et à toutes les
886 autres recommandations décrites dans <url id="&url-debian-policy;" name="la
887 charte Debian"><footnote>Debian Policy Manual</footnote>. Les
888 DFSG<footnote><em>Debian Free Software Guidelines</em></footnote> constituent
889 notre définition de « logiciel libre ». Reportez-vous à la <em>charte
890 Debian</em> pour en savoir plus.
892 Les paquets de la section <em>contrib</em> doivent être conformes aux DFSG, mais
893 ne respectent pas d'autres contraintes. Ils peuvent, par exemple, dépendre de
894 paquets de la section <em>non-free</em>.
896 Les paquets qui ne sont pas conformes aux DFSG sont rangés dans la section
897 <em>non-free</em>. Bien que nous supportions l'usage de ces paquets et qu'ils
898 bénéficient de nos infrastructures (système de suivi des bogues, listes de
899 diffusion, etc.), ces paquets <em>non-free</em> ne font pas partie de la
902 La <em>charte Debian</em> donne des définitions plus précises pour ces trois
903 sections. Les paragraphes précédents ne constituent qu'une introduction.
905 La séparation de l'archive en trois sections est importante pour toute personne
906 qui désire distribuer Debian, que ce soit par serveur FTP ou sur cédérom. Il
907 suffit de distribuer les sections <em>main</em> et <em>contrib</em> pour éviter
908 tout problème légal. Certains paquets de la section <em>non-free</em>
909 interdisent leur distribution à titre commercial par exemple.
911 D'un autre côté, un distributeur de cédérom pourra facilement vérifier
912 la licence de chacun des paquets de la section <em>non-free</em> et
913 inclure tous les paquets qu'il lui sera autorisé (dans
914 la mesure où cela varie énormément d'un distributeur à l'autre, ce travail ne
915 peut être fait par les développeurs Debian).
917 Notez que le terme « section » est également utilisé pour faire
918 référence aux catégories qui simplifient l'organisation des paquets
919 disponibles et leur recherche, e.g. <em>admin</em>, <em>net</em>, <em>utils</em> etc. Il
920 fut un temps où ces sections (sous-sections, plutôt) existaient sous la forme
921 de sous-répertoires dans l'archive Debian. Actuellement, elles n'existent plus
922 que dans le champ en-tête « Section » des paquets.
924 <sect1>Les architectures
926 À ses débuts, le noyau Linux existait uniquement pour les architectures Intel
927 x86 ; il en était de même pour Debian. Linux devenant de plus en plus
928 populaire, il a été porté vers d'autres architectures.
930 Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC,
931 Motorola, 680x0 (Atari, Amiga, et Macintosh), MIPS et PowerPC. Le noyau 2.2
932 reconnaît de nouvelles architectures, comme ARM et UltraSPARC. Puisque Linux
933 reconnaît ces architectures, le projet Debian a décidé qu'il devait également les
934 accepter. C'est pourquoi plusieurs portages sont en cours ; en fait, il y
935 a aussi des portages vers d'autres noyaux. À côté d'<em>i386</em> (notre nom
936 pour Intel x86), nous avons, au moment où j'écris, <em>m68k</em>,
937 <em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
938 <em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>, <em>mips</em>,
939 <em>mipsel</em> et <em>sh</em>.
941 &debian-formal; 1.3 est disponible uniquement pour <em>i386</em>. Debian 2.0
942 reconnaît les architectures <em>i386</em> et <em>m68k</em>. Debian 2.1 reconnaît
943 les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et
944 <em>sparc</em>. Debian 2.2 accepte en plus les architectures
945 <em>powerpc</em> et <em>arm</em>. Debian 3.0 accepte cinq
946 nouvelles architectures : <em>ia64</em>, <em>hppa</em>, <em>s390</em>,
947 <em>mips</em> et <em>mipsel</em>.
949 Pour chaque portage, vous trouverez des informations destinées aux développeurs
950 et utilisateurs sur la page <url id="&url-debian-ports;" name="Portage
955 Il existe deux types de paquets Debian : les paquets sources et les paquets
958 Les paquets sources sont constitués de deux ou trois fichiers : un fichier
959 <file>.dsc</file> et soit un fichier <file>.tar.gz</file>, soit un fichier
960 <file>.orig.tar.gz</file> et un fichier <file>.diff.gz</file>.
962 Si un paquet est développé spécifiquement pour le projet Debian et n'est pas
963 distribué en dehors de Debian, il n'y a qu'un fichier <file>.tar.gz</file> qui
964 contient les sources du programme. Si un paquet est distribué ailleurs, le
965 fichier <file>.orig.tar.gz</file> contient ce que l'on appelle <em>code source
966 amont</em>, c'est-à-dire, le code source distribué par le <em>mainteneur
967 amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le fichier
968 <file>.diff.gz</file> contient les modifications faites par le responsable
971 Le fichier <file>.dsc</file> liste tous les fichiers sources avec leurs sommes
972 de contrôle (<prgn>md5sums</prgn>) et quelques informations supplémentaires
973 concernant le paquet (responsable, version, etc.).
975 <sect1>Les distributions
977 L'organisation des répertoires présentée précédemment est elle-même englobée par
978 les <em>répertoires des distributions</em>. Chaque distribution est incluse
979 dans le répertoire <file>pool</file> à la racine de l'archive Debian.
981 Pour résumer, une archive Debian a un répertoire racine sur un serveur FTP. Par
982 exemple, sur le site miroir <ftpsite>ftp.us.debian.org</ftpsite>, l'archive
983 Debian se trouve dans <ftppath>/debian</ftppath> ce qui est un emplacement
984 courant. Un autre emplacement courant est <file>/pub/debian</file>.
986 Une distribution est composée de paquets sources et binaires et des
987 fichiers <file>Sources</file> et <file>Packages</file> correspondants qui
988 contiennent toutes les méta-informations sur les paquets. Les premiers sont
989 conservés dans le répertoire <file>pool/</file> tandis que les seconds sont
990 conservés dans le répertoire <file>dists/</file> de l'archive (pour
991 compatibilité descendante).
993 <sect2 id="sec-dists"><em>Stable</em>, <em>testing</em> et
996 Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire
997 <file>dists/stable</file>), une distribution appelée <em>testing</em> (dans le
998 répertoire <file>dists/testing</file>) et une distribution appelée
999 <em>unstable</em> (dans le répertoire <file>dists/unstable</file>). Ceci
1000 reflète le processus de développement du projet Debian.
1002 Les développements se font sur la distribution
1003 <em>unstable</em><footnote><p><em>unstable</em> signifie
1004 « instable »</footnote> (c'est pourquoi elle est aussi appelée
1005 <em>distribution de développement</em>). Chaque développeur Debian peut
1006 modifier ses paquets à tout moment dans cette distribution. Ainsi son contenu
1007 change tous les jours. Comme aucun effort particulier n'est fait pour s'assurer
1008 que tout fonctionne correctement dans cette distribution, elle est parfois
1009 littéralement « instable ».
1011 <ref id="testing"> est générée automatiquement en prenant les paquets
1012 d'<em>unstable</em> s'ils satisfont à certains critères. Ces critères
1013 garantissent que les paquets de <em>testing</em> sont de bonne qualité. La
1014 mise à jour de <em>testing</em> est lancée chaque jour après que les
1015 nouveaux paquets ont été installés.
1017 Après une période de développement, quand le responsable de
1018 distribution<footnote><p><em>Release manager</em></footnote> le juge opportun,
1019 la distribution <em>testing</em> est gelée, ce qui signifie que les conditions
1020 à remplir pour qu'un paquet passe d'<em>unstable</em> à <em>testing</em> sont
1021 durcies. Les paquets trop bogués sont supprimés et les seules mises à jours
1022 autorisées concernent les corrections de bogues. Après quelque temps, selon
1023 l'avancement, la distribution entre dans une phase de « gel complet »
1024 où les seules modifications acceptées concernent la procédure d'installation.
1025 Cette phase s'appelle un « cycle de test » et cela peut durer jusqu'à
1026 deux semaines. Il peut y avoir plusieurs cycles de tests avant que le
1027 responsable de distribution ne la déclare prête pour la diffusion. À la fin du
1028 dernier cycle de test, la distribution <em>frozen</em> devient <em>stable</em>,
1029 remplaçant l'ancienne distribution <em>stable</em> qui est enlevée à cette
1030 occasion (elle peut être retrouvée à l'adresse <tt>&archive-host;</tt>).
1032 Ce cycle de développement est basé sur l'idée que la distribution
1033 <em>unstable</em> devient <em>stable</em> après une période de test
1034 (<em>testing</em>). Une distribution contient inévitablement des bogues, même
1035 si elle est classée stable. C'est pourquoi les distributions stables sont mises
1036 à jour de temps en temps. Les corrections introduites sont testées avec une
1037 grande attention et sont ajoutées une à une à l'archive pour diminuer les
1038 risques d'introduire de nouveaux bogues. Vous pouvez trouver des paquets
1039 proposés pour les mises à jour de <em>stable</em> dans le répertoire
1040 <file>proposed-updates</file>. De temps en temps, les paquets de ce répertoire
1041 qui ne présentent pas de problème sont installés dans la distribution
1042 <em>stable</em> et le numéro de révision de cette distribution est incrémenté
1043 (« 3.0 » devient « 3.0r1 », « 2.0r4 » devient
1044 « 2.0r5 » et ainsi de suite).
1046 Notez que, pendant la période de gel, les développements continuent sur la
1047 distribution <em>unstable</em> car cette distribution reste en place.
1049 <sect2 id="testing">
1050 <heading>Informations complémentaires sur la distribution
1051 « testing »</heading>
1053 Les scripts qui mettent à jour la distribution <em>testing</em> sont exécutés
1054 chaque jour après l'installation des paquets mis à jour. Ils fabriquent les
1055 fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils
1056 le font d'une manière intelligente pour éviter toute incohérence et essayer de
1057 n'utiliser que des paquets sans bogue.
1059 L'inclusion d'un paquet d'<em>unstable</em> est soumise aux
1060 conditions suivantes :
1061 <list compact="compact">
1062 <item><p>Le paquet doit avoir été disponible dans <em>unstable</em> depuis
1063 plusieurs jours ; le nombre précis dépend du champ d'urgence de
1064 l'envoi. Il s'agit de 10 jours pour une urgence faible, 5 jours pour une
1065 urgence moyenne et 2 jours pour une urgence élevée. Ces délais peuvent
1066 être doublés lors d'un gel de distribution ;</item>
1067 <item><p>Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
1068 version disponible dans <em>testing</em> ;</item>
1069 <item><p>Il doit être disponible pour toutes les architectures pour lesquelles
1070 il a été auparavant construit. <ref id="madison"> peut être
1071 intéressant pour vérifier cette information ;</item>
1072 <item><p>Il ne doit pas casser les dépendances d'un paquet qui est déjà
1073 disponible dans <em>testing</em> ;</item>
1074 <item><p>Les paquets dont il dépend doivent soit être déjà disponibles dans
1075 <em>testing</em> soit être acceptés dans <em>testing</em> au
1076 même moment (et ils doivent eux-mêmes respecter tous ces
1080 Pour savoir si un paquet a progressé ou non dans <em>testing</em>, veuillez voir la
1081 sortie du script de <em>testing</em> sur la <url name="page web de la distribution testing"
1082 id="&url-testing-maint;"> ou utilisez le programme <prgn>grep-excuses</prgn>
1083 inclus dans le paquet <package>devscripts</package>. Si l'on veut rester
1084 informé de la progression de ses paquets dans <em>testing</em>, on peut
1085 facilement le mettre dans la <manref
1086 section="5" name="crontab">.
1088 Le fichier <file>update_excuses</file> ne donne pas toujours la raison précise
1089 pour laquelle un paquet est refusé, on peut avoir à la chercher soi-même en
1090 regardant ce qui serait cassé avec l'inclusion du paquet. La <url
1091 id="&url-testing-maint;" name="page web de la distribution testing"> donne plus
1092 d'informations à propos des problèmes courants qui peuvent occasionner cela.
1094 Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce que le
1095 jeu des inter-relations est trop compliqué et ne peut être résolu par le
1096 script. Dans ce cas, le responsable de version doit être contacté et il forcera
1097 l'inclusion du paquet.
1099 En général, veuillez vous référer à la <url name="page web de la distribution testing"
1100 id="&url-testing-maint;"> pour plus d'informations. Cette page inclut également
1101 des réponses aux questions fréquemment posées.
1104 <sect2 id="experimental">Experimental
1106 La distribution <em>experimental</em> est une distribution particulière. Ce n'est
1107 pas une distribution à part entière comme le sont <em>stable</em> et
1108 <em>unstable</em>. Elle est prévue pour servir de plate-forme de
1109 développement pour les projets expérimentaux qui risquent vraiment de
1110 détruire le système ou bien pour des logiciels qui sont vraiment trop
1111 instables pour être inclus dans la distribution <em>unstable</em> (mais pour
1112 lesquels une mise en paquet est justifiée). Les utilisateurs qui téléchargent
1113 et installent des paquets depuis <em>experimental</em> sont prévenus :
1114 on ne peut pas faire confiance à la distribution <em>experimental</em>.
1116 Voici les lignes de <manref name="sources.list" section="5"> pour
1117 <em>experimental</em> :
1119 deb http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
1120 deb-src http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
1123 Si un logiciel peut causer des dégats importants, il sera sûrement
1124 préférable de le mettre dans la distribution <em>experimental</em>. Un
1125 système de fichiers compacté expérimental, par exemple, devrait probablement
1126 aller dans <em>experimental</em>.
1128 Une nouvelle version amont qui ajoute de nouvelles fonctions tout en supprimant
1129 de nombreuses autres ne devra pas être téléchargée dans l'archive Debian,
1130 elle pourra cependant être téléchargée dans <em>experimental</em>. Une
1131 nouvelle version non finalisée d'un logiciel qui utilise une méthode de
1132 configuration complètement différente pourrait aller dans
1133 <em>experimental</em> au gré du responsable. Si vous travaillez sur un cas de
1134 mise à jour complexe ou incompatible, vous pouvez aussi utiliser
1135 <em>experimental</em> comme plate-forme d'intégration et ainsi fournir un
1138 Quelques logiciels expérimentaux peuvent cependant aller dans <em>unstable</em>,
1139 avec un avertissement dans la description, mais ce n'est pas recommandé car
1140 les paquets d'<em>unstable</em> se propagent dans <em>testing</em> et
1141 aboutissent dans <em>stable</em>. Vous ne devriez pas avoir peur d'utiliser
1142 <em>experimental</em> car ceci ne cause aucun souci aux ftpmasters, les
1143 paquets expérimentaux sont automatiquement enlevés quand vous envoyez le
1144 paquet dans <em>unstable</em> avec un numéro de version supérieur.
1146 Un nouveau logiciel qui ne risque pas d'endommager le système ira directement
1147 dans <em>unstable</em>.
1149 Une solution de rechange à <em>experimental</em> consiste à utiliser vos pages
1150 personnelles sur le serveur <tt>people.debian.org</tt>.
1152 <sect1 id="codenames">Les noms de distribution
1154 Chaque distribution Debian diffusée a un <em>nom de code</em> : Debian 1.1
1155 s'appelle « buzz » ; Debian 1.2, « rex » ; Debian
1156 1.3, « bo » ; Debian 2.0, « hamm » ; Debian 2.1,
1157 « slink »; Debian 2.2, « potato » et Debian 3.0,
1158 « woody ». Il y a aussi une pseudo-distribution nommée
1159 « sid », il s'agit de la distribution <em>unstable</em> ; comme
1160 les paquets vont d'<em>unstable</em> à <em>testing</em> quand ils approchent
1161 de la stabilité, la distribution « sid » n'est jamais diffusée. En
1162 plus du contenu habituel d'une distribution Debian, « sid » contient
1163 des paquets pour des architectures qui ne sont pas encore officiellement
1164 reconnues ou pour lesquelles la distribution n'a pas encore été diffusée. Ces
1165 architectures seront intégrées ultérieurement à la distribution principale.
1167 Comme Debian est un projet de développement ouvert (i.e. tout le monde peut
1168 participer et suivre les développements), même les distributions
1169 <em>unstable</em> et <em>testing</em> sont disponibles sur les serveurs HTTP et
1170 FTP de Debian. Si nous avions nommé le répertoire qui contient la prochaine
1171 distribution à diffuser « testing », il aurait fallu changer son nom en
1172 « stable » au moment de la diffusion, ce qui aurait forcé les miroirs
1173 FTP à télécharger à nouveau la distribution complète (qui est plutôt volumineuse).
1175 D'un autre côté, si une distribution s'appelait <em>Debian-x.y</em> dès le
1176 départ, des personnes pourraient s'imaginer que la distribution Debian
1177 <em>x.y</em> est disponible. (Cela s'est produit par le passé, un distributeur
1178 avait gravé des cédéroms Debian 1.0 en utilisant une version de développement
1179 pré-1.0. C'est pour cette raison que la première version officielle était la
1180 version 1.1 et non la 1.0).
1182 En conséquence, les noms de répertoire des distributions dans l'archive sont
1183 déterminés par leur nom de code et non par leur statut (exemple :
1184 slink). Ces noms sont identiques pendant la période de développement et une
1185 fois la distribution diffusée ; des liens symboliques, qui peuvent être
1186 modifiés facilement, indiquent la distribution stable actuelle. Tout ceci
1187 explique pourquoi les répertoires des distributions sont nommés à partir des
1188 noms de code des distributions alors que <em>stable</em>, <em>testing</em> et
1189 <em>unstable</em> sont des liens symboliques qui pointent vers les répertoires
1193 <sect id="mirrors">Les miroirs Debian
1195 Les différentes archives de téléchargement et le site web disposent de plusieurs
1196 miroirs pour soulager les serveurs principaux d'une lourde charge. En fait,
1197 certains de ces serveurs ne sont pas publics et la charge est
1198 répartie sur une première série de serveurs. De cette façon, les
1199 utilisateurs ont toujours accès aux miroirs et s'y habituent, ce qui permet à
1200 Debian de mieux répartir les besoins en bande passante sur plusieurs serveurs et
1201 plusieurs réseaux différents et évitent aux utilisateurs de surcharger
1202 l'emplacement primaire. Notez que, dans cette première série, les serveurs sont aussi à jour
1203 que possible car la mise à jour est déclenchée par les sites maîtres internes.
1205 Toutes les informations sur les miroirs Debian peuvent être trouvées à <url
1206 id="&url-debian-mirrors;">, y compris une liste des miroirs publics disponibles
1207 FTP/HTTP. Cette page utile inclut également des informations et des outils pour
1208 créer son propre miroir, soit en interne soit pour un accès public.
1210 Les miroirs sont en général mis en œuvre par des tiers qui veulent aider
1211 Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces
1215 <sect id="incoming-system">
1216 <heading>Le système Incoming
1218 Le système Incoming est responsable de la collecte des paquets mis à jour et de
1219 leur installation dans l'archive Debian. Il est constitué d'un ensemble de
1220 répertoires et de scripts qui sont installés à la fois sur
1221 <tt>&ftp-master-host;</tt> et sur <tt>&non-us-host;</tt>.
1223 Les paquets sont envoyés par tous les responsables Debian dans un répertoire
1224 nommé <file>unchecked</file>. Ce répertoire est parcouru toutes les 15 minutes
1225 par le script <prgn>katie</prgn> qui vérifie l'intégrité des paquets envoyés et
1226 les signatures de chiffrage. Si le paquet est considéré comme prêt à être
1227 installé, il est déplacé dans le répertoire <file>accepted</file>. S'il s'agit
1228 du premier envoi du paquet, il est déplacé dans le répertoire <file>new</file>
1229 où il attend l'approbation des ftpmasters. Si le paquet contient des fichiers
1230 devant être installés <em>à la main</em>, il est déplacé dans le répertoire
1231 <file>byhand</file> où il attend une installation manuelle par les ftpmasters.
1232 Sinon, si une erreur a été détectée, le paquet est refusé et il est déplacé
1233 dans le répertoire <file>reject</file>.
1235 Une fois que le paquet est accepté, le système envoie une confirmation par
1236 courrier au responsable et ferme les bogues corrigés par l'envoi, puis
1237 les compilateurs automatiques peuvent commencer la recompilation. Le paquet est
1238 maintenant accessible publiquement à <url id="&url-incoming;"> (une telle
1239 adresse n'existe pas pour les paquets de l'archive non-US) jusqu'à ce qu'il
1240 soit vraiment installé dans l'archive Debian. Ceci se produit seulement une
1241 fois par jour, le paquet est alors supprimé de <file>Incoming</file> et
1242 installé dans le pool avec les autres paquets. Une fois que toutes les autres
1243 mises à jour (fabrication des nouveaux fichiers d'index <file>Packages</file> et
1244 <file>Sources</file> par exemple) ont été effectuées, un script spécial est
1245 appelé pour demander aux miroirs primaires de se mettre à jour.
1247 Le logiciel de maintenance de l'archive enverra également le fichier
1248 <file>.changes</file> signé avec OpenPGP/GnuPG que vous avez envoyé, à la liste
1249 de diffusion appropriée. Si un paquet est diffusé avec le champ
1250 <tt>Distribution:</tt> positionné à « stable », l'annonce sera envoyée
1251 à &email-debian-changes;. Si un paquet est diffusé avec le champ
1252 <tt>Distribution:</tt> positionné à « unstable » ou
1253 « experimental », l'annonce sera à la place envoyée à
1254 &email-debian-devel-changes;.
1256 Tous les développeurs Debian ont un droit d'écriture dans le répertoire
1257 <file>unchecked</file> pour pouvoir y envoyer leurs paquets, ils ont également
1258 accès au répertoire <file>reject</file> pour supprimer les mauvais envois ou
1259 déplacer certains fichiers dans le répertoire <file>unchecked</file>. Mais
1260 seuls les ftpmasters ont droit d'écriture dans les autres répertoires.
1261 C'est pourquoi vous ne pouvez pas supprimer un envoi une fois qu'il a été
1264 <sect1 id="delayed-incoming">Incoming différé
1266 Le répertoire <file>unchecked</file> comprend un sous-répertoire spécial,
1267 <file>DELAYED</file><footnote>Différé en anglais</footnote>. Celui-ci est
1268 lui-même subdivisé en neuf répertoires nommés <file>1-day</file> à
1269 <file>9-day</file>. Les paquets qui sont envoyés dans l'un de ces
1270 répertoires seront déplacés dans le vrai répertoire <file>unchecked</file>
1271 après le nombre correspondant de jours. Un script, exécuté chaque jour,
1272 déplace les paquets entre les répertoires. Ceux
1273 qui sont dans « 1-day » sont installés dans
1274 <file>unchecked</file> alors que les autres sont déplacés dans le
1275 répertoire adjacent (par exemple, un paquet dans <file>5-day</file> sera
1276 déplacé dans <file>4-day</file>). Cette fonctionnalité est particulièrement
1277 utile pour les personnes qui effectuent des mises à jour indépendantes
1278 (NMU, « non-maintainer uploads »). Au lieu d'attendre avant
1279 d'envoyer la NMU, elle est envoyée dès qu'elle est prête dans l'un de ces
1280 répertoires <file>DELAYED/<var>x</var>-day</file>. Ceci laisse le nombre
1281 correspondant de jours au responsable pour réagir et envoyer lui-même une
1282 autre correction s'il n'est pas complètement satisfait par la NMU. Il peut
1283 également enlever complètement la NMU.
1285 L'utilisation de ce délai peut être simplifiée en
1286 l'intégrant à votre outil d'envoi. Par exemple, si vous utilisez
1287 <prgn>dupload</prgn> (voir <ref id="dupload">), vous pouvez ajouter cette
1288 partie à votre fichier de configuration :
1290 $delay = ($ENV{DELAY} || 7);
1292 fqdn => "&ftp-master-host;",
1293 login => "yourdebianlogin",
1294 incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/",
1298 Une fois que vous avez fait ce changement, <prgn>dupload</prgn> peut être
1299 utilisé pour envoyer facilement dans l'un des répertoires de délai ainsi :
1300 <example>DELAY=5 dupload --to delayed <changes-file></example>
1303 <sect id="pkg-info">Informations sur un paquet
1306 <sect1 id="pkg-info-web">Sur le web
1308 Chaque paquet a plusieurs pages web dédiées.
1309 <tt>http://&packages-host;/<var>nom-paquet</var></tt> affiche chaque version
1310 du paquet disponible dans les différentes distributions. Les informations
1311 détaillées par version incluent la description du paquet, les dépendances et
1312 des liens pour récupérer le paquet.
1314 Le système de suivi des bogues trie les bogues par paquet. Vous pouvez regarder
1315 les bogues de chaque paquet à
1316 <tt>http://&bugs-host;/<var>nom-paquet</var></tt>.
1318 <sect1 id="madison">L'outil <prgn>madison</prgn>
1320 <prgn>madison</prgn> est un outil en ligne de commande qui est disponible sur
1321 <tt>&ftp-master-host;</tt> et sur <tt>&non-us-host;</tt>. Il utilise un seul
1322 argument qui correspond au nom du paquet. Il affiche comme résultat quelle
1323 version du paquet est disponible pour chaque combinaison d'architecture et de
1324 distribution. Un exemple l'expliquera mieux.
1327 $ madison libdbd-mysql-perl
1328 libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
1329 libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
1330 libdbd-mysql-perl | 1.2216-2.0.1| testing | alpha
1331 libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc</example>
1333 Dans cet exemple, vous pouvez voir que la version dans <em>unstable</em> diffère
1334 de celle de <em>testing</em> et qu'il y a eu une NMU binaire seulement pour
1335 l'architecture alpha. À chaque fois, le paquet a été recompilé sur la plupart
1339 <sect id="pkg-tracking-system">Système de suivi des paquets
1341 Le système de suivi des paquets (PTS)<footnote>« Package Tracking
1342 System »</footnote> est un outil pour suivre par courrier l'activité
1343 concernant un paquet source. Cela veut vraiment dire que vous pourrez recevoir
1344 les mêmes courriers que le responsable, simplement en vous inscrivant au paquet
1347 Chaque courrier envoyé par le PTS est classé et associé à l'un des mots-clés
1348 listés ci-dessous. Ceci vous permettra de sélectionner les courriers que vous
1351 Par défaut, vous recevrez :
1354 <item>Tous les rapports de bogue et les discussions qui
1357 <tag><tt>bts-control</tt>
1358 <item>Les courriers de notification de <email>control@bugs.debian.org</email>
1359 sur les changement d'état de l'un des rapports de bogue.
1361 <tag><tt>upload-source</tt>
1362 <item>Le courrier de notification de <prgn>katie</prgn> quand un paquet
1363 source envoyé a été accepté.
1365 <tag><tt>katie-other</tt>
1366 <item>Les autres courriers d'avertissement et d'erreur de
1367 <prgn>katie</prgn> (comme une incohérence de passage en force pour les champs
1368 section ou priorité).
1370 <tag><tt>default</tt>
1371 <item>Tout courrier non automatique envoyé au PTS par les personnes qui
1372 veulent contacter les inscrits au paquet. Ceci peut être fait en
1373 envoyant un courrier à <tt><var>paquet-source</var>@&pts-host;</tt>. Pour
1374 prévenir l'envoi de spam, tous les courriers envoyés à ces adresses doivent
1375 contenir l'en-tête <tt>X-PTS-Approved</tt> avec une valeur non vide.
1377 <tag><tt>summary</tt>
1378 <item>(Ceci est une extension prévue).
1379 Les courriers de résumé réguliers sur l'état du paquet (statistiques sur
1380 les bogues, vue générale du portage, progression dans <em>testing</em>,
1385 Vous pouvez également décider de recevoir des informations supplémentaires :
1387 <tag><tt>upload-binary</tt>
1388 <item>Le courrier d'information de <prgn>katie</prgn> quand un paquet
1389 binaire envoyé est accepté. En d'autres termes, à chaque fois qu'un
1390 démon de compilation ou un porteur envoie votre paquet pour une autre
1391 architecture, vous recevez un courrier pour suivre comment votre paquet
1392 est recompilé pour toutes les architectures.
1395 <item>Les notifications de modifications CVS<footnote><p><em>CVS
1396 commits</em></footnote> si le responsable a mis en place un système pour
1397 faire suivre les notifications de modifications vers le PTS.
1400 <item>Les traductions des descriptions ou des questionnaires debconf soumis
1401 au Projet de traduction des descriptions de paquets
1402 Debian<footnote><p><em>Debian Description Translation Project,
1403 DDTP</em></footnote>.
1407 <sect1 id="pts-commands">L'interface de courrier du PTS
1409 Vous pouvez contrôler votre (vos) inscription(s) au PTS en envoyant différents
1410 commandes à <email>pts@qa.debian.org</email>.
1413 <tag><tt>subscribe <paquet source> [<adresse>]</tt>
1414 <item>Inscrit <var>adresse</var> aux communications liées au paquet source
1415 <var>paquet source</var>. L'adresse de l'expéditeur est utilisée si le
1416 second argument n'est pas présent. Si <var>paquet source</var> n'est pas
1417 un paquet source valide, vous obtiendrez un avertissement. Cependant,
1418 s'il s'agit d'un paquet binaire valide, le PTS vous inscrira pour le
1419 paquet source correspondant.
1421 <tag><tt>unsubscribe <paquet source> [<adresse>]</tt>
1422 <item>Supprime une inscription précédente au paquet source
1423 <var>paquet source</var> en utilisant l'adresse spécifiée ou l'adresse de
1424 l'expéditeur si le second argument n'est pas rempli.
1426 <tag><tt>which [<adresse>]</tt>
1427 <item>Liste les inscriptions pour l'expéditeur ou pour l'adresse indiquée
1428 si elle est spécifiée.
1430 <tag><tt>keyword [<adresse>]</tt>
1431 <item>Donne les mots-clés que vous acceptez. Pour une explication des ces
1432 mots-clés, <qref id="pkg-tracking-system">voir ci-dessus</qref>. Voici
1433 un rapide résumé :
1435 <item><tt>bts</tt> : courriers venant du système de gestion de bogues (BTS) Debian
1436 <item><tt>bts-control</tt> : réponses aux courriers envoyés à
1437 &bugs-host;&email-bts-control;
1438 <item><tt>summary</tt> : courriers de résumé automatique sur l'état
1440 <item><tt>cvs</tt> : notifications de modifications CVS
1441 <item><tt>ddtp</tt> : traductions des descriptions et
1442 questionnaires debconf
1443 <item><tt>upload-source</tt> : annonce d'un nouvel envoi de paquet
1444 source qui a été accepté
1445 <item><tt>upload-binary</tt> : annonce d'un nouvel envoi de binaire
1447 <item><tt>katie-other</tt> : autres courriers des ftpmasters
1448 (incohérence de passage en force, etc.)
1449 <item><tt>default</tt> : tous les autres courriers (ceux qui ne sont
1453 <tag><tt>keyword <paquet source> [<adresse>]</tt>
1454 <item>Identique à l'élément précédent, mais pour un paquet source donné
1455 car vous pouvez sélectionner un ensemble de mots-clés différent pour
1456 chaque paquet source.
1458 <tag><tt>keyword [<adresse>] {+|-|=} <liste de mots-clés></tt>
1459 <item>Accepte (+) ou refuse (-) les courriers associés au(x) mot(s)-clé(s).
1460 Définit la liste (=) des mots-clés acceptés.
1462 <tag><tt>keyword <paquet source> [<adresse>] {+|-|=} <liste de mots-clés></tt>
1463 <item>Identique à l'élément précédent, mais remplace la liste des mots-clés
1464 pour le paquet source indiqué.
1466 <tag><tt>quit | thanks | --</tt>
1467 <item>Arrête le traitement des commandes. Toutes les lignes suivantes sont
1468 ignorées par le robot.
1471 <sect1 id="pts-mail-filtering">Filtrer les courriers du PTS
1473 Une fois que vous vous êtes inscrit à un paquet, vous recevrez les courriers
1474 envoyés à <tt><var>paquet source</var>@packages.qa.debian.org</tt>. Ces courriers
1475 ont des en-têtes spéciaux ajoutés pour vous permettre de les filtrer dans des
1476 boîtes aux lettres (par exemple, avec <prgn>procmail</prgn>). Les en-têtes ajoutés sont
1477 <tt>X-Loop</tt>, <tt>X-PTS-Package</tt>, <tt>X-PTS-Keyword</tt> et
1478 <tt>X-Unsubscribe</tt>.
1480 Voici un exemple d'en-têtes ajoutés pour une notification d'envoi de
1481 source sur le paquet <package>dpkg</package> :
1483 X-Loop: dpkg@&pts-host;
1485 X-PTS-Keyword: upload-source
1486 X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
1489 <sect1 id="pts-cvs-commit">Faire suivre les modifications de CVS vers le PTS
1491 Si vous utilisez un référentiel CVS accessible publiquement pour maintenir votre
1492 paquet Debian, vous pouvez vouloir faire suivre les notifications de
1493 modifications vers le PTS pour que les inscrits (ainsi que des possibles
1494 co-responsables) puissent suivre de près l'évolution du paquet.
1496 Une fois que votre référentiel génère des notifications de modifications, vous
1497 devez simplement vous assurer qu'il envoie une copie de tous ces courriers à
1498 <tt><var>paquet source</var>_cvs@&pts-host;</tt>. Seules les personnes qui ont
1499 accepté le mot-clé <em>cvs</em> recevront les notifications.
1501 <sect1 id="pts-web">L'interface web du PTS
1503 Le PTS possède une interface web à <url id="http://&pts-host;/"> qui réunit
1504 beaucoup d'informations au
1505 même endroit à propos de chaque paquet source. Il propose plusieurs liens utiles
1506 (BTS, statistiques QA, informations de contact, état de traduction DDTP,
1507 journaux de compilation automatique) et il regroupe beaucoup d'autres informations
1508 provenant de différents endroits (les 30 dernières entrées de changelog, l'état
1509 dans <em>testing</em>, etc.). Il s'agit d'un outil très pratique si vous désirez
1510 connaître ce qu'il en est d'un paquet source spécifique. De plus, il y a un
1511 formulaire qui permet de facilement s'inscrire au PTS par courrier.
1513 Vous pouvez aller directement à la page web concernant un paquet source avec une
1514 URL comme <tt>http://&pts-host;/<var>paquet source</var></tt>.
1516 Cette interface a été conçue comme un portail pour le développements des
1517 paquets : vous pouvez ajouter du contenu personnalisé aux pages de vos
1518 paquets. Vous pouvez ajouter des « informations
1519 statiques »<footnote><em>Static information</em></footnote> (des annonces
1520 qui sont destinées à rester disponibles indéfiniment) et des nouvelles dans la
1521 section « dernières nouvelles »<footnote><em>Latest
1522 news</em></footnote>.
1524 Les annonces statiques peuvent être utilisées pour indiquer :
1526 <item>la disponibilité d'un projet hébergé sur <qref id="alioth">Alioth</qref> pour la
1527 co-maintenance du paquet,
1528 <item>un lien vers le site web amont,
1529 <item>un lien vers le suivi de bogues amont,
1530 <item>l'existence d'un canal IRC dédié au logiciel,
1531 <item>toute autre ressource disponible qui peut être utile à la maintenance du paquet.
1533 Les nouvelles usuelle peuvent être utilisées pour annoncer que :
1535 <item>des paquets bêta sont disponibles pour test,
1536 <item>des paquets finaux sont attendus pour la semaine prochaine,
1537 <item>l'empaquetage est sur le point d'être intégralement refait,
1538 <item>des rétroportages sont disponibles,
1539 <item>le responsable est en vacance (s'il désire publier cette information),
1540 <item>une mise à jour indépendante (NMU) est en cours de réalisation,
1541 <item>quelque chose d'important va affecter le paquet.
1544 Les deux types d'informations sont fabriqués de façon similaire : il vous
1545 suffit d'envoyer un courrier soit à <email>pts-static-news@qa.debian.org</email>
1546 (pour les annonces statiques), soit à <email>pts-news@qa.debian.org</email>
1547 (pour les nouvelles usuelles). Le courrier devrait indiquer quel paquet est
1548 concerné par la nouvelle en donnant le nom du paquet source dans un en-tête de
1549 courrier <tt>X-PTS-Package</tt> ou dans un pseudo-en-tête <tt>Package</tt>
1550 (comme pour les rapports de bogue du BTS). Si une URL est disponible dans
1551 l'en-tête de courrier <tt>X-PTS-Url</tt> ou dans un pseudo-en-tête <tt>Url</tt>,
1552 le résultat est un lien vers cette URL au lieu d'une nouvelle complète.
1554 Voici quelques exemples de courriers valides utilisés pour générer des nouvelles dans
1555 le PTS. Le premier ajoute un lien vers l'interface cvsweb de debian-cd dans la
1556 section « Informations statiques » :
1558 From: Raphael Hertzog <hertzog@debian.org>
1559 To: pts-static-news@qa.debian.org
1560 Subject: Browse debian-cd CVS repository with cvsweb
1563 Url: http://cvs.debian.org/debian-cd/
1566 Le second est une annonce envoyée à une liste de diffusion et également
1567 envoyée au PTS pour qu'elle soit publiée sur la page web du PTS du paquet. Notez
1568 l'utilisation du champ BCC pour éviter que des réponses ne soient envoyées par
1571 From: Raphael Hertzog <hertzog@debian.org>
1572 To: debian-gtk-gnome@lists.debian.org
1573 Bcc: pts-news@qa.debian.org
1574 Subject: Galeon 2.0 backported for woody
1575 X-PTS-Package: galeon
1579 I'm glad to announce that galeon has been backported for woody. You'll find
1584 Réfléchissez-y à deux fois avant d'ajouter une nouvelle au PTS car vous ne
1585 pourrez pas l'enlever par la suite et vous ne pourrez pas non plus l'éditer. La
1586 seule chose que vous puissiez faire est d'envoyer une deuxième nouvelle qui va
1587 déprécier l'information contenue dans la précédente.
1589 <sect id="ddpo">Vue d'ensemble des paquets d'un développeur
1591 Un portail web pour l'Assurance Qualité (QA) est disponible à <url
1592 id="&url-ddpo;"> qui affiche un tableau de tous les paquets d'un
1593 développeur (y compris ceux pour lequel il est co-responsable). Le tableau donne
1594 un bon résumé sur les paquets d'un développeur : nombre de bogues par
1595 gravité, liste des versions disponibles, état des tests et des liens vers
1596 d'autres informations utiles.
1598 C'est une bonne idée de vérifier régulièrement vos données pour ne pas oublier
1599 de bogues ouverts et pour ne pas oublier quels paquets sont sous votre
1602 <sect id="alioth">Debian *Forge : Alioth
1604 Alioth est un service de Debian plutôt récent, basé sur une version
1605 légèrement modifiée du logiciel GForge (qui a évolué à partir de
1606 SourceForge). Ce logiciel offre aux développeurs l'accès à des outils
1607 faciles d'utilisation comme un un gestionnaire de suivi de bogues, un
1608 gestionnaire de correctifs, un gestionnaire de tâches et de projets,
1609 un service d'hébergement de fichiers, des listes de diffusion, des
1610 dépôts CVS, etc. Tous ces outils sont gérés par une interface web.
1612 Alioth est destiné à fournir des facilités pour des projets de logiciels
1613 soutenus ou dirigés par Debian, à faciliter les contributions de développeurs
1614 externes aux projets initiés par Debian et à aider des projets dont les buts
1615 sont de promouvoir Debian ou ses dérivés.
1617 Pour plus d'informations, veuillez visiter <url id="&url-alioth;">.
1619 <chapt id="pkgs">Gestion des paquets
1621 Ce chapitre contient des informations relatives à la création, l'envoi, la
1622 maintenance et le portage des paquets.
1625 <sect id="newpackage">Nouveaux paquets
1627 Si vous voulez créer un nouveau paquet pour la distribution Debian, vous devriez
1628 commencer par consulter la liste des <url id="&url-wnpp;" name="paquets en
1629 souffrance et paquets souhaités">. Vous pourrez ainsi vérifier que personne ne
1630 travaille déjà sur ce paquet et éviter un double travail. Consultez aussi cette
1631 page si vous voulez en savoir plus.
1633 Supposons que personne ne travaille sur le paquet que vous visez, vous devez
1634 alors envoyer un rapport de bogue (voir <ref id="submit-bug">) concernant le
1635 pseudo-paquet <package>wnpp</package>. Ce courrier devra décrire le paquet que
1636 vous projetez de créer, la licence de ce paquet et l'URL à laquelle le source
1637 peut être téléchargé. Cette liste n'est pas limitative.
1639 Le sujet de votre rapport de bogue devra être <ITP<footnote><p><em>Intent To
1640 Package</em> : intention de d'empaquetage</footnote> :
1641 <var>NomDuPaquet</var> — <var>courte description</var>>, en remplaçant
1642 <var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera
1643 <em>wishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
1644 &email-debian-devel; en mettant cette adresse dans le champ
1645 <tt>X-Debbugs-CC:</tt> de l'en-tête du message. N'utilisez pas le champ
1646 <tt>CC:</tt> car de cette manière le sujet du message ne contiendrait pas le
1649 Il faudra aussi ajouter une entrée <tt>Closes: bug#<var>nnnnn</var></tt> dans le
1650 fichier <file>changelog</file> du nouveau paquet. Cette indication fermera
1651 automatiquement le rapport de bogue à l'installation du nouveau paquet sur les
1652 serveurs d'archivage (voir <ref id="upload-bugfix">).
1654 Plusieurs raisons nous poussent à demander aux responsables
1655 d'annoncer leur intention :
1657 <item>Les responsables ont ainsi la possibilité de puiser dans l'expérience
1658 des autres responsables et cela leur permet de savoir si une autre
1659 personne travaille déjà dessus.
1660 <item>D'autres personnes qui envisagent de travailler sur le même paquet
1661 apprendront ainsi qu'il existe déjà un volontaire, l'effort peut alors
1663 <item>Cela permet aux autres responsables de connaître le nouveau
1664 paquet mieux que ne le permettent la description d'une ligne et l'habituelle
1665 entrée de type changelog <em>Initial release</em> postée sur
1666 <tt>debian-devel-changes</tt>.
1667 <item>C'est une information utile pour
1668 les gens qui utilisent la distribution <em>unstable</em> et qui sont nos
1669 premiers testeurs. Nous devons faciliter la tâche de ces gens.
1670 <item>Avec ces annonces, les développeurs Debian et toutes les autres personnes
1671 intéressées peuvent se faire une meilleure idée des évolutions et des
1672 nouveautés du projet.
1676 <sect id="changelog-entries">Enregistrer les modifications dans le paquet
1678 Les modifications que vous apportez au paquet doivent être notifiées dans le
1679 fichier <file>debian/changelog</file>. Ces notes doivent donner une
1680 description concise des changements, expliquer les raisons de ceux-ci (si
1681 ce n'est pas clair) et indiquer si des rapports de bogue ont été clos. Il
1682 faut aussi indiquer quand le paquet a été terminé. Ce fichier sera
1684 <file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
1685 <file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un paquet
1688 Le fichier <file>debian/changelog</file> a une structure précise comportant
1689 différents champs. Le champ <em>distribution</em> est décrit dans <ref
1690 id="distribution">. Vous trouverez plus d'informations sur la structure de ce
1691 fichier dans la section « <file>debian/changelog</file> » de la
1692 <em>charte Debian</em>.
1694 Les entrées du fichier <file>changelog</file> peuvent être
1695 utilisées pour fermer des rapports de bogue au moment où le paquet est
1696 installé dans l'archive. Voir la section <ref id="upload-bugfix">.
1698 Par convention, l'entrée changelog d'un paquet contenant une nouvelle version
1699 amont ressemble à :
1701 * new upstream version
1704 Quelques outils peuvent vous aider à créer des entrées et à finaliser le fichier
1705 <file>changelog</file> pour une livraison — voir les sections <ref
1706 id="devscripts"> et <ref id="dpkg-dev-el">.
1708 Voir aussi <ref id="bpp-debian-changelog">.
1711 <sect id="sanitycheck">Tester le paquet
1713 Avant d'envoyer votre paquet, vous devriez faire quelques tests de base. Vous
1714 devriez au moins faire les tests suivants (il vous faut une ancienne version
1717 <item>Installez le paquet et vérifiez que le logiciel fonctionne. Si le
1718 paquet existait déjà dans une version plus ancienne, faites une mise à
1720 <item>Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
1721 <prgn>lintian</prgn> comme suit : <tt>lintian -v
1722 <var>version-paquet</var>.changes</tt>. Ce programme fera une
1723 vérification sur les paquets source et binaire. Si vous ne comprenez pas
1724 les messages retournés par <prgn>lintian</prgn>, essayez l'option
1725 <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
1726 bavard dans sa description du problème.
1728 En principe, un paquet pour lequel <prgn>lintian</prgn> renvoie des erreurs
1729 (elles commencent par <tt>E</tt>) <em>ne doit pas</em> être installé dans
1732 Pour en savoir plus sur <prgn>lintian</prgn>, reportez-vous à la section
1734 <item>Vous pouvez facultativement exécuter <ref id="debdiff"> pour analyser les
1735 modifications depuis une ancienne version si celle-ci existe.
1736 <item>Faites régresser le paquet vers sa version précédente si elle existe
1737 — cela permet de tester les scripts <file>postrm</file> et
1739 <item>Désinstallez le paquet et réinstallez-le.
1743 <sect id="sourcelayout">Disposition du paquet source
1745 Il existe deux types de paquets source Debian :
1747 <item>les paquets appelés <em>natifs</em> pour lesquels il
1748 n'y a pas de distinction entre les sources d'origine et les
1749 correctifs appliqués pour Debian
1750 <item>les paquets (plus courants) où il y a un fichier archive source
1751 d'origine accompagné par un autre fichier contenant les
1752 correctifs pour Debian.
1755 Pour les paquets natifs, le paquet source inclut un fichier de contrôle source
1756 Debian (<tt>.dsc</tt>) et l'archive source (<tt>.tar.gz</tt>). Un paquet source
1757 d'un paquet non natif inclut un fichier de contrôle source Debian, l'archive
1758 source d'origine (<tt>.orig.tar.gz</tt>) et les correctifs Debian
1759 (<tt>.diff.gz</tt>).
1761 Le caractère natif d'un paquet est déterminé lorsqu'il est construit par <manref
1762 name="dpkg-buildpackage" section="1">. Le reste de cette section ne se rapporte
1763 qu'aux paquets non natifs.
1766 La première fois qu'un paquet est installé dans l'archive pour une version amont
1767 donnée, le fichier <file>tar</file> de cette version amont doit être
1768 téléchargé et mentionné dans le fichier <file>.changes</file>. Par la suite,
1769 ce fichier <file>tar</file> sera utilisé pour générer les fichiers
1770 <file>diff</file> et <file>.dsc</file> et il ne sera pas nécessaire de le
1771 télécharger à nouveau.
1773 Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn>
1774 incluront le fichier <file>tar</file> amont si et seulement si le numéro de
1775 révision du paquet source est 0 ou 1, ce qui indique une nouvelle version
1776 amont. Ce comportement peut être modifié en utilisant <tt>-sa</tt> pour
1777 l'inclure systématiquement ou <tt>-sd</tt> pour ne jamais l'inclure.
1779 Si la mise à jour ne contient pas le fichier <file>tar</file> des sources
1780 originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
1781 fichiers <file>.dsc</file> et <file>diff</file> de la mise à jour, utiliser
1782 un fichier <tt>tar</tt> identique à l'octet près à celui déjà présent dans
1785 <sect id="distribution">Choisir une distribution
1787 Chaque envoi doit spécifier à quelle distribution le paquet est destiné. Le
1788 processus de construction de paquet extrait cette information à partir de la
1789 première ligne du fichier <file>debian/changelog</file> et la place dans le champ
1790 <tt>Distribution</tt> du fichier <tt>.changes</tt>.
1792 Il existe plusieurs valeurs possibles pour ce champ : « stable »,
1793 « unstable », « testing-proposed-updates » et
1794 « experimental ».
1796 En fait, il y a deux autres possibilités :
1797 « stable-security » et « testing-security », mais
1798 veuillez lire <ref id="bug-security"> pour plus d'informations sur celles-ci.
1800 Il est techniquement possible d'envoyer un paquet dans plusieurs distributions
1801 en même temps, mais ceci n'a habituellement aucun sens d'utiliser cette
1802 fonctionnalité car les dépendances d'un paquet peuvent varier selon les
1803 distributions. En particulier, il est absurde de combiner la distribution
1804 <em>experimental</em> avec tout autre chose.
1806 <sect1 id="upload-stable">Cas spécial mise à jour d'un paquet de
1807 la distribution <em>stable</em>
1809 Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
1810 sera dirigé vers le répertoire <file>stable-proposed-updates</file> des
1811 archives Debian pour y être testé avant d'être effectivement inclus dans
1814 Une livraison pour la distribution <em>stable</em> requiert des soins
1815 supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
1816 que dans les cas suivants :
1818 <item>un problème fonctionnel vraiment critique,
1819 <item>un paquet devenu ininstallable,
1820 <item>un paquet indisponible pour une architecture.
1823 Par le passé, des envois vers <em>stable</em> étaient également utilisés pour
1824 corriger les problèmes de sécurité. Cependant, cette pratique est dépréciée car
1825 les envois utilisés pour les avis de sécurité Debian<footnote>Debian security
1826 advisory</footnote> sont automatiquement copiés dans l'archive
1827 <file>proposed-updates</file> appropriée quand l'avis est publié. Reportez-vous
1828 à <ref id="bug-security"> pour des informations plus détaillées sur la gestion
1829 des problèmes de sécurité.
1831 Il est fortement déconseillé de changer quoi que ce soit si ce
1832 n'est pas important car même une modification triviale peut provoquer un
1835 Les paquets livrés pour <em>stable</em> doivent être compilés avec la
1836 distribution <em>stable</em> pour que leurs dépendances se limitent aux
1837 bibliothèques (et autres paquets) disponibles dans <em>stable</em> ;
1838 un paquet livré pour la distribution <em>stable</em> qui dépend d'une
1839 bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté.
1840 Modifier les dépendances d'autres paquets (en manipulant le champ
1841 <tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
1842 ininstallables, est fortement déconseillé.
1844 L'équipe responsable de la distribution<footnote><em>the Release
1845 team</em></footnote> (joignable à l'adresse &email-debian-release;)
1846 évaluera régulièrement le contenu de <em>stable-proposed-updates</em> et
1847 décidera si votre paquet peut être inclus dans la distribution
1848 <em>stable</em>. Soyez précis (et, si nécessaire, prolixe) quand vous
1849 décrivez, dans le fichier changelog, vos changements pour une livraison
1850 vers <em>stable</em>, sinon le paquet ne sera pas pris en considération.
1852 <sect1 id="upload-t-p-u">Cas spécial : Mise à jour d'un paquet de la
1853 distribution <em>testing-proposed-updates</em>
1855 La distribution <em>testing</em> est peuplée avec des paquets en provenance
1856 d'<em>unstable</em> selon des règles expliquées dans <ref id="testing">.
1857 Cependant, le responsable de distribution peut stopper les scripts de
1858 <em>testing</em> quand il veut geler la distribution. Dans ce cas, vous
1859 pouvez envoyer vos paquets vers <em>testing-proposed-updates</em> pour
1860 fournir des paquets corrigés durant le gel.
1862 Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement,
1863 ils doivent passer entre les mains du responsable de distribution. Vous devez
1864 donc avoir une bonne raison pour les y envoyer. Pour savoir ce que
1865 représente une bonne raison aux yeux du responsable de distribution, vous
1866 devriez lire les instructions données qu'il envoie régulièrement sur
1867 &email-debian-devel-announce;.
1869 Vous ne devriez pas envoyer un paquet à <em>testing-proposed-updates</em> quand
1870 vous pouvez le mettre à jour par <em>unstable</em>. Si vous ne pouvez faire
1871 autrement (par exemple, parce que vous avez une nouvelle version dans
1872 <em>unstable</em>), vous pouvez l'utiliser, mais il est recommandé de
1873 demander l'autorisation du responsable de distribution auparavant.
1876 <sect id="upload">Mettre à jour un paquet
1878 <sect1 id="upload-ftp-master">Installer un paquet sur
1881 Pour installer un paquet, vous avez besoin d'un compte sur
1882 <ftpsite>&ftp-master-host;</ftpsite>, ce que vous devriez déjà avoir en tant
1883 que développeur Debian. Si vous utilisez <prgn>scp</prgn> ou
1884 <prgn>rsync</prgn> pour télécharger vos paquets, placez-les dans
1885 &us-upload-dir;. Si vous utilisez un FTP anonyme, placez-les dans
1888 Si vous désirez utiliser la fonctionnalité de délai décrite dans <ref
1889 id="delayed-incoming">, vous devez effectuer votre envoi vers
1890 <tt>ftp-master</tt>. Il s'agit de la seule destination d'envoi supportant
1893 Attention, il est préférable de transférer le fichier
1894 <tt>changes</tt> en dernier. Dans le cas contraire, votre livraison pourrait
1895 être rejetée car l'outil de maintenance de l'archive pourrait lire le fichier
1896 <tt>changes</tt> et constater que les fichiers ne sont pas tous présents. Si
1897 vous ne voulez pas vous embêter avec l'ordre de transfert des fichiers, vous
1898 pouvez tout simplement copier vos fichiers dans un répertoire temporaire de
1899 <tt>ftp-master</tt> et les déplacer ensuite vers &us-upload-dir;.
1901 <em>Note :</em> ne téléchargez pas sur <tt>ftp-master</tt> de paquets
1902 concernant la cryptographie qui appartiendraient à <em>contrib</em> ou <em>non-free</em>.
1903 Ces logiciels doivent aller sur <tt>non-us</tt> (voir <ref
1904 id="upload-non-us">). De plus, les paquets contenant un logiciel protégé par
1905 des brevets américains ne peuvent pas être envoyés sur
1906 <tt>ftp-master</tt> ; selon le cas, ils peuvent peut-être pourtant être
1907 envoyés vers <file>non-US/non-free</file> (le paquet est dans
1908 <em>non-free</em> à cause de problèmes de distribution et non pas à cause de
1909 la licence du logiciel). Quand vous ne pouvez télécharger sur
1910 <tt>ftp-master</tt>, vous ne pouvez pas non plus télécharger sur
1911 <tt>chiark</tt> ou <tt>erlangen</tt>. Si vous ne savez pas si votre paquet
1912 est protégé par un brevet ou s'il est soumis aux lois de contrôle des
1913 exportations américaines, posez la question sur la liste
1914 &email-debian-devel;.
1916 Les paquets <ref id="dupload"> ou <ref id="dput"> pourront vous faciliter le
1917 travail lors du téléchargement. Ces programmes, bien pratiques, aident à
1918 automatiser le processus d'envoi de paquets vers Debian
1920 Après avoir téléchargé votre paquet, vous pouvez vérifier ce qu'en
1921 fera le logiciel de maintenance de l'archive en exécutant
1922 <prgn>dinstall</prgn> sur votre fichier <file>.changes</file> :
1923 <example>dinstall -n foo.changes</example>
1925 Notez que <prgn>dput</prgn> peut le faire automatiquement pour vous.
1927 <sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
1929 Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
1930 exportations américaines ne doivent pas être installés sur
1931 <tt>ftp-master</tt>. Installez le paquet sur
1932 <ftpsite>non-us.debian.org</ftpsite> dans le répertoire &non-us-upload-dir;
1933 (<ref id="dupload"> et <ref id="dput"> avec les options adéquates peuvent
1934 tous deux être utilisés pour cela). Par défaut, vous pouvez utiliser le même
1935 <em>login/mot de passe</em> que pour <tt>ftp-master</tt>. Si vous utilisez
1936 une connexion FTP anonyme pour le téléchargement, placez vos fichiers dans le
1937 répertoire &upload-queue;.
1939 Tout comme sur <tt>ftp-master</tt>, vous pouvez vérifier votre téléchargement
1940 avec : <example>dinstall -n foo.changes</example>
1942 Attention, les personnes résidant aux États-Unis et les citoyens américains sont
1943 soumis à des restrictions sur l'exportation des logiciels de cryptographie.
1944 Au moment où j'écris, les citoyens américains peuvent exporter quelques
1945 logiciels de cryptographie soumis à une obligation de déclaration auprès du
1946 département du commerce américain. Toutefois, cette restriction a été
1947 abandonnée pour des logiciels qui sont déjà disponibles en dehors des
1948 États-Unis. En conséquence, tout logiciel de cryptographie de la section
1949 <em>main</em> de l'archive Debian qui ne dépend d'aucun paquet d'une autre
1950 section — il ne doit pas dépendre de <em>non-US/main</em> — peut
1951 être téléchargé sur <tt>ftp-master</tt> ou l'une de ses files d'attente
1954 La <em>charte Debian</em> n'empêche pas les résidents et citoyens américains de
1955 livrer des paquets sur <tt>non-US</tt> mais ils devront être vigilants en le
1956 faisant. Nous recommandons aux responsables concernés de prendre toutes les
1957 précautions nécessaires, <em>y compris la consultation d'un juriste</em>,
1958 pour s'assurer qu'ils n'enfreignent pas une loi américaine en livrant un
1959 paquet sur <tt>non-US</tt>.
1961 Pour les paquets des sections <em>non-US/main</em> et <em>non-US/contrib</em>,
1962 les responsables devraient au moins suivre la <url id="&url-u.s.-export;"
1963 name="procédure décrite par le gouvernement américain">. Les responsables de
1964 paquets <em>non-US/non-free</em> devront en plus consulter les <url
1965 id="&url-notification-of-export;" name="règles de déclaration d'exportation
1966 pour les logiciels commerciaux">.
1968 Cette section a pour seul but d'informer, elle n'a pas valeur de conseil
1969 juridique. Une fois encore, nous recommandons aux résidents et citoyens
1970 américains de consulter un juriste avant de livrer un paquet sur
1973 <sect1>Installer un paquet via <tt>chiark</tt>
1975 Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs
1976 possibilités. L'une d'elles consiste à télécharger vos fichiers dans
1977 <file>Incoming</file> en passant par le serveur <tt>chiark</tt> en Europe.
1978 Pour les détails, consultez <url id="&url-chiark-readme;">.
1980 Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux lois de
1981 contrôle des exportations américaines sur <tt>chiark</tt>. Les paquets
1982 téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>, les
1983 indications de la section <ref id="upload-ftp-master"> sont applicables ici
1986 Le programme <prgn>dupload</prgn> est capable de télécharger sur
1987 <tt>chiark</tt> ; consultez la documentation de ce programme pour en
1990 <sect1>Installer un paquet via <tt>erlangen</tt>
1992 Vous pouvez aussi accéder à un serveur situé en Allemagne : il vous suffit
1993 d'ouvrir une connexion anonyme sur <url id="&url-upload-erlangen;">.
1995 Le téléchargement fait sur ce serveur doit être aussi complet que s'il était
1996 fait dans le répertoire <file>Incoming</file> sur <tt>ftp-master</tt> : il
1997 doit comporter le fichier <file>.changes</file> et tous les fichiers
1998 mentionnés dans ce dernier. Le serveur vérifie que le fichier
1999 <file>.changes</file> est bien signé avec la clé PGP d'un développeur Debian
2000 pour éviter que des faux paquets n'atteignent <tt>ftp-master</tt>. Vérifiez
2001 bien que le champ <tt>Maintainer</tt> du fichier <file>.changes</file>
2002 contient <em>votre</em> adresse électronique. De même que sur
2003 <tt>ftp-master</tt>, cette adresse est ensuite utilisée pour toutes les
2006 Il n'est pas nécessaire de déplacer votre fichier dans un autre répertoire après
2007 le téléchargement, contrairement au serveur <tt>chiark</tt>. Vous devriez
2008 ensuite recevoir un courrier du serveur expliquant ce qu'il a fait de votre
2009 paquet. Normalement, il devrait avoir été déplacé vers
2010 <tt>ftp-master</tt> ; vous serez informé par le même biais si une erreur
2011 s'est produite au cours du processus.
2013 Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux lois de
2014 contrôle des exportations américaines sur <tt>erlangen</tt>. Les paquets
2015 téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>, les
2016 indications de la section <ref id="upload-ftp-master"> sont applicables ici
2019 Le programme <prgn>dupload</prgn> est capable de télécharger sur
2020 <tt>erlangen</tt> ; consultez la documentation de ce programme pour en
2023 <sect1>Les autres serveurs
2025 Un autre serveur est disponible aux États-Unis ; c'est un bon point de
2026 repli quand il est difficile de joindre <tt>ftp-master</tt>. Livrez vos
2027 paquets à l'adresse <url id="&url-upload-samosa;"> comme vous le feriez sur
2030 Il existe aussi un serveur au Japon : téléchargez vos paquet par FTP
2031 anonyme sur <url id="&url-upload-jp;">.
2033 <sect1 id="upload-notification">
2034 <heading>Notification de l'installation d'un nouveau paquet</heading>
2036 Les administrateurs de l'archive Debian sont responsables de l'installation des
2037 mises à jour. La plupart des mises à jour sont gérées quotidiennement par le
2038 logiciel de gestion de l'archive <prgn>katie</prgn>. Les mises à jour de
2039 paquets sur la distribution <em>unstable</em> sont installées
2040 ainsi. Dans les autres cas et notamment dans le cas d'un nouveau paquet,
2041 celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois entre le
2042 téléchargement d'un paquet vers un serveur et son installation effective. Soyez
2045 Dans tous les cas, vous recevrez un accusé de réception par courrier
2046 électronique indiquant que votre paquet a été installé et quels rapports de
2047 bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous les
2048 rapports de bogue que vous vouliez clore sont bien dans cette liste.
2050 L'accusé de réception indique aussi la section dans laquelle le paquet a été
2051 installé. S'il ne s'agit pas de votre choix, vous recevrez un second courrier
2052 qui vous informera de cette différence (voir ci-dessous).
2055 <sect id="override-file">Déterminer la section et la priorité d'un paquet
2057 Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
2058 <file>debian/control</file> n'indiquent ni où le paquet sera installé dans
2059 l'archive Debian, ni sa priorité. Afin de conserver la cohérence de
2060 l'archive, ce sont les administrateurs qui contrôlent ces champs. Les valeurs
2061 du fichier <file>debian/control</file> sont juste des indications.
2063 Les administrateurs de l'archive indiquent les sections et priorités des paquets
2064 dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le
2065 fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez
2066 informé par courrier électronique quand votre paquet sera installé dans
2067 l'archive. Vous pourrez corriger votre fichier <em>debian/control</em> avant
2068 votre prochain téléchargement ou alors vous pourrez vouloir modifier le
2069 fichier <em>override</em>.
2071 Pour modifier la section dans laquelle un paquet est archivé, vous devez d'abord
2072 vérifier que fichier <file>debian/control</file> est correct. Ensuite,
2073 envoyez un courrier à &email-override; ou un rapport de bogue sur le
2074 pseudo-paquet <package>ftp.debian.org</package> demandant la modification de
2075 la section ou de la priorité de votre paquet. Exposez bien les raisons qui
2076 vous amènent à demander ces changements.
2078 Pour en savoir plus sur les <em>fichiers override</em>, reportez-vous à <manref
2079 name="dpkg-scanpackages" section="8"> et <url
2080 id="&url-bts-devel;#maintincorrect">.
2082 Notez également que le terme « section » est utilisé pour la
2083 séparation des paquets selon leur licence, e.g <em>main</em>, <em>contrib</em>
2084 et <em>non-free</em>. Ceci est décrit dans une autre section, <ref
2088 <sect id="bug-handling">Gérer les bogues
2090 Chaque développeur doit être capable de travailler avec le <url name="système de
2091 suivi des bogues" id="&url-bts;"> Debian. Il faut savoir comment remplir
2092 des rapports de bogue correctement (voir <ref id="submit-bug">), comment les
2093 mettre à jour et les réordonner et comment les traiter et les fermer.
2095 Les fonctionnalités du système de suivi des bogues qui intéressent les
2096 développeurs sont décrites dans la <url id="&url-bts-devel;" name="documentation
2097 du BTS pour les développeurs">. Ceci inclut la fermeture des bogues, l'envoi des
2098 messages de suivi, l'assignation des niveaux de gravité et des marques,
2099 l'indication que les bogues ont été envoyés au développeur amont et autres
2102 Des opérations comme réassigner des bogues à d'autres paquets, réunir des
2103 rapports de bogues séparés traitant du même problème ou réouvrir des bogues
2104 quand ils ont été prématurément fermés, sont gérées en utilisant le serveur de
2105 courrier de contrôle. Toutes les commandes disponibles pour ce serveur sont
2106 décrites dans la <url id="&url-bts-control;" name="documentation du serveur de
2109 <sect1 id="bug-monitoring">Superviser les rapports de bogue
2111 Si vous voulez être un bon responsable, consultez régulièrement la page du <url
2112 id="&url-bts;" name="système de suivi des bogues">. Cette page contient tous
2113 les rapports de bogue qui concernent vos paquets. Vous pouvez les vérifier avec
2114 cette page : <tt>http://&bugs-host;/<var>votre_compte</var>@debian.org</tt>.
2116 Les responsables interagissent avec le système de suivi des bogues en utilisant
2117 l'adresse électronique <tt>&bugs-host;</tt>. Vous trouverez une documentation
2118 sur les commandes disponibles à l'adresse <url id="&url-bts;"> ou, si vous avez
2119 installé le paquet <package>doc-debian</package>, dans les fichiers locaux
2122 Certains trouvent utile de recevoir régulièrement une synthèse des rapports de
2123 bogues ouverts. Si vous voulez recevoir une synthèse hebdomadaire relevant tous
2124 les rapports de bogue ouverts pour vos paquets, vous pouvez configurer
2125 <prgn>cron</prgn> comme suit :
2127 # Synthèse hebdomadaire des rapports de bogue qui me concernent
2130 Remplacez <var>address</var> par votre adresse officielle de responsable Debian.
2132 <sect1 id="bug-answering">Répondre à des rapports de bogue
2134 Lorsque vous répondez à des rapports de bogue, assurez-vous que toutes vos
2135 discussions concernant les bogues sont envoyées au
2136 rapporteur du bogue et au bogue lui-même (<email>123@&bugs-host;</email>
2137 par exemple). Si vous rédigez un nouveau courrier et que vous ne vous souvenez
2138 plus de l'adresse du rapporteur de bogue, vous pouvez utiliser l'adresse
2139 <email>123-submitter@&bugs-host;</email> pour contacter le rapporteur
2140 <em>et</em> enregistrer votre courrier dans le journal du bogue (ce qui veut
2141 dire que vous n'avez pas besoin d'envoyer une copie du courrier à
2142 <email>123@&bugs-host;</email>).
2144 Si vous recevez un bogue mentionnant « FTBFS », cela veut dire
2145 « Fails To Build From Source » (Erreur de construction à partir du
2146 source). Les porteurs emploient fréquemment cet acronyme.
2148 Une fois que vous avez traité un rapport de bogue (i.e. que vous l'avez
2149 corrigé), marquez-le comme <em>done</em> (fermez-le) en envoyant un message
2150 d'explication à <email>123-done@&bugs-host;</email>. Si vous corrigez un
2151 bogue en changeant et en envoyant une nouvelle version du paquet, vous pouvez
2152 fermer le bogue automatiquement comme décrit dans <ref id="upload-bugfix">.
2154 Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la commande
2155 <tt>close</tt> à l'adresse &email-bts-control;.Si vous le faites, le rapporteur
2156 n'aura aucune information sur la clôture de son rapport.
2158 <sect1 id="bug-housekeeping">Gestion générale des bogues
2160 En tant que responsable de paquet, vous trouverez fréquemment des bogues dans
2161 d'autres paquets ou vous aurez des bogues sur vos paquets qui sont en fait des
2162 bogues sur d'autres paquets. Les fonctions intéressantes du système de suivi
2163 des bogues pour les développeurs sont décrites dans la <url
2164 id="&url-bts-devel;" name="documentation du BTS pour les développeurs Debian">.
2165 Les <url id="&url-bts-control;" name="instructions du serveur de contrôle du
2166 BTS"> documentent les opérations techniques du BTS, telles que comment remplir,
2167 réassigner, regrouper et marquer des bogues. Cette section contient des lignes
2168 directrices pour gérer vos propres bogues, définies à partir de l'expérience
2169 collective des développeurs Debian.
2171 Remplir des rapports de bogue pour des problèmes que vous trouvez dans d'autres
2172 paquet est l'une des « obligations civiques » du responsable,
2173 reportez-vous à <ref id="submit-bug"> pour les détails. Cependant, gérer les
2174 bogues de vos propres paquets est encore plus important.
2176 Voici une liste des étapes que vous pouvez suivre pour gérer un rapport de
2180 Décider si le rapport correspond à un bogue réel ou non. Parfois, les
2181 utilisateurs exécutent simplement un programme de la mauvaise façon car
2182 ils n'ont pas lu la documentation. Si c'est votre diagnostic, fermez
2183 simplement le bogue avec assez d'informations pour laisser l'utilisateur
2184 corriger son problème (donnez des indications vers la bonne
2185 documentation et ainsi de suite). Si le rapport de bogue revient
2186 régulièrement, vous devriez vous demander si la documentation est assez
2187 bonne ou si le programme ne devrait pas détecter une mauvaise
2188 utilisation pour donner un message d'erreur informatif. Il s'agit d'un
2189 problème qui peut être présenté à l'auteur amont.
2191 Si le rapporteur de bogue n'est pas d'accord avec votre décision de
2192 fermeture du bogue, il peut le ré-ouvrir jusqu'à ce que vous trouviez un
2193 accord sur la façon de le gérer. Si vous n'en trouvez pas, vous pouvez
2194 marquer le bogue avec <tt>wontfix</tt> pour indiquer aux personnes que
2195 le bogue existe, mais ne sera pas corrigé. Si cette situation n'est pas
2196 acceptable, vous (ou le rapporteur) pouvez vouloir demander une décision
2197 par le comité technique en réattribuant le bogue à
2198 <package>tech-ctte</package> (vous pouvez utiliser la commande
2199 <tt>clone</tt> du BTS si vous désirez garder le bogue comme rapporté sur
2200 votre paquet). Avant de faire cela, veuillez lire la <url
2201 id="&url-tech-ctte;" name="procédure recommandée">.
2204 Si le bogue est réel, mais est causé par un autre paquet,
2205 réattribuez simplement le bogue à l'autre paquet. Si vous ne savez pas à
2206 quel paquet il doit être réattribué, vous pouvez demander de l'aide sur
2207 &email-debian-devel; ou vous pouvez le réattribuer à
2208 <package>debian-policy</package> pour les laisser décider dans quel
2209 paquet est située l'erreur.
2211 Parfois, vous devez également ajuster la gravité du bogue pour qu'elle
2212 corresponde à notre définition de gravité des bogues. C'est dû au
2213 fait que les gens tendent à augmenter la gravité des bogues pour
2214 s'assurer que leurs bogues seront corrigés rapidement. La gravité de
2215 certains bogues peut même être rétrogradée en <em>wishlist</em> (souhait)
2216 quand le changement demandé est seulement d'ordre cosmétique.
2219 Le rapporteur de bogue peut avoir oublié de fournir certaines
2220 informations. Dans ce cas, vous devez lui demander les informations
2221 nécessaires. Vous pouvez utiliser la marque <tt>moreinfo</tt> (plus
2222 d'information) sur le bogue. De plus, si vous ne pouvez pas reproduire le
2223 bogue, vous pouvez le marquer comme <tt>unreproducible</tt> (non
2224 reproductible). Une personne qui arriverait à reproduire le bogue est
2225 alors invitée à fournir plus d'informations sur la façon de le
2226 reproduire. Après quelques mois, si cette information n'a été envoyée
2227 par personne, le bogue peut être fermé.
2230 Si le bogue est lié à l'empaquetage, vous devez simplement le
2231 corriger. Si vous ne pouvez pas le corriger vous-même, marquez alors le
2232 bogue avec <tt>help</tt> (aide). Vous pouvez également demander de
2233 l'aide sur &email-debian-devel; ou &email-debian-qa;. S'il s'agit d'un
2234 problème amont, vous devez faire suivre le rapport à l'auteur amont.
2235 Faire suivre un bogue n'est pas suffisant, vous devez vérifier à chaque
2236 version si le bogue a été corrigé ou non. S'il a été corrigé, vous le
2237 fermez simplement, sinon vous devez le rappeler à l'auteur. Si vous avez
2238 les compétences nécessaires, vous pouvez préparer un correctif pour
2239 corriger le bogue et l'envoyer en même temps à l'auteur. Assurez-vous
2240 d'envoyer le correctif au BTS et marquez le bogue avec <tt>patch</tt>
2244 Si vous avez corrigé un bogue sur votre copie locale ou si un correctif
2245 a été inclus dans le référentiel CVS, vous pouvez marquer le bogue avec
2246 <tt>pending</tt> (en attente) pour informer que le bogue est corrigé et
2247 qu'il sera fermé lors du prochain envoi (ajoutez le <tt>closes:</tt>
2248 dans le <file>changelog</file>). C'est particulièrement utile si
2249 plusieurs développeurs travaillent sur le même paquet.
2252 Une fois que le paquet corrigé est disponible dans la distribution
2253 <em>unstable</em>, vous pouvez fermer le bogue. Ceci peut être fait
2254 automatiquement, pour cela, reportez-vous à <ref id="upload-bugfix">.
2258 <sect1 id="upload-bugfix">Quand les rapports de bogue sont-ils fermés par
2259 une mise à jour ?
2261 Au fur et à mesure que les bogues et problèmes sont corrigés dans vos paquets,
2262 il est de votre responsabilité de fermer le rapport de bogue associé.
2263 Cependant, vous ne devez pas le fermer avant que le paquet n'ait été accepté
2264 dans l'archive Debian. C'est pourquoi, vous pouvez et vous devez clore le
2265 rapport dans le système de suivi des bogues une fois que vous avez reçu l'avis
2266 indiquant que votre nouveau paquet a été installé dans l'archive.
2268 Cependant, il est possible d'éviter d'avoir à fermer manuellement les bogues
2269 après l'envoi — indiquez simplement les bogues corrigés dans le fichier
2270 <file>changelog</file> en suivant une syntaxe précise. Par exemple :
2273 acme-cannon (3.1415) unstable; urgency=low
2275 * Frobbed with options (closes: Bug#98339)
2276 * Added safety to prevent operator dismemberment, closes: bug#98765,
2278 * Added man page. Closes: #98725.
2281 Techniquement parlant, l'expression rationnelle Perl suivante décrit comment les
2282 lignes de <em>changelogs</em> de fermeture de bogues sont identifiées :
2285 /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
2288 Nous préfèrons la syntaxe <tt>closes: #<var>XXX</var></tt>, car c'est l'entrée
2289 la plus concise et la plus facile à intégrer dans le texte du fichier
2290 <file>changelog</file>.
2292 Si vous entrez un numéro de bogue incorrect ou si vous oubliez un bogue dans les
2293 entrées du fichier <file>changelog</file>, n'hésitez pas à annuler tout dommage
2294 que l'erreur a entraîné. Pour réouvrir un bogue fermé par erreur, envoyez une
2295 commande <tt>reopen <var>XXX</var></tt> à l'adresse de contrôle du système de
2296 suivi des bogues, &email-bts-control;. Pour fermer tous les bogues restants qui
2297 ont été corrigés par votre envoi, envoyez le fichier <file>.changes</file> à
2298 <email>XXX-done@&bugs-host;</email> où <var>XXX</var> est le numéro du
2301 Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en utilisant le
2302 <file>changelog</file> tel que décrit ci-dessus. Si vous désirez simplement
2303 fermer les bogues qui n'ont rien à voir avec l'un de vos envois, faites-le
2304 simplement en envoyant une explication à
2305 <email>XXX-done@&bugs-host;</email>. Vous <strong>ne devez pas</strong> pas
2306 fermer des bogues dans une entrée de changelog d'une version si les
2307 changements dans cette version n'ont rien à voir avec le bogue.
2309 Pour une information plus générale sur ce qu'il faut mettre dans les entrées de
2310 changelog, veuillez vous reporter aux <ref id="bpp-debian-changelog">.
2312 <sect1 id="bug-security">Gérer les bogues de sécurité
2314 À cause de leur nature sensible, les bogues liés à la sécurité doivent être
2315 soigneusement traités. L'équipe de sécurité de Debian est là pour coordonner
2316 cette activité, pour faire le suivi des problèmes de sécurité en cours, pour
2317 aider les responsables ayant des problèmes de sécurité ou pour les corriger
2318 elle-même, pour envoyer les annonces de sécurité et pour maintenir le site
2319 security.debian.org.
2321 Si vous prenez connaissance d'un bogue lié à un problème de sécurité sur un
2322 paquet Debian, que vous soyez ou non le responsable, regroupez les
2323 informations pertinentes sur le problème et contactez rapidement l'équipe de
2324 sécurité à &email-security-team; dès que possible. Les informations utiles incluent, par
2329 les versions du paquet connues pour être affectées par le bogue. Vérifiez
2330 chaque version présente dans les distributions maintenues par Debian ainsi
2331 que dans <em>testing</em> et dans <em>unstable</em>,
2334 la nature d'une solution si elle est disponible (les correctifs sont
2335 particulièrement utiles),
2338 tout paquet corrigé que vous avez vous-même préparé (envoyez seulement les
2339 fichiers <file>.diff.gz</file> et <file>.dsc</file> et lisez d'abord <ref
2340 id="bug-security-building">),
2343 toute assistance que vous pouvez fournir pour aider les tests (exploits,
2344 tests de régression, etc.),
2347 toute information nécessaire pour l'annonce de sécurité (voir <ref
2348 id="bug-security-advisories">).
2352 <sect2 id="bug-security-confidentiality">Confidentialité
2354 À la différence de la plupart des autres activités au sein de Debian, les
2355 informations sur les problèmes de sécurité doivent parfois être gardées en
2356 privé pour un certain temps. Ceci permet les distributeurs de logiciels de
2357 coordonner leur dévoilement afin de minimiser l'exposition de leurs
2358 utilisateurs. Cette décision dépend de la nature du problème
2359 et de l'existence d'une solution correspondante et également s'il s'agit d'un
2360 fait connu publiquement.
2362 Il existe plusieurs façons pour un développeur de prendre connaissance d'un
2363 problème de sécurité :
2367 il le remarque sur un forum public (liste de diffusion, site web, etc.),
2370 quelqu'un remplit un rapport de bogue,
2373 quelqu'un l'informe par courrier privé.
2377 Dans les deux premiers cas, l'information est publique et il est important
2378 d'avoir une solution le plus vite possible. Dans le dernier cas, cependant, ce
2379 n'est peut-être pas une information publique. Dans ce cas, il existe quelques
2380 options possibles pour traiter le problème :
2384 si l'exposition de sécurité est mineure, il n'y a parfois pas besoin de
2385 garder le secret sur le problème et une correction devrait être effectuée
2389 si le problème est grave, il est préférable de partager cette
2390 information avec d'autres vendeurs et de coordonner une diffusion.
2391 L'équipe de sécurité garde des contacts avec les différentes organisations
2392 et individus et peut prendre soin des actions à mener.
2397 Dans tous les cas, si la personne qui indique le problème demande à ce que
2398 l'information ne soit pas diffusée, cela devrait être respecté avec l'évidente exception
2399 d'informer l'équipe de sécurité pour qu'une correction puisse être effectuée
2400 pour la version stable de Debian. Quand vous envoyez des informations
2401 confidentielles à l'équipe de sécurité, assurez-vous de bien mentionner ce fait.
2403 <p>Veuillez noter que si le secret est nécessaire, vous ne pourrez pas envoyer
2404 un correctif vers <em>unstable</em> (ou ailleurs) puisque les informations de
2405 changelog et de diff sont publiques pour <em>unstable</em>.
2407 <p>Il existe deux raisons pour diffuser l'information même si le secret est
2408 demandé : le problème est connu depuis un certain temps ou le problème ou
2409 son exploitation est devenu public.
2411 <sect2 id="bug-security-advisories">Annonces de sécurité
2413 Les annonces de sécurité ne sont émises que pour la distribution actuelle
2414 diffusée <em>stable</em>, <em>PAS</em> pour <em>testing</em> ou <em>unstable</em>.
2415 Quand elle est diffusée, l'annonce est envoyée à la liste de diffusion
2416 &email-debian-security-announce; et elle est postée sur <url
2417 id="&url-debian-security-advisories;" name="la page de sécurité">. Les
2418 annonces de sécurité sont écrites et postées par les membres de l'équipe de sécurité.
2419 Cependant, ils ne verront aucun inconvénient à ce qu'un responsable leur
2420 apporte des informations ou écrive une partie du texte. Les informations qui
2421 devraient être présentes dans une annonce incluent :
2424 une description du problème et de sa portée, y compris :
2427 le type du problème (usurpation de privilège, déni de service,
2431 quels sont les privilèges obtenus et par quels utilisateurs (si c'est le
2435 comment il peut être exploité,
2438 si le problème peut être exploité à distance ou localement,
2441 comment le problème a été corrigé,
2444 Ces informations permettent aux utilisateurs d'estimer la menace pesant
2449 les numéros de version des paquets affectés,
2452 les numéros de version des paquets corrigés,
2455 une information sur la façon de récupérer les paquets mis à jour
2456 (habituellement l'archive de sécurité Debian),
2459 des références à des annonces amont, des identifiants <url
2460 id="http://cve.mitre.org" name="CVE"> et toute autre information utile
2461 pour recouper les références de la vulnérabilité.
2465 <sect2 id="bug-security-building">
2466 <heading>Préparer les paquets pour corriger des problèmes de sécurité
2468 Une façon d'aider l'équipe de sécurité dans ses travaux est de leur fournir des
2469 paquets corrigés convenables pour une annonce de sécurité pour la version
2470 <em>stable</em> de Debian
2472 Quand une mise à jour de la version <em>stable</em> est effectuée, un soin
2473 particulier doit être apporté pour éviter de modifier le comportement du
2474 système ou d'introduire de nouveaux bogues. Pour cela, faites le moins de
2475 changements possibles pour corriger le bogue. Les utilisateurs et les
2476 administrateurs s'attendent à un comportement identique dans une version
2477 lorsque celle-ci est diffusée, donc tout changement qui est fait est
2478 susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour
2479 les bibliothèques : assurez-vous ne de jamais changer l'API ou l'ABI,
2480 quelque minimal que soit le changement.
2482 Cela veut dire que passer à une version amont supérieure n'est pas une bonne
2483 solution. À la place, les changements pertinents devraient être rétroportés
2484 vers la version présente dans la distribution <em>stable</em> de Debian.
2485 Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de
2486 sécurité Debian peut le faire.
2488 Dans certains cas, il n'est pas possible de rétroporter un correctif de
2489 sécurité, par exemple, quand de grandes quantités de code source doivent être
2490 modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à
2491 une nouvelle version amont. Cependant, ceci n'est fait que dans des situations
2492 extrêmes et vous devez toujours coordonner cela avec l'équipe de sécurité au
2495 Il existe une autre règle de conduite liée à cela : testez toujours vos
2496 changements. Si une exploitation du problème existe, essayez-la et
2497 vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet
2498 corrigé. Testez aussi les autres actions normales car parfois un correctif de
2499 sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas
2502 Examinez et testez autant que possible vos changements. Vérifiez les différences
2503 avec la version précédente de manière répétée (<prgn>interdiff</prgn> du
2504 paquet <package>patchutils</package> et <prgn>debdiff</prgn> du paquet
2505 <package>devscripts</package> sont des outils utiles pour cela, voir <ref
2508 Lors de la construction de la correction, gardez les points suivants à
2513 Assurez-vous que vous avez pour cible la bonne distribution dans votre
2514 fichier <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de
2515 <tt>stable-security</tt> et pour <em>testing</em>, c'est
2516 <tt>testing-security</tt> et pour l'ancienne distribution stable, c'est
2517 <tt>oldstable-security</tt>. Ne ciblez pas
2518 <var>distribution</var>-proposed-updates !
2521 Fournissez des entrées de changelog descriptives et complètes. D'autres
2522 personnes se baseront dessus pour déterminer si un bogue particulier a été
2523 corrigé. Quand cela est possible, incluez une référence externe, de
2524 préférence, un identifiant CVE, pour qu'elle puisse être recoupée.
2527 Assurez-vous que le numéro de version est correct. Il doit être plus élevé
2528 que celui du paquet actuel, mais moins que ceux des paquets des versions
2529 des distributions suivantes. En cas de doute, testez-le avec <tt>dpkg
2530 --compare-versions</tt>. Pour <em>testing</em>, il doit y avoir un numéro
2531 de version supérieur dans <em>unstable</em>. S'il n'y en a pas encore (par
2532 exemple, si <em>testing</em> et <em>unstable</em> ont la même version),
2533 vous devez envoyer une nouvelle version vers <em>unstable</em> en premier.
2536 Ne faites pas d'envoi de source seul si votre paquet possède un ou
2537 plusieurs paquets binary-all (n'utilisez pas l'option <tt>-S</tt> de
2538 <prgn>dpkg-buildpackage</prgn>). L'infrastructure <prgn>buildd</prgn> ne
2539 construira pas ceux-ci. Ce point s'applique aux envois de paquets normaux
2543 Si la source amont a été envoyée auparavant à security.debian.org (par une
2544 précédente mise à jour de sécurité), construisez le paquet sans la source
2545 amont (<tt>dpkg-buildpackage -sd</tt>). Sinon, construisez-le avec le
2546 source complet (<tt>dpkg-buildpackage -sa</tt>).
2549 Assurez-vous d'utiliser exactement le même nom <file>*.orig.tar.gz</file>
2550 que celui utilisé dans l'archive normale, sinon il ne sera pas possible de
2551 déplacer plus tard le correctif de sécurité dans l'archive principale.
2554 Assurez-vous de compiler sur un système
2555 propre, dont tous les paquets appartiennent à la distribution pour laquelle vous
2556 construisez le paquet. Si vous n'avez pas un tel système, vous pouvez
2557 utiliser l'une des machines de debian.org (voir <ref
2558 id="server-machines">) ou mettez en place un chroot (voir <ref id=
2559 "pbuilder"> et <ref id="debootstrap">).
2563 <sect2 id="bug-security-upload">Mettre à jour le paquet corrigé
2565 Vous <em>NE</em> devez <em>PAS</em> envoyer un paquet dans la file d'attente des envois de sécurité
2566 (oldstable-security, stable-security, etc.)
2567 sans l'accord préalable de l'équipe de sécurité. Si le paquet ne remplit pas
2568 exactement les exigences de l'équipe, il causera beaucoup de problèmes, ainsi
2569 que des délais dans la gestion de l'envoi indésirable.
2571 Vous <em>NE</em> devez <em>PAS</em> envoyer votre correction dans
2572 <em>proposed-updates</em> sans vous coordonner avec l'équipe de sécurité. Les
2573 paquets seront copiés de security.debian.org dans le répertoire
2574 <file>proposed-updates</file> automatiquement. Si un paquet avec le même numéro
2575 de version ou un numéro plus grand est déjà installé dans l'archive, la mise à
2576 jour de sécurité sera rejetée par le système d'archive. Ainsi, la distribution
2577 <em>stable</em> se retrouvera à la place sans la mise à jour de sécurité de ce
2580 Une fois que vous avez créé et testé le nouveau paquet et qu'il a été approuvé
2581 par l'équipe de sécurité, il doit être envoyé pour être installé dans les
2582 archives. Pour les envois de sécurité, l'adresse d'envoi est
2583 <tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt>.
2586 Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera
2587 automatiquement recompilé pour toutes les architectures et stocké pour
2588 vérification par l'équipe de sécurité.
2591 Les envois en attente d'acceptation ou de vérification ne sont accessibles que
2592 par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des
2593 correctifs pour des problèmes de sécurité qui ne peuvent pas encore être
2597 Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur
2598 security.debian.org ainsi que dans le répertoire
2599 <var>distribution</var>-proposed-updates qui convient sur ftp-master ou dans
2602 <sect id="archive-manip">
2603 <heading>Déplacer, effacer, changer le nom, adopter et abandonner des paquets
2605 Certaines manipulations de l'archive ne sont pas possibles avec le processus
2606 de mise à jour automatisé. Elles sont appliquées manuellement par les
2607 développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.
2609 <sect1 id="moving-pkgs">Déplacer des paquets
2611 Il se peut qu'un paquet puisse changer de section. Une nouvelle version d'un paquet
2612 de la section <tt>non-free</tt> pourrait, par exemple, être distribuée sous
2613 licence GNU GPL ; dans ce cas, le paquet doit être déplacé dans la section
2614 <tt>main</tt> ou <tt>contrib</tt><footnote><p>Reportez-vous à la <url
2615 id="&url-debian-policy;" name="charte Debian"> pour savoir dans quelle section
2616 un paquet doit être classé.</footnote>.
2618 Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez les
2619 informations de contrôle du paquet pour le placer dans la section désirée et
2620 téléchargez à nouveau votre paquet dans l'archive. Reportez-vous à la <url
2621 id="&url-debian-policy;" name="charte Debian"> pour en savoir plus. Si votre
2622 nouvelle section est valide, il sera déplacé automatiquement. Si ce n'est pas
2623 le cas, contactez les responsables ftp pour comprendre ce qui s'est passé.
2625 Si vous avez besoin de modifier la sous-section de l'un de vos paquets
2626 (<tt>devel</tt> ou <tt>admin</tt> par exemple), la procédure est légèrement
2627 différente. Modifiez la sous-section dans le fichier de contrôle de votre
2628 paquet et téléchargez-le. Il vous faudra ensuite demander la modification du
2629 fichier <em>override</em> comme décrit dans la section <ref
2630 id="override-file">.
2633 <sect1 id="removing-pkgs">Supprimer des paquets
2635 Si, pour une raison ou une autre, vous avez besoin de supprimer un paquet de
2636 l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile, que
2637 l'on conservait pour des raisons de compatibilité), il vous faudra envoyer un
2638 rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
2639 demander sa suppression. N'oubliez pas de préciser de quelle distribution le
2640 paquet doit être supprimé. Normalement, vous ne devriez avoir à supprimer que
2641 des paquets d'<em>unstable</em> ou de <em>experimental</em>. Les paquets de
2642 <em>testing</em> ne sont pas supprimés directement. Ils sont plutôt enlevés
2643 automatiquement après que le paquet a été supprimé d'<em>unstable</em> et
2644 si aucun paquet de <em>testing</em> n'en dépend.
2646 Vous devez également détailler les raisons justifiant cette demande. Ceci a pour
2647 but d'éviter les suppressions non désirées et de garder une trace de la raison
2648 pour laquelle un paquet a été supprimé. Par exemple, vous pouvez fournir le nom
2649 du paquet qui remplace celui à supprimer.
2651 Vous ne pouvez demander la suppression d'un paquet que si vous en
2652 êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez
2653 obtenir l'accord de son dernier responsable.
2655 Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
2656 autres développeurs sur la liste &email-debian-devel;. Le programme
2657 <prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
2658 utile. La commande <tt>apt-cache showpkg <var>paquet</var> </tt> vous
2659 indiquera, entre autres, les paquets qui dépendent de <var>paquet</var>.
2661 Une fois que le paquet a été supprimé, les bogues du paquet doivent être gérés.
2662 Soit ils sont réattribués à un autre paquet dans le cas où le code actuel a
2663 évolué en un autre paquet (par exemple, <tt>libfoo12</tt> a été supprimé parce
2664 que <tt>libfoo13</tt> le remplace) ou ils sont fermés si le logiciel ne fait
2665 simplement plus partie de Debian.
2667 <sect2>Supprimer des paquets dans <tt>Incoming</tt>
2669 Par le passé, il était possible de supprimer un paquet de <file>Incoming</file>.
2670 Cependant, ce n'est plus possible depuis la mise en place du nouveau système
2671 de file d'attente. Il vous faudra télécharger une nouvelle version de votre
2672 paquet avec un numéro de version postérieur à celui que vous voulez
2673 remplacer. Les deux versions seront installées dans l'archive mais seule la
2674 plus récente sera accessible dans <em>unstable</em> car la précédente sera
2675 immédiatement remplacée par la nouvelle. Toutefois, si vous testez
2676 correctement vos paquets, le besoin d'en remplacer un ne devrait pas être
2679 <sect1>Remplacer un paquet ou changer son nom
2681 Il peut vous arriver de vous tromper en nommant un paquet et de vouloir
2682 changer son nom. Dans ce cas, vous devrez intervenir en deux étapes. D'abord, modifiez
2683 votre fichier <file>debian/control</file> pour que votre nouveau paquet
2684 remplace et entre en conflit avec l'ancien paquet que vous voulez remplacer
2685 (reportez-vous à la <url id="&url-debian-policy;" name="charte Debian"> pour
2686 les détails). Une fois que votre paquet est installé dans l'archive, faites un
2687 rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
2688 demandez la suppression du paquet mal nommé. N'oubliez pas de réattribuer
2689 correctement les bogues du paquet en même temps.
2691 D'autres fois, vous pouvez commettre une erreur en construisant le paquet et
2692 vous désirez le remplacer. La seule façon de faire est d'incrémenter le numéro de
2693 version et d'envoyer une nouvelle version. L'ancienne version expirera de la
2694 façon habituelle. Notez que ceci s'applique à chaque partie de votre paquet, y
2695 compris les sources : si vous désirez remplacer l'archive source amont de
2696 votre paquet, vous devez l'envoyer avec un numéro de version différent. Une
2697 possibilité simple est de remplacer <file>foo_1.00.orig.tar.gz</file> par
2698 <file>foo_1.00+0.orig.tar.gz</file>. Cette restriction donne à chaque fichier
2699 du site ftp un nom unique, ce qui aide à garantir la consistance dans le réseau
2702 <sect1 id="orphaning">Abandonner un paquet
2704 Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres et
2705 faire le nécessaire pour qu'il soit marqué <em>abandonné</em> (i.e.
2706 <em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
2707 Group &orphan-address;</tt> dans le champ <tt>maintainer</tt> du paquet et
2708 faire un rapport de bogue sur le pseudo-paquet <package>wnpp</package>. Le
2709 titre de votre rapport de bogue devrait être
2710 « <tt>O<footnote><p><em>Orphaned</em> : abandonné.</footnote>:
2711 <var>paquet</var> — <var>courte description</var></tt> » pour
2712 indiquer que le paquet est abandonné. La gravité du bogue sera
2713 <em>normale</em>. Si vous le jugez nécessaire, envoyez une copie à
2714 &email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
2715 l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le sujet
2716 du message ne contiendra pas le numéro du bogue.
2718 Si le paquet est particulièrement important pour la distribution, il vous faudra
2719 faire un rapport de bogue sur le pseudo-paquet <package>wnpp</package>,
2720 l'intituler « <tt>RFA<footnote><p><em>Request For Adoption</em> :
2721 offre d'adoption.</footnote>: <var>paquet</var> — <var>courte
2722 description</var></tt> » et lui affecter la gravité <em>importante</em>.
2723 Envoyez une copie de votre rapport de bogue à la liste debian-devel comme
2726 Reportez-vous à la page WNPP<footnote><p><em>Work-needing and prospective
2727 packages</em> : paquets en souffrance et paquets souhaités.</footnote>
2728 <url id="&url-wnpp;"> pour en savoir plus.
2730 <sect1 id="adopting">Adopter un paquet
2732 Une liste des paquets en attente de nouveau responsable est disponible à la page
2733 <url id="&url-wnpp;" name="paquets en souffrance et paquets souhaités">. Si
2734 vous voulez prendre en charge un paquet de cette liste, reportez-vous à la page
2735 mentionnée ci-dessus pour connaître la procédure à suivre.
2737 Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
2738 correct — ce serait un détournement de paquet. Vous pouvez prendre
2739 contact avec le responsable actuel et lui demander si vous pouvez prendre en
2740 charge ce paquet. Si vous avez le sentiment qu'un responsable est parti sans
2741 prévenir depuis un moment, veuillez vous reporter à <ref id="mia-qa">).
2743 Généralement, vous ne pouvez pas adopter un paquet sans l'accord du responsable
2744 actuel. Même s'il vous ignore, ce n'est pas une raison pour le faire. Les
2745 plaintes à propos des responsables devraient être portées sur la liste de
2746 diffusion des développeurs. Si la discussion ne se termine pas par une
2747 conclusion positive et que le problème est de nature technique, considérez de
2748 porter le cas à l'attention du comité technique (voir la <url name="page web du
2749 comité technique" id="&url-tech-ctte;"> pour plus d'information).
2751 Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de suivi
2752 des bogues indique que vous êtes le responsable du paquet. Cela se produira
2753 automatiquement une fois que vous aurez installé une nouvelle version du paquet
2754 dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut prendre
2755 quelques heures après le téléchargement. Si vous pensez ne pas avoir de mise à
2756 jour à faire pour un moment, vous pouvez utiliser le <ref
2757 id="pkg-tracking-system"> pour recevoir les rapports de bogue. Cependant,
2758 assurez-vous que cela ne pose aucun problème à l'ancien responsable de
2759 continuer à recevoir les bogues durant ce temps.
2761 <sect id="porting">Le portage
2763 Debian accepte un nombre croissant d'architectures. Même si vous n'êtes pas un
2764 porteur et même si vous n'utilisez qu'une architecture, il est de votre
2765 responsabilité de développeur d'être attentif aux questions de
2766 portabilité. C'est pourquoi il est important que vous lisiez ce chapitre
2767 même si vous n'êtes pas un porteur.
2769 Porter un paquet consiste à faire un paquet binaire pour une architecture
2770 différente de celle du paquet binaire fait par le responsable du paquet.
2771 C'est une activité remarquable et essentielle. En fait, les porteurs sont
2772 à l'origine de la plupart des compilations de paquets Debian. Pour un
2773 paquet binaire <em>i386</em>, par exemple, il faut compter une
2774 recompilation pour chaque autre architecture, soit un total de
2775 &number-of-arches; recompilations.
2778 <sect1 id="kind-to-porters">Être gentil avec les porteurs
2780 Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un
2781 grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
2782 modification. Malheureusement, c'est rarement le cas. Cette section contient
2783 une liste d'erreurs commises régulièrement par les responsables Debian —
2784 problèmes courants qui bloquent souvent les porteurs et compliquent inutilement
2787 Ici, le mot d'ordre est de répondre rapidement aux rapports de bogues et
2788 remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
2789 étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine manière).
2790 Merci pour votre indulgence envers des rapports de bogue succincts ou peu
2791 clairs ; faites de votre mieux pour éliminer le problème.
2793 Les problèmes les plus couramment rencontrés par les porteurs sont causés par
2794 des erreurs de mise en paquet dans le paquet source. Voici un
2795 pense-bête pour les choses auxquelles vous devez être attentif :
2798 Vérifiez que les champs <tt>Build-Depends</tt> et
2799 <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
2800 corrects. Le meilleur moyen de le vérifier est d'utiliser le paquet
2801 <package>debootstrap</package> pour créer un environnement
2802 <em>unstable</em> <em>chrooté</em> (voir <ref id="debootstrap">). Dans
2803 cet environnement <em>chrooté</em>, il faudra installer le paquet
2804 <package>build-essential</package> et tous les paquets mentionnés dans
2805 les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
2806 Ensuite, vous essayerez de fabriquer votre paquet dans cet
2807 environnement. Ces étapes peuvent être automatisées en utilisant le
2808 programme <prgn>pbuilder</prgn> qui est fourni par le paquet de même
2809 nom (voir <ref id="pbuilder">).
2811 Si vous n'arrivez pas à installer un environnement <em>chrooté</em>,
2812 <prgn>dpkg-depcheck</prgn> pourra peut-être vous aider (voir <ref
2813 id="dpkg-depcheck">).
2815 Consultez la <url id="&url-debian-policy;" name="charte Debian"> pour en
2816 savoir plus sur les dépendances de fabrication.
2819 Ne choisissez pas d'autres valeurs que <em>all</em> ou <em>any</em> pour
2820 le champ architecture sans avoir de bonnes raisons pour le faire. Trop
2821 souvent, les développeurs ne respectent pas les instructions de la <url
2822 id="&url-debian-policy;" name="charte Debian">. Choisir la valeur
2823 « i386 » est la plupart du temps incorrect.
2826 Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
2827 <var>paquet</var>.dsc</tt> pour vous assurer que le paquet se
2828 décompresse correctement. En utilisant le résultat de ce test,
2829 construisez votre paquet binaire à l'aide de la commande
2830 <prgn>dpkg-buildpackage</prgn>.
2833 Vérifiez que les fichiers <file>debian/files</file> et
2834 <file>debian/substvars</file> ne sont pas dans votre paquet source. Ils
2835 doivent être effacés par la cible <em>clean</em> de
2836 <file>debian/rules</file>.
2839 Assurez-vous que vous ne vous appuyez pas sur des éléments de
2840 configuration ou des logiciels installés ou modifiés localement. Par
2841 exemple, vous ne devriez jamais appeler des programmes du répertoire
2842 <file>/usr/local/bin</file> ou de répertoires équivalents. Essayez de ne
2843 pas vous appuyer sur des logiciels configurés de manière spéciale.
2844 Essayez de construire votre paquet sur une autre machine, même s'il
2845 s'agit de la même architecture.
2848 Ne vous appuyez pas sur une installation préexistante de votre paquet
2849 (un sous-cas de la remarque précédente).
2852 Si possible, ne vous appuyez pas sur une particularité présente dans un
2853 compilateur précis ou dans une certaine version d'un compilateur. Si
2854 vous ne pouvez pas faire autrement, assurez-vous que les dépendances de
2855 fabrication reflètent bien cette restriction. Dans ce cas, vous cherchez
2856 sûrement les problèmes car quelques architectures pourraient choisir un
2857 compilateur différent.
2860 Vérifiez que votre fichier <file>debian/rules</file> distingue les
2861 cibles <em>binary-arch</em> et <em>binary-indep</em> comme l'exige la
2862 charte Debian. Vérifiez que ces cibles sont indépendantes l'une de
2863 l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer l'une de
2864 ces cibles avant d'invoquer l'autre. Pour vérifier cela, essayez
2865 d'exécuter <tt>dpkg-buildpackage -B</tt>.
2870 <sect1 id="porter-guidelines">Instructions pour les mises à jour des
2873 Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez
2874 de la chance et votre travail est facile. Cette section s'applique dans ce
2875 cas ; elle décrit comment construire et installer correctement votre
2876 paquet binaire dans l'archive Debian. Si vous devez modifier le paquet pour le
2877 rendre compilable sur votre architecture cible vous devez faire une mise à jour
2878 des sources, consultez la section <ref id="nmu-guidelines">.
2880 Pour un envoi de portage, ne faites pas de changement dans les sources. Vous
2881 n'avez pas besoin de modifier les fichiers du paquet source (cela inclut le
2882 fichier <file>debian/changelog</file>).
2884 La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante :
2885 <tt>dpkg-buildpackage -B -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
2886 <var>adresse-porteur</var> par votre adresse électronique. Cette commande
2887 construira les parties du paquet qui dépendent de l'architecture, en utilisant
2888 la cible <em>binary-arch</em> de <file>debian/rules</file>.
2890 <sect2 id="binary-only-nmu">
2891 Mises à jour indépendantes binaires ou recompilations
2893 Parfois, l'envoi du portage initial pose problème car l'environnement dans lequel
2894 le paquet a été construit n'était pas bon (bibliothèques plus à jour ou
2895 obsolètes, mauvais compilateur, etc.). Il se peut que vous ayez à le recompiler
2896 dans un environnement mis à jour. Cependant, dans ce cas, vous devez changer
2897 le numéro de version pour que les mauvais anciens paquets soient remplacés dans
2898 l'archive Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
2899 s'ils n'ont pas un numéro de version supérieur à celui actuellement
2900 disponible). Malgré les modifications nécessaires du changelog, ce type de mise
2901 à jour reste une mise à jour indépendante binaire — il n'est pas
2902 nécessaire de reconsidérer le statut des paquets binaires des autres
2903 architectures pour les marquer périmés ou à recompiler.
2905 Ces recompilations nécessitent des numéros de version « magiques »
2906 pour que le système de maintenance de l'archive comprennent que, bien qu'il y
2907 ait une nouvelle version, il n'y a pas eu de modification des sources. Si vous
2908 ne faites pas cela correctement, les administrateurs de l'archive rejetteront
2909 votre mise à jour (car il n'y aura pas de code source associé).
2911 Cette « magie » associée à une mise à jour par recompilation est déclenchée en
2912 utilisant un troisième nombre dans la partie debian du numéro de version. Si,
2913 par exemple, la dernière version du paquet que vous recompilez était
2914 « 2.9-3 », votre mise à jour portera le numéro
2915 « 2.9-3.0.1 ». Si cette version était « 3.4-2.1 » votre
2916 mise à jour portera le numéro « 3.4-2.1.1 ».
2919 <sect2 id="source-nmu-when-porter">
2920 Quand faire une mise à jour indépendante source pour un portage ?
2922 Les porteurs qui font des mises à jour indépendantes sources suivent
2923 généralement les instructions de la section <ref id="nmu"> tout comme les
2924 non-porteurs. Les délais d'attente sont cependant plus courts car les
2925 porteurs doivent manipuler un grand nombre de paquets. À nouveau, la
2926 situation diffère selon la distribution visée.
2928 Si vous êtes porteur et faites une mise à jour pour <em>unstable</em>, les
2929 instructions précédentes sont applicables à deux différences près. Tout
2930 d'abord, le temps d'attente raisonnable — délai entre le moment où vous
2931 envoyez un rapport au système de suivi des bogues et le moment où vous pouvez
2932 faire une mise à jour indépendante <em>(NMU)</em> — est de sept jours.
2933 Ce délai peut être raccourci si le problème est crucial et met l'effort de
2934 portage en difficulté : c'est à la discrétion de l'équipe de portage.
2935 (Souvenez-vous, il ne s'agit pas d'un règlement, mais de recommandations
2936 communément acceptées).
2938 Deuxième différence, les porteurs qui font des mises à jour indépendantes
2939 sources doivent choisir une gravité <em>sérieuse</em> (i.e. <em>serious</em>)
2940 ou supérieure quand ils envoient leur rapport au système de suivi des bogues.
2941 Ceci assure qu'un paquet source unique permet de produire un paquet binaire
2942 pour chaque architecture supportée au moment de la sortie de la distribution.
2943 Il est très important d'avoir un paquet source et un paquet binaire pour
2944 toutes les architectures pour être conforme à plusieurs licences.
2946 Les porteurs doivent éviter d'implémenter des contournements pour des bogues de
2947 l'environnement de compilation, du noyau ou de la libc. Quelques fois, ces
2948 contournements sont inévitables. Si vous devez faire quelque chose de ce
2949 genre, marquez proprement vos modifications avec des <tt>#ifdef</tt> et
2950 documentez votre contournement pour que l'on sache le retirer une fois que le
2951 problème aura disparu.
2953 Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de leur
2954 travail pendant le délai d'attente. Ainsi, d'autres personnes peuvent
2955 bénéficier du travail du porteur même pendant ce délai. Bien sûr, ces
2956 adresses n'ont rien d'officiel, alors soyez sur vos gardes si vous les
2960 <sect1 id="porter-automation">
2961 <heading>Infrastructure de portage et automatisation</heading>
2963 Il existe une infrastructure et plusieurs outils pour faciliter l'automatisation
2964 du portage des paquets. Cette section contient un bref aperçu de cette
2965 automatisation et du portage de ces outils ; veuillez vous reporter à la
2966 documentation des paquets ou les références pour une information complète.</p>
2969 <heading>Listes de diffusion et pages web</heading>
2971 Les pages web contenant l'état de chaque portage peuvent être trouvées à <url
2972 id="&url-debian-ports;">.
2974 Chaque portage de Debian possède sa propre liste de diffusion. La liste des
2975 listes de diffusion de portage peut être trouvée à <url
2976 id="&url-debian-port-lists;">. Ces listes sont utilisées pour coordonner les
2977 porteurs et pour mettre en relation les utilisateurs d'un portage donné avec les
2982 <heading>Outils pour les porteurs</heading>
2984 Les descriptions de plusieurs outils de portage peuvent être trouvées dans les
2985 <ref id="tools-porting">.</p>
2989 <heading><package>buildd</package></heading>
2991 Le système <package>buildd</package> est un système distribué pour la
2992 compilation d'une distribution. Il est habituellement utilisé en conjonction
2993 avec des automates de compilation ; ce sont des machines
2994 « esclaves » qui récupèrent des paquets sources et tentent de les
2995 compiler. Il est aussi possible d'interagir par courrier électronique avec ce
2996 système. Cette interface est utilisée par les porteurs pour récupérer un
2997 paquet source (en général, un paquet qui ne peut être compilé
2998 automatiquement) et travailler dessus.
3000 <package>buildd</package> n'est pas disponible sous forme de paquet ;
3001 pourtant, la plupart des équipes de porteurs l'utilisent aujourd'hui ou ont
3002 prévu de l'utiliser bientôt. L'outil de construction automatisé réel est dans
3003 le paquet <package>sbuild</package>, voir la description dans <ref
3004 id="sbuild">. Le système <package>buildd</package> regroupe également un
3005 ensemble de composants très utiles, continuellement utilisés, mais non encore
3006 mis en paquet, tels que <prgn>andrea</prgn> et <prgn>wanna-build</prgn>.
3008 Une partie des informations produites par <package>buildd</package>
3009 — utiles pour les porteurs — est disponible sur la
3010 toile à l'adresse <url id="&url-buildd;">. Ces informations
3011 incluent les résultats produits toutes les nuits par
3012 <prgn>andrea</prgn> (dépendances des sources) et
3013 <prgn>quinn-diff</prgn> (paquets à recompiler).
3015 Nous sommes très fiers de ce système car il a de nombreux usages potentiels. Des
3016 groupes de développeurs indépendants peuvent utiliser ce système pour créer
3017 différentes saveurs de Debian — qui peuvent être ou ne pas être
3018 intéressantes pour tous (par exemple, une version de Debian compilée avec des
3019 vérifications relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi
3020 de recompiler rapidement toute une distribution.
3023 <sect id="nmu">Mise à jour indépendante
3025 Dans certaines circonstances, il est nécessaire qu'une personne autre que le
3026 responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de
3027 mise à jour est désigné en anglais par l'expression <em>non-maintainer
3028 upload (NMU)</em>. Dans le présent document, nous traduisons librement
3029 cette expression par « mise à jour indépendante ».
3031 Ces mises à jour indépendantes de binaires font de temps en temps partie du
3032 travail normal des porteurs qui compilent les paquets pour d'autres
3033 architectures (voir <ref id="porting">). Un développeur peut aussi faire
3034 des mises à jour indépendantes quand il corrige le paquet d'un autre
3035 développeur pour éliminer un problème de sécurité ou un bogue bloquant. Cela
3036 se produit plus particulièrement en période de gel de la distribution de
3037 développement ou quand le responsable officiel du paquet ne peut pas
3038 fournir une correction dans un délai raisonnable.
3040 Ce chapitre contient des informations qui vous expliqueront quand et comment
3041 faire des mises à jour indépendantes. Une distinction fondamentale doit
3042 être faite entre les mises à jour indépendantes sources et les mises à
3043 jour indépendantes binaires. Elle est explicitée dans la section suivante.
3045 <sect1 id="nmu-terms">Terminologie
3047 Deux nouvelles expressions sont introduites dans cette section :
3048 « mise à jour indépendante source » et « mise à jour
3049 indépendante binaire ». Ces expressions ont une définition précise dans le
3050 monde Debian. Elles correspondent toutes deux au même type d'activité ;
3051 elles impliquent toutes deux qu'une personne fait une mise à jour d'un paquet
3052 alors qu'elle n'est pas officiellement responsable de ce paquet. C'est pourquoi
3053 nous qualifions ces mises à jours
3054 d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser
3055 entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas
3056 question d'agir sans prévenir le responsable au préalable (voir <ref
3057 id="nmu-guidelines">).</footnote>.
3059 Une mise à jour indépendante source est une livraison de paquet faite par une
3060 personne qui n'est pas le responsable officiel de ce paquet avec pour objectif
3061 de corriger un bogue dans le paquet. Une mise à jour indépendante source
3062 implique toujours une modification des sources du paquet, même s'il ne s'agit
3063 que d'un changement dans le fichier <file>debian/changelog</file>. Ce
3064 changement peut tout aussi bien concerner la partie amont du source que la
3065 partie spécifique à Debian. Une mise à jour indépendante source peut aussi
3066 inclure des paquets spécifiques à une architecture tout comme un fichier
3067 <em>diff</em> modifié.
3069 Une mise à jour indépendante binaire est constitué par la recompilation et
3070 l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du
3071 résultat d'un effort de portage. Une mise à jour indépendante binaire est la
3072 livraison d'un paquet compilé (souvent pour une autre architecture) à condition
3073 que cette compilation n'ait pas nécessité de modifications des sources. Dans de
3074 nombreux cas, les porteurs sont obligés de modifier les sources pour les rendre
3075 compilables sur leur architecture cible ; il s'agira alors d'une mise à
3076 jour indépendante source et non d'une mise à jour indépendante binaire. Comme
3077 vous pouvez le remarquer, nous ne faisons pas de distinction entre les mises à
3078 jour indépendantes faites par des porteurs et les autres mises à jour
3081 Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
3082 par l'expression « mise à jour indépendante »
3083 (NMU<footnote><p>Non-maintainer upload</footnote>). Pourtant, cela conduit
3084 souvent à des confusions car beaucoup associent « mise à jour
3085 indépendante » et « mise à jour indépendante source ». Il faut
3086 donc rester vigilant. Dans ce chapitre, si nous utilisons l'expression
3087 « mise à jour indépendante » seule, il s'agit des deux types de
3091 <sect1 id="nmu-who">Qui peut faire une mise à jour indépendante ?
3093 Seuls les responsables Debian officiels peuvent faire des mises à jour
3094 indépendantes. Un responsable officiel est une personne dont la clé est dans le
3095 porte-clés Debian. Toute personne est invitée à télécharger les paquets sources
3096 pour corriger des bogues ; au lieu de faire des mises à jour
3097 indépendantes, ils pourront soumettre les correctifs qui le méritent au système
3098 de suivi des bogues. Les responsables apprécient presque toujours les
3099 correctifs et les rapports de bogue soignés.
3102 <sect1 id="nmu-when">Quand faire une mise à jour indépendante
3105 Les recommandations pour déterminer quand faire une mise à jour indépendante
3106 source dépendent de la distribution visée (i.e. <em>stable</em>,
3107 <em>unstable</em> ou <em>experimental</em>). Les porteurs, ayant une activité
3108 particulière, obéissent à des règles légèrement différentes (voir <ref
3109 id="source-nmu-when-porter">).
3111 Quand une bogue de sécurité est détecté, l'équipe de sécurité peut faire une
3112 mise à jour indépendante. Veuillez vous reporter à <ref id="bug-security"> pour
3113 plus d'informations.
3115 Pendant le cycle de mise au point (<em>release cycle</em>, voir <ref
3116 id="sec-dists">), les livraisons qui corrigent les bogues de gravité
3117 <em>sérieuse</em> (i.e. <em>serious</em>) et supérieures sont encouragées et
3118 acceptées. Même pendant cette période, vous devriez tenter d'entrer en contact
3119 avec le responsable du paquet ; il pourrait bien être sur le point de
3120 livrer un paquet corrigé lui aussi. Comme pour n'importe quelle mise à jour
3121 indépendante source, les recommandations de la section <ref
3122 id="nmu-guidelines"> doivent être respectées. Des exceptions spéciales sont
3123 effectuées pour <ref id="qa-bsp">.
3125 Envoyer des corrections de bogues vers <em>unstable</em> par une autre personne
3126 que le responsable ne devrait être fait qu'en suivant ce protocole :
3129 <item>Vérifiez que les bogues du paquet qui devraient être corrigés par la
3130 mise à jour indépendante sont bien référencés dans le système de suivi des
3131 bogues. S'ils n'y sont pas, faites des rapports de bogue
3133 <item>Attendez la réponse du responsable quelques jours. Si vous n'obtenez
3134 aucune réponse, vous pouvez l'aider en lui envoyant le correctif qui
3135 corrige le bogue. N'oubliez pas de marquer le bogue avec le mot-clé
3136 « patch ».
3137 <item>Patientez quelques jours. Si vous n'avez toujours aucune réponse du
3138 responsable, envoyez-lui un courrier annonçant votre intention
3139 d'effectuer une mise à jour indépendante du paquet. Préparez la NMU comme
3140 décrit dans <ref id="nmu-guidelines">, testez-la soigneusement sur votre
3141 machine (cf. <ref id="sanitycheck">). Re-vérifiez que votre correctif
3142 n'a aucun effet de bord inattendu. Assurez-vous que votre correctif est
3143 aussi minimaliste et non intrusif que possible.
3144 <item>Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file> (cf.
3145 <ref id="delayed-incoming">), envoyez le correctif final au responsable
3146 par le BTS et expliquez-lui qu'il a 7 jours pour réagir s'il veut annuler
3148 <item>Suivez ce qui se passe, vous êtes responsable pour tout bogue que vous
3149 auriez introduit avec votre NMU. Vous devriez probablement utiliser le
3150 <ref id="pkg-tracking-system"> (PTS) pour vous tenir informé de l'état du
3151 paquet après votre NMU.
3154 Parfois, le responsable de version ou un groupe organisé de
3155 développeurs peut annoncer une certaine période de temps au cours de laquelle
3156 les règles de mise à jour indépendante seront plus souples. Ceci implique
3157 habituellement une période plus courte d'attente avant d'envoyer des
3158 correctifs et une période de délai plus courte. Il est important de noter que,
3159 même au cours de ces « chasses aux bogues », la personne
3160 désirant faire la mise à jour indépendante doit remplir des bogues et
3161 contacter en premier le développeur, et ensuite seulement passer à
3164 <sect1 id="nmu-guidelines">Comment faire une mise à jour indépendante
3167 Les règles qui suivent s'appliquent aux porteurs tant qu'ils jouent le double
3168 rôle de correcteur de bogue et de porteur. Si un porteur doit modifier le
3169 paquet source, cette mise à jour est automatiquement une mise à jour
3170 indépendante source et est soumise aux règles qui suivent. Si un porteur
3171 construit un paquet binaire recompilé, les règles sont différentes (voir <ref
3172 id="porter-guidelines">.
3174 Tout d'abord, il est capital que ces mises à jour indépendantes soient aussi peu
3175 intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
3176 modules ou des fichiers, ne déplacez pas les répertoires ; plus
3177 généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi
3178 petit que possible. Si certaines choses froissent votre sens de l'esthétique,
3179 parlez-en au responsable du paquet, au responsable amont ou soumettez un
3180 rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
3181 pas</em> être effectués lors d'une mise à jour indépendante.
3184 <sect2 id="nmu-version">Numéro de version pour les mises à jour
3185 indépendantes sources
3187 Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
3188 changer, même pour la plus triviale des modifications. Notre système de
3189 gestion de paquets s'appuie sur ces numéros de version.
3191 Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
3192 un numéro de version mineur à la partie <var>révision-debian</var> du numéro
3193 de version (la partie qui suit le dernier trait d'union). Ce numéro
3194 supplémentaire débutera à « 1 ». Prenons pour exemple le paquet
3195 « foo » qui porte le numéro de version 1.1-3. Dans l'archive, le
3196 fichier de contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
3197 version amont est « 1.1 » et la révision Debian est
3198 « 3 ». La mise à jour indépendante suivante ajouterait le numéro de
3199 version mineur « .1 » au numéro de révision Debian ; le nouveau
3200 fichier de contrôle du paquet source serait alors
3201 <file>foo_1.1-3.1.dsc</file>.
3203 Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro de
3204 version au responsable officiel du paquet, ce qui pourrait perturber son
3205 travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas
3206 été livré par le responsable officiel.
3208 S'il n'y a pas de partie <var>révision-debian</var> dans le numéro de version du
3209 paquet, il faut en créer une en démarrant à « 0.1 ». S'il est
3210 absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
3211 fasse une livraison basée sur une nouvelle version amont, cette personne doit
3212 choisir « 0.1 » comme numéro de révision Debian. Le mainteneur du
3213 paquet doit, lui, démarrer sa numérotation à « 1 ».
3216 <sect2 id="nmu-changelog">
3217 <heading>Les mises à jour indépendantes sources doivent être
3218 mentionnées dans le fichier changelog</heading>
3220 Une personne qui fait une mise à jour indépendante source doit ajouter une
3221 entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
3222 et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
3223 comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
3226 Par convention, dans le cas d'une mise à jour indépendante source
3227 <em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne :
3230 * Non-maintainer upload
3234 <sect2 id="nmu-patch">Mise à jour indépendante source et système de
3237 Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
3238 modifications que possible et doit toujours envoyer ses modifications au
3239 système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).
3241 Et si vous recompilez simplement le paquet ? Si vous avez simplement besoin
3242 de recompiler le paquet pour une seule architecture, vous pouvez faire une
3243 NMU binaire seulement comme décrit dans <ref id="binary-only-nmu"> qui ne
3244 nécessite pas qu'un correctif soit envoyé. Si vous désirez que le paquet soit
3245 recompilé pour toutes les architectures, vous devez alors faire une NMU
3246 source et vous devrez envoyer un correctif.
3248 Si la mise à jour indépendante source (<em>source NMU</em>) corrige des bogues,
3249 ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système de
3250 suivi des bogues plutôt que clos. Par convention, seul le responsable du
3251 paquet et la personne qui a ouvert le rapport de bogue peuvent clore ce
3252 rapport. Heureusement, le système d'archivage Debian reconnaît les mises à
3253 jours indépendantes et positionne correctement le statut des bogues à
3254 <em>fixed</em> si la personne qui fait la mise à jour a listé tous les bogues
3255 dans le fichier changelog en utilisant la syntaxe <tt>Closes:
3256 bug#<var>nnnnn</var></tt> (voir <ref id="upload-bugfix"> pour en savoir plus
3257 sur la fermeture de bogue par le fichier <file>changelog</file>). Ce passage
3258 au statut <em>fixed</em> assure que chacun sait que le bogue est corrigé par
3259 une mise à jour indépendante tout en laissant le rapport de bogue ouvert
3260 jusqu'à ce que le responsable du paquet incorpore les modifications de cette
3261 mise à jour dans la version officielle du paquet.
3263 Après avoir fait une mise à jour indépendante, il vous faudra aussi ouvrir un
3264 nouveau rapport de bogue qui inclura un correctif contenant toutes les
3265 modifications que vous avez faites. Sinon, vous pouvez envoyer cette
3266 information aux bogues qui sont fixés par votre NMU. Le responsable officiel
3267 pourra choisir d'appliquer le correctif, il pourra aussi employer une autre
3268 méthode pour régler le problème. Certains bogues sont corrigés dans la
3269 version amont, ce qui est une bonne raison pour annuler les modifications
3270 d'une mise à jour indépendante. Si le responsable choisit de mettre à jour le
3271 paquet plutôt que d'utiliser les correctifs de la mise à jour indépendante,
3272 il devra s'assurer que cette nouvelle version corrige effectivement chacun
3273 des bogues corrigés dans la mise à jour indépendante.
3275 De plus, le responsable officiel devrait <em>toujours</em> conserver les entrées
3276 documentant une mise à jour indépendante dans le fichier
3277 <file>changelog</file>.
3280 <sect2 id="nmu-build">Fabriquer une mise à jour indépendante source
3282 Les paquets faisant l'objet d'une mise à jour indépendante source sont
3283 construits comme les autres. Sélectionnez une distribution en utilisant les
3284 règles décrites dans la section <ref id="distribution"> en suivant toutes les
3285 prescriptions de la section <ref id="upload">.
3287 Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt> dans
3288 le fichier <file>debian/control</file>. Votre nom, mentionné dans l'entrée du
3289 fichier <file>debian/changelog</file> concernant la mise à jour, sera utilisé
3290 pour signer le fichier <file>.changes</file>.
3292 <sect1 id="ack-nmu">Valider une mise à jour indépendante
3294 Si l'un de vos paquets a subi une mise à jour indépendante, vous devez récupérer
3295 les changements dans votre copie des sources. Ceci est aisé, vous avez
3296 simplement à appliquer le correctif qui vous a été envoyé. Une fois ceci fait,
3297 vous devez fermer les bogues qui ont été marqués comme fixés par la mise à
3298 jour. Vous pouvez soit les fermer manuellement en envoyant les courriers
3299 nécessaires au BTS soit ajouter les <tt>closes: #nnnn</tt> nécessaires dans
3300 l'entrée du changelog de votre prochain envoi.
3302 Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une NMU n'est
3303 pas une attaque personnelle contre le responsable. C'est une preuve que le
3304 paquet est important pour quelqu'un et qu'il est désireux de vous aider dans
3305 votre travail, vous devriez donc lui être reconnaissant. Vous pouvez également
3306 lui demander s'il serait intéressé pour vous aider sur une base plus régulière
3307 comme co-responsable ou responsable de secours (cf. <ref
3308 id="collaborative-maint">).
3312 <sect id="collaborative-maint">
3313 <heading>Maintenance collective</heading>
3315 « Maintenance collective » est un terme décrivant le partage des
3316 devoirs de la maintenance d'un paquet Debian par plusieurs personnes. Cette
3317 collaboration est presque toujours une bonne idée car il en résulte
3318 généralement une meilleure qualité et un temps de correction de bogues plus
3319 petit. Il est fortement recommandé que les paquets de priorité
3320 <tt>Standard</tt> ou qui font partie de la base aient des co-responsables.
3322 Habituellement, il y a un responsable principal et un ou plusieurs
3323 co-responsables. Le responsable principal est celui dont le nom est indiqué
3324 dans le champ <tt>Maintainer</tt> du fichier <file>debian/control</file>. Les
3325 co-responsables sont tous les autres responsables.
3327 Dans sa forme la plus simple, ajouter un nouveau co-responsable est assez
3330 <item><p> Donner au co-responsable un accès aux sources à partir desquelles vous
3331 construisez le paquet. Habituellement, cela implique que vous utilisiez un
3332 système de contrôle de version comme <prgn>CVS</prgn> ou
3333 <prgn>Subversion</prgn>.
3335 <item><p> Ajouter les nom et adresse correctes du co-responsable au champ
3336 <tt>Uploaders</tt> dans la partie globale du fichier
3337 <file>debian/control</file>.
3339 Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
3343 En utilisant le PTS (<ref id="pkg-tracking-system">), les
3344 co-responsables devraient s'inscrire eux-mêmes aux paquets sources
3349 La maintenance collaborative peut souvent être facilitée par l'utilisation
3350 d'outils sur Alioth (voir <ref id="alioth">).
3353 <chapt id="best-pkging-practices">
3354 <heading>Les meilleurs pratiques pour la construction des paquets
3356 La qualité de Debian est principalement due à la <url id="&url-debian-policy;"
3357 name="charte Debian"> qui définit explicitement les obligations que tous les
3358 paquets doivent suivre. Mais c'est également grâce à une histoire partagée
3359 d'expériences qui va au-delà de la charte Debian, une accumulation d'années
3360 d'expérience pour la construction des paquets ; des développeurs de grand
3361 talent ont créé de bons outils qui vous aideront, vous, responsable Debian, à
3362 créer et maintenir d'excellents paquets.
3365 Ce chapitre fournit les meilleurs pratiques pour les développeurs Debian. Ce ne
3366 sont que des recommandations, non pas des obligations ou des règles. Ce sont
3367 seulement des astuces et conseils subjectifs et des liens collectés pour les
3368 développeurs Debian. Prenez et choisissez ce qui vous convient le mieux.
3370 <sect id="bpp-debian-rules">
3371 <heading>Les meilleures pratiques pour le fichier <file>debian/rules</file></heading>
3373 Les recommandations suivantes s'appliquent au fichier <file>debian/rules</file>.
3374 Comme ce fichier contrôle le processus de compilation et qu'il sélectionne les
3375 fichiers inclus dans le paquet (directement ou indirectement), il s'agit
3376 habituellement du fichier sur lequel les responsables passent le plus de temps.
3379 <sect1 id="helper-scripts">Scripts d'aide
3381 La raison sous-jacente à l'utilisation des scripts d'aide dans le fichier
3382 <file>debian/rules</file> est que cela permet aux responsables d'utiliser et de
3383 partager une logique commune pour un grand nombre de paquets. Prenez, par
3384 exemple, l'installation des entrées de menu : vous avez besoin de
3385 placer un fichier dans <file>/usr/lib/menu</file> et d'ajouter des commandes aux
3386 scripts de maintenance pour enregistrer et désenregistrer ces entrées de menu.
3387 Comme il s'agit d'une chose très commune, pourquoi chaque
3388 responsable devrait-il écrire sa propre version, parfois avec des bogues ?
3389 Supposons également que le répertoire de menu soit modifié, chaque paquet
3390 devrait être modifié.
3392 Les scripts d'aide peuvent résoudre ces problèmes. En supposant que vous vous
3393 conformiez aux conventions attendues par le script d'aide, celui-ci prend soin
3394 de tous les détails. Les changements dans la charte peuvent alors être faits
3395 dans le script d'aide, les paquets ont alors simplement besoin d'être
3396 reconstruits avec la nouvelle version du script et sans aucun changement
3399 L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus
3400 courant et le meilleur (à notre avis) système est <package>debhelper</package>.
3401 Les précédents systèmes d'aide comme <package>debmake</package> étaient
3402 « monolithiques » : vous ne pouviez pas choisir quelles parties
3403 intéressantes vous pouviez utiliser, mais vous étiez obligé de choisir le
3404 système pour tout faire. <package>debhelper</package>, à l'inverse, consiste en
3405 un certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple,
3406 <prgn>dh_installman</prgn> installe et compacte les pages de manuel,
3407 <prgn>dh_installmenu</prgn> installe les fichiers de menu et ainsi de suite.
3408 Ainsi, il offre une flexibilité suffisante pour pouvoir utiliser les scripts
3409 d'aide quand ils sont utiles, en complément de commandes définies manuellement
3410 dans le fichier <file>debian/rules</file>.
3412 Vous pouvez débuter avec <package>debhelper</package> en lisant <manref
3413 name="debhelper" section="1"> et en regardant les exemples fournis avec le
3414 paquet. <prgn>dh_make</prgn> du paquet <package>dh-make</package> (voir <ref
3415 id="dh-make">) peut être utilisé pour convertir un paquet source
3416 « vierge » en une version utilisant <package>debhelper</package>. Ce
3417 raccourci ne devrait cependant pas vous faire croire que vous n'avez pas besoin
3418 de comprendre les scripts individuels <prgn>dh_*</prgn>. Si vous comptez
3419 utiliser un système d'aide, vous devez prendre le temps d'apprendre à utiliser
3420 ce système pour savoir ce que vous pouvez en attendre ainsi que son
3423 Plusieurs personnes pensent que des fichiers <file>debian/rules</file> vierges
3424 sont préférables car vous n'avez pas à apprendre les détails internes d'un
3425 quelconque système d'aide. La décision vous appartient complètement. Utilisez ce
3426 qui vous convient. Plusieurs exemples de fichiers <file>debian/rules</file> sont
3427 disponibles à <url id="&url-rules-files;">.
3429 <sect1 id="multiple-patches">
3430 <heading>Séparer vos correctifs en plusieurs fichiers</heading>
3432 Les gros paquets peuvent avoir plusieurs bogues que vous devez gérer. Si
3433 vous corrigez sans faire attention les bogues dans les sources, vous ne
3434 pourrez pas différencier facilement les nombreux correctifs que vous aurez
3435 appliqués. Cela peut devenir trés compliqué de mettre à jour le paquet avec
3436 une nouvelle version amont qui intègre certains correctifs (mais pas tous).
3437 Vous ne pouvez pas prendre l'ensemble des correctifs (par exemple, dans les
3438 fichiers <file>.diff.gz</file>) et décider quels correctifs il vous faut
3439 enlever parce que les bogues ont été corrigés en amont.
3441 Malheureusement, le système de création des paquets tel qu'il est actuellement
3442 ne fournit pas de moyen de séparer les correctifs en plusieurs fichiers.
3443 Cependant, il existe des moyens de séparer les correctifs : les fichiers
3444 correctifs sont livrés dans le fichier correctif Debian
3445 (<file>.diff.gz</file>), habituellement dans le répertoire <file>debian/</file>.
3446 La seule différence est qu'ils ne sont pas appliqués immédiatement par
3447 dpkg-source, mais par la règle <tt>build</tt> du fichier
3448 <file>debian/rules</file>. Inversement, ils sont annulés par la règle
3451 <prgn>dbs</prgn> est l'une des approches les plus populaires pour cela. Il fait
3452 ce qui est décrit ci-dessus et fournit la possibilité de créer de nouveaux
3453 correctifs et de mettre à jour d'anciens correctifs. Veuillez vous reporter au
3454 paquet <package>dbs</package> pour plus d'informations et au paquet
3455 <package>hello-dbs</package> pour un exemple.
3457 <prgn>dpatch</prgn> fournit également ces fonctions, mais il est prévu pour être
3458 encore plus facile d'utilisation. Veuillez voir le paquet
3459 <package>dpatch</package> pour la documentation et des exemples (dans
3460 <file>/usr/share/doc/dpatch</file>).
3463 <sect1 id="multiple-binary">Paquets binaires multiples
3465 Un simple paquet source va souvent permettre de construire plusieurs paquets
3466 binaires différents, que ce soit pour fournir plusieurs saveurs du même
3467 paquet (par exemple, le paquet source <package>vim</package>) ou pour créer
3468 plusieurs petits paquets au lieu d'un seul gros (par exemple, si
3469 l'utilisateur peut n'installer que la partie dont il a besoin et ainsi
3470 économiser de l'espace disque).
3472 Le second cas peut facilement être géré dans le fichier
3473 <file>debian/rules</file>. Vous avez simplement besoin de déplacer les fichiers
3474 appropriés du répertoire de construction dans les arborescence temporaires du
3475 paquet. Vous pouvez le faire en utilisant <prgn>install</prgn>
3476 ou <prgn>dh_install</prgn> du paquet <package>debhelper</package>.
3477 Assurez-vous de vérifier les différentes permutations de paquets, en
3478 garantissant que vous avez bien défini les dépendances entre les paquets dans
3479 le fichier <file>debian/control</file>.
3481 Le premier cas est un peu plus diffile car il implique de multiples
3482 recompilations du même logiciel, mais avec différentes options de
3483 configuration. Le paquet source <package>vim</package> est un exemple de la
3484 façon de gérer cela avec un fichier <file>rules</file> écrit à la main.
3486 <!-- &FIXME; Find a good debhelper example with multiple configure/make cycles
3491 <sect id="bpp-debian-control">
3492 <heading>Les meilleures pratiques pour le fichier
3493 <file>debian/control</file></heading>
3495 Les pratiques suivantes sont relatives au fichier <file>debian/control</file>.
3496 Elles viennent en complément des <url
3497 id="&url-debian-policy;ch-miscellaneous.html#s-descriptions" name="règles pour
3498 les descriptions des paquets">.
3500 La description du paquet, telle qu'elle est définie par le champ correspondant
3501 dans le fichier <file>control</file>, contient à la fois le résumé du paquet et
3502 la description longue pour le paquet. <ref id="bpp-desc-basics"> décrit des
3503 lignes générales pour les deux parties de la description. Ensuite, <ref
3504 id="bpp-pkg-synopsis"> fournit des principes spécifiques pour le résumé et <ref
3505 id="bpp-pkg-desc"> contient des principes spécifiques pour la description
3508 <sect1 id="bpp-desc-basics">
3509 <heading>Les règles générales pour les descriptions des paquets</heading>
3511 La description du paquet devrait être écrite pour l'utilisateur moyen,
3512 l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple, les paquets
3513 de développement sont pour les développeurs et leur description peut utiliser un
3514 langage technique. Pour les applications à but plus général comme un éditeur, la
3515 description devrait être écrite pour un non-spécialiste.
3517 Notre critique des descriptions des paquets nous amène à conclure que la plupart
3518 des descriptions des paquets sont techniques, c'est-à-dire, qu'elles ne sont pas
3519 écrites pour être comprises par les non-spécialistes. À moins que
3520 votre paquet ne soit que pour les techniciens, c'est un problème.
3522 Comment écrire pour les non-spécialistes ? Évitez le jargon.
3523 Évitez de vous référer à d'autres applications et cadres de travail avec
3524 lesquels l'utilisateur n'est pas forcément familier — « GNOME »
3525 ou « KDE » sont corrects car les utilisateurs sont probablement
3526 familiers avec ces termes, mais « GTK+ » ne l'est probablement pas.
3527 Ne supposez aucune connaissance. Si vous devez utiliser des termes techniques,
3530 Soyez objectif. Les descriptions de paquet ne sont pas un endroit pour
3531 promouvoir votre paquet, quel que soit l'amour que vous lui portez.
3532 Rappelez-vous que le lecteur n'a pas forcément les mêmes priorités que vous.
3534 Des références aux noms de tout autre paquet de logiciels, noms de protocoles,
3535 standards ou spécifications devraient utiliser leurs formes canoniques si elles
3536 existent. Par exemple, utilisez « X Window System », « X11 »
3537 ou « X » et non « X Windows », « X-Windows » ou
3538 « X Window ». Utilisez « GTK+ » et non « GTK » ou
3539 « gtk ». Utilisez « GNOME » et non « Gnome ».
3540 Utilisez « PostScript » et non « Postscript » ou
3541 « postscript ».
3543 Si vous avez des problèmes pour écrire votre description, vous pouvez l'envoyer à
3544 &email-debian-l10n-english; et demander un retour d'informations.
3548 <sect1 id="bpp-pkg-synopsis">
3549 <heading>Le résumé du paquet ou description courte</heading>
3551 La ligne de résumé (la description courte) devrait être concise. Elle ne doit
3552 pas répéter le nom du paquet (c'est une règle).
3554 C'est une bonne idée de penser au résumé comme à une clause apposée et non une
3555 phrase complète. Une clause apposée est définie dans WordNet comme une relation
3556 grammaticale entre un mot et une phrase pronominale qui la suit, par exemple
3557 « Rudolph, le renne au nez rouge ». La clause apposée ici est
3558 « le renne au nez rouge ». Comme le résumé est une clause et non une
3559 phrase complète, nous recommandons de ne pas la commencer par une majuscule et
3560 de ne pas la finir par un point. Il ne doit pas non plus commencer avec un
3561 article, défini (« le ») ou indéfini (« un »).
3563 Cela peut vous aider d'imaginer le résumé combiné avec le nom du paquet de
3564 la façon suivante :
3566 <example><var>nom-paquet</var> est un <var>résumé</var>.</example>
3568 Sinon, il peut être plus compréhensible de le voir comme
3570 <example><var>nom-paquet</var> est <var>résumé</var>.</example>
3572 ou, si le nom du paquet est lui-même un pluriel (comme
3573 « developer-tools »)
3575 <example><var>nom-paquet</var> sont <var>résumé</var>.</example>
3577 Cette façon de former une phrase à partir du nom du paquet et du résumé devrait
3578 être considérée comme une heuristique et non comme une règle stricte. Il y a
3579 certains cas où cela n'a aucun sens de former une phrase.
3583 <sect1 id="bpp-pkg-desc">
3584 <heading>La description longue</heading>
3586 La description longue du paquet est la première information dont dispose
3587 l'utilisateur avant d'installer un paquet. Aussi, elle devrait fournir toutes
3588 les informations nécessaires pour le laisser décider de l'installation du
3589 paquet. Vous pouvez supposer que l'utilisateur a déjà lu le résumé du paquet.
3591 La description longue devrait toujours être constituée de phrases complètes.
3593 Le premier paragraphe de la description longue devrait répondre aux questions
3594 suivantes : qu'est-ce que fait le paquet ? Quelle tâche aide-t-il
3595 l'utilisateur à accomplir ? Il est important de décrire ceci d'une manière
3596 non technique, à moins que le paquet ne s'adresse qu'à un auditoire de techniciens.
3598 Les paragraphes suivants devraient répondre aux questions suivantes :
3599 Pourquoi, en tant qu'utilisateur, ai-je besoin de ce paquet ? Quelles
3600 sont les autres fonctionnalités dont dispose le paquet ? Quelles
3601 sont les fonctionnalités marquantes et les déficiences de ce paquet comparé à
3602 d'autres paquets (par exemple, « si vous avez besoin de X, utilisez Y à la
3603 place ») ? Est-ce que le paquet est lié à d'autres paquets d'une
3604 certaine façon qui n'est pas gérée par le gestionnaire de paquet (par exemple,
3605 « il s'agit d'un client pour le serveur foo ») ?
3607 Soyez attentif à éviter les fautes d'orthographe et de grammaire. N'oubliez
3608 pas votre vérificateur orthographique. <prgn>ispell</prgn> possède une option
3609 spéciale (<tt>-g</tt>) pour cela :
3611 <example>ispell -d american -g debian/control</example>
3615 <sect1 id="bpp-upstream-info">
3616 <heading>Page d'accueil amont</heading>
3618 Nous vous recommandons d'ajouter l'adresse de la page d'accueil du paquet à la
3619 description du paquet dans le fichier <file>debian/control</file>. Cette
3620 information devrait être ajoutée à la fin de la description en utilisant le
3621 format suivant :
3624 Homepage: http://some-project.some-place.org/</example>
3626 Veuillez noter les espaces au début de la ligne, ils servent à séparer les
3627 lignes correctement. Pour voir un exemple de ce que cela affiche, veuillez vous
3628 reporter à <url id="&url-eg-desc-upstream-info;">.
3630 Ne mettez rien s'il n'existe pas de page pour le logiciel.
3633 Veuillez noter que nous espérons que ce champ sera remplacé par un
3634 vrai champ de <file>debian/control</file> que comprendraient <prgn>dpkg</prgn>
3635 et <tt>&packages-host;</tt>. Si vous ne voulez pas vous embêter à déplacer la
3636 page d'accueil depuis la description vers ce nouveau champ, vous devriez
3637 probablement attendre qu'il soit disponible.</p>
3642 <sect id="bpp-debian-changelog">
3643 <heading>Les meilleures pratiques pour le fichier <file>debian/changelog</file></heading>
3645 Les pratiques suivantes viennent en complément de la <url name="directive sur
3646 les fichiers changelog" id="&url-debian-policy;ch-docs.html#s-changelogs">.</p>
3648 <sect1 id="bpp-changelog-do">
3649 <heading>Écrire des entrées de changelog utiles</heading>
3651 L'entrée de changelog pour une révision de paquet documente les changements dans
3652 cette révision et seulement ceux-ci. Concentrez-vous sur la description des
3653 changements significatifs et visibles de l'utilisateur qui ont été effectués
3654 depuis la dernière version.
3656 Ciblez <em>ce</em> qui a été changé — qui, comment et quand cela a été fait
3657 est généralement de moindre importance. Ceci dit, rappelez-vous de nommer
3658 poliment les personnes qui ont fourni une aide notable pour réaliser le
3659 paquet (par exemple, ceux qui ont envoyé des correctifs).
3661 Vous n'avez pas besoin de détailler les changements triviaux et évidents. Vous
3662 pouvez également regrouper plusieurs de ces changements dans une seule entrée.
3663 D'un autre côté, ne soyez pas trop concis si vous avez entrepris un changement
3664 majeur. Soyez tout spécialement clair s'il y a des changements qui modifient le
3665 comportement du programme. Pour plus d'explications, utilisez le fichier
3666 <file>README.Debian</file>.
3668 Utilisez un langage anglais commun pour que la majorité des lecteur puissent le
3669 comprendre. Évitez les abbréviations, le parler technique et le jargon quand
3670 vous expliquez des changements fermant un bogue, spécialement pour les rapports
3671 de bogue créés par des utilisateurs qui ne vous paraissent pas particulièrement
3672 à l'aise techniquement. Vous devez être poli et ne pas jurer.
3674 Il est parfois désirable de préfixer les entrées de changelog avec le nom des
3675 fichiers qui ont été modifiés. Cependant, il n'est pas besoin de lister
3676 explicitement tous les fichiers modifiés, particulièrement si la modification
3677 est petite ou répétitive. Vous pouvez utiliser les caractères génériques.
3679 Quand vous faites référence aux bogues, ne supposez rien a priori. Dites ce
3680 qu'était le problème, comment il a été résolu et ajoutez la chaîne de caractères
3681 « closes: #nnnnn ». Veuillez voir <ref id="upload-bugfix"> pour plus
3684 <sect1 id="bpp-changelog-misconceptions">
3685 <heading>idées fausses communes sur les entrées de changelog</heading>
3687 Les entrées de changelog <strong>ne devraient pas</strong> documenter des
3688 problèmes génériques d'empaquetage (« Hé, si vous cherchez foo.conf, il
3689 est dans /etc/blah/. ») car les administrateurs et utilisateurs sont
3690 supposés être au moins vaguement rompus à la façon dont les choses sont
3691 arrangées sur un système Debian. Mentionnez cependant tout changement
3692 d'emplacement d'un fichier de configuration.
3694 Les seuls bogues fermés par une entrée de changelog devraient être ceux qui sont
3695 vraiment corrigés dans la même révision du paquet. Fermer des bogues non liés
3696 par le fichier changelog est considéré comme une très mauvaise pratique.
3697 Veuillez voir <ref id="upload-bugfix">.
3699 Les entrées de changelog <strong>ne devraient pas</strong> être le lieu de
3700 discussions avec les émetteurs de bogues (« Je ne vois pas de segfaults
3701 lors du lancement de foo avec l'option bar ; envoyez-moi plus
3702 d'informations. »), ni celui de phrases génériques sur la vie, l'univers et
3703 tout le reste (« Désolé, cet envoi m'a pris du temps, mais j'avais attrapé
3704 la grippe ») ou celui de demandes d'aide (« La liste des bogues sur
3705 ce paquet est énorme, donnez-moi un coup de main »). Ceci ne sera
3706 généralement pas remarqué par les personnes ciblées, mais peut ennuyer les
3707 personnes qui désirent lire des informations sur les changements réels du
3708 paquet. Veuillez vous reporter à <ref id="bug-answering"> pour plus
3709 d'informations sur la façon d'utiliser le système de suivi des bogues.
3711 C'est une vieille tradition de valider les bogues fixés par une mise à jour
3712 indépendante dans la première entrée du changelog de l'envoi du vrai
3713 responsable, par exemple, dans une entrée de changelog comme ceci :
3715 * Maintainer upload, closes: #42345, #44484, #42444.
3717 Ceci fermera les bogues NMU marqués comme corrigé (« fixed ») quand le
3718 paquet arrivera dans l'archive. Le bogue pour le fait qu'une NMU a été faite
3719 peut être fermé de la même façon. Bien sûr, il est également parfaitement
3720 acceptable de fermer les bogues corrigés par NMU par d'autres moyens ; voir
3721 <ref id="bug-answering">.
3724 <sect1 id="bpp-changelog-errors">
3725 <heading>Erreurs communes dans les entrées de changelogs</heading>
3727 Les exemples suivants montrent des erreurs communes ou des exemples de mauvais
3728 style dans les entrées de changelog<footnote>NdT : Les entrées de
3729 changelog sont ici affichées en français pour faciliter la compréhension, mais
3730 vos entrées devront naturellement être rédigées en anglais.</footnote>.
3734 * Corrige tous les bogues restants.
3737 Ceci n'indique visiblement rien d'utile au lecteur.
3740 * Correctif de Jane Random appliqué.
3742 Sur quoi portait le correctif ?
3746 * Révision de cible d'installation la nuit dernière.
3748 Qu'a accompli la révision ? Est-ce que la mention de la nuit dernière
3749 est supposée nous rappeler que nous ne devons pas faire confiance à ce
3754 * Corrige MRD vsync av. anciens CRTs.
3756 Trop d'acronymes et il n'est pas très clair de ce qu'était vraiment cette...
3757 euh... merde (oups, un mot interdit !) ou comment cela a été corrigé.
3761 * Ceci n'est pas un bogue. Closes: #nnnnnn.
3763 Premièrement, il n'y a absolument pas besoin d'envoyer un paquet pour
3764 communiquer cette information ; à la place, utilisez le système de suivi des
3765 bogues. Deuxièmement, il n'y a aucune explication concernant la raison
3766 pour laquelle le rapport n'était pas un bogue.
3770 * A été fixé il y a longtemps, mais j'ai oublié de le fermer. Closes: #54321.
3772 Si, pour toute raison, vous n'aviez pas indiqué le numéro du bogue dans une
3773 précédente entrée de changelog, ceci n'est pas un problème, fermez simplement le
3774 bogue normalement dans le BTS. Il n'y a pas besoin de modifier le fichier
3775 changelog, en supposant que la description de la correction est déjà intégrée
3776 (ceci s'applique aux correctifs par les auteurs/responsables amont également,
3777 vous n'avez pas à suivre les bogues qui ont été corrigés il y a longtemps dans
3782 * Closes: #12345, #12346, #15432.
3784 Où est la description ?! Si vous n'arrivez pas à trouver un message
3785 descriptif, commencez par insérer le titre de chacun des différents bogues.
3790 <!-- <sect1 id="pkg-mgmt-cvs">Managing a package with CVS
3792 &FIXME; presentation of cvs-buildpackage, updating sources
3793 via CVS (debian/rules refresh).
3794 <url id="http://www.debian.org/devel/cvs_packages">
3797 <sect id="bpp-debian-maint-scripts">
3798 <heading>Les meilleures pratiques pour les scripts de
3799 maintenance</heading>
3801 Les scripts de maintenance incluent les fichiers <file>debian/postinst</file>,
3802 <file>debian/preinst</file>, <file>debian/prerm</file> et
3803 <file>debian/postrm</file>. Ces scripts prennent soin de la configuration
3804 d'installation ou de désinstallation des paquets, ce qui n'est pas simplement créer ou
3805 supprimer des fichiers et des répertoires. Les instructions suivantes
3806 complètent la <url id="&url-debian-policy;" name="charte Debian">.
3808 Les scripts de maintenance doivent être idempotents. Cela veut dire que vous
3809 devez vous assurer que rien de grave ne se produit si un script est appelé deux
3810 fois là où il ne devrait habituellement être appelé qu'une fois.
3812 Les entrée et sortie standard peuvent être redirigées (par exemple, dans des
3813 tubes<footnote><p>pipes</p></footnote>) pour des besoins d'enregistrement
3814 d'activité, donc vous ne devez pas supposer que ce sont des tty.
3816 Tous les affichages et les configurations interactives devraient être
3817 minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet
3818 <package>debconf</package> pour l'interface. Rappelez-vous que, dans tous les
3819 cas, l'affichage ne doit se faire que dans l'étape de configuration,
3820 <tt>configure</tt> du script de post-installation, <file>postinst</file>.
3822 Gardez les scripts de maintenance aussi simples que possible. Nous vous
3823 suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que si vous
3824 avez besoin d'une fonctionnalité de Bash, le script de maintenance doit
3825 l'indiquer dans sa première ligne. Un shell POSIX ou Bash sont préférés à
3826 Perl car ils permettent à <package>debhelper</package> d'ajouter facilement des
3827 parties aux scripts.
3829 Si vous modifiez les scripts de maintenance, assurez-vous de tester la
3830 suppression du paquet, la double installation et la purge complète. Assurez-vous
3831 qu'il ne reste rien d'un paquet purgé, c'est-à-dire, que la purge doit enlever
3832 tout fichier créé, directement ou indirectement, par les scripts de
3835 Si vous avez besoin de vérifier l'existence d'une commande, vous devriez
3836 utiliser quelque chose comme :
3837 <example>if [ -x /usr/sbin/install-docs ]; then ...</example>
3839 Si vous ne désirez pas mettre en dur le chemin de la commande dans le script de
3840 maintenance, la fonction de shell suivante conforme à POSIX peut vous
3845 Vous pouvez utiliser cette fonction pour rechercher le <tt>$PATH</tt> pour un
3846 nom de commande passé en argument. Il renvoie vrai (zéro) si la commande a été
3847 trouvée et faux sinon. Il s'agit réellement de la façon la plus portable de faire
3848 car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn> ne sont pas
3851 Bien que <prgn>which</prgn> soit une alternative acceptable car il est
3852 présent dans le paquet classé <em>required</em> <package>debianutils</package>, il n'est pas
3853 présent dans la partition racine. Autrement dit, il est placé dans
3854 <file>/usr/bin</file> au lieu de <file>/bin</file>, il n'est donc pas possible
3855 de l'utiliser dans les scripts qui sont exécutés avant que la partition
3856 <file>/usr</file> soit montée. Cependant, la plupart des scripts n'auront pas ce
3860 <sect id="bpp-config-mgmt">
3861 <heading>Gestion de la configuration avec <package>debconf</package></heading>
3865 <package>Debconf</package> est un système de gestion de configuration qui
3866 peut être utilisé par les divers scripts de maintenance (principalement
3867 en post-installation dans le fichier <file>postinst</file>) pour demander à
3868 l'utilisateur des informations concernant la configuration du paquet. Il
3869 faut maintenant éviter les interactions directes avec l'utilisateur et
3870 préférer les interactions utilisant <package>debconf</package>. Ceci permettra
3871 à l'avenir des installations non interactives.
3873 Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs erreurs
3874 communes sont référencées dans la page de manuel <manref section="7"
3875 name="debconf-devel">. Vous devriez vraiment lire cette page si vous décidez
3880 <sect id="bpp-i18n">
3881 <heading>Internationalisation</heading>
3885 <sect1 id="bpp-i18n-debconf">Gestion des traductions de
3888 Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur
3889 un grand nombre de paquets et doivent donc collaborer avec plusieurs
3890 responsables différents. De plus, la plupart du temps, l'anglais n'est pas leur
3891 langue maternelle, il se peut que vous deviez être particulièrement patient
3894 Le but de <package>debconf</package> était de faciliter la configuration des
3895 paquets aux responsables et aux utilisateurs. À l'origine, les
3896 traductions des questionnaires debconf étaient gérées avec
3897 <prgn>debconf-mergetemplate</prgn>. Cependant, cette technique est maintenant
3898 déconseillée ; la meilleure façon pour l'internationalisation de
3899 <package>debconf</package> est d'utiliser le paquet
3900 <package>po-debconf</package>. Cette méthode est plus facile et pour le
3901 responsable et pour les traducteurs ; des scripts de transition sont
3904 Lors de l'utilisation de <package>po-debconf</package>, la traduction est
3905 stockée dans des fichiers <file>po</file> (à l'instar des techniques de
3906 traduction de <prgn>gettext</prgn>). Des fichiers modèles contiennent les
3907 messages d'origine et indiquent quels sont les champs traduisibles. Quand vous
3908 modifiez l'état d'un champ traduisible en appelant
3909 <prgn>debconf-updatepo</prgn>, la traduction est marquée comme ayant besoin de
3910 l'attention des traducteurs. Puis, lors de la construction du paquet, le
3911 programme <prgn>dh_installdebconf</prgn> prendra soin de toute la magie
3912 nécessaire à l'ajout du modèle avec les traductions à jour dans les paquets
3913 binaires. Veuillez vous reporter à la page de manuel <manref name="po-debconf"
3914 section="7"> pour les détails.
3917 <sect1 id="bpp-i18n-docs">
3918 <heading>Documentation traduite</heading>
3920 La traduction de la documentation est cruciale pour les utilisateurs, mais elle
3921 représente un important travail. Il n'existe aucun moyen d'éliminer ce travail,
3922 mais vous pouvez faciliter les choses pour les traducteurs.
3924 Si vous êtes responsable d'une documentation quelle que soit sa taille, il est
3925 plus facile pour les traducteurs d'avoir accès à un système de contrôle de
3926 source. Ceci permet aux traducteurs de voir les différences entre deux versions
3927 de la documentation, pour, par exemple, qu'ils puissent voir ce qui a besoin
3928 d'être retraduit. Il est recommandé que le document traduit inclue une note à
3929 propos de la révision de contrôle du source sur laquelle la traduction est
3930 basée. Un système intéressant est fourni par <url id="&url-i18n-doc-check;"
3931 name="doc-check"> dans le paquet <package>boot-floppies</package> qui donne un
3932 aperçu de l'état de la traduction pour une langue donnée, en utilisant les
3933 commentaires structurés pour une révision donnée du fichier à traduire et, pour
3934 un fichier traduit, la révision du fichier d'origine sur laquelle la traduction
3935 est basée. Vous pouvez vouloir adapter et fournir ceci dans votre référentiel CVS.
3937 Si vous maintenez de la documentation au format XML ou SGML, nous vous suggérons
3938 d'isoler les informations indépendantes de la langue et de les définir
3939 comme des entités dans un fichier séparé qui sera inclus par les différentes
3940 traductions. Ceci aide, par exemple, à garder à jour les adresses pour
3946 <sect id="bpp-common-situations">
3947 <heading>Pratiques communes d'empaquetage</heading>
3950 <sect1 id="bpp-kernel">Kernel modules/patches
3953 &FIXME; Heavy use of kernel-package. provide files in
3954 /etc/modutils/ for module configuration.
3957 <sect1 id="bpp-autotools">
3958 <heading>Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
3960 Conserver à jour les fichiers d'<prgn>autoconf</prgn>, <file>config.sub</file>
3961 et <file>config.guess</file>, est critique pour les porteurs, spécialement pour
3962 les architectures plus changeantes. De très bonnes pratiques d'empaquetage
3963 utilisant <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été regroupées
3964 dans &file-bpp-autotools; du paquet <package>autotools-dev</package>. Vous êtes
3965 vivement encouragé à lire ce fichier et à suivre les recommandations indiquées.
3968 <sect1 id="bpp-libraries">Bibliothèques
3970 Pour diverses raisons, il a toujours été difficile d'empaqueter les
3971 bibliothèques. La charte impose plusieurs contraintes pour faciliter la maintenance
3972 et pour garantir que les mises à jour sont aussi simples que possible quand une
3973 nouvelle version amont est disponible. Une erreur dans une bibliothèque peut
3974 rendre défectueux une douzaine de paquets qui en dépendent.
3976 Les bonnes pratiques d'empaquetage des bibliothèques ont été regroupées dans
3977 <url id="&url-libpkg-guide;" name="le guide d'empaquetage des
3980 <sect1 id="bpp-docs">Documentation
3982 Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html"
3983 name="règles sur la documentation">.</p>
3985 Si votre paquet contient de la documentation construite à partir de XML ou SGML,
3986 nous vous recommandons de ne pas fournir le source XML ou SGML dans le(s)
3987 paquet(s) binaire(s). Si les utilisateurs désirent avoir le source de la
3988 documentation, ils peuvent récupérer le paquet source.</p>
3990 La charte spécifie que la documentation doit être fournie au format HTML.
3991 Nous vous recommandons également de la fournir au format PDF et texte simple si
3992 c'est adapté et qu'une sortie de qualité est possible. Cependant, il n'est
3993 généralement pas approprié de fournir des versions en texte simple pour la
3994 documentation dont le format source est du HTML.</p>
3996 Les principaux manuels fournis devraient être enregistrés par le paquet
3997 <package>doc-base</package> à l'installation. Reportez-vous à la documentation
3998 du paquet <package>doc-base</package> pour plus d'information.</p>
4002 <sect1 id="bpp-other">Types spécifiques de paquets
4004 Plusieurs types spécifiques de paquets ont des sous-chartes spéciales et des
4005 règles et pratiques d'empaquetage correspondantes :
4008 Les paquets liés à Perl ont leur <url id="&url-perl-policy;" name="charte
4009 Perl">, quelques exemples de paquets qui suivent cette charte sont
4010 <package>libdbd-pg-perl</package> (module perl binaire) ou
4011 <package>libmldbm-perl</package> (module perl indépendant de
4015 Les paquets liés à Python ont leur charte Python ; voir
4016 &file-python-policy; dans le paquet <package>python</package>.
4019 Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;"
4020 name="charte Emacs">.
4023 Les paquets liés à Java ont leur <url id="&url-java-policy;" name="charte
4027 Les paquets liés à Ocaml ont leur propre charte que l'on trouve dans
4028 &file-ocaml-policy; du paquet <package>ocaml</package>. Un bon exemple est
4029 le paquet source <package>camlzip</package>.
4032 Les paquets fournissant des DTDs XML ou SGML devraient se conformer aux
4033 recommandations que l'on peut trouver dans le paquet
4034 <package>sgml-base-doc</package>
4036 Les paquets Lisp devraient s'enregistrer avec le paquet
4037 <package>common-lisp-controller</package> pour lequel vous pouvez vous
4038 reporter au fichier &file-lisp-controller;.
4043 <sect1 id="bpp-archindepdata">Données indépendantes de l'architecture
4045 Il n'est pas rare d'avoir une grande quantité de données indépendantes de
4046 l'architecture fournie avec un programme. Par exemple, des fichiers
4047 audio, une collection d'icônes, des motifs de papiers peints ou autres
4048 fichiers graphiques. Si la taille des données est négligeable par
4049 rapport à la taille du reste du paquet, il est probablement mieux de
4050 tout garder dans le même paquet.
4053 Cependant, si la taille des données est considérable, vous devez
4054 envisager de les partager dans un paquet séparé et indépendant de
4055 l'architecture (« _all.deb »). Ainsi, en faisant cela, vous
4056 évitez une duplication inutile des mêmes données dans onze fichiers
4057 .debs pour chaque architecture. Bien que ceci ajoute une surcharge
4058 supplémentaire aux fichiers <file>Packages</file>, ceci sauve beaucoup
4059 d'espace disque sur les miroirs Debian. Séparer les données
4060 indépendantes de l'architecture réduit également le temps de traitement
4061 de <prgn>lintian</prgn> ou de <prgn>linda</prgn> (voir <ref
4062 id="tools-lint">) quand ils sont exécutés sur l'ensemble de l'archive
4070 <chapt id="beyond-pkging">
4071 <heading>Au-delà de l'empaquetage
4073 Debian, c'est beaucoup plus que de l'empaquetage de logiciels et de
4074 la maintenance de paquets. Ce chapitre contient des informations sur les
4075 façons, souvent vraiment importantes, de contribuer à Debian au-delà de la
4076 simple création et maintenance de paquets.
4078 En tant qu'organisation de volontaires, Debian repose sur la liberté de
4079 choisir ce sur quoi l'on désire travailler et de choisir la
4080 partie la plus importante à laquelle on veut consacrer son temps.
4082 <sect id="submit-bug">
4083 <heading>Rapporter des bogues
4085 Nous vous encourageons à remplir des rapports de bogue quand vous trouvez des
4086 bogues dans les paquets Debian. En fait, les développeurs Debian sont souvent
4087 les testeurs de première ligne. Trouver et rapporter les bogues dans les
4088 paquets d'autres développeurs améliore la qualité de Debian.
4090 Lisez les <url name="instructions pour créer un rapport de bogue"
4091 id="&url-bts-report;"> dans le <url name="système de suivi des bogues"
4092 id="&url-bts;"> Debian.
4094 Essayez de soumettre le bogue à partir d'un compte utilisateur normal sur lequel
4095 vous pouvez recevoir des courriers, pour que les personnes puissent vous
4096 joindre s'ils ont besoin de plus d'informations à propos du bogue. Ne soumettez
4097 pas de bogues en tant que root.
4099 Vous pouvez utiliser un outil comme <manref name="reportbug" section="1"> pour
4100 soumettre des bogues. Il peut automatiser et dans l'ensemble faciliter le
4103 Assurez-vous que le bogue n'a pas déjà été rapporté. Chaque paquet dispose d'une
4104 liste de bogues facilement accessible à
4105 <tt>http://&bugs-host;/<var>nom_paquet</var></tt>. Des outils comme <manref
4106 name="querybts" section="1"> peuvent également vous fournir ces informations (et
4107 <prgn>reportbug</prgn> invoquera également habituellement <prgn>querybts</prgn>
4110 Essayer d'envoyer vos bogues au bon emplacement. Quand, par exemple, votre bogue
4111 concerne un paquet qui réécrit des fichiers d'un autre paquet, vérifiez les
4112 listes des bogues pour les <em>deux</em> paquets pour éviter de créer des
4113 rapports de bogues dupliqués.
4115 Vous pouvez également parcourir les bogues d'autres paquets, en les regroupant
4116 s'ils sont indiqués plus d'une fois, ou en les marquant avec
4117 « fixed » quand ils ont déjà été corrigés. Notez cependant que si
4118 vous n'êtes ni le rapporteur du bogue, ni le responsable du paquet, vous ne
4119 devriez pas fermer réellement le bogue (à moins que vous n'ayez obtenu la
4120 permission du responsable).
4122 De temps en temps, vous pourrez vouloir vérifier ce qui s'est passé à propos des
4123 bogues que vous avez rapportés. Saisissez cette occasion pour fermer les bogues
4124 que vous ne pouvez plus reproduire. Pour trouver tous les bogues que vous avez
4125 rapportés, vous avez simplement besoin d'aller à
4126 <tt>http://&bugs-host;/from:<var><votre-adresse-de-courrier></var></tt>.
4128 <sect1 id="submit-many-bugs">Ouvrir un grand nombre de rapports d'un seul
4131 Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
4132 paquets — plus de dix — est une pratique que nous déconseillons.
4133 Prenez toutes les mesures possibles pour éviter cette situation. Si le problème
4134 peut être détecté automatiquement par exemple, ajoutez un nouveau test dans le
4135 paquet <package>lintian</package> pour générer une erreur ou un avertissement.
4137 Si vous ouvrez plus de dix rapports sur le même sujet, il est préférable
4138 d'indiquer votre intention sur la liste &email-debian-devel;. Cela donnera à
4139 d'autres développeurs la possibilité de vérifier que le problème existe
4140 vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent
4141 les mêmes rapports de bogue simultanément.
4143 Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez
4144 les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils ne soient
4145 pas redirigés vers les listes de diffusion.
4148 <sect id="qa-effort">Effort d'assurance qualité
4150 <sect1 id="qa-daily-work">Travail journalier
4152 Bien qu'il y ait un groupe de personnes dédiées à l'assurance qualité, les
4153 devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez participer à
4154 cet effort en conservant vos paquets aussi exempts de bogues que possible et
4155 aussi corrects que possible selon <prgn>lintian</prgn> (reportez-vous à <ref
4156 id="lintian">). Si cela vous paraît impossible, vous devriez alors envisager
4157 d'abandonner certains de vos paquets (reportez-vous à <ref id="orphaning">).
4158 Sinon, vous pouvez demander de l'aide à d'autres personnes pour qu'elles
4159 puissent rattraper votre retard dans la correction des bogues (vous pouvez
4160 demander de l'aide sur &email-debian-qa; ou &email-debian-devel;). En même
4161 temps, vous pouvez rechercher des co-responsables (reportez-vous à <ref
4162 id="collaborative-maint">).
4164 <sect1 id="qa-bsp">Les chasses aux bogues
4166 De temps en temps, le groupe d'assurance qualité organise des chasses aux
4167 bogues<footnote><em>Bug Squashing Party</em></footnote> pour essayer de
4168 supprimer le plus de problèmes possible. Elles sont annoncées sur
4169 &email-debian-devel-announce; et l'annonce explique quel domaine sera visé
4170 pendant la chasse : habituellement, il s'agit des bogues empêchant
4171 l'intégration du paquet dans la distribution (« Release Critical »),
4172 mais il peut arriver qu'ils décident d'aider à finir une transition majeure
4173 (comme une nouvelle version de Perl qui demande la recompilation de tous les
4176 Les règles pour les mises à jour indépendantes sont différentes au cours de la
4177 chasse parce que l'annonce de la chasse est considérée comme une annonce
4178 préalable pour les mises à jour indépendantes. Si vous avez des paquets qui
4179 peuvent être affectées par la chasse (parce qu'ils ont des bogues critiques par
4180 exemple), vous devriez envoyer une mise à jour pour chaque bogue correspondant
4181 pour expliquer leur état actuel et ce que vous attendez de la chasse. Si vous
4182 ne voulez pas d'une mise à jour indépendante ou si vous n'êtes intéressé que
4183 par un correctif ou si vous voulez gérer vous-même le bogue, veuillez l'expliquer
4186 Les personnes qui participent à la chasse ont des règles spécifiques pour les
4187 mises à jour indépendantes, ils peuvent en faire une sans avertissement
4188 préalable s'ils envoient leur paquet avec un délai d'au moins 3 jours dans
4189 DELAYED/3-day. Toutes les autres règles de mise à jour indépendante
4190 s'appliquent comme d'habitude, ils devraient envoyer le correctif de la
4191 mise à jour dans le BTS (pour l'un des bogues ouverts corrigé par la mise à
4192 jour ou pour un nouveau bogue marqué comme fixé). Ils devraient également
4193 respecter les souhaits du responsable s'il en a exprimés.
4195 Si une personne ne se sent pas à l'aise avec une mise à jour indépendante, elle
4196 devrait simplement envoyer un correctif au BTS. C'est de loin meilleur qu'une
4197 mise à jour défectueuse.
4199 <sect id="contacting-maintainers">Contacter d'autres responsables
4201 Pendant vos activités dans Debian, vous aurez à contacter d'autres responsables
4202 pour différentes raisons. Vous pourrez vouloir discuter d'une nouvelle
4203 façon de coopérer au sein d'un ensemble de paquets liés, ou vous pouvez
4204 simplement rappeler à quelqu'un qu'une nouvelle version est disponible et
4205 que vous en avez besoin.
4207 Chercher l'adresse d'un responsable d'un paquet peut être fastidieux.
4208 Heureusement, il existe un alias de courrier simple,
4209 <tt><paquet>@&packages-host;</tt>, qui fournit un moyen d'envoyer
4210 un courrier à un responsable, quelle que soit son adresse (ou ses
4211 adresses). Remplacez <tt><paquet></tt> par le nom du paquet source
4214 Vous pouvez également vouloir contacter les personnes qui sont inscrites à un
4215 paquet de source donné par le <ref id="pkg-tracking-system">. Vous pouvez le
4216 faire en utilisant l'adresse <tt><nom-paquet>@&pts-host;</tt>.
4219 <sect id="mia-qa">Gérer les responsables non joignables
4221 Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer
4222 que le responsable est toujours actif et qu'il continue à travailler sur
4223 ses paquets. Il est possible qu'il ne soit plus actif, mais qu'il ne se
4224 soit pas désenregistré du système. D'un autre côté, il est possible qu'il
4225 ait simplement besoin d'un rappel.
4227 La première étape est de contacter poliment le responsable et d'attendre une
4228 réponse pendant un temps raisonnable. Il est assez difficile de définir le
4229 « temps raisonnable », mais il est important de prendre en compte que
4230 la vraie vie est parfois assez mouvementée. Une façon de gérer cela pourrait
4231 être d'envoyer un rappel après deux semaines.
4233 Si le responsable ne répond pas après quatre semaines (un mois), on peut
4234 supposer qu'il n'y aura probablement pas de réponse. Si ceci se produit, vous
4235 devriez poursuivre vos investigations et essayer de réunir toutes les
4236 informations utiles sur ce responsable. Ceci inclut :
4239 <item>Les informations « echelon » disponibles dans la <url
4240 id="&url-debian-db;" name="base de données LDAP des
4241 développeurs">, qui indiquent quand le développeur a envoyé un
4242 message pour la dernière fois sur une liste de diffusion Debian.
4243 (Ceci inclut les envois via les listes debian-*-changes.)
4244 Rappelez-vous également de vérifier si le responsable est indiqué
4245 comme en vacances dans la base de données.
4247 <item>Le nombre de paquets de ce responsable et les conditions de ces
4248 paquets. En particulier, restent-ils des bogues empêchant
4249 l'intégration du paquet dans la distribution qui sont ouverts
4250 depuis des lustres ? De plus, combien de bogues y a-t-il en
4251 général ? Un autre point d'information important est si les
4252 paquets ont subi des mises à jour indépendantes et si oui, par
4255 <item>Est-ce que le responsable est actif en dehors de Debian ? Par
4256 exemple, il peut avoir envoyé des messages récemment à des
4257 listes de diffusion non-Debian ou des groupes de discussion.
4260 Un gros problème est représenté par les paquets parrainés — le responsable
4261 n'est pas un développeur Debian officiel. Les informations « echelon »
4262 ne sont pas disponibles pour les personnes parrainés, par exemple, vous devez
4263 donc trouver et contacter le responsable Debian qui a réellement envoyé le
4264 paquet. Étant donné qu'il a signé le paquet, il est responsable de l'envoi de
4265 toute façon et il devrait savoir ce qui s'est passé avec la personne qu'il
4268 Il est également permis d'envoyer une demande à &email-debian-devel; demandant
4269 si quelqu'un est au courant d'information sur le responsable manquant.
4271 Une fois que vous avez réuni toutes ces informations, vous pouvez contacter
4272 &email-debian-qa;. Les personnes de cet alias utiliseront les informations que
4273 vous aurez fournies pour décider comment procéder. Par exemple, ils peuvent
4274 abandonner un ou tous les paquets du responsable. Si un paquet a subi une mise à
4275 jour indépendante, ils peuvent préférer contacter le responsable ayant fait cette
4276 mise à jour — il est peut-être intéressé par le paquet.
4278 Un dernier mot : veuillez vous souvenir d'être poli. Nous sommes tous des
4279 volontaires et nous ne pouvons dédier l'intégralité de notre temps à Debian.
4280 Vous n'êtes pas non plus au courant des circonstances de la personne impliquée.
4281 Elle est peut-être sérieusement malade ou pourrait même nous avoir quitté
4282 — vous ne savez pas qui recevra vos courriers — imaginez comme un
4283 proche se sentira s'il lit un courrier pour la personne décédée et trouve un
4284 message très impoli, en colère et accusateur !)
4286 D'un autre côté, bien que nous soyons tous volontaires, nous avons une
4287 responsabilité. Vous pouvez donc insister sur l'importance du plus grand intérêt
4288 — si un responsable n'a plus le temps ou l'envie, il devrait
4289 « laisser filer » et donner le paquet à quelqu'un ayant plus de temps.
4291 <sect id="newmaint">
4292 <heading>Interagir avec de futurs développeurs Debian
4294 Le succès de Debian dépend de sa capacité à attirer et retenir de nouveaux et
4295 talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous
4296 recommandons de vous impliquer dans le processus d'apport des nouveaux
4297 responsables. Cette section décrit comment aider les futurs développeurs.
4300 <sect1 id="sponsoring">Parrainer des paquets
4302 Parrainer un paquet veut dire envoyer un paquet pour un responsable qui n'est
4303 pas encore autorisé à le faire lui-même, un candidat nouveau responsable.
4304 Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité.
4306 Si vous désirez être volontaire pour être parrain, vous pouvez vous inscrire à
4307 <url id="&url-sponsors;">.
4309 Les nouveaux responsables ont habituellement certaines difficultés à créer des
4310 paquets Debian — ceci est bien compréhensible. C'est pourquoi le parrain
4311 est là pour vérifier que le paquet parrainé est assez bon pour être inclus
4312 dans Debian. (Notez que si le paquet parrainé est nouveau, les ftpmasters
4313 devront également l'inspecter avant de l'intégrer)
4315 Effectuer un parrainage en signant simplement l'envoi ou en recompilant le
4316 paquet <strong>n'est définitivement pas recommandé</strong>. Vous devez
4317 construire le paquet source comme si vous vouliez construire l'un de vos
4318 paquets. Rappelez-vous que cela ne change rien si vous avez laissé le nom du
4319 candidat développeur dans le changelog et dans le fichier de
4320 contrôle, il est toujours possible de savoir que c'est vous qui avez fait l'envoi.
4322 Si vous êtes un gestionnaire de candidature pour un futur développeur, vous
4323 pouvez également être son parrain. Ainsi, vous pourrez vérifier comment le
4324 candidat gère la partie « Tâches et Capacités »<footnote>Tasks and
4325 Skills</footnote> de sa candidature.
4327 <sect1>Gérer les paquets parrainés
4329 En envoyant un paquet sponsorisé vers Debian, vous certifiez que le paquet
4330 atteint les standards minimum de Debian. Ceci implique que vous devez
4331 construire et tester le paquet sur votre propre système avant l'envoi.
4333 Vous ne pouvez pas simplement envoyer un fichier <file>.deb</file> binaire d'un
4334 filleul. En théorie, vous devriez seulement demander le fichier diff et
4335 l'emplacement de l'archive source d'origine et ensuite vous devriez récupérer
4336 le source et appliquer le diff vous-même. En pratique, vous pouvez vouloir
4337 utiliser le paquet source construit par votre filleul. Dans ce cas, vous devez
4338 vérifier qu'il n'a pas modifié les fichiers sources du fichier
4339 <file>.orig.tar.gz</file> qu'il fournit.
4341 N'ayez pas peur de répondre au filleul et de lui indiquer les changements qu'il
4342 doit faire. Cela prend souvent plusieurs échanges de courriers avant que le
4343 paquet ne soit dans un état acceptable. Être un parrain veut dire être un
4346 Une fois que le paquet a atteint les standards Debian, construisez et signez le
4349 dpkg-buildpackage -k<var>KEY-ID</var>
4351 avant de l'envoyer dans le répertoire Incoming.
4353 Le champ Maintainer du fichier <file>control</file> et le fichier
4354 <file>changelog</file> devraient afficher la personne qui a fait l'empaquetage,
4355 c'est-à-dire, le filleul. Celui-ci recevra donc tous les courriers du système
4356 de suivi des bogues (BTS) à propos de son paquet.
4358 Si vous préférez laisser une trace plus visible de votre travail de parrainage,
4359 vous pouvez ajouter une ligne l'indiquant dans la plus récente entrée du
4362 Vous êtes encouragé à garder un œil sur le suivi des paquets que vous parrainez
4363 en utilisant le <ref id="pkg-tracking-system">.
4365 <sect1>Recommander un nouveau développeur
4367 Reportez-vous à la page sur les <url id="&url-newmaint-advocate;"
4368 name="recommandations pour un développeur prospectif"> sur le site web Debian.
4370 <sect1>Gérer les candidatures des nouveaux candidats
4372 Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;" name="liste à
4373 vérifier pour les responsables de candidatures"> sur le site web Debian.
4377 <appendix id="tools">Aperçu des outils du responsable Debian
4379 Cette section contient un aperçu rapide des outils dont dispose le responsable.
4380 Cette liste n'est ni complète, ni définitive, il s'agit juste d'un guide
4381 des outils les plus utilisés.
4383 Les outils du responsable Debian sont destinés à améliorer le confort des
4384 responsables et libérer leur temps des tâches plus cruciales. Comme le dit
4385 Larry Wall, il y a plus d'une manière de le faire.
4387 Certaines personnes préfèrent utiliser des outils de haut niveau, d'autres pas.
4388 Debian n'a pas de position officielle sur la question ; tout outil
4389 conviendra du moment qu'il fait le boulot. C'est pourquoi cette section
4390 n'a pas été conçue pour indiquer à chacun quel outil il doit utiliser ou
4391 comment il devrait faire pour gérer sa charge de responsable Debian. Elle
4392 n'est pas non plus destinée à favoriser l'utilisation d'un outil aux
4395 La plupart des descriptions de ces outils proviennent des descriptions de leurs
4396 paquets. Vous trouverez plus d'informations dans les documentations de ces
4397 paquets. Vous pouvez aussi obtenir plus d'informations avec la commande
4398 <tt>apt-cache show <nom_paquet></tt>.</p>
4401 <sect id="tools-core">
4402 <heading>Outils de base</heading>
4404 Les outils suivants sont pratiquement nécessaires à tout responsable.</p>
4407 <sect1 id="dpkg-dev">
4408 <heading><package>dpkg-dev</package></heading>
4410 Le paquet <package>dpkg-dev</package> contient les outils (y compris
4411 <prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des
4412 paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas
4413 niveau indispensables pour créer et manipuler les paquets ; en tant que
4414 tels, ils sont indispensables à tout responsable Debian.
4416 <sect1 id="debconf">
4417 <heading><package>debconf</package></heading>
4419 Le paquet <package>debconf</package> fournit une interface unifiée pour
4420 configurer les paquets interactivement. Il est indépendant de l'interface et
4421 permet une configuration en mode texte, par une interface HTML ou par boîtes de
4422 dialogue. D'autres types d'interface peuvent être ajoutés sous forme de
4425 Vous trouverez la documentation de ce paquet dans le paquet
4426 <package>debconf-doc</package>.
4428 Beaucoup pensent que ce système devrait être utilisé pour tout paquet
4429 nécessitant une configuration interactive ; reportez-vous à la <ref
4430 id="bpp-config-mgmt">. <package>debconf</package> n'est pas requis par la
4431 <em>charte Debian</em> pour le moment ; cependant, cela pourra changer.
4434 <sect1 id="fakeroot">
4435 <package>fakeroot</package>
4437 <package>fakeroot</package> simule les privilèges <em>root</em>. Cela permet de
4438 fabriquer un paquet sans être root (en général, les paquets installent des
4439 fichiers appartenant à <em>root</em>). Si vous avez installé
4440 <package>fakeroot</package>, vous pouvez construire un paquet en tant que
4441 simple utilisateur avec : <tt>dpkg-buildpackage -rfakeroot</tt>.
4444 <sect id="tools-lint">
4445 <heading>Outils du paquet lint</heading>
4447 Selon le « Free On-line Dictionary of Computing » (FOLDOC),
4448 « lint » est « un outil de traitement de langage C qui contient
4449 beaucoup plus de tests complets sur le code que n'en font habituellement les
4450 compilateurs C. ». Les outils du paquet lint aide les responsables de
4451 paquet à trouver automatiquement des problèmes habituels et des violations de
4452 charte dans leurs paquets</p>
4454 <sect1 id="lintian">
4455 <heading><package>lintian</package></heading>
4457 <package>lintian</package> dissèque les paquets pour y repérer des bogues et des
4458 manquements aux règles de développement. Il contient des tests automatisés pour
4459 vérifier de nombreuses règles et quelques erreurs courantes.
4461 Vous devriez récupérer la dernière version de <package>lintian</package> depuis
4462 <em>unstable</em> régulièrement et vérifier tous vos paquets. Notez que
4463 l'option <tt>-i</tt> donne des explications détaillées sur la signication de
4464 chaque erreur, la partie concernée dans la charte et le moyen habituel de
4467 Veuillez vous reporter à <ref id="sanitycheck"> pour plus d'informations sur
4468 comment et quand utiliser Lintian.
4470 Vous pouvez aussi obtenir un résumé de tous les problèmes reportés par Lintian
4471 sur vos paquets à <url id="&url-lintian;">. Ces rapports contiennent la sortie
4472 de la dernière version de <prgn>lintian</prgn> sur l'ensemble de la
4473 distribution de développement (<em>unstable</em>).
4477 <heading><package>linda</package></heading>
4479 <package>linda</package> est un autre vérificateur de paquet. Il est sembable à
4480 <package>lintian</package>, mais il a un ensemble de tests différents. Il est écrit
4481 en Python plutôt qu'en Perl.</p>
4485 <sect1 id="debdiff">
4486 <heading><package>debdiff</package></heading>
4488 <prgn>debdiff</prgn> (du paquet <package>devscripts</package>, <ref
4489 id="devscripts">) compare des listes de fichiers et des fichiers de contrôle de
4490 deux paquets. C'est un simple test de régression qui peut vous aider à remarquer
4491 si le nombre de paquets binaires à changer depuis le dernier envoi ou si autre
4492 chose a changé dans le fichier de contrôle. Bien sûr, certains des changements
4493 qu'il indique sont normaux, mais il peut aider à empêcher différents accidents.
4495 Vous pouvez l'exécuter sur un couple de paquets binaires :
4497 debdiff package_1-1_arch.deb package_2-1_arch.deb
4500 Ou même sur un couple de fichiers de changements :
4502 debdiff package_1-1_arch.changes package_2-1_arch.changes
4505 Pour plus d'informations, veuillez voir <manref name="debdiff" section="1">.
4511 <sect id="tools-helpers">
4512 <heading>Aides pour le fichier <file>debian/rules</file></heading>
4514 Des outils de construction de paquets rendent le processus d'écriture du fichier
4515 <file>debian/rules</file> plus facile. Veuillez voir les <ref
4516 id="helper-scripts"> pour plus d'informations sur les raisons pour lesquelles
4517 ils peuvent être désirables ou non.
4519 <sect1 id="debhelper">
4520 <heading><package>debhelper</package></heading>
4522 Le paquet <package>debhelper</package> regroupe un ensemble de programmes qui
4523 peuvent être utilisés dans <file>debian/rules</file> pour automatiser les
4524 tâches courantes relatives à la fabrication des paquets Debian binaires. Ce
4525 paquet contient des utilitaires pour installer différents fichiers, les
4526 compresser, ajuster leurs droits et intégrer votre paquet dans le système de
4529 À la différence des autres approches, <package>debhelper</package> est divisé en
4530 plusieurs petits utilitaires qui agissent de manière cohérente. Ce découpage
4531 permet un contrôle des opérations plus fin que d'autres « <em>outils
4532 debian/rules</em> ».
4534 Il existe aussi un certain nombre de petites extensions
4535 <package>debhelper</package> trop éphémères pour être documentées. Vous en
4536 listerez la plupart en faisant <tt>apt-cache search ^dh-</tt>.
4540 <sect1 id="debmake">
4541 <heading><package>debmake</package></heading>
4543 <package>debmake</package> — un précurseur de <package>debhelper</package>
4544 — est un assistant moins modulaire pour manipuler le fichier
4545 <file>debian/rules</file>. Il inclut deux programmes principaux :
4546 <prgn>deb-make</prgn>, utile au développeur Debian pour convertir un paquet
4547 source normal (non-Debian) en paquet source Debian, et <prgn>debstd</prgn> qui
4548 regroupe le type de fonction que l'on trouve dans <package>debhelper</package>.
4550 Le consensus actuel est que l'usage de <package>debmake</package> est
4551 déconseillé au profit de <package>debhelper</package>, mais ce n'est pas une
4552 erreur d'utiliser <package>debmake</package>.
4555 <sect1 id="dh-make">
4556 <heading><package>dh-make</package>
4558 Le paquet <package/dh-make/ contient <prgn/dh_make/, un programme qui crée un
4559 squelette de fichiers nécessaires à la construction d'un paquet Debian à partir
4560 d'une arborescence source. Comme le nom le suggère, <prgn/dh_make/ est une
4561 réécriture de <package/debmake/ et ses fichiers modèles utilisent les
4562 programmes dh_* de <package/debhelper/.
4564 Quoique les fichiers de règles fabriqués par <prgn/dh_make/ constituent en général
4565 une base suffisante pour un paquet fonctionnel, ce ne sont que les
4566 fondations : la charge incombe toujours au responsable d'affiner
4567 les fichiers générés et de rendre le paquet complètement fonctionnel et
4568 en conformité avec la charte.
4572 <heading><package>yada</package></heading>
4574 Le paquet <package>yada</package> est un autre assistant pour la création de
4575 paquets. Il utilise un fichier <file>debian/packages</file> pour générer
4576 <file>debian/rules</file> et d'autres fichiers nécessaires dans le
4577 sous-répertoire <file>debian/</file>.
4579 Remarque : <package>yada</package> est qualifié de « quasiment non
4580 maintenu » par son responsable, Charles Briscoe-Smith. Son usage est donc
4586 <heading><package>equivs</package></heading>
4588 <package>equivs</package> est un autre paquet pour faire des paquets. Il est
4589 souvent conseillé pour un usage local, si vous avez besoin de faire un paquet
4590 pour satisfaire des dépendances. Il est aussi parfois utilisé pour faire des
4591 « méta-paquets » qui sont des paquets dont l'unique objet est de
4592 dépendre d'autres paquets.</p>
4597 <sect id="tools-builders">
4598 <heading>Constructeurs de paquets</heading>
4600 Les paquets suivants aident le processus de construction des paquets, en général
4601 en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que la gestion du support de
4604 <sect1 id="cvs-buildpackage">
4605 <heading><package>cvs-buildpackage</package></heading>
4607 Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou de
4608 récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer
4609 un paquet Debian depuis le référentiel CVS et il assiste le développeur lors de
4610 l'intégration de modifications amont dans le référentiel.
4612 Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS pour le
4613 responsable Debian. Il permet de conserver des branches CVS distinctes pour les
4614 distributions <em>stable</em>, <em>unstable</em> et probablement
4615 <em>experimental</em> et de bénéficier des avantages d'un système de contrôle
4619 <sect1 id="debootstrap">
4620 <heading><package>debootstrap</package></heading>
4622 Le paquet <package>debootstrap</package> vous permet d'amorcer un système Debian
4623 de base à n'importe quel endroit dans votre système de fichier. Par
4624 « système de base », nous entendons le strict minimum nécessaire pour
4625 fonctionner et installer le reste du système.
4627 Avoir un système comme celui-ci peut vous servir de différentes manières. Vous
4628 pouvez, par exemple, déplacer votre racine dans ce système avec
4629 <prgn>chroot</prgn> pour tester vos dépendances de fabrication. Vous pouvez
4630 aussi l'utiliser pour voir comment se comporte votre paquet quand il est
4631 installé dans un environnement minimum.
4634 <sect1 id="pbuilder">
4635 <heading><package>pbuilder</package></heading>
4637 <package>pbuilder</package> construit un système « chrooté » et
4638 compile des paquets dans ce système. Ceci est très utile pour vérifier que les
4639 dépendances de compilation de votre paquet sont correctes et pour vous assurer
4640 qu'aucune dépendance de construction inutile ou incorrecte n'existe dans le
4641 paquet résultant. </sect1>
4644 <heading><package>sbuild</package></heading>
4646 <package>sbuild</package> est un autre compilateur automatique. Il peut aussi
4647 être utilisé dans un environnement « chrooté ». Il peut être utilisé
4648 seul ou comme partie d'un environnement de compilation distribué en réseau.
4649 Comme le précédent, c'est une partie du système utilisé par les porteurs pour
4650 construire des paquets binaires pour toutes les architectures disponibles.
4651 Veuillez vous reporter à <ref id="buildd"> pour plus d'informations et à <url
4652 id="&url-buildd;"> pour voir le système en fonctionnement.</p>
4656 <sect id="uploaders">
4657 <heading>Téléchargeurs de paquets</heading>
4659 Les paquets suivants aident à automatiser ou à simplifier le processus d'envoi
4660 de paquets dans l'archive officielle.</p>
4662 <sect1 id="dupload">
4663 <heading><package>dupload</package></heading>
4665 Le paquet <package>dupload</package> contient un script du même nom pour mettre
4666 à jour des paquets dans l'archive Debian, tracer les mises à jour et les
4667 annoncer par courrier électronique automatiquement. Vous pouvez le configurer
4668 pour faire des mises à jour à d'autres endroits et avec d'autres méthodes.
4672 <heading><package>dput</package></heading>
4674 Le script <package>dput</package> fait à peu près la même chose que
4675 <package>dupload</package>, mais il le fait différemment. Il a aussi quelques
4676 fonctions supplémentaires telles que la possibilité de vérifier la signature
4677 GnuPG et les sommes de contrôles avant le téléchargement et la possibilité de
4678 démarrer <prgn>dinstall</prgn> en mode simulation (<em>dry-run</em>) après le
4684 <sect id="tools-maint-automate">
4685 <heading>Automatisation de la maintenance</heading>
4687 Les outils suivants aident à automatiser les différentes tâches de maintenance
4688 par l'ajout des entrées de changelog ou de lignes de signatures, par la
4689 recherche de bogues à partir d'Emacs ou par l'utilisation du plus récent fichier
4690 officiel <file>config.sub</file>.</p>
4693 <sect1 id="devscripts">
4694 <heading><package>devscripts</package></heading>
4696 Le paquet <package>devscripts</package> contient des scripts et outils qui sont
4697 très utiles pour maintenir vos paquets Debian. Parmi ces scripts, vous
4698 trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui manipulent votre
4699 fichier <file>debian/changelog</file> depuis la ligne de commande et
4700 <prgn>debuild</prgn> qui est construit au-dessus de
4701 <prgn>dpkg-buildpackage</prgn>. L'outil <prgn>bts</prgn> est également très
4702 utile pour mettre à jour l'état des rapports de bogue depuis la ligne de
4703 commande. Le programme <prgn>uscan</prgn> peut être utilisé pour suivre les
4704 nouvelles versions amont de vos paquets. Le programme <prgn>debrsign</prgn>
4705 peut être utilisé pour signer à distance un paquet avant de l'envoyer, ce qui
4706 est agréable quand la machine sur laquelle vous construisez le paquet est
4707 différente de celle où résident vos clés GPG.</p>
4709 Vérifiez la page de manuel <manref section="1" name="devscripts"> pour une liste
4710 complète des scripts disponibles.
4712 <sect1 id="autotools-dev">
4713 <heading><package>autotools-dev</package></heading>
4715 Contient les meilleurs pratiques pour des personnes assurant la maintenance de
4716 paquets qui utilisent <prgn>autoconf</prgn> et/ou <prgn>automake</prgn>.
4717 Contient également des fichiers canoniques <file>config.sub</file> et
4718 <file>config.guess</file> qui sont connus pour fonctionner avec tous les
4719 portages Debian.</p>
4722 <sect1 id="dpkg-repack">
4723 <heading><package>dpkg-repack</package></heading>
4725 <prgn>dpkg-repack</prgn> crée un paquet Debian à partir d'un paquet qui
4726 a déjà été installé. Si des changements ont été effectués sur le paquet quand il
4727 a été décompacté (par exemple, des fichiers dans <file>/etc</file> ont été
4728 modifés), le nouveau paquet héritera de ces changements.</p>
4730 Cet utilitaire peut faciliter la copie de paquet d'un ordinateur vers un autre
4731 ou la re-création de paquets installés sur un système, mais qui ne sont plus
4732 disponibles ailleurs ou pour stocker l'état actuel d'un paquet avant de le
4737 <heading><package>alien</package></heading>
4739 <prgn>alien</prgn> convertit des paquets binaires entre différents formats de
4740 paquets, y compris des paquets Debian, RPM (RedHat), LSB (Linux Standard Base),
4741 Solaris et Slackware.</p>
4744 <sect1 id="debsums">
4745 <heading><package>debsums</package></heading>
4747 <prgn>debsums</prgn> vérifie des paquets installés par rapport à leur somme de
4748 hachage MD5. Veuillez noter que tous les paquets n'ont pas de sommes MD5 car
4749 elles ne sont pas requises par la charte.</p>
4752 <sect1 id="dpkg-dev-el">
4753 <heading><package>dpkg-dev-el</package></heading>
4755 <package>dpkg-dev-el</package> fournit des macros Emacs Lisp qui apportent une
4756 aide lors de l'édition des fichiers du répertoire <file>debian</file> de votre
4757 paquet. À l'édition de <file>debian/changelog</file>, par exemple, vous
4758 disposez de fonctions pour finaliser une version et consulter la liste des
4759 rapports de bogue ouverts.</p>
4763 <sect1 id="dpkg-depcheck">
4764 <heading><package>dpkg-depcheck</package></heading>
4766 <prgn>dpkg-depcheck</prgn> (du paquet <package>devscripts</package>, <ref
4767 id="devscripts">) exécute une commande sous <prgn>strace</prgn> pour déterminer
4768 tous les paquets utilisés par la commande.
4770 Pour les paquets Debian, c'est utile quand vous devez créer une ligne
4771 <tt>Build-Depends</tt> pour votre nouveau paquet : exécuter le processus de
4772 compilation avec <prgn>dpkg-depcheck</prgn> vous fournira une bonne première
4773 approximation des dépendances de compilation. Par exemple :
4775 dpkg-depcheck -b debian/rules build
4778 <prgn>dpkg-depcheck</prgn> peut aussi être utilisé pour vérifier les dépendances
4779 d'exécution, particulièrement si votre paquet utilise exec(2) pour exécuter
4780 d'autres programmes.
4782 Pour plus d'informations, veuillez voir <manref name="dpkg-depcheck" section="1">.
4786 <sect id="tools-porting">
4787 <heading>Outils de portage</heading>
4789 Les outils suivants facilitent le travail des porteurs et la compilation
4792 <sect1 id="quinn-diff">
4793 <heading><package>quinn-diff</package></heading>
4795 <package>quinn-diff</package> est utilisé pour localiser les différences d'une
4796 architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de
4797 l'architecture <var>X</var> doivent être portés sur l'architecture
4800 <sect1 id="dpkg-cross">
4801 <heading><package>dpkg-cross</package></heading>
4803 <package>dpkg-cross</package> est un outil qui installe les bibliothèques et les
4804 en-têtes nécessaires à une compilation
4805 croisée<footnote><p><em>cross-compilation</em></footnote> d'une manière
4806 similaire à <package>dpkg</package>. De plus, les paquets
4807 <prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
4808 améliorés pour accepter les compilations croisées.
4810 <sect id="tools-doc">
4811 <heading>Documentation et information</heading>
4813 Les paquets suivants fournissent des informations pour les responsables ou de
4814 l'aide pour construire de la documentation
4816 <sect1 id="debiandoc-sgml">
4817 <heading><package>debiandoc-sgml</package></heading>
4819 <package>debiandoc-sgml</package> fournit la DTD DebianDoc SGML qui est
4820 habituellement utilisée pour la documentation Debian. Ce manuel, par exemple,
4821 est écrit en DebianDoc. Il fournit également des scripts pour construire et
4822 décliner le source en de multiples formats de sortie.</p>
4824 La documentation sur la DTD peut être trouvée dans le paquet
4825 <package>debiandoc-sgml-doc</package>.</p>
4828 <sect1 id="debian-keyring">
4829 <heading><package>debian-keyring</package></heading>
4831 Contient les clés publiques GPG et PGP des développeurs Debian. Voir <ref
4832 id="key-maint"> et la documentation du paquet pour plus d'informations.</p>
4835 <sect1 id="debview">
4836 <heading><package>debview</package></heading>
4838 <package>debview</package> fournit un mode Emacs pour voir les paquets binaires
4839 Debian. Il vous permet d'examiner un paquet sans le décompresser.</p>
4844 <!-- FIXME: add the following
4847 dbs (referred to above)
4848 dpatch (referred to above)
4865 debaux: too new, unmaintained?
4866 dh-make-perl: too new, unmaintained?
4873 <!-- Keep this comment at the end of the file
4878 sgml-minimize-attributes:nil
4879 sgml-always-quote-attributes:t
4881 sgml-indent-data:nil
4882 sgml-parent-document:nil
4883 sgml-exposed-tags:nil
4884 sgml-declaration:nil
4885 sgml-local-catalogs:nil
4886 sgml-local-ecat-files:nil