1 <!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
2 <!-- include version information so we don't have to hard code it
3 within the document -->
4 <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
5 <!-- common, language independent entities -->
6 <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
8 <!-- CVS revision of this document -->
9 <!ENTITY cvs-rev "$Revision: 1.40 $">
10 <!-- if you are translating this document, please notate the CVS
11 revision of the developers reference here -->
12 <!-- <!ENTITY cvs-en-rev "1.241"> -->
14 <!-- how to mark a section that needs more work -->
15 <!ENTITY FIXME "<em>FIXME:</em> ">
21 <title>Référence du développeur Debian
23 <author>L'équipe de la Référence du développeur &email-devel-ref;
26 <author>Raphaël Hertzog
27 <author>Christian Schwarz
30 <translator>version française par Frédéric Bothamy (traducteur actuel)</translator>
31 <translator>et Antoine Hulin (ancien traducteur)</translator>
32 <translator>et les membres de la liste <email>debian-l10n-french@lists.debian.org</email></translator>
33 <version>Version &version;, &date-fr; (version française 20041007).</version>
36 <copyrightsummary>Copyright © 2004 Andreas Barth</copyrightsummary>
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"> et <url
246 id="&url-mentors;"> pour en savoir plus
247 sur le sujet). Si vous préférez porter Debian sur une architecture ou un noyau
248 alternatif, abonnez-vous aux listes dédiées au portage et demandez-y comment
249 démarrer. Finalement, si vous êtes intéressé par la documentation ou
250 l'assurance qualité (QA), vous pouvez contacter les responsables qui
251 travaillent déjà sur ces tâches et proposer des correctifs et des
255 <sect id="registering">S'enregistrer comme responsable Debian
257 Avant de décider de devenir responsable Debian, il vous faudra lire toute la
258 documentation disponible dans le <url id="&url-newmaint;" name="coin du nouveau
259 responsable">. Elle décrit toutes les étapes préparatoires qu'il vous faudra
260 franchir avant de déposer votre candidature.
262 Par exemple, avant d'être candidat, il vous faudra lire le <url
263 id="&url-social-contract;" name="contrat social Debian">. Devenir responsable
264 Debian implique que vous adhériez à ce contrat social et que vous vous engagiez
265 à le soutenir ; il est très important que les responsables soient en
266 accord avec les principes fondamentaux qui animent le projet &debian-formal;.
267 Lire le <url id="&url-gnu-manifesto;" name="Manifeste GNU"> est aussi une bonne
270 Le processus d'enregistrement a pour but de vérifier votre identité, vos
271 intentions et vos compétences. Le nombre de personnes travaillant pour
272 &debian-formal; a atteint &number-of-maintainers; et notre système est utilisé
273 dans plusieurs endroits très importants : nous devons rester vigilants
274 pour éviter un acte malveillant. C'est pourquoi nous contrôlons les nouveaux
275 responsables avant de leur donner un compte sur nos serveurs et de les autoriser à
276 ajouter des paquets dans l'archive.
278 Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail
279 et que vous serez un bon contributeur. Pour cela, vous pourrez proposer des correctifs
280 par le système de suivi des bogues (BTS) ou maintenir un paquet parrainé
281 pendant un temps. Nous attendons aussi des contributeurs qu'ils soient
282 intéressés par le projet dans son ensemble et pas uniquement par leurs propres
283 paquets. Si vous pouvez aider d'autres responsables en fournissant des
284 informations sur un bogue ou même avec un correctif, faites-le !
286 Pour votre candidature, vous devrez être familiarisé avec la philosophie du
287 projet Debian et avec sa documentation technique. Il vous faudra aussi une clé
288 GnuPG signée par un responsable Debian. Si votre clé GnuPG n'est pas encore
289 signée, vous devriez essayer de rencontrer un responsable Debian pour le faire.
290 La <url id="&url-gpg-coord;" name="page de coordination des signatures de clé
291 GnuPG"> devrait vous aider à trouver un responsable Debian près de chez vous.
292 (Si vous ne trouvez pas de responsable près de chez vous, il existe un second
293 moyen pour valider votre identité. Vous pouvez envoyer une photo d'identité
294 signée avec votre clé GnuPG. Privilégiez tout de même la clé GnuPG signée pour
295 valider une identité. Reportez-vous à la <url id="&url-newmaint-id;" name="page
296 d'identification"> pour en savoir plus sur ces deux options).
299 Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin d'une clé
300 OpenPGP pour signer et vérifier les mises à jour de paquets. Vous lirez la
301 documentation du logiciel de cryptographie que vous utiliserez car elle
302 contient des informations indispensables pour la sécurité de votre clé. Les
303 défaillances de sécurité sont bien plus souvent dues à des erreurs humaines
304 qu'à des problèmes logiciels ou à des techniques d'espionnage avancées. Voir
305 <ref id="key-maint"> pour plus d'informations sur la gestion de votre clé
308 Debian utilise <prgn>GNU Privacy Guard</prgn> (paquet <package>gnupg</package>
309 version 1 ou supérieure) comme standard de base. Vous pouvez aussi utiliser une
310 autre implémentation d'OpenPGP. OpenPGP est un standard ouvert basé sur la <url
311 id="&url-rfc2440;" name="RFC 2440">.
313 L'algorithme à clé publique recommandé pour les développements Debian est DSA
314 (parfois appelé « DSS » ou « DH\ElGamal »). Vous pouvez
315 aussi utiliser d'autres types de clés. La longueur de votre clé doit être au
316 minimum de 1024 bits ; il n'y a pas de raison d'utiliser une clé plus
317 courte et le faire serait beaucoup moins sûr. Votre clé doit être signée avec
318 votre propre identifiant ; cela évite les falsifications. <prgn>GNU
319 Privacy Guard</prgn> le fait automatiquement.
321 Si votre clé publique n'est pas sur un serveur public tel que &pgp-keyserv;,
322 reportez-vous à la documentation disponible localement dans &file-keyservs;.
323 Cette documentation explique comment mettre votre clé publique sur un serveur.
324 L'équipe <em>New maintainer</em> mettra votre clé publique sur les serveurs de
325 clés si elle n'y est pas déjà.
327 Certains pays limitent l'usage des logiciels de cryptographie. Cela ne devrait
328 cependant pas avoir d'impact sur l'activité d'un responsable de paquet car il
329 peut être tout à fait légal d'utiliser des logiciels de cryptographie pour
330 l'authentification plutôt que pour le chiffrement. &debian-formal; ne nécessite
331 en aucune façon l'utilisation de chiffrement. Si vous vivez dans un pays où
332 l'utilisation de la cryptographie pour authentification est interdite,
333 contactez-nous pour que nous prenions des dispositions particulières.
335 Pour faire acte de candidature, il vous faut un responsable Debian qui vérifiera
336 votre candidature (un <em>avocat</em>). Après avoir contribué au projet Debian
337 pendant un temps, quand vous choisissez de devenir un responsable Debian
338 officiel, un responsable déjà enregistré avec qui vous aurez travaillé dans les
339 derniers mois devra exprimer que, d'après lui, vous pouvez contribuer avec
340 succès au projet Debian.
342 Quand vous avez trouvez un <em>avocat</em>, quand votre clé GnuPG est signée et
343 quand vous avez déjà contribué au projet, vous êtes prêt à faire
344 acte de candidature. Il vous suffit pour cela de vous enregistrer sur notre
345 <url id="&url-newmaint-apply;" name="page de candidature">. Ensuite, votre
346 avocat devra confirmer votre candidature. Quand il aura accompli cette tâche,
347 un responsable de candidature<footnote><p>Application manager</footnote> sera
348 désigné pour vous accompagner dans le processus d'enregistrement. Vous pouvez
349 toujours consulter le <url id="&url-newmaint-db;" name="tableau de bord des
350 candidatures"> pour connaître l'état de votre candidature.
352 Pour en savoir plus, consultez le <url id="&url-newmaint;" name="coin des
353 nouveaux responsables"> sur le site Debian. Assurez-vous de bien connaître les
354 étapes nécessaires au processus d'enregistrement avant de vous porter candidat.
355 Vous gagnerez beaucoup de temps si vous êtes bien préparé.
358 <sect id="mentors">Mentors et parrains Debian
360 La liste de diffusion &email-debian-mentors; a été créée pour les responsables
361 débutants qui cherchent de l'aide pour leur première création de paquet ainsi
362 que pour des problèmes spécifiques aux développeurs. Tout responsable débutant
363 est invité à s'y inscrire (voir <ref id="mailing-lists"> pour plus de détails).
365 Ceux qui préfèrent une aide personnalisée (via une correspondance privée)
366 doivent aussi poster dans cette liste, un développeur expérimenté se portera
367 volontaire pour les aider.
369 Si vos paquets sont prêts à être intégrés mais que vous attendiez le
370 résultat de votre candidature, vous pouvez chercher un parrain qui téléchargera
371 les paquets à votre place. Les parrains sont des responsables Debian officiels
372 volontaires pour examiner et télécharger vos paquets. Vous pouvez
373 demander un parrainage à l'adresse <url id="&url-sponsors;">. Veuillez tout
374 d'abord lire la FAQ non officielle de debian-mentors à <url id="&url-mentors;">.
376 Si vous désirez être mentor ou parrain, reportez-vous à <ref id="newmaint">.
379 <chapt id="developer-duties">Les charges du responsable Debian
381 <sect id="user-maint">Mise à jour de vos références Debian
383 Il existe une base de données LDAP contenant des informations concernant les
384 développeurs Debian à <url id="&url-debian-db;">. Vous devriez y entrer vos
385 informations et les mettre à jour quand elles changent. Le plus important est de
386 vous assurer que l'adresse vers laquelle est redirigée votre adresse debian.org
387 est toujours à jour, de même que l'adresse à laquelle vous recevez votre
388 abonnement à debian-private si vous choisissez d'être abonné à cette liste.
390 Pour plus d'informations à propos de cette base de données, veuillez consulter
393 <sect id="key-maint">Gérer votre clé publique
395 Soyez très vigilant en utilisant votre clé privée. Ne la placez pas sur un
396 serveur public ou sur des machines multi-utilisateurs telles que les serveurs
397 Debian (voir <ref id="server-machines">). Sauvegardez vos clés et gardez-en une
398 copie hors connexion. Lisez la documentation fournie avec votre logiciel et la
399 <url id="&url-pgp-faq;" name="FAQ PGP">.
401 Si vous ajoutez des signatures ou des identifiants à votre clé publique, vous
402 pouvez mettre à jour le porte-clés Debian en envoyant votre clé publique à
403 <tt>&keyserver-host;</tt>. Si vous voulez ajouter ou supprimer une clé, envoyez
404 un courrier à &email-debian-keyring;. Les procédures d'extraction de clé
405 décrites dans <ref id="registering"> s'appliquent ici.
407 Vous pouvez trouver une présentation approfondie de la gestion de clé Debian
408 dans la documentation du paquet <package>debian-keyring</package>.
410 <sect id="voting">Voter
412 Bien que Debian ne soit pas vraiment une démocratie, nous disposons d'un
413 processus démocratique pour élire nos chefs et pour approuver les résolutions
414 générales. Ces procédures sont définies par la <url id="&url-constitution;"
415 name="charte Debian">.
417 En dehors de l'élection annuelle du chef, les votes ne se tiennent pas
418 régulièrement et ils ne sont pas entrepris à la légère. Chaque proposition est
419 tout d'abord discutée sur la liste de diffusion &email-debian-vote; et elle a
420 besoin de plusieurs approbations avant que le secrétaire du projet n'entame la
423 Vous n'avez pas besoin de suivre les discussions précédant le vote car le
424 secrétaire enverra plusieurs appels au vote sur la liste
425 &email-debian-devel-announce; (et tous les développeurs devraient être inscrits
426 à cette liste). La démocratie ne fonctionne pas si les personnes ne prennent pas
427 part au vote, c'est pourquoi nous encourageons tous les développeurs à voter. Le
428 vote est conduit par messages signés ou chiffrés par GPG.
431 La liste de toutes les propositions (passées et présentes) est disponible à la
432 page <url id="&url-vote;" name="Informations sur les votes Debian">, ainsi que
433 des informations complémentaires sur la procédure à suivre pour effectuer une
434 proposition, la soutenir et voter pour elle.
436 <sect id="inform-vacation">Prendre des vacances courtoisement
438 Il est courant pour les développeurs de s'absenter, que ce
439 soit pour des vacances prévues ou parce qu'ils sont submergés de travail. La
440 chose importante à noter est que les autres développeurs ont besoin de savoir
441 que vous êtes en vacances pour qu'ils puissent agir en conséquence si un
442 problème se produit pendant vos vacances.
444 Habituellement, cela veut dire que les autres développeurs peuvent faire des NMU
445 (voir <ref id="nmu">) sur votre paquet si un gros problème (bogues empêchant
446 l'intégration dans la distribution, mise à jour de sécurité, etc.) se produit pendant que vous êtes en
447 vacances. Parfois, ce n'est pas très important, mais il est de
448 toute façon approprié d'indiquer aux autres que vous n'êtes pas disponible.
450 Il y a deux choses à faire pour informer les autres développeurs.
451 Premièrement, envoyez un courrier électronique à &email-debian-private; en
452 commençant le sujet de votre message par « [VAC] »<footnote>Ainsi, le
453 message peut être facilement filtré par les personnes qui ne veulent pas lire
454 ces annonces de vacances.</footnote> et donnez la période de vos
455 vacances. Vous pouvez également donner quelques instructions pour
456 indiquer comment agir si un problème survenait.
458 L'autre chose à faire est de vous signaler comme « en
459 vacances »<footnote><p><em>on vacation</em> en anglais</footnote> dans la
460 <qref id="devel-db">base de données Debian LDAP</qref> (l'accès à cette
461 information est réservé aux développeurs). N'oubliez pas de retirer votre
462 indicateur « en vacances » lorsque celles-ci sont terminées !
464 <sect id="upstream-coordination">Coordination avec les développeurs amont
466 Une grande part de votre travail de responsable Debian sera de rester en contact
467 avec les développeurs amont. Parfois, les utilisateurs établissent des
468 rapports de bogue qui ne sont pas spécifiques à Debian. Vous devez transmettre
469 ces rapports de bogue aux développeurs amont pour qu'ils soient corrigés dans
470 les prochaines versions.
472 Bien qu'il ne soit pas de votre responsabilité de corriger les
473 bogues non spécifiques à Debian, vous pouvez le faire si vous en êtes capable.
474 Quand vous faites de telles corrections, assurez-vous de les envoyer
475 également au développeur amont. Les utilisateurs et responsables
476 Debian proposent souvent des correctifs pour corriger des bogues amont, il
477 vous faudra alors évaluer ce correctif puis le transmettre aux développeurs
480 Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
481 paquet conforme à la charte Debian, alors vous devriez proposer un correctif
482 aux développeurs amont pour qu'il soit inclus dans leur version. Ainsi, vous
483 n'aurez plus besoin de modifier les sources lors des mises à jour amont
484 suivantes. Quels que soient les changements dont vous avez besoin, il faut
485 toujours essayer de rester dans la lignée des sources amont.
487 <sect id="rc-bugs">Comment gérer les bogues empêchant l'intégration du
488 paquet dans la distribution ?
490 Habituellement, vous devriez traiter les rapports de bogue sur vos paquets tel
491 que cela est décrit dans <ref id="bug-handling">. Cependant, il y a une
492 catégorie spéciale de bogues qui nécessite particulièrement votre
493 attention : les bogues empêchant l'intégration du paquet dans la
494 distribution<footnote>Traduction de l'anglais <em>Release-critical bug (RC
495 Bugs)</em></footnote>. Tous les rapports de bogue de gravité <em>critique</em>,
496 <em>grave</em> et <em>sérieuse</em><footnote>Respectivement <em>critical</em>,
497 <em>grave</em> et <em>serious</em> en anglais</footnote> sont considérés comme
498 ayant un impact sur la présence du paquet dans la prochaine version stable de
499 Debian. Ces bogues peuvent retarder la diffusion d'une distribution Debian
500 ou peuvent justifier la suppression d'un paquet d'une distribution gelée.
501 C'est pourquoi ces bogues doivent être corrigés au plus vite.
503 Les développeurs faisant partie de l'équipe d'<url id="&url-debian-qa;"
504 name="assurance qualité Debian"> surveillent ces bogues et essaient de vous
505 aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas corriger un bogue de
506 ce type dans les deux semaines, vous devriez soit demander de l'aide en
507 envoyant un courrier à l'équipe d'assurance qualité (<em>QA group</em>) à
508 &email-debian-qa;, soit expliquer vos difficultés et présenter un plan pour
509 corriger le problème en répondant au rapport de bogue concerné. Si rien n'est
510 fait, des personnes de l'équipe d'assurance qualité pourraient chercher à
511 corriger votre paquet (voir <ref id="nmu">) après avoir tenté de vous contacter
512 (ils pourraient attendre moins longtemps que d'habitude pour faire leur mise à
513 jour s'il n'y a pas trace d'activité récente de votre part dans le système de
519 Si vous choisissez de quitter le projet Debian, procédez comme suit :
520 <enumlist compact="compact">
521 <item><p>abandonnez tous vos paquets comme décrit dans <ref
522 id="orphaning"> ;</item>
523 <item><p>envoyez un courrier électronique à &email-debian-private; indiquant
524 pourquoi vous quittez le projet ;</item>
525 <item><p>signalez aux responsables du porte-clés Debian que vous quittez le
526 projet en écrivant à &email-debian-keyring;.</item>
531 <chapt id="resources">Ressources pour le responsable Debian
533 Dans ce chapitre, vous trouverez une brève description des listes de diffusion,
534 des machines Debian qui seront à votre disposition en tant que responsable
535 Debian ainsi que toutes les autres ressources à votre disposition pour vous
536 aider dans votre travail de responsable.
538 <sect id="mailing-lists">Les listes de diffusion
540 Une grande partie des discussions entre les développeurs Debian (et les
541 utilisateurs) est gérée par un vaste éventail de listes de diffusion que nous
542 hébergeons à <tt><url id="http://&lists-host;/" name="&lists-host;"></tt>.
543 Pour en savoir plus sur comment s'abonner ou se désabonner, comment envoyer un
544 message et comment ne pas en envoyer, comment retrouver d'anciens messages et
545 comment les rechercher, comment contacter les responsables des listes et pour
546 sevoir d'autres informations sur les listes de diffusion, veuillez lire <url
547 id="&url-debian-lists;">. Cette section ne couvrira que les aspects des listes
548 de diffusion qui ont un intérêt particulier pour les développeurs.
550 <sect1 id="mailing-lists-rules">Rêgles de base d'utilisation
552 Lorsque vous répondez sur une liste de diffusion, veuillez ne pas envoyer de
553 copie (<tt>CC</tt>) à l'auteur d'origine sauf s'il le demande explicitement.
554 Toute personne envoyant un message à une liste de diffusion devrait la suivre
555 pour voir les réponses.
557 Le multi-postage (cross-posting) (envoyer le même message à plusieurs listes)
558 est découragé. Comme toujours sur le net, veuillez réduire la citation des
559 articles auxquels vous répondez. En général, veuillez adhérez aux conventions
560 usuelles d'envoi de messages.
562 Veuillez lire le <url name="code de conduite"
563 id="&url-debian-lists;#codeofconduct"> pour plus d'informations.
565 <sect1 id="core-devel-mailing-lists">Principales listes pour les
568 Les principales listes de diffusion de Debian que les développeurs
569 devraient suivre sont :
571 <item>&email-debian-devel-announce;, utilisée pour les annonces importantes
572 faites aux responsables. Tous les responsables Debian sont censés être
573 inscrits à cette liste,</item>
574 <item>&email-debian-devel;, utilisée pour discuter de diverses questions
575 techniques relatives au développement,</item>
576 <item>&email-debian-policy; où l'on discute et vote les modifications de la
577 charte Debian,</item>
578 <item>&email-debian-project;, utilisée pour discuter de questions non
582 Il existe d'autres listes de diffusion spécialisées dans différents thèmes.
583 Reportez-vous à la page <url id="http://&lists-host;/"> pour en obtenir
586 <sect1 id="mailing-lists-special">Listes spéciales
588 &email-debian-private; est une liste de diffusion destinée aux discussions
589 privées entre développeurs Debian. Elle doit être utilisée pour tout message
590 qui ne doit pas être publié, quelle qu'en soit la raison. C'est une liste à
591 faible trafic et les utilisateurs sont priés de ne l'utiliser qu'en cas de
592 réelle nécessité. De plus, il ne faut <em>jamais</em> faire suivre un courrier
593 de cette liste à qui que ce soit. Pour des raisons évidentes, les archives de
594 cette liste ne sont pas disponibles sur la toile. Vous pouvez les consulter en
595 visitant le répertoire <file>~debian/archive/debian-private</file> avec votre
596 compte sur <tt>lists.debian.org</tt>.
598 &email-debian-email; est une liste de diffusion fourre-tout. Elle est utilisée
599 pour les correspondances relatives à Debian qu'il serait utile d'archiver,
600 telles que des échanges avec les auteurs amont à propos de licences, de bogues
601 ou encore des discussions sur le projet avec d'autres personnes.
603 <sect1 id="mailing-lists-new">Demander une nouvelle liste relative au développement
605 Avant de demander un liste de diffusion liée au développement d'un paquet (ou
606 d'un petit groupe de paquets liés), veuillez considérer si l'utilisation d'un
607 alias (via un fichier .forward-aliasname sur master.debian.org, ce qui se
608 traduit en une adresse raisonnablement agréable
609 <var>you-aliasname@debian.org</var>) ou une liste de diffusion auto-gérée sur
610 <qref id="alioth">Alioth</qref> serait plus appropriée.
612 Si vous décidez qu'une liste de diffusion standard sur lists.debian.org est
613 vraiment ce que vous voulez, lancez-vous et faites une demande en suivant <url
614 name="le guide" id="&url-debian-lists-new;">.
617 <sect id="irc-channels">Canaux IRC
619 Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont
620 principalement hébergés sur le réseau <url id="&url-openprojects;"
621 name="freenode"> (anciennement connu sous le nom de Open Projects Network).
622 L'entrée DNS <tt>irc.debian.org</tt> est simplement un alias vers
623 <tt>irc.freenode.net</tt>.
625 Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un
626 canal important, généraliste, où les utilisateurs peuvent trouver des nouvelles
627 récentes dans le sujet et qui est administré par des robots. <em>#debian</em>
628 est destiné aux anglophones ; il existe également <em>#debian.de</em>,
629 <em>#debian-fr</em>, <em>#debian-br</em> et d'autres canaux avec des noms
630 semblables pour les personnes parlant d'autres langues.
632 Le canal principal pour le développement Debian est <em>#debian-devel</em>.
633 C'est un canal très actif avec habituellement plus de 150 personnes connectées
634 en permanence. C'est un canal pour les personnes qui travaillent sur Debian, ce
635 n'est pas un canal d'aide (il existe <em>#debian</em> pour cela). Il est
636 cependant ouvert à tous ceux qui veulent écouter (et apprendre). Le sujet est
637 toujours rempli d'informations intéressantes.
639 Comme <em>#debian-devel</em> est un canal ouvert, vous ne devriez pas y parler
640 de problèmes discutés sur &email-debian-private;. Il existe un canal protégé
641 par clé <em>#debian-private</em> dans ce but. La clé est disponible dans les
642 archives de debian-private à
643 <file>master.debian.org:&file-debian-private-archive;</file>, effectuez
644 simplement un <prgn>zgrep</prgn> avec <em>#debian-private</em> dans tous les
647 Il existe d'autres canaux dédiés à des sujets spécifiques. <em>#debian-bugs</em>
648 est utilisé pour la coordination des <em>chasses aux bogues</em>.
649 <em>#debian-boot</em> est utilisé pour la coordination du travail sur les
650 disquettes de démarrage (i.e., l'installeur). <em>#debian-doc</em> est utilisé
651 occasionnellement pour travailler sur la documentation comme celle que vous
652 lisez actuellement. D'autres canaux sont dédiés à une architecture ou un
653 ensemble de paquets : <em>#debian-bsd</em>, <em>#debian-kde</em>,
654 <em>#debian-jr</em>, <em>#debian-edu</em>, <em>#debian-sf</em> (paquet
655 SourceForge), <em>#debian-oo</em> (paquet OpenOffice), etc.
657 Certains canaux pour développeurs non anglophones existent, par exemple,
658 <em>#debian-devel-fr</em> pour les francophones intéressés dans le
659 développement de Debian.
661 Il existe également des canaux dédiés pour Debian sur d'autres réseaux IRC,
662 notamment sur le réseau IRC <url name="Open and free technology community
663 (OFTC)" id="http://www.oftc.net/">.
666 <sect id="doc-rsrcs">Documentation
668 Ce document contient beaucoup d'informations très utiles aux développeurs
669 Debian, mais il ne peut pas tout contenir. La plupart des autres documents
670 intéressants sont référencés dans le <url id="&url-devel-docs;" name="coin
671 du développeur Debian">. Prenez le temps de parcourir tous les liens, vous
672 apprendrez encore beaucoup de choses.
675 <sect id="server-machines">Les serveurs Debian
677 Debian possède plusieurs ordinateurs employés comme serveurs, dont la plupart hébergent
678 les fonctions critiques du projet Debian. La plupart des machines sont
679 utilisées pour des activités de portage et elles ont toutes un accès permanent
682 La plupart des machines peuvent être utilisées par les développeurs
683 tant qu'ils respectent les règles définies dans la <url
684 id="&url-dmup;" name="charte d'utilisation des machines Debian">.
686 Dans l'ensemble, vous pouvez faire usage de ces machines pour des buts relatifs
687 à Debian comme vous l'entendez. Veuillez cependant être gentil avec les
688 administrateurs système et ne pas utiliser de grandes quantités d'espace
689 disque, de ressource réseau ou CPU sans obtenir auparavant l'accord des
690 administrateurs. Habituellement, ces machines sont administrées par des
693 Veuillez prendre soin de votre mot de passe Debian ainsi que des clés SSH
694 installées sur les machines Debian. Évitez les méthodes de connexion ou d'envoi
695 de données qui envoient les mots de passe en clair par l'Internet comme telnet,
698 Veuillez ne pas déposer de données non relatives à Debian sur les serveurs
699 Debian à moins que vous n'ayez préalablement obtenu la permission de le faire.
701 La liste actuelle des machines Debian est disponible à <url
702 id="&url-devel-machines;">. Cette page web contient les noms des machines, les
703 informations de contact, les informations sur qui peut s'y connecter, les clés
706 Si vous avez un problème en utilisant un serveur Debian et si vous estimez que
707 les administrateurs système devraient en être avertis, l'équipe des
708 administrateurs système peut être jointe à
709 <email>debian-admin@lists.debian.org</email>.
711 Si votre problème est lié à un certain service ou n'est pas lié au système
712 (paquet à supprimer de l'archive ou suggestion pour le site web par exemple),
713 il vous faudra en général ouvrir un rapport de bogue sur un
714 « pseudo-paquet ». Reportez-vous à la section <ref id="submit-bug">
715 pour connaître la procédure à suivre.
717 Certains des serveurs de base sont à accès restreint, mais les informations de
718 ceux-ci sont fournies par d'autres serveurs miroirs.
720 <sect1 id="servers-bugs">Le serveur pour les rapports de bogues
722 <tt>&bugs-host;</tt> est le serveur maître du système de suivi des bogues
723 (BTS<footnote><p>Système de suivi des bogues se dit <em>Bug Tracking
724 System</em> en anglais</footnote>).
726 Ce serveur est à accès restreint ; un miroir est disponible sur <tt>merkel</tt>.
728 Si vous envisagez de manipuler les rapports
729 de bogue ou d'en faire une analyse statistique, ce sera le bon endroit pour le
730 faire. Informez la liste &email-debian-devel; de votre intention avant
731 d'implémenter quoi que ce soit afin d'éviter un travail en double ou un
732 gaspillage de temps machine.
734 <sect1 id="servers-ftp-master">Le serveur ftp-master
736 Le serveur <tt>ftp-master.debian.org</tt> est le serveur maître de l'archive
737 Debian (exception faite des paquets non-US). En général, les mises à jour de
738 paquets se font sur ce serveur. Reportez-vous à la section <ref id="upload">
741 Ce serveur est à accès restreint ; un miroir est disponible sur <tt>merkel</tt>.
743 Les problèmes avec l'archive Debian FTP doivent généralement être rapportés
744 comme bogues sur le pseudo-paquet <package>ftp.debian.org</package> ou par
745 courrier électronique à &email-ftpmaster; ; reportez-vous à la section
746 <ref id="archive-manip"> pour connaître la procédure à suivre.
748 <sect1 id="servers-non-us">Le serveur non-US
750 Le serveur non-US <tt>non-us.debian.org</tt> est le serveur maître de la partie
751 non-US de l'archive Debian. Si vous avez besoin d'envoyer un paquet dans l'une
752 des sections non-US, envoyez-le vers ce serveur. Reportez-vous à la section
753 <ref id="upload-non-us"> pour en savoir plus.
755 Les problèmes avec l'archive de paquets non-US doivent généralement être
756 rapportés comme bogues sur le pseudo-paquet <package>nonus.debian.org</package>
757 (remarquez l'absence de trait d'union entre "non" et "us" dans le nom du
758 pseudo-paquet — c'est dû à la compatibilité descendante). Rappelez-vous
759 de vérifier si quelqu'un n'aurait pas déjà rempli un rapport de bogue
760 concernant le problème sur le <url id="http://&bugs-host;/nonus.debian.org"
761 name="système de suivi des bogues">.
763 <sect1 id="servers-www">Le serveur www-master
765 Le serveur web principal est <tt>www-master.debian.org</tt>. Il héberge les
766 pages web officielles, la façade de Debian pour la plupart des débutants.
768 Si vous rencontrez un problème avec un serveur web Debian, vous devez
769 généralement envoyer un rapport de bogue sur le pseudo-paquet
770 <package>www.debian.org</package>. Vérifiez d'abord sur le <url
771 id="http://&bugs-host;/www.debian.org" name="système de suivi des bogues">
772 que personne ne l'a déjà rapporté avant vous.
774 <sect1 id="servers-people">Le serveur web people
776 <tt>people.debian.org</tt> est le serveur utilisé par les développeurs pour
777 leurs pages concernant Debian.
779 Si vous avez des informations spécifiques Debian que vous voulez rendre
780 disponibles sur le web, vous pouvez le faire en les plaçant dans le répertoire
781 <file>public_html</file> de votre répertoire personnel sur
782 <tt>people.debian.org</tt>. Elles seront accessibles à l'adresse
783 <tt>http://people.debian.org/~<var>votre-user-id</var>/</tt>.
785 Vous ne devriez utiliser que cet emplacement particulier car il sera sauvegardé
786 alors que sur les autres serveurs, ce ne sera pas le cas.
788 Habituellement, la seule raison pour utiliser un serveur différent est que vous
789 avez besoin de publier des informations soumises aux restrictions d'exportation
790 américaines, dans ce cas, vous pouvez utiliser l'un des autres serveurs situés
791 en dehors des États-Unis, comme le serveur mentionné ci-dessus
792 <tt>non-us.debian.org</tt>.
794 Veuillez envoyer un courrier à &email-debian-devel; si vous avez une question.
796 <sect1 id="servers-cvs">Le serveur CVS
798 Notre serveur CVS est situé sur <tt>cvs.debian.org</tt>.
800 Si vous avez besoin d'un serveur CVS accessible par tous pour, par exemple,
801 coordonner le travail de plusieurs développeurs sur un paquet, vous pouvez
802 demander un espace CVS sur ce serveur.
804 Le serveur <tt>cvs.debian.org</tt> autorise les accès CVS locaux, les accès en
805 lecture seule pour les connexions client-serveur anonymes et les accès
806 client-serveur complets pour les connexions <prgn>ssh</prgn>. L'espace CVS peut
807 aussi être consulté par la toile à l'adresse <url id="&url-cvsweb;">.
809 Pour obtenir un espace CVS, envoyez une demande à l'adresse &email-debian-admin;
810 en précisant le nom de l'espace, le compte Debian propriétaire du répertoire
811 racine et pourquoi vous en avez besoin.
813 <sect1 id="dchroot">Chroots de différentes distributions
815 Sur certaines machines, des chroots de différentes distributions sont
816 disponibles. Vous pouvez les utiliser comme ceci :
819 vore% dchroot unstable
820 Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
823 Dans tous les chroots, les répertoires normaux des utilisateurs sont disponibles.
824 Vous pouvez trouver quels chroots sont disponibles à
825 <tt>&url-devel-machines;</tt>.
828 <sect id="devel-db">La base de données des développeurs
830 La base de données des développeurs à <url id="&url-debian-db;"> est un annuaire
831 LDAP de gestion des informations des développeurs Debian. Vous pouvez utiliser
832 cette ressource pour rechercher la liste des développeurs Debian. Une partie de
833 ces informations est également disponible à travers le service <prgn>finger</prgn> sur les
834 serveurs Debian, essayez <prgn>finger yourlogin@debian.org</prgn> pour voir ce
837 Les développeurs peuvent <url name="se connecter à la base de données"
838 id="&url-debian-db-login;"> pour modifier différentes informations les
839 concernant, comme :
841 <item>l'adresse de suivi pour leur adresse debian.org,
842 <item>l'abonnement à debian-private,
843 <item>l'état en vacances ou non,
844 <item>des informations personnelles comme les adresse, pays, latitude et
845 longitude de l'endroit où ils vivent pour utilisation dans la <url
846 name="carte mondiale des développeurs Debian" id="&url-worldmap">,
847 numéros de téléphone et de fax, surnom IRC et page web,
848 <item>le mot de passe et le shell préféré sur les machines du projet Debian.
851 La plupart des informations ne sont naturellement pas accessibles publiquement.
852 Pour plus d'informations, veuillez lire la documentation en ligne que vous
853 pouvez trouver à <url id="&url-debian-db-doc;">.
856 Il est également possible d'envoyer ses clés SSH pour les utiliser pour
857 autorisation sur les machines Debian officielles et même d'ajouter de nouvelles
858 entrées DNS du type *.debian.net. Ces fonctionnalités sont documentées à <url
859 id="&url-debian-db-mail-gw;">.
862 <sect id="archive">L'archive Debian
864 La distribution &debian-formal; est composée d'un grand nombre de paquets
865 (fichiers <tt>.deb</tt> : actuellement, à peu près &number-of-pkgs;) et de
866 quelques autres fichiers (comme la documentation et des images des disquettes
869 Voici un exemple d'arborescence pour une archive Debian complète :
871 &sample-dist-dirtree;
873 Comme vous pouvez le voir, le répertoire racine contient deux répertoires,
874 <file>dists/</file> et <file>pool/</file>. Le second est un ensemble de
875 répertoires où sont stockés les paquets. Ceux-ci sont manipulés grâce à la base
876 de données de l'archive et aux logiciels qui l'accompagnent. Le premier
877 répertoire contient les distributions <em>stable</em>, <em>testing</em> et
878 <em>unstable</em>. Les fichiers <file>Packages</file> et <file>Sources</file>
879 qui se trouvent dans les répertoires de distribution peuvent faire référence à
880 des fichiers du répertoire <file>pool/</file>. Le découpage en sous-répertoires
881 est identique d'un répertoire de distribution à l'autre . Ce que nous
882 exposerons ci-dessous pour la distribution <em>stable</em> est également
883 applicable aux distributions <em>unstable</em> et <em>testing</em>.
885 Le répertoire <file>dists/stable</file> contient trois répertoires nommés
886 <file>main</file>, <file>contrib</file> et <file>non-free</file>.
888 Dans chacune de ces sections, se trouve un répertoire contenant les paquets
889 sources (<file>source/</file>) et un répertoire pour chaque architecture
890 acceptée (<file>binary-i386/</file>, <file>binary-m68k/</file>, etc.).
892 La section <em>main</em> contient d'autres répertoires destinés aux images de
893 disquettes et à plusieurs documents essentiels pour installer la distribution
894 Debian sur une architecture particulière (<file>disk-i386/</file>,
895 <file>disk-m68k/</file>, etc.).
897 <sect1 id="archive-sections">Les sections
899 La section <em>main</em> constitue la <strong>distribution &debian-formal;
900 officielle</strong>. Elle est officielle parce qu'elle est entièrement conforme
901 à toutes nos recommandations. Les deux autres sections divergent de ces
902 recommandations à différents degrés, elles <strong>ne</strong> font donc <strong>pas</strong>
903 officiellement partie de &debian-formal;.
905 Chaque paquet de la section <em>main</em> doit être conforme aux <url
906 id="&url-dfsg;" name="directives Debian pour le logiciel
907 libre"><footnote>Debian Free Software Guidelines</footnote> et à toutes les
908 autres recommandations décrites dans <url id="&url-debian-policy;" name="la
909 charte Debian"><footnote>Debian Policy Manual</footnote>. Les
910 DFSG<footnote><em>Debian Free Software Guidelines</em></footnote> constituent
911 notre définition de « logiciel libre ». Reportez-vous à la <em>charte
912 Debian</em> pour en savoir plus.
914 Les paquets de la section <em>contrib</em> doivent être conformes aux DFSG, mais
915 ne respectent pas d'autres contraintes. Ils peuvent, par exemple, dépendre de
916 paquets de la section <em>non-free</em>.
918 Les paquets qui ne sont pas conformes aux DFSG sont rangés dans la section
919 <em>non-free</em>. Bien que nous supportions l'usage de ces paquets et qu'ils
920 bénéficient de nos infrastructures (système de suivi des bogues, listes de
921 diffusion, etc.), ces paquets <em>non-free</em> ne font pas partie de la
924 La <em>charte Debian</em> donne des définitions plus précises pour ces trois
925 sections. Les paragraphes précédents ne constituent qu'une introduction.
927 La séparation de l'archive en trois sections est importante pour toute personne
928 qui désire distribuer Debian, que ce soit par serveur FTP ou sur cédérom. Il
929 suffit de distribuer les sections <em>main</em> et <em>contrib</em> pour éviter
930 tout problème légal. Certains paquets de la section <em>non-free</em>
931 interdisent leur distribution à titre commercial par exemple.
933 D'un autre côté, un distributeur de cédérom pourra facilement vérifier
934 la licence de chacun des paquets de la section <em>non-free</em> et
935 inclure tous les paquets qu'il lui sera autorisé (dans
936 la mesure où cela varie énormément d'un distributeur à l'autre, ce travail ne
937 peut être fait par les développeurs Debian).
939 Notez que le terme « section » est également utilisé pour faire
940 référence aux catégories qui simplifient l'organisation des paquets
941 disponibles et leur recherche, e.g. <em>admin</em>, <em>net</em>, <em>utils</em> etc. Il
942 fut un temps où ces sections (sous-sections, plutôt) existaient sous la forme
943 de sous-répertoires dans l'archive Debian. Actuellement, elles n'existent plus
944 que dans le champ en-tête « Section » des paquets.
946 <sect1>Les architectures
948 À ses débuts, le noyau Linux existait uniquement pour les architectures Intel
949 x86 ; il en était de même pour Debian. Linux devenant de plus en plus
950 populaire, il a été porté vers d'autres architectures.
952 Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC,
953 Motorola, 680x0 (Atari, Amiga, et Macintosh), MIPS et PowerPC. Le noyau 2.2
954 reconnaît de nouvelles architectures, comme ARM et UltraSPARC. Puisque Linux
955 reconnaît ces architectures, le projet Debian a décidé qu'il devait également les
956 accepter. C'est pourquoi plusieurs portages sont en cours ; en fait, il y
957 a aussi des portages vers d'autres noyaux non-Linux. À côté d'<em>i386</em> (notre nom
958 pour Intel x86), nous avons, au moment où j'écris, <em>m68k</em>,
959 <em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
960 <em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>, <em>mips</em>,
961 <em>mipsel</em> et <em>sh</em>.
963 &debian-formal; 1.3 est disponible uniquement pour <em>i386</em>. Debian 2.0
964 reconnaît les architectures <em>i386</em> et <em>m68k</em>. Debian 2.1 reconnaît
965 les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et
966 <em>sparc</em>. Debian 2.2 accepte en plus les architectures
967 <em>powerpc</em> et <em>arm</em>. Debian 3.0 accepte cinq
968 nouvelles architectures : <em>ia64</em>, <em>hppa</em>, <em>s390</em>,
969 <em>mips</em> et <em>mipsel</em>.
971 Pour chaque portage, vous trouverez des informations destinées aux développeurs
972 et utilisateurs sur la page <url id="&url-debian-ports;" name="Portage
977 Il existe deux types de paquets Debian : les paquets sources et les paquets
980 Les paquets sources sont constitués de deux ou trois fichiers : un fichier
981 <file>.dsc</file> et soit un fichier <file>.tar.gz</file>, soit un fichier
982 <file>.orig.tar.gz</file> et un fichier <file>.diff.gz</file>.
984 Si un paquet est développé spécifiquement pour le projet Debian et n'est pas
985 distribué en dehors de Debian, il n'y a qu'un fichier <file>.tar.gz</file> qui
986 contient les sources du programme. Si un paquet est distribué ailleurs, le
987 fichier <file>.orig.tar.gz</file> contient ce que l'on appelle <em>code source
988 amont</em>, c'est-à-dire, le code source distribué par le <em>mainteneur
989 amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le fichier
990 <file>.diff.gz</file> contient les modifications faites par le responsable
993 Le fichier <file>.dsc</file> liste tous les fichiers sources avec leurs sommes
994 de contrôle (<prgn>md5sums</prgn>) et quelques informations supplémentaires
995 concernant le paquet (responsable, version, etc.).
997 <sect1>Les distributions
999 L'organisation des répertoires présentée précédemment est elle-même englobée par
1000 les <em>répertoires des distributions</em>. Chaque distribution est incluse
1001 dans le répertoire <file>pool</file> à la racine de l'archive Debian.
1003 Pour résumer, une archive Debian a un répertoire racine sur un serveur FTP. Par
1004 exemple, sur le site miroir <ftpsite>ftp.us.debian.org</ftpsite>, l'archive
1005 Debian se trouve dans <ftppath>/debian</ftppath> ce qui est un emplacement
1006 courant. Un autre emplacement courant est <file>/pub/debian</file>.
1008 Une distribution est composée de paquets sources et binaires et des
1009 fichiers <file>Sources</file> et <file>Packages</file> correspondants qui
1010 contiennent toutes les méta-informations sur les paquets. Les premiers sont
1011 conservés dans le répertoire <file>pool/</file> tandis que les seconds sont
1012 conservés dans le répertoire <file>dists/</file> de l'archive (pour
1013 compatibilité descendante).
1015 <sect2 id="sec-dists"><em>Stable</em>, <em>testing</em> et
1018 Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire
1019 <file>dists/stable</file>), une distribution appelée <em>testing</em> (dans le
1020 répertoire <file>dists/testing</file>) et une distribution appelée
1021 <em>unstable</em> (dans le répertoire <file>dists/unstable</file>). Ceci
1022 reflète le processus de développement du projet Debian.
1024 Les développements se font sur la distribution
1025 <em>unstable</em><footnote><p><em>unstable</em> signifie
1026 « instable »</footnote> (c'est pourquoi elle est aussi appelée
1027 <em>distribution de développement</em>). Chaque développeur Debian peut
1028 modifier ses paquets à tout moment dans cette distribution. Ainsi son contenu
1029 change tous les jours. Comme aucun effort particulier n'est fait pour s'assurer
1030 que tout fonctionne correctement dans cette distribution, elle est parfois
1031 littéralement « instable ».
1033 La distribution <qref id="testing">« testing »</qref> est générée
1034 automatiquement en prenant les paquets
1035 d'<em>unstable</em> s'ils satisfont à certains critères. Ces critères
1036 garantissent que les paquets de <em>testing</em> sont de bonne qualité. La
1037 mise à jour de <em>testing</em> est lancée chaque jour après que les
1038 nouveaux paquets ont été installés. Voir <ref id="testing">.
1040 Après une période de développement, quand le responsable de
1041 distribution<footnote><p><em>Release manager</em></footnote> le juge opportun,
1042 la distribution <em>testing</em> est gelée, ce qui signifie que les conditions
1043 à remplir pour qu'un paquet passe d'<em>unstable</em> à <em>testing</em> sont
1044 durcies. Les paquets trop bogués sont supprimés et les seules mises à jours
1045 autorisées concernent les corrections de bogues. Après quelque temps, selon
1046 l'avancement, la distribution entre dans une phase de « gel complet »
1047 où les seules modifications acceptées concernent la procédure d'installation.
1048 Cette phase s'appelle un « cycle de test » et cela peut durer jusqu'à
1049 deux semaines. Il peut y avoir plusieurs cycles de tests avant que le
1050 responsable de distribution ne la déclare prête pour la diffusion. À la fin du
1051 dernier cycle de test, la distribution <em>frozen</em> devient <em>stable</em>,
1052 remplaçant l'ancienne distribution <em>stable</em> qui est enlevée à cette
1053 occasion (elle peut être retrouvée à l'adresse <tt>&archive-host;</tt>).
1055 Ce cycle de développement est basé sur l'idée que la distribution
1056 <em>unstable</em> devient <em>stable</em> après une période de test
1057 (<em>testing</em>). Une distribution contient inévitablement des bogues, même
1058 si elle est classée stable. C'est pourquoi les distributions stables sont mises
1059 à jour de temps en temps. Les corrections introduites sont testées avec une
1060 grande attention et sont ajoutées une à une à l'archive pour diminuer les
1061 risques d'introduire de nouveaux bogues. Vous pouvez trouver des paquets
1062 proposés pour les mises à jour de <em>stable</em> dans le répertoire
1063 <file>proposed-updates</file>. De temps en temps, les paquets de ce répertoire
1064 qui ne présentent pas de problème sont installés dans la distribution
1065 <em>stable</em> et le numéro de révision de cette distribution est incrémenté
1066 (« 3.0 » devient « 3.0r1 », « 2.0r4 » devient
1067 « 2.0r5 » et ainsi de suite).
1069 Notez que, pendant la période de gel, les développements continuent sur la
1070 distribution <em>unstable</em> car cette distribution reste en place.
1073 <heading>Informations complémentaires sur la distribution
1074 « testing »</heading>
1076 Les paquets sont habituellement installés dans la distribution <em>testing</em>
1077 après avoir atteint un certain degré de test dans <em>unstable</em>.
1079 Pour plus de détails, veuillez consulter les <qref id="testing">informations à
1080 propos de la distribution <em>testing</em></qref>.
1082 <sect2 id="experimental">Experimental
1084 La distribution <em>experimental</em> est une distribution particulière. Ce n'est
1085 pas une distribution à part entière comme le sont <em>stable</em> et
1086 <em>unstable</em>. Elle est prévue pour servir de plate-forme de
1087 développement pour les projets expérimentaux qui risquent vraiment de
1088 détruire le système ou bien pour des logiciels qui sont vraiment trop
1089 instables pour être inclus dans la distribution <em>unstable</em> (mais pour
1090 lesquels une mise en paquet est justifiée). Les utilisateurs qui téléchargent
1091 et installent des paquets depuis <em>experimental</em> sont prévenus :
1092 on ne peut pas faire confiance à la distribution <em>experimental</em>.
1094 Voici les lignes de <manref name="sources.list" section="5"> pour
1095 <em>experimental</em> :
1097 deb http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
1098 deb-src http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
1101 Si un logiciel peut causer des dégats importants, il sera sûrement
1102 préférable de le mettre dans la distribution <em>experimental</em>. Un
1103 système de fichiers compacté expérimental, par exemple, devrait probablement
1104 aller dans <em>experimental</em>.
1106 Une nouvelle version amont qui ajoute de nouvelles fonctions tout en supprimant
1107 de nombreuses autres ne devra pas être téléchargée dans l'archive Debian,
1108 elle pourra cependant être téléchargée dans <em>experimental</em>. Une
1109 nouvelle version non finalisée d'un logiciel qui utilise une méthode de
1110 configuration complètement différente pourrait aller dans
1111 <em>experimental</em> au gré du responsable. Si vous travaillez sur un cas de
1112 mise à jour complexe ou incompatible, vous pouvez aussi utiliser
1113 <em>experimental</em> comme plate-forme d'intégration et ainsi fournir un
1116 Quelques logiciels expérimentaux peuvent cependant aller dans <em>unstable</em>,
1117 avec un avertissement dans la description, mais ce n'est pas recommandé car
1118 les paquets d'<em>unstable</em> se propagent dans <em>testing</em> et
1119 aboutissent dans <em>stable</em>. Vous ne devriez pas avoir peur d'utiliser
1120 <em>experimental</em> car ceci ne cause aucun souci aux ftpmasters, les
1121 paquets expérimentaux sont automatiquement enlevés quand vous envoyez le
1122 paquet dans <em>unstable</em> avec un numéro de version supérieur.
1124 Un nouveau logiciel qui ne risque pas d'endommager le système ira directement
1125 dans <em>unstable</em>.
1127 Une solution de rechange à <em>experimental</em> consiste à utiliser vos pages
1128 personnelles sur le serveur <tt>people.debian.org</tt>.
1130 Veuillez considérer l'utilisation de l'option <tt>-v</tt> de
1131 <prgn>dpkg-buildpackage</prgn> si l'envoi d'un paquet dans <em>unstable</em> ferme
1132 finalement des bogues qui ont d'abord été corrigés dans <em>experimental</em>.
1134 <sect1 id="codenames">Les noms de distribution
1136 Chaque distribution Debian diffusée a un <em>nom de code</em> : Debian 1.1
1137 s'appelle « buzz » ; Debian 1.2, « rex » ; Debian
1138 1.3, « bo » ; Debian 2.0, « hamm » ; Debian 2.1,
1139 « slink »; Debian 2.2, « potato » et Debian 3.0,
1140 « woody ». Il y a aussi une pseudo-distribution nommée
1141 « sid », il s'agit de la distribution <em>unstable</em> ; comme
1142 les paquets vont d'<em>unstable</em> à <em>testing</em> quand ils approchent
1143 de la stabilité, la distribution « sid » n'est jamais diffusée. En
1144 plus du contenu habituel d'une distribution Debian, « sid » contient
1145 des paquets pour des architectures qui ne sont pas encore officiellement
1146 reconnues ou pour lesquelles la distribution n'a pas encore été diffusée. Ces
1147 architectures seront intégrées ultérieurement à la distribution principale.
1149 Comme Debian est un projet de développement ouvert (i.e. tout le monde peut
1150 participer et suivre les développements), même les distributions
1151 <em>unstable</em> et <em>testing</em> sont disponibles sur les serveurs HTTP et
1152 FTP de Debian. Si nous avions nommé le répertoire qui contient la prochaine
1153 distribution à diffuser « testing », il aurait fallu changer son nom en
1154 « stable » au moment de la diffusion, ce qui aurait forcé les miroirs
1155 FTP à télécharger à nouveau la distribution complète (qui est plutôt volumineuse).
1157 D'un autre côté, si une distribution s'appelait <em>Debian-x.y</em> dès le
1158 départ, des personnes pourraient s'imaginer que la distribution Debian
1159 <em>x.y</em> est disponible. (Cela s'est produit par le passé, un distributeur
1160 avait gravé des cédéroms Debian 1.0 en utilisant une version de développement
1161 pré-1.0. C'est pour cette raison que la première version officielle était la
1162 version 1.1 et non la 1.0).
1164 En conséquence, les noms de répertoire des distributions dans l'archive sont
1165 déterminés par leur nom de code et non par leur statut (exemple :
1166 slink). Ces noms sont identiques pendant la période de développement et une
1167 fois la distribution diffusée ; des liens symboliques, qui peuvent être
1168 modifiés facilement, indiquent la distribution stable actuelle. Tout ceci
1169 explique pourquoi les répertoires des distributions sont nommés à partir des
1170 noms de code des distributions alors que <em>stable</em>, <em>testing</em> et
1171 <em>unstable</em> sont des liens symboliques qui pointent vers les répertoires
1175 <sect id="mirrors">Les miroirs Debian
1177 Les différentes archives de téléchargement et le site web disposent de plusieurs
1178 miroirs pour soulager les serveurs principaux d'une lourde charge. En fait,
1179 certains de ces serveurs ne sont pas publics — la charge est
1180 répartie sur une première série de serveurs. De cette façon, les
1181 utilisateurs ont toujours accès aux miroirs et s'y habituent, ce qui permet à
1182 Debian de mieux répartir les besoins en bande passante sur plusieurs serveurs et
1183 plusieurs réseaux différents et évitent aux utilisateurs de surcharger
1184 l'emplacement primaire. Notez que, dans cette première série, les serveurs sont aussi à jour
1185 que possible car la mise à jour est déclenchée par les sites maîtres internes.
1187 Toutes les informations sur les miroirs Debian peuvent être trouvées à <url
1188 id="&url-debian-mirrors;">, y compris une liste des miroirs publics disponibles
1189 FTP/HTTP. Cette page utile inclut également des informations et des outils pour
1190 créer son propre miroir, soit en interne soit pour un accès public.
1192 Les miroirs sont en général mis en œuvre par des tiers qui veulent aider
1193 Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces
1197 <sect id="incoming-system">
1198 <heading>Le système Incoming
1200 Le système Incoming est responsable de la collecte des paquets mis à jour et de
1201 leur installation dans l'archive Debian. Il est constitué d'un ensemble de
1202 répertoires et de scripts qui sont installés à la fois sur
1203 <tt>&ftp-master-host;</tt> et sur <tt>&non-us-host;</tt>.
1205 Les paquets sont envoyés par tous les responsables Debian dans un répertoire
1206 nommé <file>unchecked</file>. Ce répertoire est parcouru toutes les 15 minutes
1207 par le script <prgn>katie</prgn> qui vérifie l'intégrité des paquets envoyés et
1208 leurs signatures de chiffrage. Si le paquet est considéré comme prêt à être
1209 installé, il est déplacé dans le répertoire <file>accepted</file>. S'il s'agit
1210 du premier envoi du paquet, il est déplacé dans le répertoire <file>new</file>
1211 où il attend l'approbation des ftpmasters. Si le paquet contient des fichiers
1212 devant être installés <em>à la main</em>, il est déplacé dans le répertoire
1213 <file>byhand</file> où il attend une installation manuelle par les ftpmasters.
1214 Sinon, si une erreur a été détectée, le paquet est refusé et il est déplacé
1215 dans le répertoire <file>reject</file>.
1217 Une fois que le paquet est accepté, le système envoie une confirmation par
1218 courrier au responsable et ferme les bogues corrigés par l'envoi, puis
1219 les compilateurs automatiques peuvent commencer la recompilation. Le paquet est
1220 maintenant accessible publiquement à <url id="&url-incoming;"> (une telle
1221 adresse n'existe pas pour les paquets de l'archive non-US) jusqu'à ce qu'il
1222 soit vraiment installé dans l'archive Debian. Ceci se produit seulement une
1223 fois par jour, le paquet est alors supprimé de <file>Incoming</file> et
1224 installé dans le pool avec les autres paquets. Une fois que toutes les autres
1225 mises à jour (fabrication des nouveaux fichiers d'index <file>Packages</file> et
1226 <file>Sources</file> par exemple) ont été effectuées, un script spécial est
1227 appelé pour demander aux miroirs primaires de se mettre à jour.
1229 Le logiciel de maintenance de l'archive enverra également le fichier
1230 <file>.changes</file> signé avec OpenPGP/GnuPG que vous avez envoyé, à la liste
1231 de diffusion appropriée. Si un paquet est diffusé avec le champ
1232 <tt>Distribution:</tt> positionné à « stable », l'annonce sera envoyée
1233 à &email-debian-changes;. Si un paquet est diffusé avec le champ
1234 <tt>Distribution:</tt> positionné à « unstable » ou
1235 « experimental », l'annonce sera à la place envoyée à
1236 &email-debian-devel-changes;.
1238 Tous les développeurs Debian ont un droit d'écriture dans le répertoire
1239 <file>unchecked</file> pour pouvoir y envoyer leurs paquets, ils ont également
1240 accès au répertoire <file>reject</file> pour supprimer les mauvais envois ou
1241 déplacer certains fichiers dans le répertoire <file>unchecked</file>. Mais
1242 seuls les ftpmasters ont droit d'écriture dans les autres répertoires.
1243 C'est pourquoi vous ne pouvez pas supprimer un envoi une fois qu'il a été
1246 <sect1 id="delayed-incoming-broken">Incoming différé
1248 <em>Note :</em> la description présentée ici ne fonctionne pas
1249 car ftp-master est à accès restreint. Veuillez vous reporter à <ref
1250 id="delayed-incoming"> pour la façon actuelle de faire.
1252 Le répertoire <file>unchecked</file> comprend un sous-répertoire spécial,
1253 <file>DELAYED</file><footnote>Différé en anglais</footnote>. Celui-ci est
1254 lui-même subdivisé en neuf répertoires nommés <file>1-day</file> à
1255 <file>9-day</file>. Les paquets qui sont envoyés dans l'un de ces
1256 répertoires seront déplacés dans le vrai répertoire <file>unchecked</file>
1257 après le nombre correspondant de jours. Un script, exécuté chaque jour,
1258 déplace les paquets entre les répertoires. Ceux
1259 qui sont dans « 1-day » sont installés dans
1260 <file>unchecked</file> alors que les autres sont déplacés dans le
1261 répertoire adjacent (par exemple, un paquet dans <file>5-day</file> sera
1262 déplacé dans <file>4-day</file>). Cette fonctionnalité est particulièrement
1263 utile pour les personnes qui effectuent des mises à jour indépendantes
1264 (NMU, « non-maintainer uploads »). Au lieu d'attendre avant
1265 d'envoyer la NMU, elle est envoyée dès qu'elle est prête dans l'un de ces
1266 répertoires <file>DELAYED/<var>x</var>-day</file>. Ceci laisse le nombre
1267 correspondant de jours au responsable pour réagir et envoyer lui-même une
1268 autre correction s'il n'est pas complètement satisfait par la NMU. Il peut
1269 également enlever complètement la NMU.
1271 L'utilisation de ce délai peut être simplifiée en
1272 l'intégrant à votre outil d'envoi. Par exemple, si vous utilisez
1273 <prgn>dupload</prgn> (voir <ref id="dupload">), vous pouvez ajouter cette
1274 partie à votre fichier de configuration :
1276 $delay = ($ENV{DELAY} || 7);
1278 fqdn => "&ftp-master-host;",
1279 login => "yourdebianlogin",
1280 incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/",
1284 Une fois que vous avez fait ce changement, <prgn>dupload</prgn> peut être
1285 utilisé pour envoyer facilement dans l'un des répertoires de délai ainsi :
1286 <example>DELAY=5 dupload --to delayed <changes-file></example>
1289 <sect id="pkg-info">Informations sur un paquet
1292 <sect1 id="pkg-info-web">Sur le web
1294 Chaque paquet a plusieurs pages web dédiées.
1295 <tt>http://&packages-host;/<var>nom-paquet</var></tt> affiche chaque version
1296 du paquet disponible dans les différentes distributions. Les informations
1297 détaillées par version incluent la description du paquet, les dépendances et
1298 des liens pour récupérer le paquet.
1300 Le système de suivi des bogues trie les bogues par paquet. Vous pouvez regarder
1301 les bogues de chaque paquet à
1302 <tt>http://&bugs-host;/<var>nom-paquet</var></tt>.
1304 <sect1 id="madison">L'outil <prgn>madison</prgn>
1306 <prgn>madison</prgn> est un outil en ligne de commande qui est disponible sur
1307 <tt>&ftp-master-host;</tt> et sur <tt>&non-us-host;</tt>. Il utilise un seul
1308 argument qui correspond au nom du paquet. Il affiche comme résultat quelle
1309 version du paquet est disponible pour chaque combinaison d'architecture et de
1310 distribution. Un exemple l'expliquera mieux.
1313 $ madison libdbd-mysql-perl
1314 libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
1315 libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
1316 libdbd-mysql-perl | 1.2216-2.0.1| testing | alpha
1317 libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc</example>
1319 Dans cet exemple, vous pouvez voir que la version dans <em>unstable</em> diffère
1320 de celle de <em>testing</em> et qu'il y a eu une NMU binaire seulement pour
1321 l'architecture alpha. À chaque fois, le paquet a été recompilé sur la plupart
1325 <sect id="pkg-tracking-system">Système de suivi des paquets
1327 Le système de suivi des paquets (PTS)<footnote>« Package Tracking
1328 System »</footnote> est un outil pour suivre par courrier l'activité
1329 concernant un paquet source. Cela veut vraiment dire que vous pourrez recevoir
1330 les mêmes courriers que le responsable, simplement en vous inscrivant au paquet
1333 Chaque courrier envoyé par le PTS est classé sous l'un des mots-clés
1334 listés ci-dessous. Ceci vous permettra de sélectionner les courriers que vous
1337 Par défaut, vous recevrez :
1340 <item>Tous les rapports de bogue et les discussions qui
1343 <tag><tt>bts-control</tt>
1344 <item>Les courriers de notification de <email>control@bugs.debian.org</email>
1345 sur les changement d'état de l'un des rapports de bogue.
1347 <tag><tt>upload-source</tt>
1348 <item>Le courrier de notification de <prgn>katie</prgn> quand un paquet
1349 source envoyé a été accepté.
1351 <tag><tt>katie-other</tt>
1352 <item>Les autres courriers d'avertissement et d'erreur de
1353 <prgn>katie</prgn> (comme une incohérence de passage en force pour les champs
1354 section ou priorité).
1356 <tag><tt>default</tt>
1357 <item>Tout courrier non automatique envoyé au PTS par les personnes qui
1358 veulent contacter les inscrits au paquet. Ceci peut être fait en
1359 envoyant un courrier à <tt><var>paquet-source</var>@&pts-host;</tt>. Pour
1360 prévenir l'envoi de spam, tous les courriers envoyés à ces adresses doivent
1361 contenir l'en-tête <tt>X-PTS-Approved</tt> avec une valeur non vide.
1363 <tag><tt>summary</tt>
1364 <item>(Ceci est une extension prévue).
1365 Les courriers de résumé réguliers sur l'état du paquet (statistiques sur
1366 les bogues, vue générale du portage, progression dans <em>testing</em>,
1371 Vous pouvez également décider de recevoir des informations supplémentaires :
1373 <tag><tt>upload-binary</tt>
1374 <item>Le courrier d'information de <prgn>katie</prgn> quand un paquet
1375 binaire envoyé est accepté. En d'autres termes, à chaque fois qu'un
1376 démon de compilation ou un porteur envoie votre paquet pour une autre
1377 architecture, vous recevez un courrier pour suivre comment votre paquet
1378 est recompilé pour toutes les architectures.
1381 <item>Les notifications de modifications CVS<footnote><p><em>CVS
1382 commits</em></footnote> si le responsable a mis en place un système pour
1383 faire suivre les notifications de modifications vers le PTS.
1386 <item>Les traductions des descriptions ou des questionnaires debconf soumis
1387 au Projet de traduction des descriptions de paquets
1388 Debian<footnote><p><em>Debian Description Translation Project,
1389 DDTP</em></footnote>.
1393 <sect1 id="pts-commands">L'interface de courrier du PTS
1395 Vous pouvez contrôler votre (vos) inscription(s) au PTS en envoyant différents
1396 commandes à <email>pts@qa.debian.org</email>.
1399 <tag><tt>subscribe <paquet source> [<adresse>]</tt>
1400 <item>Inscrit <var>adresse</var> aux communications liées au paquet source
1401 <var>paquet source</var>. L'adresse de l'expéditeur est utilisée si le
1402 second argument n'est pas présent. Si <var>paquet source</var> n'est pas
1403 un paquet source valide, vous obtiendrez un avertissement. Cependant,
1404 s'il s'agit d'un paquet binaire valide, le PTS vous inscrira pour le
1405 paquet source correspondant.
1407 <tag><tt>unsubscribe <paquet source> [<adresse>]</tt>
1408 <item>Supprime une inscription précédente au paquet source
1409 <var>paquet source</var> en utilisant l'adresse spécifiée ou l'adresse de
1410 l'expéditeur si le second argument n'est pas rempli.
1412 <tag><tt>which [<adresse>]</tt>
1413 <item>Liste les inscriptions pour l'expéditeur ou pour l'adresse indiquée
1414 si elle est spécifiée.
1416 <tag><tt>keyword [<adresse>]</tt>
1417 <item>Donne les mots-clés que vous acceptez. Pour une explication des ces
1418 mots-clés, <qref id="pkg-tracking-system">voir ci-dessus</qref>. Voici
1419 un rapide résumé :
1421 <item><tt>bts</tt> : courriers venant du système de gestion de bogues (BTS) Debian
1422 <item><tt>bts-control</tt> : réponses aux courriers envoyés à
1423 &bugs-host;&email-bts-control;
1424 <item><tt>summary</tt> : courriers de résumé automatique sur l'état
1426 <item><tt>cvs</tt> : notifications de modifications CVS
1427 <item><tt>ddtp</tt> : traductions des descriptions et
1428 questionnaires debconf
1429 <item><tt>upload-source</tt> : annonce d'un nouvel envoi de paquet
1430 source qui a été accepté
1431 <item><tt>upload-binary</tt> : annonce d'un nouvel envoi de binaire
1433 <item><tt>katie-other</tt> : autres courriers des ftpmasters
1434 (incohérence de passage en force, etc.)
1435 <item><tt>default</tt> : tous les autres courriers (ceux qui ne sont
1439 <tag><tt>keyword <paquet source> [<adresse>]</tt>
1440 <item>Identique à l'élément précédent, mais pour un paquet source donné
1441 car vous pouvez sélectionner un ensemble de mots-clés différent pour
1442 chaque paquet source.
1444 <tag><tt>keyword [<adresse>] {+|-|=} <liste de mots-clés></tt>
1445 <item>Accepte (+) ou refuse (-) les courriers classés sous le(s) mot(s)-clé(s).
1446 Définit la liste (=) des mots-clés acceptés.
1448 <tag><tt>keyword <paquet source> [<adresse>] {+|-|=} <liste de mots-clés></tt>
1449 <item>Identique à l'élément précédent, mais remplace la liste des mots-clés
1450 pour le paquet source indiqué.
1452 <tag><tt>quit | thanks | --</tt>
1453 <item>Arrête le traitement des commandes. Toutes les lignes suivantes sont
1454 ignorées par le robot.
1457 <sect1 id="pts-mail-filtering">Filtrer les courriers du PTS
1459 Une fois que vous vous êtes inscrit à un paquet, vous recevrez les courriers
1460 envoyés à <tt><var>paquet source</var>@packages.qa.debian.org</tt>. Ces courriers
1461 ont des en-têtes spéciaux ajoutés pour vous permettre de les filtrer dans des
1462 boîtes aux lettres (par exemple, avec <prgn>procmail</prgn>). Les en-têtes ajoutés sont
1463 <tt>X-Loop</tt>, <tt>X-PTS-Package</tt>, <tt>X-PTS-Keyword</tt> et
1464 <tt>X-Unsubscribe</tt>.
1466 Voici un exemple d'en-têtes ajoutés pour une notification d'envoi de
1467 source sur le paquet <package>dpkg</package> :
1469 X-Loop: dpkg@&pts-host;
1471 X-PTS-Keyword: upload-source
1472 X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
1475 <sect1 id="pts-cvs-commit">Faire suivre les modifications de CVS vers le PTS
1477 Si vous utilisez un référentiel CVS accessible publiquement pour maintenir votre
1478 paquet Debian, vous pouvez vouloir faire suivre les notifications de
1479 modifications vers le PTS pour que les inscrits (ainsi que des possibles
1480 co-responsables) puissent suivre de près l'évolution du paquet.
1482 Une fois que votre référentiel génère des notifications de modifications, vous
1483 devez simplement vous assurer qu'il envoie une copie de tous ces courriers à
1484 <tt><var>paquet source</var>_cvs@&pts-host;</tt>. Seules les personnes qui ont
1485 accepté le mot-clé <em>cvs</em> recevront les notifications.
1487 <sect1 id="pts-web">L'interface web du PTS
1489 Le PTS possède une interface web à <url id="http://&pts-host;/"> qui réunit
1490 beaucoup d'informations au
1491 même endroit à propos de chaque paquet source. Il propose plusieurs liens utiles
1492 (BTS, statistiques QA, informations de contact, état de traduction DDTP,
1493 journaux de compilation automatique) et il regroupe beaucoup d'autres informations
1494 provenant de différents endroits (les 30 dernières entrées de changelog, l'état
1495 dans <em>testing</em>, etc.). Il s'agit d'un outil très pratique si vous désirez
1496 connaître ce qu'il en est d'un paquet source spécifique. De plus, il y a un
1497 formulaire qui permet de facilement s'inscrire au PTS par courrier.
1499 Vous pouvez aller directement à la page web concernant un paquet source avec une
1500 URL comme <tt>http://&pts-host;/<var>paquet source</var></tt>.
1502 Cette interface a été conçue comme un portail pour le développements des
1503 paquets : vous pouvez ajouter du contenu personnalisé aux pages de vos
1504 paquets. Vous pouvez ajouter des « informations
1505 statiques »<footnote><em>Static information</em></footnote> (des annonces
1506 qui sont destinées à rester disponibles indéfiniment) et des nouvelles dans la
1507 section « dernières nouvelles »<footnote><em>Latest
1508 news</em></footnote>.
1510 Les annonces statiques peuvent être utilisées pour indiquer :
1512 <item>la disponibilité d'un projet hébergé sur <qref id="alioth">Alioth</qref> pour la
1513 co-maintenance du paquet,
1514 <item>un lien vers le site web amont,
1515 <item>un lien vers le suivi de bogues amont,
1516 <item>l'existence d'un canal IRC dédié au logiciel,
1517 <item>toute autre ressource disponible qui peut être utile à la maintenance du paquet.
1519 Les nouvelles usuelle peuvent être utilisées pour annoncer que :
1521 <item>des paquets bêta sont disponibles pour test,
1522 <item>des paquets finaux sont attendus pour la semaine prochaine,
1523 <item>l'empaquetage est sur le point d'être intégralement refait,
1524 <item>des rétroportages sont disponibles,
1525 <item>le responsable est en vacance (s'il désire publier cette information),
1526 <item>une mise à jour indépendante (NMU) est en cours de réalisation,
1527 <item>quelque chose d'important va affecter le paquet.
1530 Les deux types d'informations sont fabriqués de façon similaire : il vous
1531 suffit d'envoyer un courrier soit à <email>pts-static-news@qa.debian.org</email>
1532 (pour les annonces statiques), soit à <email>pts-news@qa.debian.org</email>
1533 (pour les nouvelles usuelles). Le courrier devrait indiquer quel paquet est
1534 concerné par la nouvelle en donnant le nom du paquet source dans un en-tête de
1535 courrier <tt>X-PTS-Package</tt> ou dans un pseudo-en-tête <tt>Package</tt>
1536 (comme pour les rapports de bogue du BTS). Si une URL est disponible dans
1537 l'en-tête de courrier <tt>X-PTS-Url</tt> ou dans un pseudo-en-tête <tt>Url</tt>,
1538 le résultat est un lien vers cette URL au lieu d'une nouvelle complète.
1540 Voici quelques exemples de courriers valides utilisés pour générer des nouvelles dans
1541 le PTS. Le premier ajoute un lien vers l'interface cvsweb de debian-cd dans la
1542 section « Informations statiques » :
1544 From: Raphael Hertzog <hertzog@debian.org>
1545 To: pts-static-news@qa.debian.org
1546 Subject: Browse debian-cd CVS repository with cvsweb
1549 Url: http://cvs.debian.org/debian-cd/
1552 Le second est une annonce envoyée à une liste de diffusion et également
1553 envoyée au PTS pour qu'elle soit publiée sur la page web du PTS du paquet. Notez
1554 l'utilisation du champ BCC pour éviter que des réponses ne soient envoyées par
1557 From: Raphael Hertzog <hertzog@debian.org>
1558 To: debian-gtk-gnome@lists.debian.org
1559 Bcc: pts-news@qa.debian.org
1560 Subject: Galeon 2.0 backported for woody
1561 X-PTS-Package: galeon
1565 I'm glad to announce that galeon has been backported for woody. You'll find
1570 Réfléchissez-y à deux fois avant d'ajouter une nouvelle au PTS car vous ne
1571 pourrez pas l'enlever par la suite et vous ne pourrez pas non plus l'éditer. La
1572 seule chose que vous puissiez faire est d'envoyer une deuxième nouvelle qui va
1573 déprécier l'information contenue dans la précédente.
1575 <sect id="ddpo">Vue d'ensemble des paquets d'un développeur
1577 Un portail web pour l'Assurance Qualité (QA) est disponible à <url
1578 id="&url-ddpo;"> qui affiche un tableau de tous les paquets d'un
1579 développeur (y compris ceux pour lequel il est co-responsable). Le tableau donne
1580 un bon résumé sur les paquets d'un développeur : nombre de bogues par
1581 gravité, liste des versions disponibles, état des tests et des liens vers
1582 d'autres informations utiles.
1584 C'est une bonne idée de vérifier régulièrement vos données pour ne pas oublier
1585 de bogues ouverts et pour ne pas oublier quels paquets sont sous votre
1588 <sect id="alioth">Debian *Forge : Alioth
1590 Alioth est un service de Debian plutôt récent, basé sur une version
1591 légèrement modifiée du logiciel GForge (qui a évolué à partir de
1592 SourceForge). Ce logiciel offre aux développeurs l'accès à des outils
1593 faciles d'utilisation comme un un gestionnaire de suivi de bogues, un
1594 gestionnaire de correctifs, un gestionnaire de tâches et de projets,
1595 un service d'hébergement de fichiers, des listes de diffusion, des
1596 dépôts CVS, etc. Tous ces outils sont gérés par une interface web.
1598 Alioth est destiné à fournir des facilités pour des projets de logiciels
1599 soutenus ou dirigés par Debian, à faciliter les contributions de développeurs
1600 externes aux projets initiés par Debian et à aider des projets dont les buts
1601 sont de promouvoir Debian ou ses dérivés.
1603 Pour plus d'informations, veuillez visiter <url id="&url-alioth;">.
1605 <chapt id="pkgs">Gestion des paquets
1607 Ce chapitre contient des informations relatives à la création, l'envoi, la
1608 maintenance et le portage des paquets.
1611 <sect id="newpackage">Nouveaux paquets
1613 Si vous voulez créer un nouveau paquet pour la distribution Debian, vous devriez
1614 commencer par consulter la liste des <url id="&url-wnpp;" name="paquets en
1615 souffrance et paquets souhaités">. Vous pourrez ainsi vérifier que personne ne
1616 travaille déjà sur ce paquet et éviter un double travail. Consultez aussi cette
1617 page si vous voulez en savoir plus.
1619 Supposons que personne ne travaille sur le paquet que vous visez, vous devez
1620 alors envoyer un rapport de bogue (voir <ref id="submit-bug">) concernant le
1621 pseudo-paquet <package>wnpp</package>. Ce courrier devra décrire le paquet que
1622 vous projetez de créer, la licence de ce paquet et l'URL à laquelle le source
1623 peut être téléchargé. Cette liste n'est pas limitative.
1625 Le sujet de votre rapport de bogue devra être <ITP<footnote><p><em>Intent To
1626 Package</em> : intention d'empaquetage</footnote> :
1627 <var>NomDuPaquet</var> — <var>courte description</var>>, en remplaçant
1628 <var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera
1629 <em>wishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
1630 &email-debian-devel; en mettant cette adresse dans le champ
1631 <tt>X-Debbugs-CC:</tt> de l'en-tête du message. N'utilisez pas le champ
1632 <tt>CC:</tt> car de cette manière le sujet du message ne contiendrait pas le
1635 Il faudra aussi ajouter une entrée <tt>Closes: bug#<var>nnnnn</var></tt> dans le
1636 fichier <file>changelog</file> du nouveau paquet. Cette indication fermera
1637 automatiquement le rapport de bogue à l'installation du nouveau paquet sur les
1638 serveurs d'archivage (voir <ref id="upload-bugfix">).
1640 Plusieurs raisons nous poussent à demander aux responsables
1641 d'annoncer leur intention :
1643 <item>Les responsables ont ainsi la possibilité de puiser dans l'expérience
1644 des autres responsables et cela leur permet de savoir si une autre
1645 personne travaille déjà dessus.
1646 <item>D'autres personnes qui envisagent de travailler sur le même paquet
1647 apprendront ainsi qu'il existe déjà un volontaire, l'effort peut alors
1649 <item>Cela permet aux autres responsables de connaître le nouveau
1650 paquet mieux que ne le permettent la description d'une ligne et l'habituelle
1651 entrée de type changelog <em>Initial release</em> postée sur
1652 <tt>debian-devel-changes</tt>.
1653 <item>C'est une information utile pour
1654 les gens qui utilisent la distribution <em>unstable</em> et qui sont nos
1655 premiers testeurs. Nous devons faciliter la tâche de ces gens.
1656 <item>Avec ces annonces, les développeurs Debian et toutes les autres personnes
1657 intéressées peuvent se faire une meilleure idée des évolutions et des
1658 nouveautés du projet.
1662 <sect id="changelog-entries">Enregistrer les modifications dans le paquet
1664 Les modifications que vous apportez au paquet doivent être notifiées dans le
1665 fichier <file>debian/changelog</file>. Ces notes doivent donner une
1666 description concise des changements, expliquer les raisons de ceux-ci (si
1667 ce n'est pas clair) et indiquer si des rapports de bogue ont été clos. Il
1668 faut aussi indiquer quand le paquet a été terminé. Ce fichier sera
1670 <file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
1671 <file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un paquet
1674 Le fichier <file>debian/changelog</file> a une structure précise comportant
1675 différents champs. Le champ <em>distribution</em> est décrit dans <ref
1676 id="distribution">. Vous trouverez plus d'informations sur la structure de ce
1677 fichier dans la section « <file>debian/changelog</file> » de la
1678 <em>charte Debian</em>.
1680 Les entrées du fichier <file>changelog</file> peuvent être
1681 utilisées pour fermer des rapports de bogue au moment où le paquet est
1682 installé dans l'archive. Voir la section <ref id="upload-bugfix">.
1684 Par convention, l'entrée changelog d'un paquet contenant une nouvelle version
1685 amont ressemble à :
1687 * new upstream version
1690 Quelques outils peuvent vous aider à créer des entrées et à finaliser le fichier
1691 <file>changelog</file> pour une livraison — voir les sections <ref
1692 id="devscripts"> et <ref id="dpkg-dev-el">.
1694 Voir aussi <ref id="bpp-debian-changelog">.
1697 <sect id="sanitycheck">Tester le paquet
1699 Avant d'envoyer votre paquet, vous devriez faire quelques tests de base. Vous
1700 devriez au moins faire les tests suivants (il vous faut une ancienne version
1703 <item>Installez le paquet et vérifiez que le logiciel fonctionne. Si le
1704 paquet existait déjà dans une version plus ancienne, faites une mise à
1706 <item>Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
1707 <prgn>lintian</prgn> comme suit : <tt>lintian -v
1708 <var>version-paquet</var>.changes</tt>. Ce programme fera une
1709 vérification sur les paquets source et binaire. Si vous ne comprenez pas
1710 les messages retournés par <prgn>lintian</prgn>, essayez l'option
1711 <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
1712 bavard dans sa description du problème.
1714 En principe, un paquet pour lequel <prgn>lintian</prgn> renvoie des erreurs
1715 (elles commencent par <tt>E</tt>) <em>ne doit pas</em> être installé dans
1718 Pour en savoir plus sur <prgn>lintian</prgn>, reportez-vous à la section
1720 <item>Vous pouvez facultativement exécuter <ref id="debdiff"> pour analyser les
1721 modifications depuis une ancienne version si celle-ci existe.
1722 <item>Faites régresser le paquet vers sa version précédente si elle existe
1723 — cela permet de tester les scripts <file>postrm</file> et
1725 <item>Désinstallez le paquet et réinstallez-le.
1729 <sect id="sourcelayout">Disposition du paquet source
1731 Il existe deux types de paquets source Debian :
1733 <item>les paquets appelés <em>natifs</em> pour lesquels il
1734 n'y a pas de distinction entre les sources d'origine et les
1735 correctifs appliqués pour Debian
1736 <item>les paquets (plus courants) où il y a un fichier archive source
1737 d'origine accompagné par un autre fichier contenant les
1738 correctifs pour Debian.
1741 Pour les paquets natifs, le paquet source inclut un fichier de contrôle source
1742 Debian (<tt>.dsc</tt>) et l'archive source (<tt>.tar.gz</tt>). Un paquet source
1743 d'un paquet non natif inclut un fichier de contrôle source Debian, l'archive
1744 source d'origine (<tt>.orig.tar.gz</tt>) et les correctifs Debian
1745 (<tt>.diff.gz</tt>).
1747 Le caractère natif d'un paquet est déterminé lorsqu'il est construit par <manref
1748 name="dpkg-buildpackage" section="1">. Le reste de cette section ne se rapporte
1749 qu'aux paquets non natifs.
1752 La première fois qu'un paquet est installé dans l'archive pour une version amont
1753 donnée, le fichier <file>tar</file> de cette version amont doit être
1754 téléchargé et mentionné dans le fichier <file>.changes</file>. Par la suite,
1755 ce fichier <file>tar</file> sera utilisé pour générer les fichiers
1756 <file>diff</file> et <file>.dsc</file> et il ne sera pas nécessaire de le
1757 télécharger à nouveau.
1759 Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn>
1760 incluront le fichier <file>tar</file> amont si et seulement si le numéro de
1761 révision du paquet source est 0 ou 1, ce qui indique une nouvelle version
1762 amont. Ce comportement peut être modifié en utilisant <tt>-sa</tt> pour
1763 l'inclure systématiquement ou <tt>-sd</tt> pour ne jamais l'inclure.
1765 Si la mise à jour ne contient pas le fichier <file>tar</file> des sources
1766 originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
1767 fichiers <file>.dsc</file> et <file>diff</file> de la mise à jour, utiliser
1768 un fichier <tt>tar</tt> identique à l'octet près à celui déjà présent dans
1771 <sect id="distribution">Choisir une distribution
1773 Chaque envoi doit spécifier à quelle distribution le paquet est destiné. Le
1774 processus de construction de paquet extrait cette information à partir de la
1775 première ligne du fichier <file>debian/changelog</file> et la place dans le champ
1776 <tt>Distribution</tt> du fichier <tt>.changes</tt>.
1778 Il existe plusieurs valeurs possibles pour ce champ : « stable »,
1779 « unstable », « testing-proposed-updates » et
1780 « experimental ».
1782 En fait, il y a deux autres possibilités :
1783 « stable-security » et « testing-security », mais
1784 veuillez lire <ref id="bug-security"> pour plus d'informations sur celles-ci.
1786 Il n'est pas possible d'envoyer un paquet dans plusieurs distributions
1789 <sect1 id="upload-stable">Cas spécial : mise à jour d'un paquet de
1790 la distribution <em>stable</em>
1792 Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
1793 sera dirigé vers le répertoire <file>stable-proposed-updates</file> des
1794 archives Debian pour y être testé avant d'être effectivement inclus dans
1797 Une livraison pour la distribution <em>stable</em> requiert des soins
1798 supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
1799 que dans les cas suivants :
1801 <item>un problème fonctionnel vraiment critique,
1802 <item>un paquet devenu ininstallable,
1803 <item>un paquet indisponible pour une architecture.
1806 Par le passé, des envois vers <em>stable</em> étaient également utilisés pour
1807 corriger les problèmes de sécurité. Cependant, cette pratique est dépréciée car
1808 les envois utilisés pour les avis de sécurité Debian<footnote>Debian security
1809 advisory</footnote> sont automatiquement copiés dans l'archive
1810 <file>proposed-updates</file> appropriée quand l'avis est publié. Reportez-vous
1811 à <ref id="bug-security"> pour des informations plus détaillées sur la gestion
1812 des problèmes de sécurité.
1814 Il est fortement déconseillé de changer quoi que ce soit si ce
1815 n'est pas important car même une modification triviale peut provoquer un
1818 Les paquets livrés pour <em>stable</em> doivent être compilés avec la
1819 distribution <em>stable</em> pour que leurs dépendances se limitent aux
1820 bibliothèques (et autres paquets) disponibles dans <em>stable</em> ;
1821 un paquet livré pour la distribution <em>stable</em> qui dépend d'une
1822 bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté.
1823 Modifier les dépendances d'autres paquets (en manipulant le champ
1824 <tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
1825 ininstallables, est fortement déconseillé.
1827 L'équipe responsable de la distribution<footnote><em>the Release
1828 team</em></footnote> (joignable à l'adresse &email-debian-release;)
1829 évaluera régulièrement le contenu de <em>stable-proposed-updates</em> et
1830 décidera si votre paquet peut être inclus dans la distribution
1831 <em>stable</em>. Soyez précis (et, si nécessaire, prolixe) quand vous
1832 décrivez, dans le fichier changelog, vos changements pour une livraison
1833 vers <em>stable</em>, sinon le paquet ne sera pas pris en considération.
1835 Il est fortement conseillé de discuter avec le responsable de la version stable <em>avant</em>
1836 de réaliser un envoi dans <em>stable</em>/<em>stable-proposed-updates</em>, pour
1837 que le paquet envoyé corresponde aux besoins de la prochaine révision de <em>stable</em>.
1839 <sect1 id="upload-t-p-u">Cas spécial : mise à jour d'un paquet de la
1840 distribution <em>testing</em>/<em>testing-proposed-updates</em>
1842 Veuillez consulter les informations dans la <qref id="t-p-u">section sur
1843 <em>testing</em></qref> pour des détails.
1845 <sect id="upload">Mettre à jour un paquet
1847 <sect1 id="upload-ftp-master">Installer un paquet sur
1850 Pour installer un paquet, vous devez envoyer les fichiers (y compris les
1851 fichiers changes et dsc signés) par ftp anonyme sur
1852 <ftpsite>&ftp-master-host;</ftpsite> dans le répertoire &upload-queue;. Pour
1853 que les fichiers y soient traités, ils doivent être signés avec une clé du
1854 porte-clés (<em>keyring</em>) Debian.
1857 Attention, il est préférable de transférer le fichier
1858 <tt>changes</tt> en dernier. Dans le cas contraire, votre livraison pourrait
1859 être rejetée car l'outil de maintenance de l'archive pourrait lire le fichier
1860 <tt>changes</tt> et constater que les fichiers ne sont pas tous présents.
1862 <em>Note :</em> ne téléchargez pas sur <tt>ftp-master</tt> de paquets
1863 concernant la cryptographie qui appartiendraient à <em>contrib</em> ou <em>non-free</em>.
1864 Ces logiciels doivent aller sur <tt>non-us</tt> (voir <ref
1865 id="upload-non-us">). De plus, les paquets contenant un logiciel protégé par
1866 des brevets américains ne peuvent pas être envoyés sur
1867 <tt>ftp-master</tt> ; selon le cas, ils peuvent peut-être pourtant être
1868 envoyés vers <file>non-US/non-free</file> (le paquet est dans
1869 <em>non-free</em> à cause de problèmes de distribution et non pas à cause de
1870 la licence du logiciel). Quand vous ne pouvez télécharger sur
1871 <tt>ftp-master</tt>, vous ne pouvez pas non plus télécharger sur
1872 les sites de repli qui arrivent finalement sur <tt>ftp-master</tt>. Si vous ne savez pas si votre paquet
1873 est protégé par un brevet ou s'il est soumis aux lois de contrôle des
1874 exportations américaines, posez la question sur la liste
1875 &email-debian-devel;.
1877 Les paquets <ref id="dupload"> ou <ref id="dput"> pourront vous faciliter le
1878 travail lors du téléchargement. Ces programmes, bien pratiques, aident à
1879 automatiser le processus d'envoi de paquets vers Debian
1881 Pour supprimer des paquets, veuillez lire le fichier README dans ce répertoire
1882 FTP et le paquet Debian <ref id="dcut">.
1884 <sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
1886 <em>Note :</em> non-us n'est plus traité actuellement.
1888 Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
1889 exportations américaines ne doivent pas être installés sur
1890 <tt>ftp-master</tt>. Installez le paquet par FTP anonyme sur
1891 <ftpsite>non-us.debian.org</ftpsite> dans le répertoire &upload-queue;
1892 (<ref id="dupload"> et <ref id="dput"> avec les options adéquates peuvent
1893 tous deux être utilisés pour cela).
1895 Attention, les personnes résidant aux États-Unis et les citoyens américains sont
1896 soumis à des restrictions sur l'exportation des logiciels de cryptographie.
1897 Au moment où j'écris, les citoyens américains peuvent exporter quelques
1898 logiciels de cryptographie soumis à une obligation de déclaration auprès du
1899 département du commerce américain. Toutefois, cette restriction a été
1900 abandonnée pour des logiciels qui sont déjà disponibles en dehors des
1901 États-Unis. En conséquence, tout logiciel de cryptographie de la section
1902 <em>main</em> de l'archive Debian qui ne dépend d'aucun paquet d'une autre
1903 section — il ne doit pas dépendre de <em>non-US/main</em> — peut
1904 être téléchargé sur <tt>ftp-master</tt> ou l'une de ses files d'attente
1907 La <em>charte Debian</em> n'empêche pas les résidents et citoyens américains de
1908 livrer des paquets sur <tt>non-US</tt> mais ils devront être vigilants en le
1909 faisant. Nous recommandons aux responsables concernés de prendre toutes les
1910 précautions nécessaires, <em>y compris la consultation d'un juriste</em>,
1911 pour s'assurer qu'ils n'enfreignent pas une loi américaine en livrant un
1912 paquet sur <tt>non-US</tt>.
1914 Pour les paquets des sections <em>non-US/main</em> et <em>non-US/contrib</em>,
1915 les responsables devraient au moins suivre la <url id="&url-u.s.-export;"
1916 name="procédure décrite par le gouvernement américain">. Les responsables de
1917 paquets <em>non-US/non-free</em> devront en plus consulter les <url
1918 id="&url-notification-of-export;" name="règles de déclaration d'exportation
1919 pour les logiciels commerciaux">.
1921 Cette section a pour seul but d'informer, elle n'a pas valeur de conseil
1922 juridique. Une fois encore, nous recommandons aux résidents et citoyens
1923 américains de consulter un juriste avant de livrer un paquet sur
1926 <sect1 id="delayed-incoming">Envois différés
1928 Les envois différés sont pour le moment réalisés <em>via</em> la file différée
1929 sur gluck. Le répertoire d'envoi est
1930 <ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>.
1931 0-day est envoyé approximativement une heure avant l'exécution de dinstall.
1933 Avec une version assez récente de dput, cette section
1937 fqdn = gluck.debian.org
1940 dans votre fichier ~/.dput.cf devrait fonctionner correctement pour réaliser des
1941 envois dans la file DELAYED.
1943 <em>Note :</em>
1944 Comme la file d'envoi va sur <tt>ftp-master</tt>, la
1945 prescription que l'on trouve dans <ref id="upload-ftp-master"> s'applique
1948 <sect1>Envois de sécurité
1950 N'envoyez PAS un paquet vers la file d'envoi de sécurité (<em>oldstable-security</em>,
1951 <em>stable-security</em>, etc.) sans avoir au préalable l'autorisation de l'équipe de
1952 sécurité. Si le paquet ne correspond pas tout à fait aux besoins de cette
1953 équipe, il entraînera beaucoup de problèmes et de délais dans la gestion de cet
1954 envoi non désiré. Pour plus de détails, consultez la section <ref id="bug-security">.
1956 <sect1>Les autres files d'envoi
1958 Les files scp sur ftp-master, non-us et security sont pratiquement inutilisables
1959 à cause des restrictions de connexion sur ces hôtes.
1961 Les files anonymes sur ftp.uni-erlangen.de et ftp.uk.debian.org sont
1962 actuellement arrêtées. Un travail est en cours pour les restaurer.
1964 Les files sur master.debian.org, samosa.debian.org, master.debian.or.jp
1965 et ftp.chiark.greenend.org.uk sont arrêtées de façon permanente et ne seront pas
1966 restaurées. La file du Japon sera remplacée par une nouvelle file sur
1967 hp.debian.or.jp un jour.
1969 À l'heure actuelle, la file en ftp anonyme sur auric.debian.org (le précédent
1970 ftp-master) fonctionne, mais elle est déconseillée et sera supprimée à un moment
1973 <sect1 id="upload-notification">
1974 <heading>Notification de l'installation d'un nouveau paquet</heading>
1976 Les administrateurs de l'archive Debian sont responsables de l'installation des
1977 mises à jour. La plupart des mises à jour sont gérées quotidiennement par le
1978 logiciel de gestion de l'archive <prgn>katie</prgn>. Les mises à jour de
1979 paquets sur la distribution <em>unstable</em> sont installées
1980 ainsi. Dans les autres cas et notamment dans le cas d'un nouveau paquet,
1981 celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois entre le
1982 téléchargement d'un paquet vers un serveur et son installation effective. Soyez
1985 Dans tous les cas, vous recevrez un accusé de réception par courrier
1986 électronique indiquant que votre paquet a été installé et quels rapports de
1987 bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous les
1988 rapports de bogue que vous vouliez clore sont bien dans cette liste.
1990 L'accusé de réception indique aussi la section dans laquelle le paquet a été
1991 installé. S'il ne s'agit pas de votre choix, vous recevrez un second courrier
1992 qui vous informera de cette différence (voir ci-dessous).
1995 <sect id="override-file">Spécifier la section, la sous-section et la priorité d'un paquet
1997 Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
1998 <file>debian/control</file> n'indiquent ni où le paquet sera installé dans
1999 l'archive Debian, ni sa priorité. Afin de conserver la cohérence de
2000 l'archive, ce sont les administrateurs qui contrôlent ces champs. Les valeurs
2001 du fichier <file>debian/control</file> sont juste des indications.
2003 Les administrateurs de l'archive indiquent les sections et priorités des paquets
2004 dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le
2005 fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez
2006 informé par courrier électronique quand votre paquet sera installé dans
2007 l'archive. Vous pourrez corriger votre fichier <em>debian/control</em> avant
2008 votre prochain téléchargement ou alors vous pourrez vouloir modifier le
2009 fichier <em>override</em>.
2011 Pour modifier la section dans laquelle un paquet est archivé, vous devez d'abord
2012 vérifier que fichier <file>debian/control</file> est correct. Ensuite,
2013 envoyez un courrier à &email-override; ou un rapport de bogue sur le
2014 pseudo-paquet <package>ftp.debian.org</package> demandant la modification de
2015 la section ou de la priorité de votre paquet. Exposez bien les raisons qui
2016 vous amènent à demander ces changements.
2018 Pour en savoir plus sur les <em>fichiers override</em>, reportez-vous à <manref
2019 name="dpkg-scanpackages" section="8"> et <url
2020 id="&url-bts-devel;#maintincorrect">.
2022 Notez que le champ <tt>Section</tt> décrit à la fois la section et la
2023 sous-section, comme décrit dans <ref id="archive-sections">. Si la section est
2024 « main », elle devrait être omise. La liste des sous-sections
2025 autorisées peut être trouvée dans <url
2026 id="&url-debian-policy;ch-archive.html#s-subsections">.
2028 <sect id="bug-handling">Gérer les bogues
2030 Chaque développeur doit être capable de travailler avec le <url name="système de
2031 suivi des bogues" id="&url-bts;"> Debian. Il faut savoir comment remplir
2032 des rapports de bogue correctement (voir <ref id="submit-bug">), comment les
2033 mettre à jour et les réordonner et comment les traiter et les fermer.
2035 Les fonctionnalités du système de suivi des bogues qui intéressent les
2036 développeurs sont décrites dans la <url id="&url-bts-devel;" name="documentation
2037 du BTS pour les développeurs">. Ceci inclut la fermeture des bogues, l'envoi des
2038 messages de suivi, l'assignation des niveaux de gravité et des marques,
2039 l'indication que les bogues ont été envoyés au développeur amont et autres
2042 Des opérations comme réassigner des bogues à d'autres paquets, réunir des
2043 rapports de bogues séparés traitant du même problème ou réouvrir des bogues
2044 quand ils ont été prématurément fermés, sont gérées en utilisant le serveur de
2045 courrier de contrôle. Toutes les commandes disponibles pour ce serveur sont
2046 décrites dans la <url id="&url-bts-control;" name="documentation du serveur de
2049 <sect1 id="bug-monitoring">Superviser les rapports de bogue
2051 Si vous voulez être un bon responsable, consultez régulièrement la page du <url
2052 id="&url-bts;" name="système de suivi des bogues">. Cette page contient tous
2053 les rapports de bogue qui concernent vos paquets. Vous pouvez les vérifier avec
2054 cette page : <tt>http://&bugs-host;/<var>votre_compte</var>@debian.org</tt>.
2056 Les responsables interagissent avec le système de suivi des bogues en utilisant
2057 l'adresse électronique <tt>&bugs-host;</tt>. Vous trouverez une documentation
2058 sur les commandes disponibles à l'adresse <url id="&url-bts;"> ou, si vous avez
2059 installé le paquet <package>doc-debian</package>, dans les fichiers locaux
2062 Certains trouvent utile de recevoir régulièrement une synthèse des rapports de
2063 bogues ouverts. Si vous voulez recevoir une synthèse hebdomadaire relevant tous
2064 les rapports de bogue ouverts pour vos paquets, vous pouvez configurer
2065 <prgn>cron</prgn> comme suit :
2067 # Synthèse hebdomadaire des rapports de bogue qui me concernent
2070 Remplacez <var>address</var> par votre adresse officielle de responsable Debian.
2072 <sect1 id="bug-answering">Répondre à des rapports de bogue
2074 Lorsque vous répondez à des rapports de bogue, assurez-vous que toutes vos
2075 discussions concernant les bogues sont envoyées au
2076 rapporteur du bogue et au bogue lui-même (<email>123@&bugs-host;</email>
2077 par exemple). Si vous rédigez un nouveau courrier et que vous ne vous souvenez
2078 plus de l'adresse du rapporteur de bogue, vous pouvez utiliser l'adresse
2079 <email>123-submitter@&bugs-host;</email> pour contacter le rapporteur
2080 <em>et</em> enregistrer votre courrier dans le journal du bogue (ce qui veut
2081 dire que vous n'avez pas besoin d'envoyer une copie du courrier à
2082 <email>123@&bugs-host;</email>).
2084 Si vous recevez un bogue mentionnant « FTBFS », cela veut dire
2085 « Fails To Build From Source » (Erreur de construction à partir du
2086 source). Les porteurs emploient fréquemment cet acronyme.
2088 Une fois que vous avez traité un rapport de bogue (i.e. que vous l'avez
2089 corrigé), marquez-le comme <em>done</em> (fermez-le) en envoyant un message
2090 d'explication à <email>123-done@&bugs-host;</email>. Si vous corrigez un
2091 bogue en changeant et en envoyant une nouvelle version du paquet, vous pouvez
2092 fermer le bogue automatiquement comme décrit dans <ref id="upload-bugfix">.
2094 Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la commande
2095 <tt>close</tt> à l'adresse &email-bts-control;.Si vous le faites, le rapporteur
2096 n'aura aucune information sur la clôture de son rapport.
2098 <sect1 id="bug-housekeeping">Gestion générale des bogues
2100 En tant que responsable de paquet, vous trouverez fréquemment des bogues dans
2101 d'autres paquets ou vous aurez des bogues sur vos paquets qui sont en fait des
2102 bogues sur d'autres paquets. Les fonctions intéressantes du système de suivi
2103 des bogues pour les développeurs sont décrites dans la <url
2104 id="&url-bts-devel;" name="documentation du BTS pour les développeurs Debian">.
2105 Les <url id="&url-bts-control;" name="instructions du serveur de contrôle du
2106 BTS"> documentent les opérations techniques du BTS, telles que comment remplir,
2107 réassigner, regrouper et marquer des bogues. Cette section contient des lignes
2108 directrices pour gérer vos propres bogues, définies à partir de l'expérience
2109 collective des développeurs Debian.
2111 Remplir des rapports de bogue pour des problèmes que vous trouvez dans d'autres
2112 paquet est l'une des « obligations civiques » du responsable,
2113 reportez-vous à <ref id="submit-bug"> pour les détails. Cependant, gérer les
2114 bogues de vos propres paquets est encore plus important.
2116 Voici une liste des étapes que vous pouvez suivre pour gérer un rapport de
2120 Décider si le rapport correspond à un bogue réel ou non. Parfois, les
2121 utilisateurs exécutent simplement un programme de la mauvaise façon car
2122 ils n'ont pas lu la documentation. Si c'est votre diagnostic, fermez
2123 simplement le bogue avec assez d'informations pour laisser l'utilisateur
2124 corriger son problème (donnez des indications vers la bonne
2125 documentation et ainsi de suite). Si le rapport de bogue revient
2126 régulièrement, vous devriez vous demander si la documentation est assez
2127 bonne ou si le programme ne devrait pas détecter une mauvaise
2128 utilisation pour donner un message d'erreur informatif. Il s'agit d'un
2129 problème qui peut être présenté à l'auteur amont.
2131 Si le rapporteur de bogue n'est pas d'accord avec votre décision de
2132 fermeture du bogue, il peut le ré-ouvrir jusqu'à ce que vous trouviez un
2133 accord sur la façon de le gérer. Si vous n'en trouvez pas, vous pouvez
2134 marquer le bogue avec <tt>wontfix</tt> pour indiquer aux personnes que
2135 le bogue existe, mais ne sera pas corrigé. Si cette situation n'est pas
2136 acceptable, vous (ou le rapporteur) pouvez vouloir demander une décision
2137 par le comité technique en réattribuant le bogue à
2138 <package>tech-ctte</package> (vous pouvez utiliser la commande
2139 <tt>clone</tt> du BTS si vous désirez garder le bogue comme rapporté sur
2140 votre paquet). Avant de faire cela, veuillez lire la <url
2141 id="&url-tech-ctte;" name="procédure recommandée">.
2144 Si le bogue est réel, mais est causé par un autre paquet,
2145 réattribuez simplement le bogue à l'autre paquet. Si vous ne savez pas à
2146 quel paquet il doit être réattribué, vous pouvez demander de l'aide sur
2147 <qref id="irc-channels">IRC"</qref> ou sur &email-debian-devel;.
2149 Parfois, vous devez également ajuster la gravité du bogue pour qu'elle
2150 corresponde à notre définition de gravité des bogues. C'est dû au
2151 fait que les gens tendent à augmenter la gravité des bogues pour
2152 s'assurer que leurs bogues seront corrigés rapidement. La gravité de
2153 certains bogues peut même être rétrogradée en <em>wishlist</em> (souhait)
2154 quand le changement demandé est seulement d'ordre cosmétique.
2157 Le rapporteur de bogue peut avoir oublié de fournir certaines
2158 informations. Dans ce cas, vous devez lui demander les informations
2159 nécessaires. Vous pouvez utiliser la marque <tt>moreinfo</tt> (plus
2160 d'information) sur le bogue. De plus, si vous ne pouvez pas reproduire le
2161 bogue, vous pouvez le marquer comme <tt>unreproducible</tt> (non
2162 reproductible). Une personne qui arriverait à reproduire le bogue est
2163 alors invitée à fournir plus d'informations sur la façon de le
2164 reproduire. Après quelques mois, si cette information n'a été envoyée
2165 par personne, le bogue peut être fermé.
2168 Si le bogue est lié à l'empaquetage, vous devez simplement le
2169 corriger. Si vous ne pouvez pas le corriger vous-même, marquez alors le
2170 bogue avec <tt>help</tt> (aide). Vous pouvez également demander de
2171 l'aide sur &email-debian-devel; ou &email-debian-qa;. S'il s'agit d'un
2172 problème amont, vous devez faire suivre le rapport à l'auteur amont.
2173 Faire suivre un bogue n'est pas suffisant, vous devez vérifier à chaque
2174 version si le bogue a été corrigé ou non. S'il a été corrigé, vous le
2175 fermez simplement, sinon vous devez le rappeler à l'auteur. Si vous avez
2176 les compétences nécessaires, vous pouvez préparer un correctif pour
2177 corriger le bogue et l'envoyer en même temps à l'auteur. Assurez-vous
2178 d'envoyer le correctif au BTS et marquez le bogue avec <tt>patch</tt>
2182 Si vous avez corrigé un bogue sur votre copie locale ou si un correctif
2183 a été inclus dans le référentiel CVS, vous pouvez marquer le bogue avec
2184 <tt>pending</tt> (en attente) pour informer que le bogue est corrigé et
2185 qu'il sera fermé lors du prochain envoi (ajoutez le <tt>closes:</tt>
2186 dans le <file>changelog</file>). C'est particulièrement utile si
2187 plusieurs développeurs travaillent sur le même paquet.
2190 Une fois que le paquet corrigé est disponible dans la distribution
2191 <em>unstable</em>, vous pouvez fermer le bogue. Ceci peut être fait
2192 automatiquement, pour cela, reportez-vous à <ref id="upload-bugfix">.
2196 <sect1 id="upload-bugfix">Quand les rapports de bogue sont-ils fermés par
2197 une mise à jour ?
2199 Au fur et à mesure que les bogues et problèmes sont corrigés dans vos paquets,
2200 il est de votre responsabilité de fermer le rapport de bogue associé.
2201 Cependant, vous ne devez pas le fermer avant que le paquet n'ait été accepté
2202 dans l'archive Debian. C'est pourquoi, vous pouvez et vous devez clore le
2203 rapport dans le système de suivi des bogues une fois que vous avez reçu l'avis
2204 indiquant que votre nouveau paquet a été installé dans l'archive.
2206 Cependant, il est possible d'éviter d'avoir à fermer manuellement les bogues
2207 après l'envoi — indiquez simplement les bogues corrigés dans le fichier
2208 <file>changelog</file> en suivant une syntaxe précise. Par exemple :
2211 acme-cannon (3.1415) unstable; urgency=low
2213 * Frobbed with options (closes: Bug#98339)
2214 * Added safety to prevent operator dismemberment, closes: bug#98765,
2216 * Added man page. Closes: #98725.
2219 Techniquement parlant, l'expression rationnelle Perl suivante décrit comment les
2220 lignes de <em>changelogs</em> de fermeture de bogues sont identifiées :
2223 /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
2226 Nous préfèrons la syntaxe <tt>closes: #<var>XXX</var></tt>, car c'est l'entrée
2227 la plus concise et la plus facile à intégrer dans le texte du fichier
2228 <file>changelog</file>.
2230 Si vous entrez un numéro de bogue incorrect ou si vous oubliez un bogue dans les
2231 entrées du fichier <file>changelog</file>, n'hésitez pas à annuler tout dommage
2232 que l'erreur a entraîné. Pour réouvrir un bogue fermé par erreur, envoyez une
2233 commande <tt>reopen <var>XXX</var></tt> à l'adresse de contrôle du système de
2234 suivi des bogues, &email-bts-control;. Pour fermer tous les bogues restants qui
2235 ont été corrigés par votre envoi, envoyez le fichier <file>.changes</file> à
2236 <email>XXX-done@&bugs-host;</email> où <var>XXX</var> est le numéro du
2239 Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en utilisant le
2240 <file>changelog</file> tel que décrit ci-dessus. Si vous désirez simplement
2241 fermer les bogues qui n'ont rien à voir avec l'un de vos envois, faites-le
2242 simplement en envoyant une explication à
2243 <email>XXX-done@&bugs-host;</email>. Vous <strong>ne devez pas</strong> pas
2244 fermer des bogues dans une entrée de changelog d'une version si les
2245 changements dans cette version n'ont rien à voir avec le bogue.
2247 Pour une information plus générale sur ce qu'il faut mettre dans les entrées de
2248 changelog, veuillez vous reporter aux <ref id="bpp-debian-changelog">.
2250 <sect1 id="bug-security">Gérer les bogues de sécurité
2252 À cause de leur nature sensible, les bogues liés à la sécurité doivent être
2253 soigneusement traités. L'équipe de sécurité de Debian est là pour coordonner
2254 cette activité, pour faire le suivi des problèmes de sécurité en cours, pour
2255 aider les responsables ayant des problèmes de sécurité ou pour les corriger
2256 elle-même, pour envoyer les annonces de sécurité et pour maintenir le site
2257 security.debian.org.
2259 Si vous prenez connaissance d'un bogue lié à un problème de sécurité sur un
2260 paquet Debian, que vous soyez ou non le responsable, regroupez les
2261 informations pertinentes sur le problème et contactez rapidement l'équipe de
2262 sécurité à &email-security-team; dès que possible. <strong>N'ENVOYEZ
2263 PAS</strong> de paquet pour <em>stable</em> ; l'équipe de sécurité le
2266 Les informations utiles incluent, par exemple :
2270 les versions du paquet connues pour être affectées par le bogue. Vérifiez
2271 chaque version présente dans les distributions maintenues par Debian ainsi
2272 que dans <em>testing</em> et dans <em>unstable</em>,
2275 la nature d'une solution si elle est disponible (les correctifs sont
2276 particulièrement utiles),
2279 tout paquet corrigé que vous avez vous-même préparé (envoyez seulement les
2280 fichiers <file>.diff.gz</file> et <file>.dsc</file> et lisez d'abord <ref
2281 id="bug-security-building">),
2284 toute assistance que vous pouvez fournir pour aider les tests (exploits,
2285 tests de régression, etc.),
2288 toute information nécessaire pour l'annonce de sécurité (voir <ref
2289 id="bug-security-advisories">).
2293 <sect2 id="bug-security-confidentiality">Confidentialité
2295 À la différence de la plupart des autres activités au sein de Debian, les
2296 informations sur les problèmes de sécurité doivent parfois être gardées en
2297 privé pour un certain temps. Ceci permet les distributeurs de logiciels de
2298 coordonner leur dévoilement afin de minimiser l'exposition de leurs
2299 utilisateurs. Cette décision dépend de la nature du problème
2300 et de l'existence d'une solution correspondante et également s'il s'agit d'un
2301 fait connu publiquement.
2303 Il existe plusieurs façons pour un développeur de prendre connaissance d'un
2304 problème de sécurité :
2308 il le remarque sur un forum public (liste de diffusion, site web, etc.),
2311 quelqu'un remplit un rapport de bogue,
2314 quelqu'un l'informe par courrier privé.
2318 Dans les deux premiers cas, l'information est publique et il est important
2319 d'avoir une solution le plus vite possible. Dans le dernier cas, cependant, ce
2320 n'est peut-être pas une information publique. Dans ce cas, il existe quelques
2321 options possibles pour traiter le problème :
2325 si l'exposition de sécurité est mineure, il n'y a parfois pas besoin de
2326 garder le secret sur le problème et une correction devrait être effectuée
2330 si le problème est grave, il est préférable de partager cette
2331 information avec d'autres vendeurs et de coordonner une diffusion.
2332 L'équipe de sécurité garde des contacts avec les différentes organisations
2333 et individus et peut prendre soin des actions à mener.
2338 Dans tous les cas, si la personne qui indique le problème demande à ce que
2339 l'information ne soit pas diffusée, cela devrait être respecté avec l'évidente exception
2340 d'informer l'équipe de sécurité pour qu'une correction puisse être effectuée
2341 pour la version stable de Debian. Quand vous envoyez des informations
2342 confidentielles à l'équipe de sécurité, assurez-vous de bien mentionner ce fait.
2344 <p>Veuillez noter que si le secret est nécessaire, vous ne pourrez pas envoyer
2345 un correctif vers <em>unstable</em> (ou ailleurs) puisque les informations de
2346 changelog et de diff sont publiques pour <em>unstable</em>.
2348 <p>Il existe deux raisons pour diffuser l'information même si le secret est
2349 demandé : le problème est connu depuis un certain temps ou le problème ou
2350 son exploitation est devenu public.
2352 <sect2 id="bug-security-advisories">Annonces de sécurité
2354 Les annonces de sécurité ne sont émises que pour la distribution actuelle
2355 diffusée <em>stable</em>, <em>PAS</em> pour <em>testing</em> ou <em>unstable</em>.
2356 Quand elle est diffusée, l'annonce est envoyée à la liste de diffusion
2357 &email-debian-security-announce; et elle est postée sur <url
2358 id="&url-debian-security-advisories;" name="la page de sécurité">. Les
2359 annonces de sécurité sont écrites et postées par les membres de l'équipe de sécurité.
2360 Cependant, ils ne verront aucun inconvénient à ce qu'un responsable leur
2361 apporte des informations ou écrive une partie du texte. Les informations qui
2362 devraient être présentes dans une annonce incluent :
2365 une description du problème et de sa portée, y compris :
2368 le type du problème (usurpation de privilège, déni de service,
2372 quels sont les privilèges obtenus et par quels utilisateurs (si c'est le
2376 comment il peut être exploité,
2379 si le problème peut être exploité à distance ou localement,
2382 comment le problème a été corrigé,
2385 Ces informations permettent aux utilisateurs d'estimer la menace pesant
2390 les numéros de version des paquets affectés,
2393 les numéros de version des paquets corrigés,
2396 une information sur la façon de récupérer les paquets mis à jour
2397 (habituellement l'archive de sécurité Debian),
2400 des références à des annonces amont, des identifiants <url
2401 id="http://cve.mitre.org" name="CVE"> et toute autre information utile
2402 pour recouper les références de la vulnérabilité.
2406 <sect2 id="bug-security-building">
2407 <heading>Préparer les paquets pour corriger des problèmes de sécurité
2409 Une façon d'aider l'équipe de sécurité dans ses travaux est de leur fournir des
2410 paquets corrigés convenables pour une annonce de sécurité pour la version
2411 <em>stable</em> de Debian
2413 Quand une mise à jour de la version <em>stable</em> est effectuée, un soin
2414 particulier doit être apporté pour éviter de modifier le comportement du
2415 système ou d'introduire de nouveaux bogues. Pour cela, faites le moins de
2416 changements possibles pour corriger le bogue. Les utilisateurs et les
2417 administrateurs s'attendent à un comportement identique dans une version
2418 lorsque celle-ci est diffusée, donc tout changement qui est fait est
2419 susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour
2420 les bibliothèques : assurez-vous ne de jamais changer l'API ou l'ABI,
2421 quelque minimal que soit le changement.
2423 Cela veut dire que passer à une version amont supérieure n'est pas une bonne
2424 solution. À la place, les changements pertinents devraient être rétroportés
2425 vers la version présente dans la distribution <em>stable</em> de Debian.
2426 Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de
2427 sécurité Debian peut le faire.
2429 Dans certains cas, il n'est pas possible de rétroporter un correctif de
2430 sécurité, par exemple, quand de grandes quantités de code source doivent être
2431 modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à
2432 une nouvelle version amont. Cependant, ceci n'est fait que dans des situations
2433 extrêmes et vous devez toujours coordonner cela avec l'équipe de sécurité au
2436 Il existe une autre règle de conduite liée à cela : testez toujours vos
2437 changements. Si une exploitation du problème existe, essayez-la et
2438 vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet
2439 corrigé. Testez aussi les autres actions normales car parfois un correctif de
2440 sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas
2443 N'incluez <strong>PAS</strong> de changements dans votre paquet qui ne soient
2444 pas liés directement à la correction de la vulnérabilité. Ceux-ci devraient être
2445 ensuite enlevés et cela perd du temps. S'il y a d'autres bogues dans votre
2446 paquet que vous aimeriez corriger, faites un envoi vers
2447 proposed-updates de la façon habituelle, après l'envoi de l'alerte de sécurité.
2448 Le mécanisme de mise à jour de sécurité n'est pas un moyen d'introduire des
2449 changements dans votre paquet qui seraient sinon rejetés de la distribution
2450 stable, n'essayez donc pas de faire cela, s'il vous plaît.
2452 Examinez et testez autant que possible vos changements. Vérifiez les différences
2453 avec la version précédente de manière répétée (<prgn>interdiff</prgn> du
2454 paquet <package>patchutils</package> et <prgn>debdiff</prgn> du paquet
2455 <package>devscripts</package> sont des outils utiles pour cela, voir <ref
2458 Assurez-vous de conserver les points suivants à l'esprit :
2462 Ciblez la bonne distribution dans votre
2463 fichier <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de
2464 <tt>stable-security</tt> et pour <em>testing</em>, c'est
2465 <tt>testing-security</tt> et pour l'ancienne distribution stable, c'est
2466 <tt>oldstable-security</tt>. Ne ciblez ni
2467 <var>distribution</var>-proposed-updates, ni <tt>stable</tt> !
2469 <item>L'envoi devra avoir « urgency=high ».
2472 Fournissez des entrées de changelog descriptives et complètes. D'autres
2473 personnes se baseront dessus pour déterminer si un bogue particulier a été
2474 corrigé. Incluez toujours une référence externe, de préférence un
2475 identifiant CVE, pour qu'elle puisse être recoupée. Incluez la même
2476 information dans le changelog pour <em>unstable</em> pour qu'il soit clair
2477 que le même bogue a été corrigé car cela est très utile pour vérifier que
2478 le bogue a été corrigé pour la prochaine version stable. Si aucun
2479 identifiant CVE n'a encore été assigné, l'équipe de sécurité en demandera
2480 un pour qu'il puisse être inclus dans le paquet et dans le changelog.
2483 Fournissez des entrées de changelog descriptives et complètes. D'autres
2484 personnes se baseront dessus pour déterminer si un bogue particulier a été
2485 corrigé. Quand cela est possible, incluez une référence externe, de
2486 préférence, un identifiant CVE, pour qu'elle puisse être recoupée.
2489 Assurez-vous que le numéro de version est correct. Il doit être plus élevé
2490 que celui du paquet actuel, mais moins que ceux des paquets des versions
2491 des distributions suivantes. En cas de doute, testez-le avec <tt>dpkg
2492 --compare-versions</tt>. Soyez attentif à ne pas ré-utiliser un numéro de
2493 version que vous auriez déjà utilisé pour un précédent envoi.
2494 Pour <em>testing</em>, il doit y avoir un numéro
2495 de version supérieur dans <em>unstable</em>. S'il n'y en a pas encore (par
2496 exemple, si <em>testing</em> et <em>unstable</em> ont la même version),
2497 vous devez envoyer une nouvelle version vers <em>unstable</em> en premier.
2500 Ne faites pas d'envoi de source seul si votre paquet possède un ou
2501 plusieurs paquets binary-all (n'utilisez pas l'option <tt>-S</tt> de
2502 <prgn>dpkg-buildpackage</prgn>). L'infrastructure <prgn>buildd</prgn> ne
2503 construira pas ceux-ci. Ce point s'applique aux envois de paquets normaux
2507 Sauf si la source amont a été envoyée auparavant à security.debian.org (par une
2508 précédente mise à jour de sécurité), construisez le paquet avec la source
2509 amont complète (<tt>dpkg-buildpackage -sa</tt>). S'il y a déjà eu un
2510 précédent envoi à security.debian.org, vous pouvez faire un envoi sans le
2511 paquet source (<tt>dpkg-buildpackage -sd</tt>).
2514 Assurez-vous d'utiliser exactement le même nom <file>*.orig.tar.gz</file>
2515 que celui utilisé dans l'archive normale, sinon il ne sera pas possible de
2516 déplacer plus tard le correctif de sécurité dans l'archive principale.
2519 Compilez le paquet sur un système
2520 propre, dont tous les paquets appartiennent à la distribution pour laquelle vous
2521 construisez le paquet. Si vous n'avez pas un tel système, vous pouvez
2522 utiliser l'une des machines de debian.org (voir <ref
2523 id="server-machines">) ou mettez en place un chroot (voir <ref id=
2524 "pbuilder"> et <ref id="debootstrap">).
2528 <sect2 id="bug-security-upload">Mettre à jour le paquet corrigé
2530 Vous <em>NE</em> devez <em>PAS</em> envoyer un paquet dans la file d'attente des envois de sécurité
2531 (oldstable-security, stable-security, etc.)
2532 sans l'accord préalable de l'équipe de sécurité. Si le paquet ne remplit pas
2533 exactement les exigences de l'équipe, il causera beaucoup de problèmes, ainsi
2534 que des délais dans la gestion de l'envoi indésirable.
2536 Vous <em>NE</em> devez <em>PAS</em> envoyer votre correction dans
2537 <em>proposed-updates</em> sans vous coordonner avec l'équipe de sécurité. Les
2538 paquets seront copiés de security.debian.org dans le répertoire
2539 <file>proposed-updates</file> automatiquement. Si un paquet avec le même numéro
2540 de version ou un numéro plus grand est déjà installé dans l'archive, la mise à
2541 jour de sécurité sera rejetée par le système d'archive. Ainsi, la distribution
2542 <em>stable</em> se retrouvera à la place sans la mise à jour de sécurité de ce
2545 Une fois que vous avez créé et testé le nouveau paquet et qu'il a été approuvé
2546 par l'équipe de sécurité, il doit être envoyé pour être installé dans les
2547 archives. Pour les envois de sécurité, l'adresse d'envoi est
2548 <tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt>.
2551 Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera
2552 automatiquement recompilé pour toutes les architectures et stocké pour
2553 vérification par l'équipe de sécurité.
2556 Les envois en attente d'acceptation ou de vérification ne sont accessibles que
2557 par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des
2558 correctifs pour des problèmes de sécurité qui ne peuvent pas encore être
2562 Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur
2563 security.debian.org ainsi que dans le répertoire
2564 <var>distribution</var>-proposed-updates qui convient sur ftp-master ou dans
2567 <sect id="archive-manip">
2568 <heading>Déplacer, effacer, changer le nom, adopter et abandonner des paquets
2570 Certaines manipulations de l'archive ne sont pas possibles avec le processus
2571 de mise à jour automatisé. Elles sont appliquées manuellement par les
2572 développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.
2574 <sect1 id="moving-pkgs">Déplacer des paquets
2576 Il se peut qu'un paquet puisse changer de section. Une nouvelle version d'un paquet
2577 de la section <tt>non-free</tt> pourrait, par exemple, être distribuée sous
2578 licence GNU GPL ; dans ce cas, le paquet doit être déplacé dans la section
2579 <tt>main</tt> ou <tt>contrib</tt><footnote><p>Reportez-vous à la <url
2580 id="&url-debian-policy;" name="charte Debian"> pour savoir dans quelle section
2581 un paquet doit être classé.</footnote>.
2583 Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez les
2584 informations de contrôle du paquet pour le placer dans la section désirée et
2585 téléchargez à nouveau votre paquet dans l'archive. Reportez-vous à la <url
2586 id="&url-debian-policy;" name="charte Debian"> pour en savoir plus. Si votre
2587 nouvelle section est valide, il sera déplacé automatiquement. Si ce n'est pas
2588 le cas, contactez les responsables ftp pour comprendre ce qui s'est passé.
2590 Si vous avez besoin de modifier la sous-section de l'un de vos paquets
2591 (<tt>devel</tt> ou <tt>admin</tt> par exemple), la procédure est légèrement
2592 différente. Modifiez la sous-section dans le fichier de contrôle de votre
2593 paquet et téléchargez-le. Il vous faudra ensuite demander la modification du
2594 fichier <em>override</em> comme décrit dans la section <ref
2595 id="override-file">.
2598 <sect1 id="removing-pkgs">Supprimer des paquets
2600 Si, pour une raison ou une autre, vous avez besoin de supprimer un paquet de
2601 l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile, que
2602 l'on conservait pour des raisons de compatibilité), il vous faudra envoyer un
2603 rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
2604 demander sa suppression. N'oubliez pas de préciser de quelle distribution le
2605 paquet doit être supprimé. Normalement, vous ne devriez avoir à supprimer que
2606 des paquets d'<em>unstable</em> ou de <em>experimental</em>. Les paquets de
2607 <em>testing</em> ne sont pas supprimés directement. Ils sont plutôt enlevés
2608 automatiquement après que le paquet a été supprimé d'<em>unstable</em> et
2609 si aucun paquet de <em>testing</em> n'en dépend.
2611 Vous devez également détailler les raisons justifiant cette demande. Ceci a pour
2612 but d'éviter les suppressions non désirées et de garder une trace de la raison
2613 pour laquelle un paquet a été supprimé. Par exemple, vous pouvez fournir le nom
2614 du paquet qui remplace celui à supprimer.
2616 Vous ne pouvez demander la suppression d'un paquet que si vous en
2617 êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez
2618 obtenir l'accord de son responsable.
2620 Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
2621 autres développeurs sur la liste &email-debian-devel;. Le programme
2622 <prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
2623 utile. La commande <tt>apt-cache showpkg <var>paquet</var> </tt> vous
2624 indiquera, entre autres, les paquets qui dépendent de <var>paquet</var>.
2625 Le retrait de paquets orphelins est discuté sur &email-debian-qa;.
2627 Une fois que le paquet a été supprimé, les bogues du paquet doivent être gérés.
2628 Soit ils sont réattribués à un autre paquet dans le cas où le code actuel a
2629 évolué en un autre paquet (par exemple, <tt>libfoo12</tt> a été supprimé parce
2630 que <tt>libfoo13</tt> le remplace) ou ils sont fermés si le logiciel ne fait
2631 simplement plus partie de Debian.
2633 <sect2>Supprimer des paquets dans <tt>Incoming</tt>
2635 Par le passé, il était possible de supprimer un paquet de <file>Incoming</file>.
2636 Cependant, ce n'est plus possible depuis la mise en place du nouveau système
2637 de file d'attente. Il vous faudra télécharger une nouvelle version de votre
2638 paquet avec un numéro de version plus élevé que celui que vous voulez
2639 remplacer. Les deux versions seront installées dans l'archive mais seule la
2640 plus récente sera accessible dans <em>unstable</em> car la précédente sera
2641 immédiatement remplacée par la nouvelle. Toutefois, si vous testez
2642 correctement vos paquets, le besoin d'en remplacer un ne devrait pas être
2645 <sect1>Remplacer un paquet ou changer son nom
2647 Si vous vous trompez en nommant un paquet, vous devrez intervenir en deux
2648 étapes pour changer son nom. D'abord, modifiez
2649 votre fichier <file>debian/control</file> pour que votre nouveau paquet
2650 remplace et entre en conflit avec l'ancien paquet que vous voulez remplacer
2651 (reportez-vous à la <url id="&url-debian-policy;" name="charte Debian"> pour
2652 les détails). Une fois que votre paquet est installé dans l'archive, faites un
2653 rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
2654 demandez la suppression du paquet mal nommé. N'oubliez pas de réattribuer
2655 correctement les bogues du paquet en même temps.
2657 D'autres fois, vous pouvez commettre une erreur en construisant le paquet et
2658 vous désirez le remplacer. La seule façon de faire est d'incrémenter le numéro de
2659 version et d'envoyer une nouvelle version. L'ancienne version expirera de la
2660 façon habituelle. Notez que ceci s'applique à chaque partie de votre paquet, y
2661 compris les sources : si vous désirez remplacer l'archive source amont de
2662 votre paquet, vous devez l'envoyer avec un numéro de version différent. Une
2663 possibilité simple est de remplacer <file>foo_1.00.orig.tar.gz</file> par
2664 <file>foo_1.00+0.orig.tar.gz</file>. Cette restriction donne à chaque fichier
2665 du site ftp un nom unique, ce qui aide à garantir la consistance dans le réseau
2668 <sect1 id="orphaning">Abandonner un paquet
2670 Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres et
2671 faire le nécessaire pour qu'il soit marqué <em>abandonné</em> (i.e.
2672 <em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
2673 Group &orphan-address;</tt> dans le champ <tt>maintainer</tt> du paquet et
2674 faire un rapport de bogue sur le pseudo-paquet <package>wnpp</package>. Le
2675 titre de votre rapport de bogue devrait être
2676 « <tt>O<footnote><p><em>Orphaned</em> : abandonné.</footnote>:
2677 <var>paquet</var> — <var>courte description</var></tt> » pour
2678 indiquer que le paquet est abandonné. La gravité du bogue sera
2679 <em>normale</em> ; si le paquet a une priorité standard ou supérieure,
2680 elle devrait être <em>importante</em>. Si vous le jugez nécessaire, envoyez une copie à
2681 &email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
2682 l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le sujet
2683 du message ne contiendra pas le numéro du bogue.
2685 Si vous avez simplement l'intention de donner le paquet, mais que vous pouvez
2686 conserver sa maintenance pour le moment, vous devriez à la place soumettre un
2687 rapport de bogue sur <package>wnpp</package> et l'intituler <tt>RFA: <var>paquet</var> --
2688 <var>description courte</var></tt>.
2689 <tt>RFA</tt> veut dire <em>Request For Adoption</em> (demande d'adoption).
2691 Vous pouvez trouver plus d'informations sur les <url id="&url-wnpp;" name="pages
2692 web WNPP"><footnote><p><em>Work-needing and prospective
2693 packages</em> : paquets en souffrance et paquets
2694 souhaités.</footnote>.
2696 <sect1 id="adopting">Adopter un paquet
2698 Une liste des paquets en attente de nouveau responsable est disponible à la page
2699 <url id="&url-wnpp;" name="paquets en souffrance et paquets souhaités">. Si
2700 vous voulez prendre en charge un paquet de cette liste, reportez-vous à la page
2701 mentionnée ci-dessus pour connaître la procédure à suivre.
2703 Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
2704 correct — ce serait un détournement de paquet. Vous pouvez prendre
2705 contact avec le responsable actuel et lui demander si vous pouvez prendre en
2706 charge ce paquet. Si vous avez le sentiment qu'un responsable est parti sans
2707 prévenir depuis un moment, veuillez vous reporter à <ref id="mia-qa">).
2709 Généralement, vous ne pouvez pas adopter un paquet sans l'accord du responsable
2710 actuel. Même s'il vous ignore, ce n'est pas une raison pour le faire. Les
2711 plaintes à propos des responsables devraient être portées sur la liste de
2712 diffusion des développeurs. Si la discussion ne se termine pas par une
2713 conclusion positive et que le problème est de nature technique, considérez de
2714 porter le cas à l'attention du comité technique (voir la <url name="page web du
2715 comité technique" id="&url-tech-ctte;"> pour plus d'information).
2717 Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de suivi
2718 des bogues indique que vous êtes le responsable du paquet. Cela se produira
2719 automatiquement une fois que vous aurez installé une nouvelle version du paquet
2720 dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut prendre
2721 quelques heures après le téléchargement. Si vous pensez ne pas avoir de mise à
2722 jour à faire pour un moment, vous pouvez utiliser le <ref
2723 id="pkg-tracking-system"> pour recevoir les rapports de bogue. Cependant,
2724 assurez-vous que cela ne pose aucun problème à l'ancien responsable de
2725 continuer à recevoir les bogues durant ce temps.
2727 <sect id="porting">Le portage
2729 Debian accepte un nombre croissant d'architectures. Même si vous n'êtes pas un
2730 porteur et même si vous n'utilisez qu'une architecture, il est de votre
2731 responsabilité de développeur d'être attentif aux questions de
2732 portabilité. C'est pourquoi il est important que vous lisiez ce chapitre
2733 même si vous n'êtes pas un porteur.
2735 Porter un paquet consiste à faire un paquet binaire pour des architectures
2736 différentes de celle du paquet binaire fait par le responsable du paquet.
2737 C'est une activité remarquable et essentielle. En fait, les porteurs sont
2738 à l'origine de la plupart des compilations de paquets Debian. Pour un
2739 paquet binaire <em>i386</em>, par exemple, il faut compter une
2740 recompilation pour chaque autre architecture, soit un total de
2741 &number-of-arches; recompilations.
2744 <sect1 id="kind-to-porters">Être courtois avec les porteurs
2746 Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un
2747 grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
2748 modification. Malheureusement, c'est rarement le cas. Cette section contient
2749 une liste d'erreurs commises régulièrement par les responsables Debian —
2750 problèmes courants qui bloquent souvent les porteurs et compliquent inutilement
2753 Ici, la première et la plus importante chose est de répondre rapidement aux rapports de bogues et
2754 remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
2755 étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine manière).
2756 Merci pour votre indulgence envers des rapports de bogue succincts ou peu
2757 clairs ; faites de votre mieux pour éliminer le problème.
2759 Les problèmes les plus couramment rencontrés par les porteurs sont causés par
2760 des erreurs de mise en paquet dans le paquet source. Voici un
2761 pense-bête pour les choses auxquelles vous devez être attentif :
2764 Vérifiez que les champs <tt>Build-Depends</tt> et
2765 <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
2766 corrects. Le meilleur moyen de le vérifier est d'utiliser le paquet
2767 <package>debootstrap</package> pour créer un environnement
2768 <em>unstable</em> <em>chrooté</em> (voir <ref id="debootstrap">). Dans
2769 cet environnement <em>chrooté</em>, il faudra installer le paquet
2770 <package>build-essential</package> et tous les paquets mentionnés dans
2771 les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
2772 Ensuite, vous essayerez de fabriquer votre paquet dans cet
2773 environnement. Ces étapes peuvent être automatisées en utilisant le
2774 programme <prgn>pbuilder</prgn> qui est fourni par le paquet de même
2775 nom (voir <ref id="pbuilder">).
2777 Si vous n'arrivez pas à installer un environnement <em>chrooté</em>,
2778 <prgn>dpkg-depcheck</prgn> pourra peut-être vous aider (voir <ref
2779 id="dpkg-depcheck">).
2781 Consultez la <url id="&url-debian-policy;" name="charte Debian"> pour en
2782 savoir plus sur les dépendances de fabrication.
2785 Ne choisissez pas d'autres valeurs que <em>all</em> ou <em>any</em> pour
2786 le champ architecture sans avoir de bonnes raisons pour le faire. Trop
2787 souvent, les développeurs ne respectent pas les instructions de la <url
2788 id="&url-debian-policy;" name="charte Debian">. Choisir la valeur
2789 « i386 » est la plupart du temps incorrect.
2792 Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
2793 <var>paquet</var>.dsc</tt> pour vous assurer que le paquet se
2794 décompresse correctement. En utilisant le résultat de ce test,
2795 construisez votre paquet binaire à l'aide de la commande
2796 <prgn>dpkg-buildpackage</prgn>.
2799 Vérifiez que les fichiers <file>debian/files</file> et
2800 <file>debian/substvars</file> ne sont pas dans votre paquet source. Ils
2801 doivent être effacés par la cible <em>clean</em> de
2802 <file>debian/rules</file>.
2805 Assurez-vous que vous ne vous appuyez pas sur des éléments de
2806 configuration ou des logiciels installés ou modifiés localement. Par
2807 exemple, vous ne devriez jamais appeler des programmes du répertoire
2808 <file>/usr/local/bin</file> ou de répertoires équivalents. Essayez de ne
2809 pas vous appuyer sur des logiciels configurés de manière spéciale.
2810 Essayez de construire votre paquet sur une autre machine, même s'il
2811 s'agit de la même architecture.
2814 Ne vous appuyez pas sur une installation préexistante de votre paquet
2815 (un sous-cas de la remarque précédente).
2818 Si possible, ne vous appuyez pas sur une particularité présente dans un
2819 compilateur précis ou dans une certaine version d'un compilateur. Si
2820 vous ne pouvez pas faire autrement, assurez-vous que les dépendances de
2821 fabrication reflètent bien cette restriction. Dans ce cas, vous cherchez
2822 sûrement les problèmes car quelques architectures pourraient choisir un
2823 compilateur différent.
2826 Vérifiez que votre fichier <file>debian/rules</file> distingue les
2827 cibles <em>binary-arch</em> et <em>binary-indep</em> comme l'exige la
2828 charte Debian. Vérifiez que ces cibles sont indépendantes l'une de
2829 l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer l'une de
2830 ces cibles avant d'invoquer l'autre. Pour vérifier cela, essayez
2831 d'exécuter <tt>dpkg-buildpackage -B</tt>.
2836 <sect1 id="porter-guidelines">Instructions pour les mises à jour des
2839 Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez
2840 de la chance et votre travail est facile. Cette section s'applique dans ce
2841 cas ; elle décrit comment construire et installer correctement votre
2842 paquet binaire dans l'archive Debian. Si vous devez modifier le paquet pour le
2843 rendre compilable sur votre architecture cible vous devez faire une mise à jour
2844 des sources, consultez la section <ref id="nmu-guidelines">.
2846 Pour un envoi de portage, ne faites pas de changement dans les sources. Vous
2847 n'avez pas besoin de modifier les fichiers du paquet source (cela inclut le
2848 fichier <file>debian/changelog</file>).
2850 La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante :
2851 <tt>dpkg-buildpackage -B -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
2852 <var>adresse-porteur</var> par votre adresse électronique. Cette commande
2853 construira les parties du paquet qui dépendent de l'architecture, en utilisant
2854 la cible <em>binary-arch</em> de <file>debian/rules</file>.
2856 Si vous travaillez sur une machine Debian pour vos efforts de portage et que
2857 vous devez signer votre envoi localement pour son acceptation dans l'archive,
2858 vous pouvez exécuter <prgn>debsign</prgn> sur votre fichier
2859 <file>.changes</file> pour qu'il soit signé de manière commode ou utilisez le
2860 mode de signature à distance de <prgn>dpkg-sig</prgn>.
2862 <sect2 id="binary-only-nmu">
2863 Mises à jour indépendantes binaires ou recompilations
2865 Parfois, l'envoi du portage initial pose problème car l'environnement dans lequel
2866 le paquet a été construit n'était pas bon (bibliothèques plus à jour ou
2867 obsolètes, mauvais compilateur, etc.). Il se peut que vous ayez à le recompiler
2868 dans un environnement mis à jour. Cependant, dans ce cas, vous devez changer
2869 le numéro de version pour que les mauvais anciens paquets soient remplacés dans
2870 l'archive Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
2871 s'ils n'ont pas un numéro de version supérieur à celui actuellement
2874 Vous devez vous assurez que votre mise à jour indépendante binaire ne rend pas
2875 le paquet non installable. Cela peut arriver si un paquet source génère des
2876 paquets dépendants et indépendants de l'architecture qui dépendent
2877 les uns des autres <em>via</em> $(Source-Version).
2880 Malgré les modifications nécessaires du changelog, ce type de mise
2881 à jour reste une mise à jour indépendante binaire — il n'est pas
2882 nécessaire de reconsidérer le statut des paquets binaires des autres
2883 architectures pour les marquer périmés ou à recompiler.
2885 Ces recompilations nécessitent des numéros de version « magiques »
2886 pour que le système de maintenance de l'archive comprennent que, bien qu'il y
2887 ait une nouvelle version, il n'y a pas eu de modification des sources. Si vous
2888 ne faites pas cela correctement, les administrateurs de l'archive rejetteront
2889 votre mise à jour (car il n'y aura pas de code source associé).
2891 Cette « magie » associée à une mise à jour par recompilation est déclenchée en
2892 utilisant un troisième nombre dans la partie debian du numéro de version. Si,
2893 par exemple, la dernière version du paquet que vous recompilez était
2894 « 2.9-3 », votre mise à jour portera le numéro
2895 « 2.9-3.0.1 ». Si cette version était « 3.4-2.1 » votre
2896 mise à jour portera le numéro « 3.4-2.1.1 ».
2898 De manière similaire aux envois du porteur initial, la façon correcte d'invoquer
2899 <prgn>dpkg-buildpackage</prgn> est <tt>dpkg-buildpackage -B</tt> pour ne
2900 construire que les parties dépendant de l'architecture du paquet.
2903 <sect2 id="source-nmu-when-porter">
2904 Quand faire une mise à jour indépendante source pour un portage ?
2906 Les porteurs qui font des mises à jour indépendantes sources suivent
2907 généralement les instructions de la section <ref id="nmu"> tout comme les
2908 non-porteurs. Les délais d'attente sont cependant plus courts car les
2909 porteurs doivent manipuler un grand nombre de paquets. À nouveau, la
2910 situation diffère selon la distribution visée. Elle varie également selon que
2911 l'architecture est candidate pour inclusion dans la prochaine version
2912 stable ; les responsables de diffusion décident et annoncent quelles
2913 architectures sont candidates.
2915 Si vous êtes porteur et faites une mise à jour pour <em>unstable</em>, les
2916 instructions précédentes sont applicables à deux différences près. Tout
2917 d'abord, le temps d'attente raisonnable — délai entre le moment où vous
2918 envoyez un rapport au système de suivi des bogues et le moment où vous pouvez
2919 faire une mise à jour indépendante <em>(NMU)</em> — est de sept jours.
2920 Ce délai peut être raccourci si le problème est crucial et met l'effort de
2921 portage en difficulté : c'est à la discrétion de l'équipe de portage.
2922 (Souvenez-vous, il ne s'agit pas d'un règlement, mais de recommandations
2923 communément acceptées). Pour les envois de <em>stable</em> ou
2924 <em>testing</em>, veuillez tout d'abord vous coordonner avec l'équipe de
2925 diffusion appropriée.
2928 Deuxième différence, les porteurs qui font des mises à jour indépendantes
2929 sources doivent choisir une gravité <em>sérieuse</em> (i.e. <em>serious</em>)
2930 ou supérieure quand ils envoient leur rapport au système de suivi des bogues.
2931 Ceci assure qu'un paquet source unique permet de produire un paquet binaire
2932 pour chaque architecture supportée au moment de la sortie de la distribution.
2933 Il est très important d'avoir un paquet source et un paquet binaire pour
2934 toutes les architectures pour être conforme à plusieurs licences.
2936 Les porteurs doivent éviter d'implémenter des contournements pour des bogues de
2937 l'environnement de compilation, du noyau ou de la libc. Quelques fois, ces
2938 contournements sont inévitables. Si vous devez faire quelque chose de ce
2939 genre, marquez proprement vos modifications avec des <tt>#ifdef</tt> et
2940 documentez votre contournement pour que l'on sache le retirer une fois que le
2941 problème aura disparu.
2943 Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de leur
2944 travail pendant le délai d'attente. Ainsi, d'autres personnes peuvent
2945 bénéficier du travail du porteur même pendant ce délai. Bien sûr, ces
2946 adresses n'ont rien d'officiel, alors soyez sur vos gardes si vous les
2950 <sect1 id="porter-automation">
2951 <heading>Infrastructure de portage et automatisation</heading>
2953 Il existe une infrastructure et plusieurs outils pour faciliter l'automatisation
2954 du portage des paquets. Cette section contient un bref aperçu de cette
2955 automatisation et du portage de ces outils ; veuillez vous reporter à la
2956 documentation des paquets ou les références pour une information complète.</p>
2959 <heading>Listes de diffusion et pages web</heading>
2961 Les pages web contenant l'état de chaque portage peuvent être trouvées à <url
2962 id="&url-debian-ports;">.
2964 Chaque portage de Debian possède sa propre liste de diffusion. La liste des
2965 listes de diffusion de portage peut être trouvée à <url
2966 id="&url-debian-port-lists;">. Ces listes sont utilisées pour coordonner les
2967 porteurs et pour mettre en relation les utilisateurs d'un portage donné avec les
2972 <heading>Outils pour les porteurs</heading>
2974 Les descriptions de plusieurs outils de portage peuvent être trouvées dans les
2975 <ref id="tools-porting">.</p>
2979 <heading><package>buildd</package></heading>
2981 Le système <package>buildd</package> est un système distribué pour la
2982 compilation d'une distribution. Il est habituellement utilisé en conjonction
2983 avec des automates de compilation ; ce sont des machines
2984 « esclaves » qui récupèrent des paquets sources et tentent de les
2985 compiler. Il est aussi possible d'interagir par courrier électronique avec ce
2986 système. Cette interface est utilisée par les porteurs pour récupérer un
2987 paquet source (en général, un paquet qui ne peut être compilé
2988 automatiquement) et travailler dessus.
2990 <package>buildd</package> n'est pas disponible sous forme de paquet ;
2991 pourtant, la plupart des équipes de porteurs l'utilisent aujourd'hui ou ont
2992 prévu de l'utiliser bientôt. L'outil de construction automatisé réel est dans
2993 le paquet <package>sbuild</package>, voir la description dans <ref
2994 id="sbuild">. Le système <package>buildd</package> regroupe également un
2995 ensemble de composants très utiles, continuellement utilisés, mais non encore
2996 mis en paquet, tels que <prgn>andrea</prgn> et <prgn>wanna-build</prgn>.
2998 Une partie des informations produites par <package>buildd</package>
2999 — utiles pour les porteurs — est disponible sur la
3000 toile à l'adresse <url id="&url-buildd;">. Ces informations
3001 incluent les résultats produits toutes les nuits par
3002 <prgn>andrea</prgn> (dépendances des sources) et
3003 <prgn>quinn-diff</prgn> (paquets à recompiler).
3005 Nous sommes très fiers de ce système car il a de nombreux usages potentiels. Des
3006 groupes de développeurs indépendants peuvent utiliser ce système pour créer
3007 différentes saveurs de Debian — qui peuvent être ou ne pas être
3008 intéressantes pour tous (par exemple, une version de Debian compilée avec des
3009 vérifications relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi
3010 de recompiler rapidement toute une distribution.
3013 <sect id="nmu">Mise à jour indépendante
3015 Dans certaines circonstances, il est nécessaire qu'une personne autre que le
3016 responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de
3017 mise à jour est désigné en anglais par l'expression <em>non-maintainer
3018 upload (NMU)</em>. Dans le présent document, nous traduisons librement
3019 cette expression par « mise à jour indépendante ».
3021 Cette section ne traite que des mises à jour indépendantes de source, c.-à-d.,
3022 les mises à jour qui envoient une nouvelle version d'un paquet. Pour les
3023 mises à jour indépendantes par des porteurs ou des membres de la QA,
3024 veuillez consulter <ref id="binary-only-nmu">. Pour les envois buildd (qui
3025 sont également strictement parlant des NMU), veuillez consulter <ref
3028 La raison principale pour laquelle une mise à jour indépendante est réalisée est
3029 quand un développeur a besoin de corriger des paquets d'un autre
3030 développeur pour résoudre des problèmes sérieux ou des bogues paralysants
3031 ou quand le responsable d'un paquet ne peut pas
3032 fournir une correction dans un délai raisonnable.
3034 Tout d'abord, il est capital que ces mises à jour indépendantes soient aussi peu
3035 intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
3036 modules ou des fichiers, ne déplacez pas les répertoires ; plus
3037 généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi
3038 petit que possible. Si certaines choses froissent votre sens de l'esthétique,
3039 parlez-en au responsable du paquet, au responsable amont ou soumettez un
3040 rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
3041 pas</em> être effectués lors d'une mise à jour indépendante.
3044 Et souvenez-vous du Serment d'Hippocrate « Par dessus tout, ne pas
3045 faire de mal ». Il est préférable qu'un paquet ait un bogue ouvert grave
3046 plutôt qu'un correctif non fonctionnel soit appliqué et que le bogue devienne
3047 caché, mais toujours non résolu.
3049 <sect1 id="nmu-guidelines">Comment faire une mise à jour indépendante ?
3051 Les mises à jour indépendantes qui corrigent des bogues de gravité importante,
3052 sérieuse et plus élevée sont encouragées et acceptées. Vous devriez vous
3053 efforcer de contacter le responsable actuel du paquet : il est peut-être
3054 sur le point d'envoyer un correctif pour le problème ou il a peut-être une
3057 Les mises à jour indépendantes doivent être réalisées pour assister un
3058 responsable de paquet à résoudre des bogues. Les responsables devraient être
3059 reconnaissants pour cette aide et les personnes faisant la mise à jour
3060 indépendante devraient respecter les décisions du responsable et tenter
3061 d'aider personnellement le responsable dans son travail.
3063 Une mise à jour indépendante devrait suivre toutes les conventions décrites dans
3064 cette section. Pour un envoi vers <em>testing</em> ou <em>unstable</em>, l'ordre
3065 suivant des étapes est recommandé :
3069 <item>Vérifiez que les bogues du paquet qui devraient être corrigés par la
3070 mise à jour indépendante sont bien référencés dans le système de suivi des
3071 bogues. S'ils n'y sont pas, faites des rapports de bogue
3073 <item>Attendez la réponse du responsable quelques jours. Si vous n'obtenez
3074 aucune réponse, vous pouvez l'aider en lui envoyant le correctif qui
3075 corrige le bogue. N'oubliez pas de marquer le bogue avec le mot-clé
3076 « patch ».
3077 <item>Patientez quelques jours. Si vous n'avez toujours aucune réponse du
3078 responsable, envoyez-lui un courrier annonçant votre intention
3079 d'effectuer une mise à jour indépendante du paquet. Préparez la NMU comme
3080 décrit dans <ref id="nmu-guidelines">, testez-la soigneusement sur votre
3081 machine (cf. <ref id="sanitycheck">). Re-vérifiez que votre correctif
3082 n'a aucun effet de bord inattendu. Assurez-vous que votre correctif est
3083 aussi minimaliste et non intrusif que possible.
3084 <item>Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file> (cf.
3085 <ref id="delayed-incoming">), envoyez le correctif final au responsable
3086 par le BTS et expliquez-lui qu'il a 7 jours pour réagir s'il veut annuler
3088 <item>Suivez ce qui se passe, vous êtes responsable pour tout bogue que vous
3089 auriez introduit avec votre NMU. Vous devriez probablement utiliser le
3090 <ref id="pkg-tracking-system"> (PTS) pour vous tenir informé de l'état du
3091 paquet après votre NMU.
3094 Parfois, le responsable de version ou un groupe organisé de
3095 développeurs peut annoncer une certaine période de temps au cours de laquelle
3096 les règles de mise à jour indépendante seront plus souples. Ceci implique
3097 habituellement une période plus courte d'attente avant d'envoyer des
3098 correctifs et une période de délai plus courte. Il est important de noter que,
3099 même au cours de ces « chasses aux bogues », la personne
3100 désirant faire la mise à jour indépendante doit remplir des bogues et
3101 contacter en premier le développeur, et ensuite seulement passer à
3104 Veuillez vous reporter à <ref id="qa-bsp"> pour des détails.
3106 Pour la distribution <em>testing</em>, les règles peuvent être changées par les
3107 responsables de diffusion. Veuillez porter une attention spéciale au fait que le
3108 moyen habituel pour un paquet d'entrer dans <em>testing</em> est de passer par
3111 Pour la distribution <em>stable</em>, veuillez y apporter une attention
3112 supplémentaire. Bien sûr, les responsables de version peuvent également modifier
3113 les rêgles ici. Veuillez vérifier avant l'envoi que tous vos changements sont
3114 acceptables pour inclusion dans la prochaine version stable par le responsable
3117 Quand un bogue de sécurité est détecté, l'équipe de sécurité peut effectuer une
3118 mise à jour indépendante en utilisant ses propres règles. Veuillez vous référer
3119 à <ref id="bug-security"> pour plus d'informations.
3121 Pour les différences pour les mises à jour indépendantes par les porteurs,
3122 veuillez voir <ref id="source-nmu-when-porter">.
3124 Bien sûr, il est toujours possible de s'accorder avec un responsable pour des
3125 règles spéciales (comme quand le responsable demande « merci d'envoyer le
3126 correctif directement pour moi et pas de diff nécessaire »).
3128 <sect1 id="nmu-version">Numéro de version pour les mises à jour
3131 Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
3132 changer, même pour la plus triviale des modifications. Notre système de
3133 gestion de paquets s'appuie sur ces numéros de version.
3135 Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
3136 un numéro de version mineur à la partie <var>révision-debian</var> du numéro
3137 de version (la partie qui suit le dernier trait d'union). Ce numéro
3138 supplémentaire débutera à « 1 ». Prenons pour exemple le paquet
3139 « foo » qui porte le numéro de version 1.1-3. Dans l'archive, le
3140 fichier de contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
3141 version amont est « 1.1 » et la révision Debian est
3142 « 3 ». La mise à jour indépendante suivante ajouterait le numéro de
3143 version mineur « .1 » au numéro de révision Debian ; le nouveau
3144 fichier de contrôle du paquet source serait alors
3145 <file>foo_1.1-3.1.dsc</file>.
3147 Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro de
3148 version au responsable officiel du paquet, ce qui pourrait perturber son
3149 travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas
3150 été livré par le responsable officiel.
3152 S'il n'y a pas de partie <var>révision-debian</var> dans le numéro de version du
3153 paquet, il faut en créer une en démarrant à « 0.1 ». S'il est
3154 absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
3155 fasse une livraison basée sur une nouvelle version amont, cette personne doit
3156 choisir « 0.1 » comme numéro de révision Debian. Le mainteneur du
3157 paquet doit, lui, démarrer sa numérotation à « 1 ».
3159 Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>, vous devrez
3160 parfois créer une branche (« fork ») dans l'arbre de numéro des version. Pour cela, vous
3161 pouvez utiliser des numéros de version comme 1.1-3sarge0.1.
3164 <sect1 id="nmu-changelog">
3165 <heading>Les mises à jour indépendantes sources doivent être
3166 mentionnées dans le fichier changelog</heading>
3168 Une personne qui fait une mise à jour indépendante source doit ajouter une
3169 entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
3170 et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
3171 comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
3174 Par convention, dans le cas d'une mise à jour indépendante source
3175 <em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne :
3178 * Non-maintainer upload
3182 <sect1 id="nmu-patch">Mise à jour indépendante source et système de
3185 Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
3186 modifications que possible et doit toujours envoyer ses modifications au
3187 système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).
3189 Et si vous recompilez simplement le paquet ? Si vous avez simplement besoin
3190 de recompiler le paquet pour une seule architecture, vous pouvez faire une
3191 NMU binaire seulement comme décrit dans <ref id="binary-only-nmu"> qui ne
3192 nécessite pas qu'un correctif soit envoyé. Si vous désirez que le paquet soit
3193 recompilé pour toutes les architectures, vous devez alors faire une NMU
3194 source et vous devrez envoyer un correctif.
3196 Si la mise à jour indépendante source (<em>source NMU</em>) corrige des bogues,
3197 ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système de
3198 suivi des bogues plutôt que clos. Par convention, seul le responsable du
3199 paquet et la personne qui a ouvert le rapport de bogue ferment les
3200 rapports. Heureusement, le système d'archivage Debian reconnaît les mises à
3201 jours indépendantes et positionne correctement le statut des bogues à
3202 <em>fixed</em> si la personne qui fait la mise à jour a listé tous les bogues
3203 dans le fichier changelog en utilisant la syntaxe <tt>Closes:
3204 bug#<var>nnnnn</var></tt> (voir <ref id="upload-bugfix"> pour en savoir plus
3205 sur la fermeture de bogue par le fichier <file>changelog</file>). Ce passage
3206 au statut <em>fixed</em> assure que chacun sait que le bogue est corrigé par
3207 une mise à jour indépendante tout en laissant le rapport de bogue ouvert
3208 jusqu'à ce que le responsable du paquet incorpore les modifications de cette
3209 mise à jour dans la version officielle du paquet.
3211 Après avoir fait une mise à jour indépendante, il vous faudra aussi envoyer
3212 cette information aux bogues existants que vous avez corrigés par votre NMU
3213 en incluant le diff unifié. Sinon, vous pouvez créer un nouveau rapport de
3214 bogue et inclure un correctif comprenant toutes les modifications que vous
3215 avez réalisées. Le responsable officiel
3216 pourra choisir d'appliquer le correctif, il pourra aussi employer une autre
3217 méthode pour régler le problème. Certains bogues sont corrigés dans la
3218 version amont, ce qui est une bonne raison pour annuler les modifications
3219 d'une mise à jour indépendante. Si le responsable choisit de mettre à jour le
3220 paquet plutôt que d'utiliser les correctifs de la mise à jour indépendante,
3221 il devra s'assurer que cette nouvelle version corrige effectivement chacun
3222 des bogues corrigés dans la mise à jour indépendante.
3224 De plus, le responsable officiel devrait <em>toujours</em> conserver les entrées
3225 documentant une mise à jour indépendante dans le fichier
3226 <file>changelog</file>.
3229 <sect1 id="nmu-build">Fabriquer une mise à jour indépendante source
3231 Les paquets faisant l'objet d'une mise à jour indépendante source sont
3232 construits comme les autres. Sélectionnez une distribution en utilisant les
3233 règles décrites dans la section <ref id="distribution"> en suivant toutes les
3234 prescriptions de la section <ref id="upload">.
3236 Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt> dans
3237 le fichier <file>debian/control</file>. Votre nom, mentionné dans l'entrée du
3238 fichier <file>debian/changelog</file> concernant la mise à jour, sera utilisé
3239 pour signer le fichier <file>.changes</file>.
3241 <sect1 id="ack-nmu">Valider une mise à jour indépendante
3243 Si l'un de vos paquets a subi une mise à jour indépendante, vous devez récupérer
3244 les changements dans votre copie des sources. Ceci est aisé, vous avez
3245 simplement à appliquer le correctif qui vous a été envoyé. Une fois ceci fait,
3246 vous devez fermer les bogues qui ont été marqués comme fixés par la mise à
3247 jour. Le moyen le plus simple est d'utiliser l'option <tt>-v</tt> de
3248 <prgn>dpkg-buildpackage</prgn> car cela vous permet d'inclure tous les
3249 changements depuis votre dernier envoi de responsable. Sinon, vous pouvez soit
3250 les fermer manuellement en envoyant les courriers
3251 nécessaires au BTS soit ajouter les <tt>closes: #nnnn</tt> nécessaires dans
3252 l'entrée du changelog de votre prochain envoi.
3254 Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une NMU n'est
3255 pas une attaque personnelle contre le responsable. C'est une preuve que le
3256 paquet est important pour quelqu'un et qu'il est désireux de vous aider dans
3257 votre travail, vous devriez donc lui être reconnaissant. Vous pouvez également
3258 lui demander s'il serait intéressé pour vous aider sur une base plus régulière
3259 comme co-responsable ou responsable de secours (cf. <ref
3260 id="collaborative-maint">).
3262 <sect1 id="nmu-vs-qa">Mise à jour indépendante ou envoi de QA ?
3264 Sauf si vous savez que le responsable est toujours actif, il est sage de
3265 vérifier le paquet pour voir s'il n'a pas été abandonné. La liste actuelle des
3266 paquets orphelins pour lesquel le champ responsable n'a pas été positionné
3267 correctement est disponible à <url id="&url-debian-qa-orphaned;">. Si vous
3268 effectuez une mise à jour indépendante sur un paquet incorrectement orphelin,
3269 veuillez positionner le responsable à « Debian QA Group
3270 <packages@qa.debian.org> ».
3272 <sect1 id="nmu-who">Qui peut faire une mise à jour indépendante ?
3274 Seuls les responsables Debian officiels peuvent faire des mises à jour
3275 indépendantes binaire ou source. Un responsable officiel est une personne dont la clé est dans le
3276 porte-clés Debian. Tout autre personne est toutefois invitée à télécharger les paquets sources
3277 pour corriger des bogues ; au lieu de faire des mises à jour
3278 indépendantes, ils pourront soumettre les correctifs qui le méritent au système
3279 de suivi des bogues. Les responsables apprécient presque toujours les
3280 correctifs et les rapports de bogue soignés.
3282 <sect1 id="nmu-terms">Terminologie
3284 Deux nouvelles expressions sont introduites dans cette section :
3285 « mise à jour indépendante source » et « mise à jour
3286 indépendante binaire ». Ces deux expressions ont une signification
3287 technique précise dans ce document. Elles correspondent toutes deux au même type d'activité ;
3288 elles impliquent toutes deux qu'une personne fait une mise à jour d'un paquet
3289 alors qu'elle n'est pas officiellement responsable de ce paquet. C'est pourquoi
3290 nous qualifions ces mises à jours
3291 d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser
3292 entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas
3293 question d'agir sans prévenir le responsable au préalable (voir <ref
3294 id="nmu-guidelines">).</footnote>.
3296 Une mise à jour indépendante source est une livraison de paquet faite par une
3297 personne qui n'est pas le responsable officiel de ce paquet avec pour objectif
3298 de corriger un bogue dans le paquet. Une mise à jour indépendante source
3299 implique toujours une modification des sources du paquet, même s'il ne s'agit
3300 que d'un changement dans le fichier <file>debian/changelog</file>. Ce
3301 changement peut tout aussi bien concerner la partie amont du source que la
3302 partie spécifique à Debian. Une mise à jour indépendante source peut aussi
3303 inclure des paquets spécifiques à une architecture tout comme un fichier
3304 <em>diff</em> modifié.
3306 Une mise à jour indépendante binaire est constitué par la recompilation et
3307 l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du
3308 résultat d'un effort de portage. Une mise à jour indépendante binaire est la
3309 livraison d'un paquet compilé (souvent pour une autre architecture) à condition
3310 que cette compilation n'ait pas nécessité de modifications des sources. Dans de
3311 nombreux cas, les porteurs sont obligés de modifier les sources pour les rendre
3312 compilables sur leur architecture cible ; il s'agira alors d'une mise à
3313 jour indépendante source et non d'une mise à jour indépendante binaire. Comme
3314 vous pouvez le remarquer, nous ne faisons pas de distinction entre les mises à
3315 jour indépendantes faites par des porteurs et les autres mises à jour
3318 Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
3319 par l'expression « mise à jour indépendante »
3320 (NMU<footnote><p>Non-maintainer upload</footnote>). Pourtant, cela conduit
3321 souvent à des confusions car beaucoup associent « mise à jour
3322 indépendante » et « mise à jour indépendante source ». Il faut
3323 donc rester vigilant. Il est préférable de toujours utiliser « mise à jour
3324 indépendante binaire » ou «NMU binaire » pour les mises à jour
3325 indépendantes de binaires seuls.
3328 <sect id="collaborative-maint">
3329 <heading>Maintenance collective</heading>
3331 « Maintenance collective » est un terme décrivant le partage des
3332 devoirs de la maintenance d'un paquet Debian par plusieurs personnes. Cette
3333 collaboration est presque toujours une bonne idée car il en résulte
3334 généralement une meilleure qualité et un temps de correction de bogues plus
3335 petit. Il est fortement recommandé que les paquets de priorité
3336 <tt>Standard</tt> ou qui font partie de la base aient des co-responsables.
3338 Habituellement, il y a un responsable principal et un ou plusieurs
3339 co-responsables. Le responsable principal est la personne dont le nom est indiqué
3340 dans le champ <tt>Maintainer</tt> du fichier <file>debian/control</file>. Les
3341 co-responsables sont tous les autres responsables.
3343 Dans sa forme la plus simple, ajouter un nouveau co-responsable est assez
3346 <item><p> Donner au co-responsable un accès aux sources à partir desquelles vous
3347 construisez le paquet. Habituellement, cela implique que vous utilisiez un
3348 système de contrôle de version comme <prgn>CVS</prgn> ou
3349 <prgn>Subversion</prgn>.
3351 <item><p> Ajouter les nom et adresse correctes du co-responsable au champ
3352 <tt>Uploaders</tt> dans la partie globale du fichier
3353 <file>debian/control</file>.
3355 Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
3359 En utilisant le PTS (<ref id="pkg-tracking-system">), les
3360 co-responsables devraient s'inscrire eux-mêmes aux paquets sources
3365 La maintenance collaborative peut souvent être facilitée par l'utilisation
3366 d'outils sur Alioth (voir <ref id="alioth">).
3370 <heading>La distribution <em>testing</em></heading>
3372 <sect1 id="testing-basics">
3373 <heading>Bases</heading>
3375 Les paquets sont habituellement installés dans la distribution <em>testing</em>
3376 après avoir atteint un certain degré de test dans <em>unstable</em>.
3378 Ils doivent être en synchronisation pour toutes les architectures et ne doivent
3379 pas avoir de dépendances qui les rendraient ininstallables ; ils doivent
3380 également n'avoir aucun bogue bloquant l'inclusion du paquet dans une version
3381 stable (« release-critical ») au moment où ils sont installés dans
3382 <em>testing</em>. Ainsi, <em>testing</em> devrait toujours être prête pour être
3383 une version candidate stable. Veuillez voir ci-dessous pour les détails.
3385 <sect1 id="testing-unstable">
3386 <heading>Mises à jour depuis <em>unstable</em></heading>
3388 Les scripts qui mettent à jour la distribution <em>testing</em> sont exécutés
3389 chaque jour après l'installation des paquets mis à jour. Ils fabriquent les
3390 fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils
3391 le font d'une manière intelligente pour éviter toute incohérence et essayer de
3392 n'utiliser que des paquets sans bogue.
3394 L'inclusion d'un paquet d'<em>unstable</em> est soumise aux conditions
3398 Le paquet doit avoir été disponible dans <em>unstable</em> depuis 2, 5 ou
3399 10 jours selon le champ d'urgence de l'envoi (élevée, moyenne ou basse).
3400 Veuillez noter que cette urgence est « collande » (« sticky »), ce qui
3401 veut dire que l'envoi avec l'urgence la plus élevée depuis la dernière
3402 transition dans <em>testing</em> est prise en compte. Ces délais peuvent être
3403 doublés lors d'un gel de distribution, ou la transition dans <em>testing</em>
3404 peut être complètement désactivée ;
3406 Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
3407 version disponible dans <em>testing</em> ;
3409 Il doit être disponible pour toutes les architectures pour lesquelles
3410 il a été auparavant construit. <ref id="madison"> peut être
3411 intéressant pour vérifier cette information ;
3413 Il ne doit pas casser les dépendances d'un paquet qui est déjà
3414 disponible dans <em>testing</em> ;
3416 Les paquets dont il dépend doivent soit être déjà disponibles dans
3417 <em>testing</em> soit être acceptés dans <em>testing</em> au
3418 même moment (et ils doivent respecter tous les critères nécessaires).
3421 Pour savoir si un paquet a progressé ou non dans <em>testing</em>, veuillez voir la
3422 sortie du script de <em>testing</em> sur la <url name="page web de la distribution testing"
3423 id="&url-testing-maint;"> ou utilisez le programme <prgn>grep-excuses</prgn>
3424 inclus dans le paquet <package>devscripts</package>. Si l'on veut rester
3425 informé de la progression de ses paquets dans <em>testing</em>, on peut
3426 facilement le mettre dans la <manref section="5" name="crontab">.
3428 Le fichier <file>update_excuses</file> ne donne pas toujours la raison précise
3429 pour laquelle un paquet est refusé, on peut avoir à la chercher soi-même en
3430 regardant ce qui serait cassé avec l'inclusion du paquet. La <url
3431 id="&url-testing-maint;" name="page web de la distribution testing"> donne plus
3432 d'informations à propos des problèmes courants qui peuvent occasionner cela.
3434 Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce que le
3435 jeu des inter-relations est trop compliqué et ne peut être résolu par le
3436 script. Voir ci-dessous pour des détails.
3438 Des analyses de dépendances plus avancées sont présentées sur
3439 <url id="http://bjorn.haxx.se/debian/"> – mais, attention, elles affichent
3440 également les dépendances de construction qui ne sont pas considérées par
3443 <sect2 id="outdated">
3444 <heading>Désynchronisation</heading>
3446 Pour le script de migration dans <em>testing</em>, « désynchronisé »
3447 (<em>outdated</em> veut dire ceci : il y a différentes versions dans
3448 <em>unstable</em> pour les architectures de version (à l'exception des
3449 architectures dans fuckedarches ; fuckedarches est une liste des
3450 architectures qui ne suivent pas le rythme (dans update_out.py), mais
3451 actuellement cette liste est vide). « Désynchronisé » n'a rien à voir
3452 avec les architectures que le paquet fournit pour <em>testing</em>.
3454 Considérons cet exemple :
3458 ---------+-------+----
3463 Le paquet est désynchronisé pour alpha dans <em>unstable</em> et n'entrera pas
3464 dans <em>testing</em>. Supprimer foo de <em>testing</em> n'aiderait en rien, le
3465 paquet serait toujours désynchronisé pour alpha et ne se propagerait pas dans
3468 Cependant, si ftp-master supprime un paquet d'<em>unstable</em> (ici pour arm) :
3471 foo | alpha | arm | hurd-i386
3472 ---------+-------+-----+----------
3474 unstable | 2 | - | 1
3477 Dans ce cas, le paquet est synchronisé pour toutes les architectures de version
3478 dans <em>unstable</em> (et l'architecture supplémentaire hurd-i386 ne compte pas
3479 car ce n'est pas une architecture de version).
3481 Quelquefois, la question est soulevée pour savoir s'il est possible de permettre
3482 à des paquets de passer dans <em>testing</em> qui ne sont pas encore construits
3483 pour toutes les architectures : non. Simplement non. (Excepté si vous êtes
3484 responsable de glibc ou équivalent).
3486 <sect2 id="removals">
3487 <heading>Suppressions de <em>testing</em></heading>
3489 Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre
3490 paquet : ceci ne se produit que pour permettre à un <em>autre</em> paquet
3491 d'entrer, ce dernier paquet doit être prêt pour tous les autres critères.
3492 Considérons par exemple qu'un paquet a est en conflit avec la nouvelle version
3493 de b alors a peut être supprimé pour permettre l'entrée de b.
3495 Bien sûr, il existe une autre raison pour supprimer un paquet de
3496 <em>testing</em> : le paquet est trop bogué (et avoir un seul bogue RC est
3497 suffisant pour être dans cet état).
3499 <sect2 id="circular">
3500 <heading>Dépendances circulaires</heading>
3502 Une situation qui n'est pas très bien gérée par britney est si un paquet a
3503 dépend de la nouvelle version d'un paquet b et vice versa.
3505 Voici un exemple :
3508 | testing | unstable
3509 --+-----------------+------------
3510 a | 1; dépend: b=1 | 2; dépend: b=2
3511 b | 1; dépend: a=1 | 2; dépend: a=2
3514 Le paquet a n'est pas considéré pour la mise à jour, le paquet b non plus.
3516 Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de
3517 diffusion. Veuillez les contacter en envoyant un courrier électronique à
3518 debian-release@lists.debian.org si cela se produit pour l'un de vos paquets.
3522 <heading>Influence de paquet dans <em>testing</em></heading>
3524 Généralement, l'état d'un paquet dans <em>testing</em> ne change rien pour la
3525 transition de la prochaine version d'<em>unstable</em> vers <em>testing</em>,
3526 avec deux exceptions : si le nombre de bogues RC du paquet est réduit, le
3527 paquet peut migrer même s'il a encore des bogues RC. La seconde exception est
3528 que si la version du paquet dans <em>testing</em> est désynchronisée entre les
3529 différentes architectures, alors toute architecture peut être mise à jour vers
3530 la version du paquet source ; cependant, cela ne peut se produire que si le
3531 paquet a été précédemment forcé, si l'architecture est dans fuckedarches ou s'il
3532 n'y avait pas du tout de paquet binaire de cette architecture présent dans
3533 <em>unstable</em> lors de la migration dans <em>testing</em>.
3535 En résumé, cela veut dire : la seule influence qu'un paquet de
3536 <em>testing</em> a sur la nouvelle version du même paquet est que la nouvelle
3537 version peut rentrer plus facilement.
3539 <sect2 id="details">
3540 <heading>Détails</heading>
3542 Si vous êtes intéressé par les détails, voici comment fonctionne britney :
3544 Les paquets sont examinés pour savoir si ce sont des candidats valides. Cela
3545 donne le fichier « update excuses ». Les raisons les plus communes
3546 pour lesquelles un paquet n'est pas considéré sont la jeunesse du paquet, le
3547 nombre de bogues RC et la désynchronisation pour certaines architectures. Pour
3548 cette partie, les responsables de version ont des marteaux de toute taille pour
3549 forcer britney à considérer un paquet. (Le gel de la base est également codé
3550 dans cette partie de britney.) (Il y a une chose semblable pour les mises à jour
3551 binaires pures, mais cela n'est pas décrit ici. Si vous êtes intéressé par cela,
3552 veuillez utiliser le code.)
3554 Maintenant, la partie la plus complexe se produit : britney tente de mettre
3555 à jour <em>testing</em> avec des candidats valides ; en premier, chaque
3556 paquet individuellement, puis des groupes de plus en plus larges de paquets
3557 ensemble. Chaque tentative est acceptée si <em>testing</em> n'est pas moins
3558 ininstallable après la mise à jour qu'avant celle-ci. (Avant et après cette
3559 partie, certains coups de pouce sont traités ; mais, comme seuls les
3560 responsables de version peuvent positionner des coups de pouce, cela n'est
3561 probablement pas très important pour vous.)
3563 Si vous voulez voir plus de détails, vous pouvez le voir dans
3564 merkel:/org/ftp.debian.org/testing/update_out/ (ou dans
3565 ~aba/testing/update_out pour voir une configuration avec un fichier de paquets
3566 plus petit). Par le web, c'est à <url
3567 id="http://ftp-master.debian.org/testing/update_out_code/">.
3569 Les coups de pouce sont visibles sur <url
3570 id="http://ftp-master.debian.org/testing/hints/">.
3574 <heading>Mises à jour directes dans <em>testing</em></heading>
3576 La distribution <em>testing</em> est peuplée avec des paquets en provenance
3577 d'<em>unstable</em> selon des règles expliquées ci-dessus. Cependant, dans
3578 certains cas, il est nécessaire d'envoyer des paquets construits seulement pour
3579 <em>testing</em>. Pour cela, vous pouvez envoyer vos paquets vers
3580 <em>testing-proposed-updates</em>.
3582 Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement,
3583 ils doivent passer entre les mains du responsable de distribution. Vous devez
3584 donc avoir une bonne raison pour les y envoyer. Pour savoir ce que
3585 représente une bonne raison aux yeux du responsable de distribution, vous
3586 devriez lire les instructions données qu'il envoie régulièrement sur
3587 &email-debian-devel-announce;.
3589 Vous ne devriez pas envoyer un paquet à <em>testing-proposed-updates</em> quand
3590 vous pouvez le mettre à jour par <em>unstable</em>. Si vous ne pouvez faire
3591 autrement (par exemple, parce que vous avez une nouvelle version de
3592 développement dans <em>unstable</em>), vous pouvez l'utiliser, mais il est
3593 recommandé de demander l'autorisation du responsable de distribution auparavant.
3594 Même si un paquet est gelé, des mises à jour par <em>unstable</em> sont possibles
3595 si l'envoi dans <em>unstable</em> ne tire pas de nouvelle dépendance.
3597 Les numéros de version sont habituellement choisis en ajoutant le nom de
3598 code de la distribution <em>testing</em> et un numéro d'incrémentation, comme
3599 1.2sarge1 pour le premier envoi dans <em>testing-proposed-updates</em> du paquet
3600 en version 1.2.
3604 <heading>Questions fréquemment posées</heading>
3608 <heading>Qu'est-ce que sont les bogues bloquant l'intégration dans la
3609 version stable et comment sont-ils comptés ?</heading>
3611 Tous les bogues de gravité assez élevée sont par défaut considérés
3612 comme bloquant l'intégration du paquet dans la version stable ;
3613 actuellement, ce sont les bogues critiques, graves et sérieux.
3615 Certains bogues sont supposés avoir un impact sur les chances que le paquet a
3616 d'être diffusé dans la version stable de Debian : en général, si un paquet
3617 a des bogues bloquants, il n'ira pas dans <em>testing</em> et par conséquent,
3618 ne pourra pas être diffusé dans <em>stable</em>.
3620 Le compte des bogues de <em>testing</em> pour un paquet est considéré comme
3621 étant à peu près le nombre de bogue lors du dernier pointage quand la version
3622 <em>testing</em> a été égale à la version <em>unstable</em>. Les bogues marqués
3623 <em>woody</em> ou <em>sarge</em> ne sont pas comptés. Cependant les bogues
3624 marqués <em>sid</em> sont comptés.
3628 <heading>Comment est-ce que l'installation d'un paquet dans
3629 <em>testing</em> peut casser d'autres paquets ?</heading>
3631 La structure des archives de la distribution est faite de telle façon qu'elles
3632 ne peuvent contenir qu'une version d'un paquet ; un paquet est défini par
3633 son nom. Donc, quand le paquet source acmefoo est installé dans
3634 <em>testing</em> avec ses paquets binaires acme-foo-bin, acme-bar-bin,
3635 libacme-foo1 et libacme-foo-dev, l'ancienne version est supprimée.
3638 Cependant, l'ancienne version pouvait fournir à un paquet binaire un vieux
3639 soname d'une bibliothèque, comme libacme-foo0. Supprimer l'ancien acmefoo va
3640 supprimer libacme-foo0, ce qui va casser tout paquet qui en dépend.
3642 Évidemment, cela touche principalement des paquets qui fournissent des jeux
3643 changeants de paquets binaires dans différentes version (par suite,
3644 principalement des bibliothèques). Cependant, cela va aussi toucher des paquets
3645 sur lesquels une dépendance versionnée a été déclarée du type ==, <= ou <<.
3647 Quand le jeu de paquets binaires fournis par un paquet source change de cette
3648 façon, tous les paquets qui dépendent des anciens binaires doivent être mis à
3649 jour pour dépendre de la nouvelle version à la place. Comme l'installation d'un
3650 tel paquet source dans <em>testing</em> casse tous les paquets qui en dépendent
3651 dans <em>testing</em>, une certaine attention doit y être portée : tous les
3652 paquets en dépendant doivent être mis à jour et prêts à être installés eux-même
3653 pour qu'ils ne cassent pas et, une fois que tout est prêt, une intervention
3654 manuelle du responsable de version ou d'un de ses assistants est normalement
3657 Si vous avez des problèmes avec des groupes compliqués de paquets comme ceci,
3658 contactez debian-devel ou debian-release en demandant de l'aide.
3662 <chapt id="best-pkging-practices">
3663 <heading>Les meilleurs pratiques pour la construction des paquets
3665 La qualité de Debian est principalement due à la <url id="&url-debian-policy;"
3666 name="charte Debian"> qui définit explicitement les obligations que tous les
3667 paquets doivent suivre. Mais c'est également grâce à une histoire partagée
3668 d'expériences qui va au-delà de la charte Debian, une accumulation d'années
3669 d'expérience pour la construction des paquets ; des développeurs de grand
3670 talent ont créé de bons outils qui vous aideront, vous, responsable Debian, à
3671 créer et maintenir d'excellents paquets.
3674 Ce chapitre fournit les meilleurs pratiques pour les développeurs Debian. Ce ne
3675 sont que des recommandations, non pas des obligations ou des règles. Ce sont
3676 seulement des astuces et conseils subjectifs et des liens collectés pour les
3677 développeurs Debian. Prenez et choisissez ce qui vous convient le mieux.
3679 <sect id="bpp-debian-rules">
3680 <heading>Les meilleures pratiques pour le fichier <file>debian/rules</file></heading>
3682 Les recommandations suivantes s'appliquent au fichier <file>debian/rules</file>.
3683 Comme ce fichier contrôle le processus de compilation et qu'il sélectionne les
3684 fichiers inclus dans le paquet (directement ou indirectement), il s'agit
3685 habituellement du fichier sur lequel les responsables passent le plus de temps.
3688 <sect1 id="helper-scripts">Scripts d'aide
3690 La raison sous-jacente à l'utilisation des scripts d'aide dans le fichier
3691 <file>debian/rules</file> est que cela permet aux responsables d'utiliser et de
3692 partager une logique commune pour un grand nombre de paquets. Prenez, par
3693 exemple, l'installation des entrées de menu : vous avez besoin de
3694 placer un fichier dans <file>/usr/lib/menu</file> et d'ajouter des commandes aux
3695 scripts de maintenance pour enregistrer et désenregistrer ces entrées de menu.
3696 Comme il s'agit d'une chose très commune, pourquoi chaque
3697 responsable devrait-il écrire sa propre version, parfois avec des bogues ?
3698 Supposons également que le répertoire de menu soit modifié, chaque paquet
3699 devrait être modifié.
3701 Les scripts d'aide peuvent résoudre ces problèmes. En supposant que vous vous
3702 conformiez aux conventions attendues par le script d'aide, celui-ci prend soin
3703 de tous les détails. Les changements dans la charte peuvent alors être faits
3704 dans le script d'aide, les paquets ont alors simplement besoin d'être
3705 reconstruits avec la nouvelle version du script et sans aucun changement
3708 L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus
3709 courant et le meilleur (à notre avis) système est <package>debhelper</package>.
3710 Les précédents systèmes d'aide comme <package>debmake</package> étaient
3711 « monolithiques » : vous ne pouviez pas choisir quelles parties
3712 intéressantes vous pouviez utiliser, mais vous étiez obligé de choisir le
3713 système pour tout faire. <package>debhelper</package>, à l'inverse, consiste en
3714 un certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple,
3715 <prgn>dh_installman</prgn> installe et compacte les pages de manuel,
3716 <prgn>dh_installmenu</prgn> installe les fichiers de menu et ainsi de suite.
3717 Ainsi, il offre une flexibilité suffisante pour pouvoir utiliser les scripts
3718 d'aide quand ils sont utiles, en complément de commandes définies manuellement
3719 dans le fichier <file>debian/rules</file>.
3721 Vous pouvez débuter avec <package>debhelper</package> en lisant <manref
3722 name="debhelper" section="1"> et en regardant les exemples fournis avec le
3723 paquet. <prgn>dh_make</prgn> du paquet <package>dh-make</package> (voir <ref
3724 id="dh-make">) peut être utilisé pour convertir un paquet source
3725 « vierge » en une version utilisant <package>debhelper</package>. Ce
3726 raccourci ne devrait cependant pas vous faire croire que vous n'avez pas besoin
3727 de comprendre les scripts individuels <prgn>dh_*</prgn>. Si vous comptez
3728 utiliser un système d'aide, vous devez prendre le temps d'apprendre à utiliser
3729 ce système pour savoir ce que vous pouvez en attendre ainsi que son
3732 Plusieurs personnes pensent que des fichiers <file>debian/rules</file> vierges
3733 sont préférables car vous n'avez pas à apprendre les détails internes d'un
3734 quelconque système d'aide. La décision vous appartient complètement. Utilisez ce
3735 qui vous convient. Plusieurs exemples de fichiers <file>debian/rules</file> sont
3736 disponibles à <url id="&url-rules-files;">.
3738 <sect1 id="multiple-patches">
3739 <heading>Séparer vos correctifs en plusieurs fichiers</heading>
3741 Les gros paquets peuvent avoir plusieurs bogues que vous devez gérer. Si
3742 vous corrigez sans faire attention les bogues dans les sources, vous ne
3743 pourrez pas différencier facilement les nombreux correctifs que vous aurez
3744 appliqués. Cela peut devenir trés compliqué de mettre à jour le paquet avec
3745 une nouvelle version amont qui intègre certains correctifs (mais pas tous).
3746 Vous ne pouvez pas prendre l'ensemble des correctifs (par exemple, dans les
3747 fichiers <file>.diff.gz</file>) et décider quels correctifs il vous faut
3748 enlever parce que les bogues ont été corrigés en amont.
3750 Malheureusement, le système de création des paquets tel qu'il est actuellement
3751 ne fournit pas de moyen de séparer les correctifs en plusieurs fichiers.
3752 Cependant, il existe des moyens de séparer les correctifs : les fichiers
3753 correctifs sont livrés dans le fichier correctif Debian
3754 (<file>.diff.gz</file>), habituellement dans le répertoire <file>debian/</file>.
3755 La seule différence est qu'ils ne sont pas appliqués immédiatement par
3756 dpkg-source, mais par la règle <tt>build</tt> du fichier
3757 <file>debian/rules</file>. Inversement, ils sont annulés par la règle
3760 <prgn>dbs</prgn> est l'une des approches les plus populaires pour cela. Il fait
3761 ce qui est décrit ci-dessus et fournit la possibilité de créer de nouveaux
3762 correctifs et de mettre à jour d'anciens correctifs. Veuillez vous reporter au
3763 paquet <package>dbs</package> pour plus d'informations et au paquet
3764 <package>hello-dbs</package> pour un exemple.
3766 <prgn>dpatch</prgn> fournit également ces fonctions, mais il est prévu pour être
3767 encore plus facile d'utilisation. Veuillez voir le paquet
3768 <package>dpatch</package> pour la documentation et des exemples (dans
3769 <file>/usr/share/doc/dpatch</file>).
3772 <sect1 id="multiple-binary">Paquets binaires multiples
3774 Un simple paquet source va souvent permettre de construire plusieurs paquets
3775 binaires différents, que ce soit pour fournir plusieurs saveurs du même
3776 paquet (par exemple, le paquet source <package>vim</package>) ou pour créer
3777 plusieurs petits paquets au lieu d'un seul gros (par exemple, si
3778 l'utilisateur peut n'installer que la partie dont il a besoin et ainsi
3779 économiser de l'espace disque).
3781 Le second cas peut facilement être géré dans le fichier
3782 <file>debian/rules</file>. Vous avez simplement besoin de déplacer les fichiers
3783 appropriés du répertoire de construction dans les arborescence temporaires du
3784 paquet. Vous pouvez le faire en utilisant <prgn>install</prgn>
3785 ou <prgn>dh_install</prgn> du paquet <package>debhelper</package>.
3786 Assurez-vous de vérifier les différentes permutations de paquets, en
3787 garantissant que vous avez bien défini les dépendances entre les paquets dans
3788 le fichier <file>debian/control</file>.
3790 Le premier cas est un peu plus diffile car il implique de multiples
3791 recompilations du même logiciel, mais avec différentes options de
3792 configuration. Le paquet source <package>vim</package> est un exemple de la
3793 façon de gérer cela avec un fichier <file>rules</file> écrit à la main.
3795 <!-- &FIXME; Find a good debhelper example with multiple configure/make cycles
3800 <sect id="bpp-debian-control">
3801 <heading>Les meilleures pratiques pour le fichier
3802 <file>debian/control</file></heading>
3804 Les pratiques suivantes sont relatives au fichier <file>debian/control</file>.
3805 Elles viennent en complément des <url
3806 id="&url-debian-policy;ch-binary.html#s-descriptions" name="règles pour
3807 les descriptions des paquets">.
3809 La description du paquet, telle qu'elle est définie par le champ correspondant
3810 dans le fichier <file>control</file>, contient à la fois le résumé du paquet et
3811 la description longue pour le paquet. <ref id="bpp-desc-basics"> décrit des
3812 lignes générales pour les deux parties de la description. Ensuite, <ref
3813 id="bpp-pkg-synopsis"> fournit des principes spécifiques pour le résumé et <ref
3814 id="bpp-pkg-desc"> contient des principes spécifiques pour la description
3817 <sect1 id="bpp-desc-basics">
3818 <heading>Les règles générales pour les descriptions des paquets</heading>
3820 La description du paquet devrait être écrite pour l'utilisateur moyen,
3821 l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple, les paquets
3822 de développement sont pour les développeurs et leur description peut utiliser un
3823 langage technique. Pour les applications à but plus général comme un éditeur, la
3824 description devrait être écrite pour un non-spécialiste.
3826 Notre critique des descriptions des paquets nous amène à conclure que la plupart
3827 des descriptions des paquets sont techniques, c'est-à-dire, qu'elles ne sont pas
3828 écrites pour être comprises par les non-spécialistes. À moins que
3829 votre paquet ne soit que pour les techniciens, c'est un problème.
3831 Comment écrire pour les non-spécialistes ? Évitez le jargon.
3832 Évitez de vous référer à d'autres applications et cadres de travail avec
3833 lesquels l'utilisateur n'est pas forcément familier — « GNOME »
3834 ou « KDE » sont corrects car les utilisateurs sont probablement
3835 familiers avec ces termes, mais « GTK+ » ne l'est probablement pas.
3836 Ne supposez aucune connaissance. Si vous devez utiliser des termes techniques,
3839 Soyez objectif. Les descriptions de paquet ne sont pas un endroit pour
3840 promouvoir votre paquet, quel que soit l'amour que vous lui portez.
3841 Rappelez-vous que le lecteur n'a pas forcément les mêmes priorités que vous.
3843 Des références aux noms de tout autre paquet de logiciels, noms de protocoles,
3844 standards ou spécifications devraient utiliser leurs formes canoniques si elles
3845 existent. Par exemple, utilisez « X Window System », « X11 »
3846 ou « X » et non « X Windows », « X-Windows » ou
3847 « X Window ». Utilisez « GTK+ » et non « GTK » ou
3848 « gtk ». Utilisez « GNOME » et non « Gnome ».
3849 Utilisez « PostScript » et non « Postscript » ou
3850 « postscript ».
3852 Si vous avez des problèmes pour écrire votre description, vous pouvez l'envoyer à
3853 &email-debian-l10n-english; et demander un retour d'informations.
3857 <sect1 id="bpp-pkg-synopsis">
3858 <heading>Le résumé du paquet ou description courte</heading>
3860 La ligne de résumé (la description courte) devrait être concise. Elle ne doit
3861 pas répéter le nom du paquet (c'est une règle).
3863 C'est une bonne idée de penser au résumé comme à une clause apposée et non une
3864 phrase complète. Une clause apposée est définie dans WordNet comme une relation
3865 grammaticale entre un mot et une phrase pronominale qui la suit, par exemple
3866 « Rudolph, le renne au nez rouge ». La clause apposée ici est
3867 « le renne au nez rouge ». Comme le résumé est une clause et non une
3868 phrase complète, nous recommandons de ne pas la commencer par une majuscule et
3869 de ne pas la finir par un point. Il ne doit pas non plus commencer avec un
3870 article, défini (« le ») ou indéfini (« un »).
3872 Cela peut vous aider d'imaginer le résumé combiné avec le nom du paquet de
3873 la façon suivante :
3875 <example><var>nom-paquet</var> est un <var>résumé</var>.</example>
3877 Sinon, il peut être plus compréhensible de le voir comme
3879 <example><var>nom-paquet</var> est <var>résumé</var>.</example>
3881 ou, si le nom du paquet est lui-même un pluriel (comme
3882 « developer-tools »)
3884 <example><var>nom-paquet</var> sont <var>résumé</var>.</example>
3886 Cette façon de former une phrase à partir du nom du paquet et du résumé devrait
3887 être considérée comme une heuristique et non comme une règle stricte. Il y a
3888 certains cas où cela n'a aucun sens de former une phrase.
3892 <sect1 id="bpp-pkg-desc">
3893 <heading>La description longue</heading>
3895 La description longue du paquet est la première information dont dispose
3896 l'utilisateur avant d'installer un paquet. Aussi, elle devrait fournir toutes
3897 les informations nécessaires pour le laisser décider de l'installation du
3898 paquet. Vous pouvez supposer que l'utilisateur a déjà lu le résumé du paquet.
3900 La description longue devrait toujours être constituée de phrases complètes.
3902 Le premier paragraphe de la description longue devrait répondre aux questions
3903 suivantes : qu'est-ce que fait le paquet ? Quelle tâche aide-t-il
3904 l'utilisateur à accomplir ? Il est important de décrire ceci d'une manière
3905 non technique, à moins que le paquet ne s'adresse qu'à un auditoire de techniciens.
3907 Les paragraphes suivants devraient répondre aux questions suivantes :
3908 Pourquoi, en tant qu'utilisateur, ai-je besoin de ce paquet ? Quelles
3909 sont les autres fonctionnalités dont dispose le paquet ? Quelles
3910 sont les fonctionnalités marquantes et les déficiences de ce paquet comparé à
3911 d'autres paquets (par exemple, « si vous avez besoin de X, utilisez Y à la
3912 place ») ? Est-ce que le paquet est lié à d'autres paquets d'une
3913 certaine façon qui n'est pas gérée par le gestionnaire de paquet (par exemple,
3914 « il s'agit d'un client pour le serveur foo ») ?
3916 Soyez attentif à éviter les fautes d'orthographe et de grammaire. N'oubliez
3917 pas votre vérificateur orthographique. <prgn>ispell</prgn> possède une option
3918 spéciale (<tt>-g</tt>) pour cela :
3920 <example>ispell -d american -g debian/control</example>
3923 L'utilisateur s'attend habituellement à ce que les réponses aux questions
3924 suivantes soient présentes dans la description du paquet.
3927 Qu'est-ce que fait le paquet ? Si c'est un ajout d'un autre paquet, la
3928 description courte du paquet dont il est un ajout devrait le spécifier.
3930 Pourquoi est-ce qu'il voudrait installer ce paquet ? Ceci est lié à ce qui
3931 est ci-dessus, mais pas tout à fait (c'est un client de messagerie ; il
3932 est cool, rapide, s'interface avec pgp, ldap et imap, a les fonctionnalités
3935 Si ce paquet ne devrait pas être installé directement, mais être tiré par un
3936 autre paquet, cela devrait être mentionné.
3938 Si le paquet est expérimental, ou s'il y a d'autres raisons pour lesquelles il
3939 ne devrait pas être utilisé, si un autre paquet devrait être utilisé à la place,
3940 cela devrait également être présent.
3942 En quoi le paquet est différent des paquets concurrents ? Est-ce que c'est
3943 une meilleure implémentation ? A-t-il plus de fonctionnalités, des
3944 fonctionnalités différentes ? Pourquoi devrait-il choisir ce paquet (2.
3945 devrait parler de la classe des paquets et ceci à propos de ce paquet
3946 particulier, si vous avez des informations liés au deux).
3951 <sect1 id="bpp-upstream-info">
3952 <heading>Page d'accueil amont</heading>
3954 Nous vous recommandons d'ajouter l'adresse de la page d'accueil du paquet à la
3955 description du paquet dans le fichier <file>debian/control</file>. Cette
3956 information devrait être ajoutée à la fin de la description en utilisant le
3957 format suivant :
3960 Homepage: http://some-project.some-place.org/</example>
3962 Veuillez noter les espaces au début de la ligne, ils servent à séparer les
3963 lignes correctement. Pour voir un exemple de ce que cela affiche, veuillez vous
3964 reporter à <url id="&url-eg-desc-upstream-info;">.
3966 Ne mettez rien s'il n'existe pas de page pour le logiciel.
3969 Veuillez noter que nous espérons que ce champ sera remplacé par un
3970 vrai champ de <file>debian/control</file> que comprendraient <prgn>dpkg</prgn>
3971 et <tt>&packages-host;</tt>. Si vous ne voulez pas vous embêter à déplacer la
3972 page d'accueil depuis la description vers ce nouveau champ, vous devriez
3973 probablement attendre qu'il soit disponible.</p>
3978 <sect id="bpp-debian-changelog">
3979 <heading>Les meilleures pratiques pour le fichier <file>debian/changelog</file></heading>
3981 Les pratiques suivantes viennent en complément de la <url name="directive sur
3982 les fichiers changelog" id="&url-debian-policy;ch-docs.html#s-changelogs">.</p>
3984 <sect1 id="bpp-changelog-do">
3985 <heading>Écrire des entrées de changelog utiles</heading>
3987 L'entrée de changelog pour une révision de paquet documente les changements dans
3988 cette révision et seulement ceux-ci. Concentrez-vous sur la description des
3989 changements significatifs et visibles de l'utilisateur qui ont été effectués
3990 depuis la dernière version.
3992 Ciblez <em>ce</em> qui a été changé — qui, comment et quand cela a été fait
3993 est généralement de moindre importance. Ceci dit, rappelez-vous de nommer
3994 poliment les personnes qui ont fourni une aide notable pour réaliser le
3995 paquet (par exemple, ceux qui ont envoyé des correctifs).
3997 Vous n'avez pas besoin de détailler les changements triviaux et évidents. Vous
3998 pouvez également regrouper plusieurs de ces changements dans une seule entrée.
3999 D'un autre côté, ne soyez pas trop concis si vous avez entrepris un changement
4000 majeur. Soyez tout spécialement clair s'il y a des changements qui modifient le
4001 comportement du programme. Pour plus d'explications, utilisez le fichier
4002 <file>README.Debian</file>.
4004 Utilisez un langage anglais commun pour que la majorité des lecteur puissent le
4005 comprendre. Évitez les abbréviations, le parler technique et le jargon quand
4006 vous expliquez des changements fermant un bogue, spécialement pour les rapports
4007 de bogue créés par des utilisateurs qui ne vous paraissent pas particulièrement
4008 à l'aise techniquement. Vous devez être poli et ne pas jurer.
4010 Il est parfois désirable de préfixer les entrées de changelog avec le nom des
4011 fichiers qui ont été modifiés. Cependant, il n'est pas besoin de lister
4012 explicitement tous les fichiers modifiés, particulièrement si la modification
4013 est petite ou répétitive. Vous pouvez utiliser les caractères génériques.
4015 Quand vous faites référence aux bogues, ne supposez rien a priori. Dites ce
4016 qu'était le problème, comment il a été résolu et ajoutez la chaîne de caractères
4017 « closes: #nnnnn ». Veuillez voir <ref id="upload-bugfix"> pour plus
4020 <sect1 id="bpp-changelog-misconceptions">
4021 <heading>idées fausses communes sur les entrées de changelog</heading>
4023 Les entrées de changelog <strong>ne devraient pas</strong> documenter des
4024 problèmes génériques d'empaquetage (« Hé, si vous cherchez foo.conf, il
4025 est dans /etc/blah/. ») car les administrateurs et utilisateurs sont
4026 supposés être au moins vaguement rompus à la façon dont les choses sont
4027 arrangées sur un système Debian. Mentionnez cependant tout changement
4028 d'emplacement d'un fichier de configuration.
4030 Les seuls bogues fermés par une entrée de changelog devraient être ceux qui sont
4031 vraiment corrigés dans la même révision du paquet. Fermer des bogues non liés
4032 par le fichier changelog est considéré comme une très mauvaise pratique.
4033 Veuillez voir <ref id="upload-bugfix">.
4035 Les entrées de changelog <strong>ne devraient pas</strong> être le lieu de
4036 discussions avec les émetteurs de bogues (« Je ne vois pas de segfaults
4037 lors du lancement de foo avec l'option bar ; envoyez-moi plus
4038 d'informations. »), ni celui de phrases génériques sur la vie, l'univers et
4039 tout le reste (« Désolé, cet envoi m'a pris du temps, mais j'avais attrapé
4040 la grippe ») ou celui de demandes d'aide (« La liste des bogues sur
4041 ce paquet est énorme, donnez-moi un coup de main »). Ceci ne sera
4042 généralement pas remarqué par les personnes ciblées, mais peut ennuyer les
4043 personnes qui désirent lire des informations sur les changements réels du
4044 paquet. Veuillez vous reporter à <ref id="bug-answering"> pour plus
4045 d'informations sur la façon d'utiliser le système de suivi des bogues.
4047 C'est une vieille tradition de valider les bogues fixés par une mise à jour
4048 indépendante dans la première entrée du changelog de l'envoi du vrai
4049 responsable, par exemple, dans une entrée de changelog comme ceci :
4051 * Maintainer upload, closes: #42345, #44484, #42444.
4053 Ceci fermera les bogues NMU marqués comme corrigé (« fixed ») quand le
4054 paquet arrivera dans l'archive. Le bogue pour le fait qu'une NMU a été faite
4055 peut être fermé de la même façon. Bien sûr, il est également parfaitement
4056 acceptable de fermer les bogues corrigés par NMU par d'autres moyens ; voir
4057 <ref id="bug-answering">.
4060 <sect1 id="bpp-changelog-errors">
4061 <heading>Erreurs communes dans les entrées de changelogs</heading>
4063 Les exemples suivants montrent des erreurs communes ou des exemples de mauvais
4064 style dans les entrées de changelog<footnote>NdT : Les entrées de
4065 changelog sont ici affichées en français pour faciliter la compréhension, mais
4066 vos entrées devront naturellement être rédigées en anglais.</footnote>.
4070 * Corrige tous les bogues restants.
4073 Ceci n'indique visiblement rien d'utile au lecteur.
4076 * Correctif de Jane Random appliqué.
4078 Sur quoi portait le correctif ?
4082 * Révision de cible d'installation la nuit dernière.
4084 Qu'a accompli la révision ? Est-ce que la mention de la nuit dernière
4085 est supposée nous rappeler que nous ne devons pas faire confiance à ce
4090 * Corrige MRD vsync av. anciens CRTs.
4092 Trop d'acronymes et il n'est pas très clair de ce qu'était vraiment cette...
4093 euh... merde (oups, un mot interdit !) ou comment cela a été corrigé.
4097 * Ceci n'est pas un bogue. Closes: #nnnnnn.
4099 Premièrement, il n'y a absolument pas besoin d'envoyer un paquet pour
4100 communiquer cette information ; à la place, utilisez le système de suivi des
4101 bogues. Deuxièmement, il n'y a aucune explication concernant la raison
4102 pour laquelle le rapport n'était pas un bogue.
4106 * A été fixé il y a longtemps, mais j'ai oublié de le fermer. Closes: #54321.
4108 Si, pour toute raison, vous n'aviez pas indiqué le numéro du bogue dans une
4109 précédente entrée de changelog, ceci n'est pas un problème, fermez simplement le
4110 bogue normalement dans le BTS. Il n'y a pas besoin de modifier le fichier
4111 changelog, en supposant que la description de la correction est déjà intégrée
4112 (ceci s'applique aux correctifs par les auteurs/responsables amont également,
4113 vous n'avez pas à suivre les bogues qui ont été corrigés il y a longtemps dans
4118 * Closes: #12345, #12346, #15432.
4120 Où est la description ?! Si vous n'arrivez pas à trouver un message
4121 descriptif, commencez par insérer le titre de chacun des différents bogues.
4125 <sect1 id="bpp-news-debian">
4126 <heading>Compléter les changelogs avec les fichiers NEWS.Debian</heading>
4128 Les nouvelles importantes à propos des changements dans un paquet peuvent
4129 également être placées dans les fichiers NEWS.Debian. Ces nouvelles seront
4130 affichées par des outils comme apt-listchanges, avant le reste des changelogs.
4131 Ceci est le moyen préféré pour informer les utilisateurs des changements
4132 significatifs dans un paquet. Il est préférable d'utiliser ce fichier plutôt que
4133 d'utiliser des notes debconf car c'est moins ennuyeux et l'utilisateur peut y
4134 revenir et se référer au fichier NEWS.Debian après l'installation. Et c'est
4135 mieux que de lister les changements principaux dans README.Debian car
4136 l'utilisateur peut facilement rater de telles notes.
4138 Le format du fichier est le même que pour un fichier de changelog Debian, mais
4139 il n'utilise pas d'astérisques et décrit chaque élément de nouvelle dans un
4140 paragraphe complet si nécessaire plutôt que les résumés concis qui iraient dans un
4141 changelog. C'est une bonne idée de passer votre fichier par dpkg-parsechangelog
4142 pour vérifier son formatage car il n'est pas vérifié automatiquement pendant la
4143 construction comme le changelog. Voici un exemple d'un vrai fichier NEWS.Debian :
4145 cron (3.0pl1-74) unstable; urgency=low
4147 The checksecurity script is no longer included with the cron package:
4148 it now has its own package, "checksecurity". If you liked the
4149 functionality provided with that script, please install the new
4152 -- Steve Greenland <stevegr&debian.org> Sat, 6 Sep 2003 17:15:03 -0500
4155 Le fichier NEWS.Debian est installé comme
4156 /usr/share/doc/<package>/NEWS.Debian.gz. Il est compressé et a toujours ce
4157 nom même dans les paquets natifs Debian. Si vous utilisez debhelper,
4158 dh_installchangelogs installera les fichiers debian/NEWS pour vous.
4160 À la différence des fichiers changelog, vous n'avez pas besoin de mettre à jour
4161 les fichiers NEWS.Debian à chaque nouvelle version. Ne les mettez à jour que si
4162 vous avez quelque chose de particulièrement important que l'utilisateur a
4163 besoin de savoir. Si vous n'avez pas de nouvelles du tout, il n'est pas
4164 nécessaire de fournir de fichier NEWS.Debian dans votre paquet. Pas de
4165 nouvelles, bonne nouvelle !
4169 <!-- <sect1 id="pkg-mgmt-cvs">Managing a package with CVS
4171 &FIXME; presentation of cvs-buildpackage, updating sources
4172 via CVS (debian/rules refresh).
4173 <url id="http://www.debian.org/devel/cvs_packages">
4176 <sect id="bpp-debian-maint-scripts">
4177 <heading>Les meilleures pratiques pour les scripts de
4178 maintenance</heading>
4180 Les scripts de maintenance incluent les fichiers <file>debian/postinst</file>,
4181 <file>debian/preinst</file>, <file>debian/prerm</file> et
4182 <file>debian/postrm</file>. Ces scripts prennent soin de la configuration
4183 d'installation ou de désinstallation des paquets, ce qui n'est pas simplement créer ou
4184 supprimer des fichiers et des répertoires. Les instructions suivantes
4185 complètent la <url id="&url-debian-policy;" name="charte Debian">.
4187 Les scripts de maintenance doivent être idempotents. Cela veut dire que vous
4188 devez vous assurer que rien de grave ne se produit si un script est appelé deux
4189 fois là où il ne devrait habituellement être appelé qu'une fois.
4191 Les entrée et sortie standard peuvent être redirigées (par exemple, dans des
4192 tubes<footnote><p>pipes</p></footnote>) pour des besoins d'enregistrement
4193 d'activité, donc vous ne devez pas supposer que ce sont des tty.
4195 Tous les affichages et les configurations interactives devraient être
4196 minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet
4197 <package>debconf</package> pour l'interface. Rappelez-vous que, dans tous les
4198 cas, l'affichage ne doit se faire que dans l'étape de configuration,
4199 <tt>configure</tt> du script de post-installation, <file>postinst</file>.
4201 Gardez les scripts de maintenance aussi simples que possible. Nous vous
4202 suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que si vous
4203 avez besoin d'une fonctionnalité de Bash, le script de maintenance doit
4204 l'indiquer dans sa première ligne. Un shell POSIX ou Bash sont préférés à
4205 Perl car ils permettent à <package>debhelper</package> d'ajouter facilement des
4206 parties aux scripts.
4208 Si vous modifiez les scripts de maintenance, assurez-vous de tester la
4209 suppression du paquet, la double installation et la purge complète. Assurez-vous
4210 qu'il ne reste rien d'un paquet purgé, c'est-à-dire, que la purge doit enlever
4211 tout fichier créé, directement ou indirectement, par les scripts de
4214 Si vous avez besoin de vérifier l'existence d'une commande, vous devriez
4215 utiliser quelque chose comme :
4216 <example>if [ -x /usr/sbin/install-docs ]; then ...</example>
4218 Si vous ne désirez pas mettre en dur le chemin de la commande dans le script de
4219 maintenance, la fonction de shell suivante conforme à POSIX peut vous
4224 Vous pouvez utiliser cette fonction pour rechercher le <tt>$PATH</tt> pour un
4225 nom de commande passé en argument. Il renvoie vrai (zéro) si la commande a été
4226 trouvée et faux sinon. Il s'agit réellement de la façon la plus portable de faire
4227 car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn> ne sont pas
4230 Bien que <prgn>which</prgn> soit une alternative acceptable car il est
4231 présent dans le paquet classé <em>required</em> <package>debianutils</package>, il n'est pas
4232 présent dans la partition racine. Autrement dit, il est placé dans
4233 <file>/usr/bin</file> au lieu de <file>/bin</file>, il n'est donc pas possible
4234 de l'utiliser dans les scripts qui sont exécutés avant que la partition
4235 <file>/usr</file> soit montée. Cependant, la plupart des scripts n'auront pas ce
4239 <sect id="bpp-config-mgmt">
4240 <heading>Gestion de la configuration avec <package>debconf</package></heading>
4244 <package>Debconf</package> est un système de gestion de configuration qui
4245 peut être utilisé par les divers scripts de maintenance (principalement
4246 en post-installation dans le fichier <file>postinst</file>) pour demander à
4247 l'utilisateur des informations concernant la configuration du paquet. Il
4248 faut maintenant éviter les interactions directes avec l'utilisateur et
4249 préférer les interactions utilisant <package>debconf</package>. Ceci permettra
4250 à l'avenir des installations non interactives.
4252 Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs erreurs
4253 communes sont référencées dans la page de manuel <manref section="7"
4254 name="debconf-devel">. Vous devriez vraiment lire cette page si vous décidez
4259 <sect id="bpp-i18n">
4260 <heading>Internationalisation</heading>
4264 <sect1 id="bpp-i18n-debconf">Gestion des traductions de
4267 Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur
4268 un grand nombre de paquets et doivent donc collaborer avec plusieurs
4269 responsables différents. De plus, la plupart du temps, l'anglais n'est pas leur
4270 langue maternelle, il se peut que vous deviez être particulièrement patient
4273 Le but de <package>debconf</package> était de faciliter la configuration des
4274 paquets aux responsables et aux utilisateurs. À l'origine, les
4275 traductions des questionnaires debconf étaient gérées avec
4276 <prgn>debconf-mergetemplate</prgn>. Cependant, cette technique est maintenant
4277 déconseillée ; la meilleure façon pour l'internationalisation de
4278 <package>debconf</package> est d'utiliser le paquet
4279 <package>po-debconf</package>. Cette méthode est plus facile et pour le
4280 responsable et pour les traducteurs ; des scripts de transition sont
4283 Lors de l'utilisation de <package>po-debconf</package>, la traduction est
4284 stockée dans des fichiers <file>po</file> (à l'instar des techniques de
4285 traduction de <prgn>gettext</prgn>). Des fichiers modèles contiennent les
4286 messages d'origine et indiquent quels sont les champs traduisibles. Quand vous
4287 modifiez l'état d'un champ traduisible en appelant
4288 <prgn>debconf-updatepo</prgn>, la traduction est marquée comme ayant besoin de
4289 l'attention des traducteurs. Puis, lors de la construction du paquet, le
4290 programme <prgn>dh_installdebconf</prgn> prendra soin de toute la magie
4291 nécessaire à l'ajout du modèle avec les traductions à jour dans les paquets
4292 binaires. Veuillez vous reporter à la page de manuel <manref name="po-debconf"
4293 section="7"> pour les détails.
4296 <sect1 id="bpp-i18n-docs">
4297 <heading>Documentation traduite</heading>
4299 La traduction de la documentation est cruciale pour les utilisateurs, mais elle
4300 représente un important travail. Il n'existe aucun moyen d'éliminer ce travail,
4301 mais vous pouvez faciliter les choses pour les traducteurs.
4303 Si vous êtes responsable d'une documentation quelle que soit sa taille, il est
4304 plus facile pour les traducteurs d'avoir accès à un système de contrôle de
4305 source. Ceci permet aux traducteurs de voir les différences entre deux versions
4306 de la documentation, pour, par exemple, qu'ils puissent voir ce qui a besoin
4307 d'être retraduit. Il est recommandé que le document traduit inclue une note à
4308 propos de la révision de contrôle du source sur laquelle la traduction est
4309 basée. Un système intéressant est fourni par <url id="&url-i18n-doc-check;"
4310 name="doc-check"> dans le paquet <package>boot-floppies</package> qui donne un
4311 aperçu de l'état de la traduction pour une langue donnée, en utilisant les
4312 commentaires structurés pour une révision donnée du fichier à traduire et, pour
4313 un fichier traduit, la révision du fichier d'origine sur laquelle la traduction
4314 est basée. Vous pouvez vouloir adapter et fournir ceci dans votre référentiel CVS.
4316 Si vous maintenez de la documentation au format XML ou SGML, nous vous suggérons
4317 d'isoler les informations indépendantes de la langue et de les définir
4318 comme des entités dans un fichier séparé qui sera inclus par les différentes
4319 traductions. Ceci aide, par exemple, à garder à jour les adresses pour
4325 <sect id="bpp-common-situations">
4326 <heading>Pratiques communes d'empaquetage</heading>
4329 <sect1 id="bpp-kernel">Kernel modules/patches
4332 &FIXME; Heavy use of kernel-package. provide files in
4333 /etc/modutils/ for module configuration.
4336 <sect1 id="bpp-autotools">
4337 <heading>Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
4339 Conserver à jour les fichiers d'<prgn>autoconf</prgn>, <file>config.sub</file>
4340 et <file>config.guess</file>, est critique pour les porteurs, spécialement pour
4341 les architectures plus changeantes. De très bonnes pratiques d'empaquetage
4342 utilisant <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été regroupées
4343 dans &file-bpp-autotools; du paquet <package>autotools-dev</package>. Vous êtes
4344 vivement encouragé à lire ce fichier et à suivre les recommandations indiquées.
4347 <sect1 id="bpp-libraries">Bibliothèques
4349 Pour diverses raisons, il a toujours été difficile d'empaqueter les
4350 bibliothèques. La charte impose plusieurs contraintes pour faciliter la maintenance
4351 et pour garantir que les mises à jour sont aussi simples que possible quand une
4352 nouvelle version amont est disponible. Une erreur dans une bibliothèque peut
4353 rendre défectueux une douzaine de paquets qui en dépendent.
4355 Les bonnes pratiques d'empaquetage des bibliothèques ont été regroupées dans
4356 <url id="&url-libpkg-guide;" name="le guide d'empaquetage des
4359 <sect1 id="bpp-docs">Documentation
4361 Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html"
4362 name="règles sur la documentation">.</p>
4364 Si votre paquet contient de la documentation construite à partir de XML ou SGML,
4365 nous vous recommandons de ne pas fournir le source XML ou SGML dans le(s)
4366 paquet(s) binaire(s). Si les utilisateurs désirent avoir le source de la
4367 documentation, ils peuvent récupérer le paquet source.</p>
4369 La charte spécifie que la documentation doit être fournie au format HTML.
4370 Nous vous recommandons également de la fournir au format PDF et texte simple si
4371 c'est adapté et qu'une sortie de qualité est possible. Cependant, il n'est
4372 généralement pas approprié de fournir des versions en texte simple pour la
4373 documentation dont le format source est du HTML.</p>
4375 Les principaux manuels fournis devraient être enregistrés par le paquet
4376 <package>doc-base</package> à l'installation. Reportez-vous à la documentation
4377 du paquet <package>doc-base</package> pour plus d'information.</p>
4381 <sect1 id="bpp-other">Types spécifiques de paquets
4383 Plusieurs types spécifiques de paquets ont des sous-chartes spéciales et des
4384 règles et pratiques d'empaquetage correspondantes :
4387 Les paquets liés à Perl ont leur <url id="&url-perl-policy;" name="charte
4388 Perl">, quelques exemples de paquets qui suivent cette charte sont
4389 <package>libdbd-pg-perl</package> (module perl binaire) ou
4390 <package>libmldbm-perl</package> (module perl indépendant de
4394 Les paquets liés à Python ont leur charte Python ; voir
4395 &file-python-policy; dans le paquet <package>python</package>.
4398 Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;"
4399 name="charte Emacs">.
4402 Les paquets liés à Java ont leur <url id="&url-java-policy;" name="charte
4406 Les paquets liés à Ocaml ont leur propre charte que l'on trouve dans
4407 &file-ocaml-policy; du paquet <package>ocaml</package>. Un bon exemple est
4408 le paquet source <package>camlzip</package>.
4411 Les paquets fournissant des DTDs XML ou SGML devraient se conformer aux
4412 recommandations que l'on peut trouver dans le paquet
4413 <package>sgml-base-doc</package>
4415 Les paquets Lisp devraient s'enregistrer avec le paquet
4416 <package>common-lisp-controller</package> pour lequel vous pouvez vous
4417 reporter au fichier &file-lisp-controller;.
4422 <sect1 id="bpp-archindepdata">Données indépendantes de l'architecture
4424 Il n'est pas rare d'avoir une grande quantité de données indépendantes de
4425 l'architecture fournie avec un programme. Par exemple, des fichiers
4426 audio, une collection d'icônes, des motifs de papiers peints ou autres
4427 fichiers graphiques. Si la taille des données est négligeable par
4428 rapport à la taille du reste du paquet, il est probablement mieux de
4429 tout garder dans le même paquet.
4432 Cependant, si la taille des données est considérable, vous devez
4433 envisager de les partager dans un paquet séparé et indépendant de
4434 l'architecture (« _all.deb »). Ainsi, en faisant cela, vous
4435 évitez une duplication inutile des mêmes données dans onze fichiers
4436 .debs pour chaque architecture. Bien que ceci ajoute une surcharge
4437 supplémentaire aux fichiers <file>Packages</file>, ceci sauve beaucoup
4438 d'espace disque sur les miroirs Debian. Séparer les données
4439 indépendantes de l'architecture réduit également le temps de traitement
4440 de <prgn>lintian</prgn> ou de <prgn>linda</prgn> (voir <ref
4441 id="tools-lint">) quand ils sont exécutés sur l'ensemble de l'archive
4445 <sect1 id="bpp-locale">
4446 <heading>Avoir besoin d'une certaine locale pendant la construction</heading>
4448 Si vous avez besoin d'une certaine locale pendant la construction, vous pouvez
4449 créer un fichier temporaire par cette astuce :
4451 Si vous positionnez LOCPATH à l'équivalent de /usr/lib/locale, et LC_ALL au nom
4452 de la locale que vous générez, vous devriez obtenir ce que vous voulez sans être
4453 root. Quelque chose comme ceci :
4456 LOCALE_PATH=debian/tmpdir/usr/lib/locale
4458 LOCALE_CHARSET=UTF-8
4460 mkdir -p $LOCALE_PATH
4461 localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
4464 LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
4468 <sect1 id="bpp-transition">
4469 <heading>Rendre les paquets de transition conformes avec deborphan</heading>
4471 Deborphan est un programme qui aide les utilisateurs à détecter quels paquets
4472 peuvent être enlevés sans problème du système, i.e. ceux dont aucun paquet ne
4473 dépend. L'opération par défaut est de chercher seulement parmi les sections libs
4474 et oldlibs pour débusquer les bibliothèques inutilisées. Mais si l'on passe le
4475 bon argument, il tente d'attraper d'autres paquets inutiles.
4477 Par exemple, avec --guess-dummy, il cherche tous les paquets de transition qui
4478 étaient nécessaires pour une mise à jour, mais qui peuvent sans problème être
4479 supprimés. Pour cela, il recherche la chaîne de caractères « dummy »
4480 ou « transitional » dans la description courte.
4482 Ainsi, quand vous créez un tel paquet, assurez-vous d'ajouter ce texte dans la
4483 description courte. Si vous cherchez des exemples, exécutez simplement :
4484 <example>apt-cache search .|grep dummy</example> or
4485 <example>apt-cache search .|grep transitional</example>.
4492 <chapt id="beyond-pkging">
4493 <heading>Au-delà de l'empaquetage
4495 Debian, c'est beaucoup plus que de l'empaquetage de logiciels et de
4496 la maintenance de paquets. Ce chapitre contient des informations sur les
4497 façons, souvent vraiment importantes, de contribuer à Debian au-delà de la
4498 simple création et maintenance de paquets.
4500 En tant qu'organisation de volontaires, Debian repose sur la liberté de
4501 choisir ce sur quoi l'on désire travailler et de choisir la
4502 partie la plus importante à laquelle on veut consacrer son temps.
4504 <sect id="submit-bug">
4505 <heading>Rapporter des bogues
4507 Nous vous encourageons à remplir des rapports de bogue quand vous trouvez des
4508 bogues dans les paquets Debian. En fait, les développeurs Debian sont souvent
4509 les testeurs de première ligne. Trouver et rapporter les bogues dans les
4510 paquets d'autres développeurs améliore la qualité de Debian.
4512 Lisez les <url name="instructions pour créer un rapport de bogue"
4513 id="&url-bts-report;"> dans le <url name="système de suivi des bogues"
4514 id="&url-bts;"> Debian.
4516 Essayez de soumettre le bogue à partir d'un compte utilisateur normal sur lequel
4517 vous pouvez recevoir des courriers, pour que les personnes puissent vous
4518 joindre s'ils ont besoin de plus d'informations à propos du bogue. Ne soumettez
4519 pas de bogues en tant que root.
4521 Vous pouvez utiliser un outil comme <manref name="reportbug" section="1"> pour
4522 soumettre des bogues. Il peut automatiser et dans l'ensemble faciliter le
4525 Assurez-vous que le bogue n'a pas déjà été rapporté. Chaque paquet dispose d'une
4526 liste de bogues facilement accessible à
4527 <tt>http://&bugs-host;/<var>nom_paquet</var></tt>. Des outils comme <manref
4528 name="querybts" section="1"> peuvent également vous fournir ces informations (et
4529 <prgn>reportbug</prgn> invoquera également habituellement <prgn>querybts</prgn>
4532 Essayer d'envoyer vos bogues au bon emplacement. Quand, par exemple, votre bogue
4533 concerne un paquet qui réécrit des fichiers d'un autre paquet, vérifiez les
4534 listes des bogues pour les <em>deux</em> paquets pour éviter de créer des
4535 rapports de bogues dupliqués.
4537 Vous pouvez également parcourir les bogues d'autres paquets, en les regroupant
4538 s'ils sont indiqués plus d'une fois, ou en les marquant avec
4539 « fixed » quand ils ont déjà été corrigés. Notez cependant que si
4540 vous n'êtes ni le rapporteur du bogue, ni le responsable du paquet, vous ne
4541 devriez pas fermer réellement le bogue (à moins que vous n'ayez obtenu la
4542 permission du responsable).
4544 De temps en temps, vous pourrez vouloir vérifier ce qui s'est passé à propos des
4545 bogues que vous avez rapportés. Saisissez cette occasion pour fermer les bogues
4546 que vous ne pouvez plus reproduire. Pour trouver tous les bogues que vous avez
4547 rapportés, vous avez simplement besoin d'aller à
4548 <tt>http://&bugs-host;/from:<var><votre-adresse-de-courrier></var></tt>.
4550 <sect1 id="submit-many-bugs">Ouvrir un grand nombre de rapports d'un seul
4553 Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
4554 paquets — plus de dix — est une pratique que nous déconseillons.
4555 Prenez toutes les mesures possibles pour éviter cette situation. Si le problème
4556 peut être détecté automatiquement par exemple, ajoutez un nouveau test dans le
4557 paquet <package>lintian</package> pour générer une erreur ou un avertissement.
4559 Si vous ouvrez plus de dix rapports sur le même sujet, il est préférable
4560 d'indiquer votre intention sur la liste &email-debian-devel;. Cela donnera à
4561 d'autres développeurs la possibilité de vérifier que le problème existe
4562 vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent
4563 les mêmes rapports de bogue simultanément.
4565 Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez
4566 les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils ne soient
4567 pas redirigés vers les listes de diffusion.
4570 <sect id="qa-effort">Effort d'assurance qualité
4572 <sect1 id="qa-daily-work">Travail journalier
4574 Bien qu'il y ait un groupe de personnes dédiées à l'assurance qualité, les
4575 devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez participer à
4576 cet effort en conservant vos paquets aussi exempts de bogues que possible et
4577 aussi corrects que possible selon <prgn>lintian</prgn> (reportez-vous à <ref
4578 id="lintian">). Si cela vous paraît impossible, vous devriez alors envisager
4579 d'abandonner certains de vos paquets (reportez-vous à <ref id="orphaning">).
4580 Sinon, vous pouvez demander de l'aide à d'autres personnes pour qu'elles
4581 puissent rattraper votre retard dans la correction des bogues (vous pouvez
4582 demander de l'aide sur &email-debian-qa; ou &email-debian-devel;). En même
4583 temps, vous pouvez rechercher des co-responsables (reportez-vous à <ref
4584 id="collaborative-maint">).
4586 <sect1 id="qa-bsp">Les chasses aux bogues
4588 De temps en temps, le groupe d'assurance qualité organise des chasses aux
4589 bogues<footnote><em>Bug Squashing Party</em></footnote> pour essayer de
4590 supprimer le plus de problèmes possible. Elles sont annoncées sur
4591 &email-debian-devel-announce; et l'annonce explique quel domaine sera visé
4592 pendant la chasse : habituellement, il s'agit des bogues empêchant
4593 l'intégration du paquet dans la distribution (« Release Critical »),
4594 mais il peut arriver qu'ils décident d'aider à finir une transition majeure
4595 (comme une nouvelle version de Perl qui demande la recompilation de tous les
4598 Les règles pour les mises à jour indépendantes sont différentes au cours de la
4599 chasse parce que l'annonce de la chasse est considérée comme une annonce
4600 préalable pour les mises à jour indépendantes. Si vous avez des paquets qui
4601 peuvent être affectées par la chasse (parce qu'ils ont des bogues critiques par
4602 exemple), vous devriez envoyer une mise à jour pour chaque bogue correspondant
4603 pour expliquer leur état actuel et ce que vous attendez de la chasse. Si vous
4604 ne voulez pas d'une mise à jour indépendante ou si vous n'êtes intéressé que
4605 par un correctif ou si vous voulez gérer vous-même le bogue, veuillez l'expliquer
4608 Les personnes qui participent à la chasse ont des règles spécifiques pour les
4609 mises à jour indépendantes, ils peuvent en faire une sans avertissement
4610 préalable s'ils envoient leur paquet avec un délai d'au moins 3 jours dans
4611 DELAYED/3-day. Toutes les autres règles de mise à jour indépendante
4612 s'appliquent comme d'habitude, ils devraient envoyer le correctif de la
4613 mise à jour dans le BTS (pour l'un des bogues ouverts corrigé par la mise à
4614 jour ou pour un nouveau bogue marqué comme fixé). Ils devraient également
4615 respecter les souhaits du responsable s'il en a exprimés.
4617 Si une personne ne se sent pas à l'aise avec une mise à jour indépendante, elle
4618 devrait simplement envoyer un correctif au BTS. C'est de loin meilleur qu'une
4619 mise à jour défectueuse.
4621 <sect id="contacting-maintainers">Contacter d'autres responsables
4623 Pendant vos activités dans Debian, vous aurez à contacter d'autres responsables
4624 pour différentes raisons. Vous pourrez vouloir discuter d'une nouvelle
4625 façon de coopérer au sein d'un ensemble de paquets liés, ou vous pouvez
4626 simplement rappeler à quelqu'un qu'une nouvelle version est disponible et
4627 que vous en avez besoin.
4629 Chercher l'adresse d'un responsable d'un paquet peut être fastidieux.
4630 Heureusement, il existe un alias de courrier simple,
4631 <tt><paquet>@&packages-host;</tt>, qui fournit un moyen d'envoyer
4632 un courrier à un responsable, quelle que soit son adresse (ou ses
4633 adresses). Remplacez <tt><paquet></tt> par le nom du paquet source
4636 Vous pouvez également vouloir contacter les personnes qui sont inscrites à un
4637 paquet de source donné par le <ref id="pkg-tracking-system">. Vous pouvez le
4638 faire en utilisant l'adresse <tt><nom-paquet>@&pts-host;</tt>.
4641 <sect id="mia-qa">Gérer les responsables non joignables
4643 Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer
4644 que le responsable est toujours actif et qu'il continue à travailler sur
4645 ses paquets. Il est possible qu'il ne soit plus actif, mais qu'il ne se
4646 soit pas désenregistré du système. D'un autre côté, il est possible qu'il
4647 ait simplement besoin d'un rappel.
4649 Il y a un système simple (la base de données MIA) dans laquelle les informations
4650 sur les responsables supposés (deemed ?) inactifs sont enregistrées. Quand un
4651 membre du groupe QA contacte un responsable inactif ou trouve plus d'informations
4652 sur celui-ci, c'est enregistré dans la base de données MIA. Ce système
4653 est disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut être
4654 interrogé avec un outil de nom <prgn>mia-history</prgn>. Par défaut,
4655 <prgn>mia-history</prgn> affiche des informations sur toutes les personnes qu'il
4656 connaît, mais il accepte des expressions rationnelles comme paramètre qu'il
4657 utilise comme correspondance de noms d'utilisateur. <example>mia-history
4658 --help</example> affiche quels paramètres sont acceptés. Si vous déterminez
4659 qu'aucune information n'a encore été enregistrée pour un responsable inactif ou
4660 que vous voulez ajouter plus d'informations, vous devez utiliser la procédure
4663 La première étape est de contacter poliment le responsable et d'attendre une
4664 réponse pendant un temps raisonnable. Il est assez difficile de définir le
4665 « temps raisonnable », mais il est important de prendre en compte que
4666 la vraie vie est parfois assez mouvementée. Une façon de gérer cela pourrait
4667 être d'envoyer un rappel après deux semaines.
4669 Si le responsable ne répond pas après quatre semaines (un mois), on peut
4670 supposer qu'il n'y aura probablement pas de réponse. Si ceci se produit, vous
4671 devriez poursuivre vos investigations et essayer de réunir toutes les
4672 informations utiles sur ce responsable. Ceci inclut :
4675 <item>Les informations « echelon » disponibles dans la <url
4676 id="&url-debian-db;" name="base de données LDAP des
4677 développeurs">, qui indiquent quand le développeur a envoyé un
4678 message pour la dernière fois sur une liste de diffusion Debian.
4679 (Ceci inclut les envois via les listes debian-*-changes.)
4680 Rappelez-vous également de vérifier si le responsable est indiqué
4681 comme en vacances dans la base de données.
4683 <item>Le nombre de paquets de ce responsable et les conditions de ces
4684 paquets. En particulier, restent-ils des bogues empêchant
4685 l'intégration du paquet dans la distribution qui sont ouverts
4686 depuis des lustres ? De plus, combien de bogues y a-t-il en
4687 général ? Un autre point d'information important est si les
4688 paquets ont subi des mises à jour indépendantes et si oui, par
4691 <item>Est-ce que le responsable est actif en dehors de Debian ? Par
4692 exemple, il peut avoir envoyé des messages récemment à des
4693 listes de diffusion non-Debian ou des groupes de discussion.
4696 Un gros problème est représenté par les paquets parrainés — le responsable
4697 n'est pas un développeur Debian officiel. Les informations « echelon »
4698 ne sont pas disponibles pour les personnes parrainés, par exemple, vous devez
4699 donc trouver et contacter le responsable Debian qui a réellement envoyé le
4700 paquet. Étant donné qu'il a signé le paquet, il est responsable de l'envoi de
4701 toute façon et il devrait savoir ce qui s'est passé avec la personne qu'il
4704 Il est également permis d'envoyer une demande à &email-debian-devel; demandant
4705 si quelqu'un est au courant d'information sur le responsable manquant.
4707 Une fois que vous avez réuni toutes ces informations, vous pouvez contacter
4708 &email-debian-qa;. Les personnes de cet alias utiliseront les informations que
4709 vous aurez fournies pour décider comment procéder. Par exemple, ils peuvent
4710 abandonner un ou tous les paquets du responsable. Si un paquet a subi une mise à
4711 jour indépendante, ils peuvent préférer contacter le responsable ayant fait cette
4712 mise à jour — il est peut-être intéressé par le paquet.
4714 Un dernier mot : veuillez vous souvenir d'être poli. Nous sommes tous des
4715 volontaires et nous ne pouvons dédier l'intégralité de notre temps à Debian.
4716 Vous n'êtes pas non plus au courant des circonstances de la personne impliquée.
4717 Elle est peut-être sérieusement malade ou pourrait même nous avoir quitté
4718 — vous ne savez pas qui recevra vos courriers — imaginez comme un
4719 proche se sentira s'il lit un courrier pour la personne décédée et trouve un
4720 message très impoli, en colère et accusateur !)
4722 D'un autre côté, bien que nous soyons tous volontaires, nous avons une
4723 responsabilité. Vous pouvez donc insister sur l'importance du plus grand intérêt
4724 — si un responsable n'a plus le temps ou l'envie, il devrait
4725 « laisser filer » et donner le paquet à quelqu'un ayant plus de temps.
4727 <sect id="newmaint">
4728 <heading>Interagir avec de futurs développeurs Debian
4730 Le succès de Debian dépend de sa capacité à attirer et retenir de nouveaux et
4731 talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous
4732 recommandons de vous impliquer dans le processus d'apport des nouveaux
4733 responsables. Cette section décrit comment aider les futurs développeurs.
4736 <sect1 id="sponsoring">Parrainer des paquets
4738 Parrainer un paquet veut dire envoyer un paquet pour un responsable qui n'est
4739 pas encore autorisé à le faire lui-même, un candidat nouveau responsable.
4740 Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité.
4742 Si vous désirez être volontaire pour être parrain, vous pouvez vous inscrire à
4743 <url id="&url-sponsors;">.
4745 Les nouveaux responsables ont habituellement certaines difficultés à créer des
4746 paquets Debian — ceci est bien compréhensible. C'est pourquoi le parrain
4747 est là pour vérifier que le paquet parrainé est assez bon pour être inclus
4748 dans Debian. (Notez que si le paquet parrainé est nouveau, les ftpmasters
4749 devront également l'inspecter avant de l'intégrer)
4751 Effectuer un parrainage en signant simplement l'envoi ou en recompilant le
4752 paquet <strong>n'est définitivement pas recommandé</strong>. Vous devez
4753 construire le paquet source comme si vous vouliez construire l'un de vos
4754 paquets. Rappelez-vous que cela ne change rien si vous avez laissé le nom du
4755 candidat développeur dans le changelog et dans le fichier de
4756 contrôle, il est toujours possible de savoir que c'est vous qui avez fait l'envoi.
4758 Si vous êtes un gestionnaire de candidature pour un futur développeur, vous
4759 pouvez également être son parrain. Ainsi, vous pourrez vérifier comment le
4760 candidat gère la partie « Tâches et Capacités »<footnote>Tasks and
4761 Skills</footnote> de sa candidature.
4763 <sect1>Gérer les paquets parrainés
4765 En envoyant un paquet sponsorisé vers Debian, vous certifiez que le paquet
4766 atteint les standards minimum de Debian. Ceci implique que vous devez
4767 construire et tester le paquet sur votre propre système avant l'envoi.
4769 Vous ne pouvez pas simplement envoyer un fichier <file>.deb</file> binaire d'un
4770 filleul. En théorie, vous devriez seulement demander le fichier diff et
4771 l'emplacement de l'archive source d'origine et ensuite vous devriez récupérer
4772 le source et appliquer le diff vous-même. En pratique, vous pouvez vouloir
4773 utiliser le paquet source construit par votre filleul. Dans ce cas, vous devez
4774 vérifier qu'il n'a pas modifié les fichiers sources du fichier
4775 <file>.orig.tar.gz</file> qu'il fournit.
4777 N'ayez pas peur de répondre au filleul et de lui indiquer les changements qu'il
4778 doit faire. Cela prend souvent plusieurs échanges de courriers avant que le
4779 paquet ne soit dans un état acceptable. Être un parrain veut dire être un
4782 Une fois que le paquet a atteint les standards Debian, construisez et signez le
4785 dpkg-buildpackage -k<var>KEY-ID</var>
4787 avant de l'envoyer dans le répertoire incoming. Bien sûr, vous pouvez également
4788 utiliser toute partie de votre <var>KEY-ID</var>, tant qu'elle est unique dans
4789 votre porte-clés secret.
4791 Le champ Maintainer du fichier <file>control</file> et le fichier
4792 <file>changelog</file> devraient afficher la personne qui a fait l'empaquetage,
4793 c'est-à-dire, le filleul. Celui-ci recevra donc tous les courriers du système
4794 de suivi des bogues (BTS) à propos de son paquet.
4796 Si vous préférez laisser une trace plus visible de votre travail de parrainage,
4797 vous pouvez ajouter une ligne l'indiquant dans la plus récente entrée du
4800 Vous êtes encouragé à garder un œil sur le suivi des paquets que vous parrainez
4801 en utilisant le <ref id="pkg-tracking-system">.
4803 <sect1>Recommander un nouveau développeur
4805 Reportez-vous à la page sur les <url id="&url-newmaint-advocate;"
4806 name="recommandations pour un développeur prospectif"> sur le site web Debian.
4808 <sect1>Gérer les candidatures des nouveaux candidats
4810 Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;" name="liste à
4811 vérifier pour les responsables de candidatures"> sur le site web Debian.
4813 <chapt id="l10n">Internationalisation, traduction, être internationalisé et
4816 Debian prend en charge un nombre toujours croissant de langues naturelles. Même
4817 si l'anglais est votre langue maternelle et que vous ne parlez pas d'autre
4818 langue, il est de votre devoir de responsable d'être conscient des problèmes
4819 d'internationalisation (abrégé en i18n à cause des 18 lettres entre le i et
4820 le n dans internationalisation). C'est pourquoi, même si des programmes
4821 seulement en anglais vous suffisent, vous devriez lire la plupart de ce chapitre.
4823 Selon l'<url id="http://www.debian.org/doc/manuals/intro-i18n/"
4824 name="introduction à l'i18n"> de Tomohiro KUBOTA, « I18N
4825 (internationalisation) veut dire la modification d'un logiciel ou de
4826 technologies liées pour qu'un logiciel puisse potentiellement gérer des langues
4827 multiples, des conventions multiples et ainsi de suite dans le monde
4828 entier » alors que "L10N (localisation) veut dire l'implémentation dans
4829 une langue spécifique pour un logiciel déjà internationalisé ».
4831 La l10n et l'i18n sont liées, mais les difficultés liées à chacune sont très
4832 différentes. Il n'est pas vraiment difficile de permettre à un programme de
4833 changer la langue dans laquelle sont affichés les textes selon les paramètres de
4834 l'utilisateur, mais il est très couteux en temps de traduire réellement ces
4835 messages. D'un autre côté, définir le codage des caractères est trivial, mais
4836 adapter le code pour utiliser des codages de caractères différents est un
4837 problème vraiment difficile.
4839 En laissant de côté les problèmes d'i18n pour lesquels il n'existe pas de règle
4840 générale, il n'y a pas actuellement d'infrastructure centralisée pour la l10n
4841 dans Debian qui puisse être comparée au mécanisme dbuild pour le portage. Le
4842 plus gros du travail doit donc être réalisé manuellement.
4845 <sect id="l10n-handling">Comment sont gérées les traductions au sein de Debian
4847 La gestion des traductions des textes contenus dans un paquet est encore une
4848 tâche manuelle et le processus dépend du type de texte que vous désirez voir traduit.
4850 Pour les messages des programmes, l'infrastructure gettext est utilisée pour la
4851 plupart d'entre eux. La plupart du temps, la traduction est gérée en amont dans
4852 des projets comme le
4853 <url id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="projet de trduction
4854 libre">, le <url id="http://developer.gnome.org/projects/gtp/"
4855 name="projet de traduction de Gnome"> ou <url
4856 id="http://i18n.kde.org/" name="celui de KDE">.
4857 La seule ressource centralisée dans Debian est les <url
4858 id="http://www.debian.org/intl/l10n/" name="statistiques de traduction Debian
4859 centralisées"> où vous pouvez trouvez des statistiques sur les
4860 fichiers de traduction trouvés dans les paquets, mais il n'y a aucune
4861 infrastructure pour faciliter le processus de traduction.
4863 Un effort pour traduire les descriptions de paquet a démarré il y a longtemps
4864 même si les outils fournissent très peu de prise en charge pour les utiliser
4865 vraiement (i.e. seul APT peut les utiliser quand il est configuré
4866 convenablement). Il n'y a rien à faire de la part des responsables et les
4867 traducteurs devraient utiliser le <url id="http://ddtp.debian.org/"
4870 Pour les questionnaires debconf, le responsable devrait utiliser le paquet
4871 po-debconf pour faciliter le travail des traducteurs, qui peuvent utiliser le
4872 DDTP pour faire leur travail (mais les équipes française et brésilienne ne le
4873 font pas). On peut trouver certaines statistiques à la fois sur le site du
4874 DDTP (à propos de ce qui est vraiment traduit) et sur le site des <url
4875 id="http://www.debian.org/intl/l10n/" name="statistiques de traduction
4876 Debian centralisées"> (à propos de ce qui est intégré dans les paquets).
4878 Pour les pages web, chaque équipe l10n a accès au CVS correspondant et les
4879 statistiques sont disponibles sur le site des statistiques de traduction Debian
4882 Pour la documentation générale à propos de Debian, le processus est plus ou
4883 moins le même que pour les pages web (les traducteurs ont un accès au CVS), mais
4884 il n'y a pas de page de statistiques.
4886 Pour la documentation spécifique des paquets (pages de manuel, document info,
4887 autres formats), presque tout est encore à faire. Le plus notable, le projet KDE
4888 gère la traduction de ses documentations de la même façon que ses messages de
4889 programme. Les pages de manuel spécifiques Debian sont gérées dans un <url
4890 id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="dépôt CVS spécifique">.
4892 <sect id="l10n-faqm">FAQ I18N & L10N pour les responsables
4894 Voici une liste des problèmes que les responsables peuvent rencontrer concernant
4895 l'i18n et la l10n. Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de
4896 consensus sur ces points au sein de Debian et que ce ne sont que des conseils.
4897 Si vous avez une meilleure idée pour un problème donné ou si vous êtes en
4898 désaccord avec certains points, vous êtes libre de fournir vos impressions pour
4899 que ce document puisse être amélioré.
4901 <sect1 id="l10n-faqm-tr">Comment faire en sorte qu'un texte soit traduit ?
4903 Pour traduire une description de paquet ou un questionnaire debconf, nous n'avez
4904 rien à faire, l'infrastructure du DDTP répartira le matériel à traduire aux
4905 volontaires sans besoin d'interaction de votre part.
4907 Pour tous les autres matériels (fichiers gettext, pages de manuel ou autre
4908 documentation), la meilleure solution est de placer votre texte quelque part sur
4909 l'Internet et de demander sur debian-i18n pour une traductions dans différentes
4910 langues. Certains membres des équipes de traduction sont abonnés à cette liste
4911 et ils prendront soin de la traduction et du processus de relecture. Une fois
4912 ceci fait, vous recevrez de leur part votre document traduit dans votre boîte à
4915 <sect1 id="l10n-faqm-rev">Comment faire en sorte qu'une traduction
4916 donnée soit relue ?
4918 De temps en temps, des personnes indépendantes traduiront certains textes
4919 inclus dans votre paquet et vous demanderont de les inclure dans le paquet.
4920 Cela peut devenir problématique si vous n'êtes pas familier avec la langue
4921 donnée. C'est une bonne idée d'envoyer le document à la liste de diffusion l10n
4922 correspondante en demandant une relecture. Une fois celle-ci faite, vous devriez
4923 avoir plus confiance dans la qualité de la traduction et l'inclure sans crainte
4926 <sect1 id="l10n-faqm-update">Comment faire en sorte qu'une traduction
4927 donnée soit mise à jour ?
4929 Si vous avez certaines traductions d'un texte donné qui trainent (?), chaque fois
4930 que vous mettez à jour l'original, vous devriez gentiment demander au précédent
4931 traducteur de mettre à jour sa traduction avec le texte original. Gardez à
4932 l'esprit que cette tâche demande du temps, au moins une semaine pour obtenir une
4935 Si votre traducteur ne répond pas, vous pouvez demander de l'aide sur la liste de
4936 diffusion correspondante. Si tout échoue, n'oubliez pas de mettre un
4937 avertissement dans le document traduit, indiquant que la traduction est un peu
4938 obsolète et que le lecteur devrait se référer au document d'origine si possible.
4940 Évitez de supprimer complètement une traduction à cause de son obsolescence. Un
4941 vieux document est souvent mieux que pas de documentation du tout pour les
4942 personnes non anglophones.
4944 <sect1 id="l10n-faqm-bug">Comment gérer un rapport de bogue concernant
4945 une traduction ?
4947 La meilleure solution peut être de marquer le bogue comme « suivi au développeur
4948 amont » (<em>forwarded to upstream</em>) et de faire suivre le bogue à la
4949 fois au précédent traducteur et à son équipe (en utilisant la liste de diffusion
4950 debian-l10n-XXX correspondante).
4952 <sect id="l10n-faqtr">FAQ I18N & L10N pour les traducteurs
4954 Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de
4955 procédure générale dans Debian concernant ces points et que, dans tous les cas,
4956 vous devriez collaborer avec votre équipe et les responsables des paquets.
4958 <sect1 id="l10n-faqtr-help">Comment aider l'effort de traduction ?
4960 Choisissez ce que vous désirez traduire, assurez-vous que personne ne travaille
4961 déjà dessus (en utilisant votre liste de diffusion debian-l10n-XXX),
4962 traduisez-le, faites-le relire par d'autres personnes dont c'est également la
4963 langue maternelle sur votre liste de diffusion l10n et fournissez-le au
4964 responsable du paquet (voir le point suivant).
4966 <sect1 id="l10n-faqtr-inc">Comment fournir une traduction pour
4967 inclusion dans un paquet ?
4969 Assurez-vous que votre traduction est correcte (en demandant une relecture sur
4970 votre liste de discussion l10n) avant de la fournir pour inclusion. Cela
4971 gagnera du temps à tout le monde et évitera le chaos qui résulterait d'avoir
4972 plusieurs versions du même document dans les rapports de bogue.
4974 La meilleure solution est de remplir un bogue standard contenant la traduction
4975 sur le paquet. Assurez-vous d'utiliser l'étiquette « patch » et
4976 n'utilisez pas une gravité supérieure à « wishlist » car l'absence de
4977 traduction n'empêche jamais un programme de fonctionner.
4979 <sect id="l10n-best">Meilleures pratiques actuelles concernant la l10n
4983 En tant que responsable, n'éditez jamais les traductions en aucune façon (même
4984 pour reformater l'affichage) sans demander à la liste de diffusion l10n
4985 correspondante. Vous risquez, par exemple, de casser le codage du fichier en
4986 agissant ainsi. De plus, ce que vous considérez comme une erreur peut être
4987 correct (ou même nécessaire) pour une langue donnée.
4989 En tant que traducteur, si vous trouvez une erreur dans le texte d'origine,
4990 assurez-vous de l'indiquer. Les traducteurs sont souvent les lecteurs les plus
4991 attentifs d'un texte donné et s'ils ne rendent pas compte des erreurs qu'ils
4992 trouvent, personne ne le fera.
4994 Dans tous les cas, rappelez-vous que le problème principal avec la l10n est
4995 qu'elle demande la coopération de plusieurs personnes et qu'il est très facile
4996 de démarrer une guerre incendiaire à propos de petits problèmes dûs à une
4997 incompréhension. Donc, si vous avez des problèmes avec votre interlocuteur,
4998 demandez de l'aide sur la liste de diffusion l10n correspondante, sur
4999 debian-i18n ou même sur debian-devel (attention, cependant, les discussions sur
5000 la l10n tournent très souvent à l'incendie sur cette liste :)
5002 Dans tous les cas, la coopération ne peut être atteinte qu'avec un
5003 <strong>respect mutuel</strong>.
5007 <appendix id="tools">Aperçu des outils du responsable Debian
5009 Cette section contient un aperçu rapide des outils dont dispose le responsable.
5010 Cette liste n'est ni complète, ni définitive, il s'agit juste d'un guide
5011 des outils les plus utilisés.
5013 Les outils du responsable Debian sont destinés à améliorer le confort des
5014 responsables et libérer leur temps des tâches plus cruciales. Comme le dit
5015 Larry Wall, il y a plus d'une manière de le faire.
5017 Certaines personnes préfèrent utiliser des outils de haut niveau, d'autres pas.
5018 Debian n'a pas de position officielle sur la question ; tout outil
5019 conviendra du moment qu'il fait le boulot. C'est pourquoi cette section
5020 n'a pas été conçue pour indiquer à chacun quel outil il doit utiliser ou
5021 comment il devrait faire pour gérer sa charge de responsable Debian. Elle
5022 n'est pas non plus destinée à favoriser l'utilisation d'un outil aux
5025 La plupart des descriptions de ces outils proviennent des descriptions de leurs
5026 paquets. Vous trouverez plus d'informations dans les documentations de ces
5027 paquets. Vous pouvez aussi obtenir plus d'informations avec la commande
5028 <tt>apt-cache show <nom_paquet></tt>.</p>
5031 <sect id="tools-core">
5032 <heading>Outils de base</heading>
5034 Les outils suivants sont pratiquement nécessaires à tout responsable.</p>
5037 <sect1 id="dpkg-dev">
5038 <heading><package>dpkg-dev</package></heading>
5040 Le paquet <package>dpkg-dev</package> contient les outils (y compris
5041 <prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des
5042 paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas
5043 niveau indispensables pour créer et manipuler les paquets ; en tant que
5044 tels, ils sont indispensables à tout responsable Debian.
5046 <sect1 id="debconf">
5047 <heading><package>debconf</package></heading>
5049 Le paquet <package>debconf</package> fournit une interface unifiée pour
5050 configurer les paquets interactivement. Il est indépendant de l'interface et
5051 permet une configuration en mode texte, par une interface HTML ou par boîtes de
5052 dialogue. D'autres types d'interface peuvent être ajoutés sous forme de
5055 Vous trouverez la documentation de ce paquet dans le paquet
5056 <package>debconf-doc</package>.
5058 Beaucoup pensent que ce système devrait être utilisé pour tout paquet
5059 nécessitant une configuration interactive ; reportez-vous à la <ref
5060 id="bpp-config-mgmt">. <package>debconf</package> n'est pas requis par la
5061 <em>charte Debian</em> pour le moment ; cependant, cela pourra changer.
5064 <sect1 id="fakeroot">
5065 <package>fakeroot</package>
5067 <package>fakeroot</package> simule les privilèges <em>root</em>. Cela permet de
5068 fabriquer un paquet sans être root (en général, les paquets installent des
5069 fichiers appartenant à <em>root</em>). Si vous avez installé
5070 <package>fakeroot</package>, vous pouvez construire un paquet en tant que
5071 simple utilisateur avec : <tt>dpkg-buildpackage -rfakeroot</tt>.
5074 <sect id="tools-lint">
5075 <heading>Outils du paquet lint</heading>
5077 Selon le « Free On-line Dictionary of Computing » (FOLDOC),
5078 « lint » est « un outil de traitement de langage C qui contient
5079 beaucoup plus de tests complets sur le code que n'en font habituellement les
5080 compilateurs C. ». Les outils du paquet lint aide les responsables de
5081 paquet à trouver automatiquement des problèmes habituels et des violations de
5082 charte dans leurs paquets</p>
5084 <sect1 id="lintian">
5085 <heading><package>lintian</package></heading>
5087 <package>lintian</package> dissèque les paquets pour y repérer des bogues et des
5088 manquements aux règles de développement. Il contient des tests automatisés pour
5089 vérifier de nombreuses règles et quelques erreurs courantes.
5091 Vous devriez récupérer la dernière version de <package>lintian</package> depuis
5092 <em>unstable</em> régulièrement et vérifier tous vos paquets. Notez que
5093 l'option <tt>-i</tt> donne des explications détaillées sur la signication de
5094 chaque erreur, la partie concernée dans la charte et le moyen habituel de
5097 Veuillez vous reporter à <ref id="sanitycheck"> pour plus d'informations sur
5098 comment et quand utiliser Lintian.
5100 Vous pouvez aussi obtenir un résumé de tous les problèmes reportés par Lintian
5101 sur vos paquets à <url id="&url-lintian;">. Ces rapports contiennent la sortie
5102 de la dernière version de <prgn>lintian</prgn> sur l'ensemble de la
5103 distribution de développement (<em>unstable</em>).
5107 <heading><package>linda</package></heading>
5109 <package>linda</package> est un autre vérificateur de paquet. Il est sembable à
5110 <package>lintian</package>, mais il a un ensemble de tests différents. Il est écrit
5111 en Python plutôt qu'en Perl.</p>
5115 <sect1 id="debdiff">
5116 <heading><package>debdiff</package></heading>
5118 <prgn>debdiff</prgn> (du paquet <package>devscripts</package>, <ref
5119 id="devscripts">) compare des listes de fichiers et des fichiers de contrôle de
5120 deux paquets. C'est un simple test de régression qui peut vous aider à remarquer
5121 si le nombre de paquets binaires à changer depuis le dernier envoi ou si autre
5122 chose a changé dans le fichier de contrôle. Bien sûr, certains des changements
5123 qu'il indique sont normaux, mais il peut aider à empêcher différents accidents.
5125 Vous pouvez l'exécuter sur un couple de paquets binaires :
5127 debdiff package_1-1_arch.deb package_2-1_arch.deb
5130 Ou même sur un couple de fichiers de changements :
5132 debdiff package_1-1_arch.changes package_2-1_arch.changes
5135 Pour plus d'informations, veuillez voir <manref name="debdiff" section="1">.
5141 <sect id="tools-helpers">
5142 <heading>Aides pour le fichier <file>debian/rules</file></heading>
5144 Des outils de construction de paquets rendent le processus d'écriture du fichier
5145 <file>debian/rules</file> plus facile. Veuillez voir les <ref
5146 id="helper-scripts"> pour plus d'informations sur les raisons pour lesquelles
5147 ils peuvent être désirables ou non.
5149 <sect1 id="debhelper">
5150 <heading><package>debhelper</package></heading>
5152 Le paquet <package>debhelper</package> regroupe un ensemble de programmes qui
5153 peuvent être utilisés dans <file>debian/rules</file> pour automatiser les
5154 tâches courantes relatives à la fabrication des paquets Debian binaires. Ce
5155 paquet contient des utilitaires pour installer différents fichiers, les
5156 compresser, ajuster leurs droits et intégrer votre paquet dans le système de
5159 À la différence des autres approches, <package>debhelper</package> est divisé en
5160 plusieurs petits utilitaires qui agissent de manière cohérente. Ce découpage
5161 permet un contrôle des opérations plus fin que d'autres « <em>outils
5162 debian/rules</em> ».
5164 Il existe aussi un certain nombre de petites extensions
5165 <package>debhelper</package> trop éphémères pour être documentées. Vous en
5166 listerez la plupart en faisant <tt>apt-cache search ^dh-</tt>.
5170 <sect1 id="debmake">
5171 <heading><package>debmake</package></heading>
5173 <package>debmake</package> — un précurseur de <package>debhelper</package>
5174 — est un assistant moins modulaire pour manipuler le fichier
5175 <file>debian/rules</file>. Il inclut deux programmes principaux :
5176 <prgn>deb-make</prgn>, utile au développeur Debian pour convertir un paquet
5177 source normal (non-Debian) en paquet source Debian, et <prgn>debstd</prgn> qui
5178 regroupe le type de fonction que l'on trouve dans <package>debhelper</package>.
5180 Le consensus actuel est que l'usage de <package>debmake</package> est
5181 déconseillé au profit de <package>debhelper</package>, mais ce n'est pas une
5182 erreur d'utiliser <package>debmake</package>.
5185 <sect1 id="dh-make">
5186 <heading><package>dh-make</package>
5188 Le paquet <package/dh-make/ contient <prgn/dh_make/, un programme qui crée un
5189 squelette de fichiers nécessaires à la construction d'un paquet Debian à partir
5190 d'une arborescence source. Comme le nom le suggère, <prgn/dh_make/ est une
5191 réécriture de <package/debmake/ et ses fichiers modèles utilisent les
5192 programmes dh_* de <package/debhelper/.
5194 Quoique les fichiers de règles fabriqués par <prgn/dh_make/ constituent en général
5195 une base suffisante pour un paquet fonctionnel, ce ne sont que les
5196 fondations : la charge incombe toujours au responsable d'affiner
5197 les fichiers générés et de rendre le paquet complètement fonctionnel et
5198 en conformité avec la charte.
5202 <heading><package>yada</package></heading>
5204 Le paquet <package>yada</package> est un autre assistant pour la création de
5205 paquets. Il utilise un fichier <file>debian/packages</file> pour générer
5206 <file>debian/rules</file> et d'autres fichiers nécessaires dans le
5207 sous-répertoire <file>debian/</file>. Le fichier <file>debian/packages</file>
5208 contient des instructions pour construire les paquets et il n'y a pas besoin de
5210 <file>Makefile</file>. Il existe la possibilité d'utiliser un moteur de macros
5211 semblable à celui utilisé dans les fichiers SPECS des paquets source RPM.</p>
5213 Pour plus d'informations, voir le
5214 <tt><url id="http://yada.alioth.debian.org/" name="site de YADA"></tt>.</p>
5219 <heading><package>equivs</package></heading>
5221 <package>equivs</package> est un autre paquet pour faire des paquets. Il est
5222 souvent conseillé pour un usage local, si vous avez besoin de faire un paquet
5223 pour satisfaire des dépendances. Il est aussi parfois utilisé pour faire des
5224 « méta-paquets » qui sont des paquets dont l'unique objet est de
5225 dépendre d'autres paquets.</p>
5230 <sect id="tools-builders">
5231 <heading>Constructeurs de paquets</heading>
5233 Les paquets suivants aident le processus de construction des paquets, en général
5234 en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que la gestion du support de
5237 <sect1 id="cvs-buildpackage">
5238 <heading><package>cvs-buildpackage</package></heading>
5240 Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou de
5241 récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer
5242 un paquet Debian depuis le référentiel CVS et il assiste le développeur lors de
5243 l'intégration de modifications amont dans le référentiel.
5245 Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS pour le
5246 responsable Debian. Il permet de conserver des branches CVS distinctes pour les
5247 distributions <em>stable</em>, <em>unstable</em> et probablement
5248 <em>experimental</em> et de bénéficier des avantages d'un système de contrôle
5252 <sect1 id="debootstrap">
5253 <heading><package>debootstrap</package></heading>
5255 Le paquet <package>debootstrap</package> vous permet d'amorcer un système Debian
5256 de base à n'importe quel endroit dans votre système de fichier. Par
5257 « système de base », nous entendons le strict minimum nécessaire pour
5258 fonctionner et installer le reste du système.
5260 Avoir un système comme celui-ci peut vous servir de différentes manières. Vous
5261 pouvez, par exemple, déplacer votre racine dans ce système avec
5262 <prgn>chroot</prgn> pour tester vos dépendances de fabrication. Vous pouvez
5263 aussi l'utiliser pour voir comment se comporte votre paquet quand il est
5264 installé dans un environnement minimum.
5267 <sect1 id="pbuilder">
5268 <heading><package>pbuilder</package></heading>
5270 <package>pbuilder</package> construit un système « chrooté » et
5271 compile des paquets dans ce système. Ceci est très utile pour vérifier que les
5272 dépendances de compilation de votre paquet sont correctes et pour vous assurer
5273 qu'aucune dépendance de construction inutile ou incorrecte n'existe dans le
5274 paquet résultant. </sect1>
5277 <heading><package>sbuild</package></heading>
5279 <package>sbuild</package> est un autre compilateur automatique. Il peut aussi
5280 être utilisé dans un environnement « chrooté ». Il peut être utilisé
5281 seul ou comme partie d'un environnement de compilation distribué en réseau.
5282 Comme le précédent, c'est une partie du système utilisé par les porteurs pour
5283 construire des paquets binaires pour toutes les architectures disponibles.
5284 Veuillez vous reporter à <ref id="buildd"> pour plus d'informations et à <url
5285 id="&url-buildd;"> pour voir le système en fonctionnement.</p>
5289 <sect id="uploaders">
5290 <heading>Téléchargeurs de paquets</heading>
5292 Les paquets suivants aident à automatiser ou à simplifier le processus d'envoi
5293 de paquets dans l'archive officielle.</p>
5295 <sect1 id="dupload">
5296 <heading><package>dupload</package></heading>
5298 Le paquet <package>dupload</package> contient un script du même nom pour mettre
5299 à jour des paquets dans l'archive Debian, tracer les mises à jour et les
5300 annoncer par courrier électronique automatiquement. Vous pouvez le configurer
5301 pour faire des mises à jour à d'autres endroits et avec d'autres méthodes.
5305 <heading><package>dput</package></heading>
5307 Le script <package>dput</package> fait à peu près la même chose que
5308 <package>dupload</package>, mais il le fait différemment. Il a aussi quelques
5309 fonctions supplémentaires telles que la possibilité de vérifier la signature
5310 GnuPG et les sommes de contrôles avant le téléchargement et la possibilité de
5311 démarrer <prgn>dinstall</prgn> en mode simulation (<em>dry-run</em>) après le
5315 <heading><package>dcut</package></heading>
5317 Le script <package>dcut</package> (faisant partie du paquet <ref id="dput">)
5318 aide à la suppression de fichiers du répertoire d'envoi ftp.
5323 <sect id="tools-maint-automate">
5324 <heading>Automatisation de la maintenance</heading>
5326 Les outils suivants aident à automatiser les différentes tâches de maintenance
5327 par l'ajout des entrées de changelog ou de lignes de signatures, par la
5328 recherche de bogues à partir d'Emacs ou par l'utilisation du plus récent fichier
5329 officiel <file>config.sub</file>.</p>
5332 <sect1 id="devscripts">
5333 <heading><package>devscripts</package></heading>
5335 Le paquet <package>devscripts</package> contient des scripts et outils qui sont
5336 très utiles pour maintenir vos paquets Debian. Parmi ces scripts, vous
5337 trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui manipulent votre
5338 fichier <file>debian/changelog</file> depuis la ligne de commande et
5339 <prgn>debuild</prgn> qui est construit au-dessus de
5340 <prgn>dpkg-buildpackage</prgn>. L'outil <prgn>bts</prgn> est également très
5341 utile pour mettre à jour l'état des rapports de bogue depuis la ligne de
5342 commande. Le programme <prgn>uscan</prgn> peut être utilisé pour suivre les
5343 nouvelles versions amont de vos paquets. Le programme <prgn>debrsign</prgn>
5344 peut être utilisé pour signer à distance un paquet avant de l'envoyer, ce qui
5345 est agréable quand la machine sur laquelle vous construisez le paquet est
5346 différente de celle où résident vos clés GPG.</p>
5348 Vérifiez la page de manuel <manref section="1" name="devscripts"> pour une liste
5349 complète des scripts disponibles.
5351 <sect1 id="autotools-dev">
5352 <heading><package>autotools-dev</package></heading>
5354 Contient les meilleurs pratiques pour des personnes assurant la maintenance de
5355 paquets qui utilisent <prgn>autoconf</prgn> et/ou <prgn>automake</prgn>.
5356 Contient également des fichiers canoniques <file>config.sub</file> et
5357 <file>config.guess</file> qui sont connus pour fonctionner avec tous les
5358 portages Debian.</p>
5361 <sect1 id="dpkg-repack">
5362 <heading><package>dpkg-repack</package></heading>
5364 <prgn>dpkg-repack</prgn> crée un paquet Debian à partir d'un paquet qui
5365 a déjà été installé. Si des changements ont été effectués sur le paquet quand il
5366 a été décompacté (par exemple, des fichiers dans <file>/etc</file> ont été
5367 modifés), le nouveau paquet héritera de ces changements.</p>
5369 Cet utilitaire peut faciliter la copie de paquet d'un ordinateur vers un autre
5370 ou la re-création de paquets installés sur un système, mais qui ne sont plus
5371 disponibles ailleurs ou pour stocker l'état actuel d'un paquet avant de le
5376 <heading><package>alien</package></heading>
5378 <prgn>alien</prgn> convertit des paquets binaires entre différents formats de
5379 paquets, y compris des paquets Debian, RPM (RedHat), LSB (Linux Standard Base),
5380 Solaris et Slackware.</p>
5383 <sect1 id="debsums">
5384 <heading><package>debsums</package></heading>
5386 <prgn>debsums</prgn> vérifie des paquets installés par rapport à leur somme de
5387 hachage MD5. Veuillez noter que tous les paquets n'ont pas de sommes MD5 car
5388 elles ne sont pas requises par la charte.</p>
5391 <sect1 id="dpkg-dev-el">
5392 <heading><package>dpkg-dev-el</package></heading>
5394 <package>dpkg-dev-el</package> fournit des macros Emacs Lisp qui apportent une
5395 aide lors de l'édition des fichiers du répertoire <file>debian</file> de votre
5396 paquet. À l'édition de <file>debian/changelog</file>, par exemple, vous
5397 disposez de fonctions pour finaliser une version et consulter la liste des
5398 rapports de bogue ouverts.</p>
5402 <sect1 id="dpkg-depcheck">
5403 <heading><package>dpkg-depcheck</package></heading>
5405 <prgn>dpkg-depcheck</prgn> (du paquet <package>devscripts</package>, <ref
5406 id="devscripts">) exécute une commande sous <prgn>strace</prgn> pour déterminer
5407 tous les paquets utilisés par la commande.
5409 Pour les paquets Debian, c'est utile quand vous devez créer une ligne
5410 <tt>Build-Depends</tt> pour votre nouveau paquet : exécuter le processus de
5411 compilation avec <prgn>dpkg-depcheck</prgn> vous fournira une bonne première
5412 approximation des dépendances de compilation. Par exemple :
5414 dpkg-depcheck -b debian/rules build
5417 <prgn>dpkg-depcheck</prgn> peut aussi être utilisé pour vérifier les dépendances
5418 d'exécution, particulièrement si votre paquet utilise exec(2) pour exécuter
5419 d'autres programmes.
5421 Pour plus d'informations, veuillez voir <manref name="dpkg-depcheck" section="1">.
5425 <sect id="tools-porting">
5426 <heading>Outils de portage</heading>
5428 Les outils suivants facilitent le travail des porteurs et la compilation
5431 <sect1 id="quinn-diff">
5432 <heading><package>quinn-diff</package></heading>
5434 <package>quinn-diff</package> est utilisé pour localiser les différences d'une
5435 architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de
5436 l'architecture <var>X</var> doivent être portés sur l'architecture
5439 <sect1 id="dpkg-cross">
5440 <heading><package>dpkg-cross</package></heading>
5442 <package>dpkg-cross</package> est un outil qui installe les bibliothèques et les
5443 en-têtes nécessaires à une compilation
5444 croisée<footnote><p><em>cross-compilation</em></footnote> d'une manière
5445 similaire à <package>dpkg</package>. De plus, les paquets
5446 <prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
5447 améliorés pour accepter les compilations croisées.
5449 <sect id="tools-doc">
5450 <heading>Documentation et information</heading>
5452 Les paquets suivants fournissent des informations pour les responsables ou de
5453 l'aide pour construire de la documentation
5455 <sect1 id="debiandoc-sgml">
5456 <heading><package>debiandoc-sgml</package></heading>
5458 <package>debiandoc-sgml</package> fournit la DTD DebianDoc SGML qui est
5459 habituellement utilisée pour la documentation Debian. Ce manuel, par exemple,
5460 est écrit en DebianDoc. Il fournit également des scripts pour construire et
5461 décliner le source en de multiples formats de sortie.</p>
5463 La documentation sur la DTD peut être trouvée dans le paquet
5464 <package>debiandoc-sgml-doc</package>.</p>
5467 <sect1 id="debian-keyring">
5468 <heading><package>debian-keyring</package></heading>
5470 Contient les clés publiques GPG et PGP des développeurs Debian. Voir <ref
5471 id="key-maint"> et la documentation du paquet pour plus d'informations.</p>
5474 <sect1 id="debview">
5475 <heading><package>debview</package></heading>
5477 <package>debview</package> fournit un mode Emacs pour voir les paquets binaires
5478 Debian. Il vous permet d'examiner un paquet sans le décompresser.</p>
5483 <!-- FIXME: add the following
5486 dbs (referred to above)
5487 dpatch (referred to above)
5504 debaux: too new, unmaintained?
5505 dh-make-perl: too new, unmaintained?
5512 <!-- Keep this comment at the end of the file
5517 sgml-minimize-attributes:nil
5518 sgml-always-quote-attributes:t
5520 sgml-indent-data:nil
5521 sgml-parent-document:nil
5522 sgml-exposed-tags:nil
5523 sgml-declaration:nil
5524 sgml-local-catalogs:nil
5525 sgml-local-ecat-files:nil