1 <!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
5 <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
7 <?xml version="1.0" encoding="iso-8859-1"?>
8 <!-- common entities file
10 Bits of text which are language independent. In some cases it
11 makes sense to break these out because repetitively maintaining
12 them in different translations of the Developer's Reference is
13 wasteful. In other cases, the data is rather volatile and
14 breaking it out make maintenance easier.
17 <!-- volatile information -->
19 <!ENTITY number-of-pkgs "9000">
20 <!ENTITY number-of-maintainers "900">
22 <!ENTITY number-of-arches "12">
24 <!-- standard information -->
25 <!ENTITY fsf-addr "Free Software Foundation, Inc.,
26 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA">
27 <!ENTITY file-GPL "<file>/usr/share/common-licenses/GPL</file>">
28 <!ENTITY debian-formal "Debian GNU/Linux">
33 <!ENTITY www-debian-org "www.debian.org">
34 <!ENTITY ftp-debian-org "ftp.debian.org">
35 <!ENTITY ftp-host "&ftp-debian-org;">
36 <!ENTITY www-host "&www-debian-org;">
37 <!ENTITY lists-host "lists.debian.org">
38 <!ENTITY archive-host "archive.debian.org">
39 <!ENTITY keyserver-host "keyring.debian.org">
40 <!ENTITY packages-host "packages.debian.org">
41 <!ENTITY bugs-host "bugs.debian.org">
42 <!ENTITY pts-host "packages.qa.debian.org">
43 <!ENTITY ftp-master-host "ftp-master.debian.org">
44 <!ENTITY ftp-master-mirror "merkel.debian.org">
45 <!ENTITY non-us-host "non-us.debian.org">
46 <!ENTITY upload-queue "<ftppath>/pub/UploadQueue/</ftppath>">
48 <!ENTITY url-debian-policy "http://&www-debian-org;/doc/debian-policy/">
49 <!ENTITY url-perl-policy "http://&www-debian-org;/doc/packaging-manuals/perl-policy/">
50 <!ENTITY url-emacs-policy "http://&www-debian-org;/doc/packaging-manuals/debian-emacs-policy">
51 <!ENTITY url-java-policy "http://&www-debian-org;/doc/packaging-manuals/java-policy/">
52 <!ENTITY url-libpkg-guide "http://www.netfort.gr.jp/~dancer/column/libpkg-guide/">
54 <!ENTITY url-social-contract "http://&www-debian-org;/social_contract">
55 <!ENTITY url-constitution "http://&www-debian-org;/devel/constitution">
56 <!ENTITY url-dfsg "&url-social-contract;#guidelines">
57 <!ENTITY url-debian-lists "http://&www-debian-org;/MailingLists/">
58 <!ENTITY url-debian-lists-txt "http://&ftp-debian-org;/debian/doc/mailing-lists.txt">
59 <!ENTITY url-debian-lists-subscribe "http://&www-debian-org;/MailingLists/subscribe">
60 <!ENTITY url-debian-lists-new "http://&www-debian-org;/MailingLists/HOWTO_start_list">
61 <!ENTITY url-lists-archives "http://&lists-host;/">
62 <!ENTITY url-bts "http://&www-debian-org;/Bugs/">
63 <!ENTITY url-bts-report "&url-bts;Reporting">
64 <!ENTITY url-bts-devel "&url-bts;Developer">
65 <!ENTITY url-bts-control "&url-bts;server-control">
66 <!ENTITY url-debian-mirrors "http://&www-debian-org;/mirror/">
67 <!ENTITY url-debian-mirroring "&url-debian-mirrors;">
68 <!ENTITY url-debian-ports "http://&www-debian-org;/ports/">
69 <!ENTITY url-debian-port-lists "http://&lists-host;/ports.html">
70 <!ENTITY url-wnpp "http://&www-debian-org;/devel/wnpp/">
71 <!ENTITY url-devel-docs "http://&www-debian-org;/devel/">
72 <!ENTITY url-vote "http://&www-debian-org;/vote/">
73 <!ENTITY url-cvsweb "http://cvs.debian.org/">
74 <!ENTITY url-devel-machines "http://db.debian.org/machines.cgi">
75 <!ENTITY url-buildd "http://buildd.debian.org/">
76 <!ENTITY url-lintian "http://lintian.debian.org/">
77 <!ENTITY url-debian-qa "http://qa.debian.org/">
78 <!ENTITY url-debian-qa-orphaned "http://qa.debian.org/orphaned.html">
79 <!ENTITY url-debian-db "https://db.debian.org/">
80 <!ENTITY url-debian-db-login "https://db.debian.org/login.html">
81 <!ENTITY url-debian-db-mail-gw "http://db.debian.org/doc-mail.html">
82 <!ENTITY url-debian-db-doc "http://db.debian.org/doc-general.html">
83 <!ENTITY url-newmaint "http://&www-debian-org;/devel/join/newmaint">
84 <!ENTITY url-newmaint-checklist "http://&www-debian-org;/devel/join/nm-checklist">
85 <!ENTITY url-newmaint-db "http://nm.debian.org/">
86 <!ENTITY url-newmaint-advocate "http://&www-debian-org;/devel/join/nm-advocate">
87 <!ENTITY url-newmaint-amchecklist "http://&www-debian-org;/devel/join/nm-amchecklist">
88 <!ENTITY url-newmaint-apply "http://nm.debian.org/newnm.php">
89 <!ENTITY url-newmaint-id "http://&www-debian-org;/devel/join/nm-step2">
90 <!ENTITY url-newmaint-guide "http://&www-debian-org;/doc/maint-guide/">
91 <!ENTITY url-gpg-coord "http://nm.debian.org/gpg.php">
92 <!ENTITY url-debian-security-advisories "http://&www-debian-org;/security/">
93 <!ENTITY url-tech-ctte "http://&www-debian-org;/devel/tech-ctte">
94 <!ENTITY url-ddpo "http://qa.debian.org/developer.php">
96 <!ENTITY url-debian-keyring "http://&ftp-debian-org;/debian/doc/debian-keyring.tar.gz">
97 <!ENTITY url-readme-non-us "http://&ftp-debian-org;/debian/README.non-US">
98 <!ENTITY url-incoming "http://incoming.debian.org/">
99 <!ENTITY url-testing-maint "http://www.debian.org/devel/testing">
101 <!ENTITY url-testing-faq "&url-testing-maint;">
103 <!ENTITY us-upload-dir "<file>/org/ftp.debian.org/incoming/</file>">
104 <!ENTITY non-us-upload-dir "<file>/org/non-us.debian.org/incoming/</file>">
105 <!ENTITY url-chiark-readme "ftp://ftp.chiark.greenend.org.uk/pub/debian/private/project/README.how-to-upload">
106 <!ENTITY url-upload-erlangen "ftp://ftp.uni-erlangen.de/pub/Linux/debian/UploadQueue/">
107 <!ENTITY url-upload-samosa "ftp://samosa.debian.org/pub/UploadQueue/">
108 <!ENTITY url-upload-jp "ftp://master.debian.or.jp/pub/Incoming/upload/">
110 <!ENTITY url-mentors "http://people.debian.org/~mpalmer/debian-mentors_FAQ.html">
111 <!ENTITY url-sponsors "http://www.internatif.org/bortzmeyer/debian/sponsor/">
113 <!ENTITY url-rules-files "http://arch.debian.org/arch/private/srivasta/">
115 <!ENTITY url-debconf-l10n-help "http://&www-debian-org;/intl/l10n/templates/hints">
117 <!ENTITY url-dmup "http://&www-debian-org;/devel/dmup">
118 <!ENTITY url-worldmap "http://&www-debian-org;/devel/developers.loc">
120 <!ENTITY url-i18n-doc-check "http://cvs.debian.org/boot-floppies/documentation/doc-check?rev=HEAD&content-type=text/vnd.viewcvs-markup">
122 <!ENTITY url-eg-desc-upstream-info "http://&packages-host;/unstable/web/wml">
124 <!ENTITY url-alioth "http://alioth.debian.org/">
129 <!ENTITY url-gnu-manifesto "http://www.gnu.org/gnu/manifesto.html">
130 <!ENTITY url-gpl "http://www.gnu.org/copyleft/gpl.html">
131 <!ENTITY url-pgp-faq "http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/">
132 <!ENTITY url-rfc2440 "http://www.rfc-editor.org/rfc/rfc2440.txt">
133 <!ENTITY url-u.s.-export "http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html">
134 <!ENTITY url-notification-of-export "http://www.bxa.doc.gov/Encryption/">
135 <!ENTITY url-openprojects "http://www.freenode.net/">
137 <!-- Debian email addresses -->
138 <!ENTITY email-listmaster "<email>listmaster@&lists-host;</email>">
139 <!ENTITY email-debian-announce "<email>debian-announce@&lists-host;</email>">
140 <!ENTITY email-devel-ref "<email>developers-reference@&packages-host;</email>">
141 <!ENTITY email-debian-changes "<email>debian-changes@lists.debian.org</email>">
142 <!ENTITY email-debian-devel "<email>debian-devel@&lists-host;</email>">
143 <!ENTITY email-debian-devel-announce "<email>debian-devel-announce@&lists-host;</email>">
144 <!ENTITY email-debian-devel-changes "<email>debian-devel-changes@lists.debian.org</email>">
145 <!ENTITY email-debian-devel-req "<email>debian-devel-REQUEST@&lists-host;</email>">
146 <!ENTITY email-debian-i18n "<email>debian-i18n@&lists-host;</email>">
147 <!ENTITY email-debian-mentors "<email>debian-mentors@&lists-host;</email>">
148 <!ENTITY email-debian-private "<email>debian-private@&lists-host;</email>">
149 <!ENTITY email-debian-project "<email>debian-project@&lists-host;</email>">
150 <!ENTITY email-debian-policy "<email>debian-policy@&lists-host;</email>">
151 <!ENTITY email-debian-user "<email>debian-user@&lists-host;</email>">
152 <!ENTITY orphan-address "<packages@qa.debian.org>">
153 <!ENTITY email-debian-qa "<email>debian-qa@&lists-host;</email>">
154 <!ENTITY email-debian-release "<email>debian-release@&lists-host;</email>">
155 <!ENTITY email-debian-email "<email>debian-email@&lists-host;</email>">
156 <!ENTITY email-debian-vote "<email>debian-vote@&lists-host;</email>">
157 <!ENTITY email-debian-security-announce "<email>debian-security-announce@&lists-host;</email>">
158 <!ENTITY email-debian-l10n-english "<email>debian-l10n-english@&lists-host;</email>">
159 <!ENTITY email-mia "<email>mia@qa.debian.org</email>">
161 <!ENTITY email-new-maintainer "<email>new-maintainer@debian.org</email>">
162 <!ENTITY email-debian-keyring "<email>keyring-maint@debian.org</email>">
163 <!ENTITY email-debian-admin "<email>debian-admin@debian.org</email>">
164 <!ENTITY email-ftpmaster "<email>ftpmaster@debian.org</email>">
165 <!ENTITY email-override "<email>override-change@debian.org</email>">
166 <!ENTITY email-wnpp "<email>wnpp@debian.org</email>">
167 <!ENTITY email-bts-control "<email>control@&bugs-host;</email>">
168 <!ENTITY email-security-team "<email>team@security.debian.org</email>">
170 <!-- misc Debian info -->
171 <!ENTITY file-mail-lists "<file>/usr/share/doc/debian/mailing-lists.txt</file>">
172 <!ENTITY file-bts-docs "<file>/usr/share/doc/debian/bug-*</file>">
173 <!ENTITY file-python-policy "<file>/usr/share/doc/python/python-policy.txt.gz</file>">
174 <!ENTITY file-ocaml-policy "<file>/usr/share/doc/ocaml/ocaml_packaging_policy.gz</file>">
175 <!ENTITY file-lisp-controller "<file>/usr/share/doc/common-lisp-controller/README.packaging</file>">
176 <!ENTITY file-debian-private-archive "~debian/archive/debian-private/">
177 <!ENTITY file-bpp-autotools "<file>/usr/share/doc/autotools-dev/README.Debian.gz</file>">
179 <!ENTITY cron-bug-report '0 17 * * fri echo "index maint <var>address</var>" | mail request@&bugs-host;'>
181 <!ENTITY control-file-fields "<list compact>
182 <item><tt>Format</tt>
184 <item><tt>Source</tt>
185 <item><tt>Binary</tt>
186 <item><tt>Architecture</tt>
187 <item><tt>Version</tt>
188 <item><tt>Distribution</tt>
189 <item><tt>Urgency</tt>
190 <item><tt>Maintainer</tt>
191 <item><tt>Description</tt>
192 <item><tt>Changes</tt>
199 <!ENTITY pgp-keyserv "<tt>subkeys.pgp.net</tt>">
200 <!ENTITY file-keyservs "<file>/usr/share/doc/pgp/keyserv.doc</file>">
202 <!ENTITY sample-dist-dirtree "<example>
204 dists/stable/main/binary-i386/
205 dists/stable/main/binary-m68k/
206 dists/stable/main/binary-alpha/
208 dists/stable/main/source/
210 dists/stable/main/disks-i386/
211 dists/stable/main/disks-m68k/
212 dists/stable/main/disks-alpha/
215 dists/stable/contrib/
216 dists/stable/contrib/binary-i386/
217 dists/stable/contrib/binary-m68k/
218 dists/stable/contrib/binary-alpha/
220 dists/stable/contrib/source/
222 dists/stable/non-free/
223 dists/stable/non-free/binary-i386/
224 dists/stable/non-free/binary-m68k/
225 dists/stable/non-free/binary-alpha/
227 dists/stable/non-free/source/
232 dists/testing/contrib/
234 dists/testing/non-free/
240 dists/unstable/contrib/
242 dists/unstable/non-free/
253 pool/main/liba/libalias-perl/
259 pool/non-free/n/netscape/
263 <!ENTITY example-pathfind '<example>pathfind() {
267 if [ -x "$p/$*" ]; then
276 <!ENTITY % dynamicdata SYSTEM "dynamic.ent"> %dynamicdata;
279 <!ENTITY cvs-rev "$Revision: 1.62 $">
286 <!ENTITY FIXME "<em>FIXME:</em> ">
289 <?xml version="1.0" encoding="iso-8859-1"?><debiandoc>
293 Référence du développeur Debian
296 <name>L'équipe de la Référence du développeur</name>&email-devel-ref;
299 <name>Andreas Barth </name>
302 <name>Adam Di Carlo </name>
305 <name>Raphaël Hertzog </name>
308 <name>Christian Schwarz </name>
311 <name>Ian Jackson </name>
313 <!-- <!ENTITY cvs-en-rev "1.288"> -->
315 version française par Frédéric Bothamy (traducteur actuel)
317 <translator>et Antoine Hulin (ancien traducteur)</translator>
319 et les membres de la liste <email>debian-l10n-french@lists.debian.org</email>
322 Version &version;, &date-fr; (version française 20060407).
326 Copyright © 2004—2005 Andreas Barth
329 Copyright © 1998—2003 Adam Di Carlo
332 Copyright © 2002—2003 Raphaël Hertzog
335 Copyright © 1997, 1998 Christian Schwarz.
338 Ce manuel est un logiciel libre ; il peut être redistribué et/ou
339 modifié selon les termes de la licence publique générale du projet GNU
340 (GNU GPL), telle que publiée par la « Free Software
341 Foundation » (version 2 ou toute version postérieure).
344 Il est distribué dans l'espoir qu'il sera utile, mais <em>sans aucune
345 garantie</em>, sans même la garantie implicite d'une possible valeur
346 marchande ou d'une adéquation à un besoin particulier. Consultez la
347 licence publique générale du projet GNU pour plus de détails.
350 Une copie de la licence publique générale du projet GNU est disponible
351 dans le fichier &file-GPL; de la distribution &debian-formal; ou sur
352 la toile : <url id="http://www.gnu.org/copyleft/gpl.html"
353 name="la licence publique générale du projet GNU">. Vous pouvez
354 également l'obtenir en écrivant à la &fsf-addr;. <![ %htmltext [
357 Si vous désirez imprimer cette référence, vous devriez utiliser la
358 <url id="developers-reference.pdf" name="version PDF">. Cette page est
359 également disponible en <url id="index.en.html" name="anglais">. ]]>
367 Portée de ce document
370 Le but de ce document est de donner une vue d'ensemble des procédures à
371 suivre et des ressources mises à la disposition des développeurs Debian.
374 Les procédures décrites ci-après expliquent comment devenir responsable
375 Debian (<ref id="new-maintainer">), comment créer de nouveaux paquets
376 (<ref id="newpackage">) et comment les installer dans l'archive (<ref
377 id="upload">), comment gérer les rapports de bogues (<ref
378 id="bug-handling">), comment déplacer, effacer ou abandonner un paquet
379 (<ref id="archive-manip">), comment faire le portage d'un paquet (<ref
380 id="porting">), quand et comment faire la mise à jour du paquet d'un
381 autre responsable (<ref id="nmu">).
384 Les ressources présentées dans ce manuel incluent les listes de
385 diffusion (<ref id="mailing-lists">) et les serveurs (<ref
386 id="server-machines">), une présentation de la structure de l'archive
387 Debian (<ref id="archive">), des explications sur les serveurs qui
388 acceptent les mises à jour de paquets (<ref id="upload-ftp-master">) et
389 une présentation des outils qui peuvent aider un responsable à améliorer
390 la qualité de ses paquets (<ref id="tools">).
393 Ce manuel de référence ne présente pas les aspects techniques liés aux
394 paquets Debian, ni comment les créer. Il ne décrit pas non plus les
395 règles que doivent respecter les paquets Debian. Cette information est
396 disponible dans la <url id="&url-debian-policy;" name="charte Debian">.
399 De plus ce document <em>n'est pas l'expression d'une politique
400 officielle</em>. Il contient de la documentation sur le système Debian
401 et des conseils pratiques largement suivis. Ce n'est donc pas une sorte
404 <sect>Introduction à la version française
409 Bien que ce document soit en français, l'activité de responsable Debian implique
410 une maîtrise de la langue anglaise. Le projet Debian est un projet international
411 auquel participent des japonais, néo-zélandais, américains, allemands,
412 finlandais, français, espagnols, danois, etc.
415 En conséquence, la langue utilisée dans toutes les listes de diffusion destinées
416 aux développeurs (à l'exception de la liste
417 <email>debian-devel-french@&lists-host;</email>) est l'anglais et les rapports
418 de bogue doivent être rédigés en anglais. En fait, sauf exception rare, tout
419 dialogue avec les autres responsables Debian se fera en anglais quel que soit le
426 Cette section liste les termes techniques qui ont un sens spécifique dans le
427 projet Debian. Pour chacune de ces expressions, vous trouverez la traduction
428 française utilisée dans ce manuel, une définition et une référence à la section
429 du manuel qui traite de ce sujet.
433 <item><em>Upload</em> : mise à jour, téléchargement (parfois
434 livraison). Opération qui consiste à télécharger un nouveau paquet ou
435 une nouvelle version de paquet dans l'archive Debian (<ref
438 <item><em>Non-maintainer upload (NMU)</em> : mise à jour
439 indépendante. Téléchargement d'une nouvelle version de paquet dans
440 l'archive Debian par une personne qui n'est pas officiellement
441 responsable de ce paquet (<ref id="nmu">).
443 <item><em>Source NMU</em> : mise à jour indépendante source. Il
444 s'agit d'une mise à jour indépendante pour un paquet source (<ref
447 <item><em>Binary NMU</em> : mise à jour indépendante binaire. Mise
448 à jour indépendante pour un paquet binaire (<ref id="nmu-terms">).
450 <item><em>Bug Tracking System (BTS)</em> : système de suivi des
451 bogues. Il s'agit du système utilisé par le projet Debian pour suivre
452 les bogues et leur correction (<ref id="bug-handling">).
454 <item><em>Bug submitter</em> : rapporteur du bogue. Personne qui
455 envoie un rapport de bogue au système de suivi des bogues (<ref
458 <item><em>Release critical bug</em> : bogue empêchant l'intégration
459 du paquet dans la distribution. Bogues de gravité <em>critique</em>,
460 <em>grave</em> et <em>sérieuse</em>. Ces bogues ne doivent pas
461 apparaître dans une distribution <em>stable</em>. Ils doivent être
462 corrigés ou bien les paquets en cause doivent être supprimés (<ref
465 <item><em>Package Tracking System (PTS)</em> : système de suivi des
466 paquets. Il s'agit du système utilisé par le projet Debian pour suivre
467 les paquets sources des différentes distributions (<ref
468 id="pkg-tracking-system">).
470 <item><em>Unstable</em> : nom de la distribution en cours
471 de développement. Cette distribution contient les paquets
472 envoyés par les développeurs. Ceux-ci n'étant que des êtres
473 humains, elle est parfois cassée (<ref id="sec-dists">).
475 <item><em>Testing</em> : nom de la distribution en test. Cette
476 distribution reçoit les paquets des développeurs qui ont passé une
477 période de deux semaines dans <em>unstable</em> et pour lesquels aucun
478 bogue remettant en cause la distribution (cf. <em>Release critical
479 bug</em>) n'a été découvert. Cette distribution n'a pas été testée en
480 profondeur. Elle est cependant censée être plus stable
481 qu'<em>unstable</em> (<ref id="sec-dists">).
483 <item><em>Stable</em> : nom de la distribution stable. Cette
484 distribution a été testée, validée et diffusée (<ref id="sec-dists">).
486 <item><em>Debian maintainer</em> : responsable Debian, développeur
487 Debian (parfois mainteneur). Personne qui fait officiellement partie du
488 projet Debian. Elle a accès aux serveurs Debian et participe au
489 développement — au sens large — de la distribution (<ref
490 id="developer-duties">). La plupart des responsables font de la mise en
491 paquet, mais il existe d'autres activités telles que la documentation,
492 la gestion du site web, la création des cédéroms, l'administration des
495 <item><em>Upstream version</em> : version amont. Il s'agit du
496 logiciel tel qu'il est fourni par le responsable amont — par
497 opposition à la version fournie par la distribution Debian. (Voir <ref
498 id="upstream-coordination">.)
500 <item><em>Upstream maintainer</em> : responsable amont ou
501 développeur amont. Personne responsable du développement ou de la
502 maintenance d'un logiciel. En général, le responsable amont n'a rien à
503 voir avec le projet Debian (<ref id="upstream-coordination">).
505 <item><em>Debian keyring</em> : porte-clés Debian. Le porte-clés
506 Debian contient les clés publiques de tous les responsables Debian (<ref
509 <item><em>Work-needing and prospective packages (WNPP)</em> :
510 paquets en souffrance et paquets souhaités. La liste des paquets en
511 souffrance indique les paquets qui n'ont plus de responsable. La liste
512 des paquets souhaités indique les logiciels que des utilisateurs
513 aimeraient bien voir dans la distribution (<ref id="upload">).
517 <chapt id="new-maintainer">
519 Devenir responsable Debian
521 <sect id="getting-started">
526 Vous avez lu toute la documentation, vous avez examiné le <url
527 id="&url-newmaint-guide;" name="guide du nouveau responsable">, vous
528 comprenez l'intérêt de tout ce qui se trouve dans le paquet d'exemple
529 <package>hello</package> et vous vous apprêtez à mettre en paquet votre
530 logiciel préféré. Comment devenir responsable Debian et intégrer votre
531 travail au projet ?
534 Si vous ne l'avez pas encore fait, commencez par vous inscrire à la
535 liste &email-debian-devel;. Pour cela, envoyez un courrier à l'adresse
536 &email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne
537 <em>Objet</em><footnote><p><em>Subject</em> en anglais</p></footnote>
538 de votre message. En cas de problème, contactez l'administrateur de la
539 liste &email-listmaster;. Vous trouverez plus d'informations dans la
540 section <ref id="mailing-lists">. &email-debian-devel-announce; est une
541 autre liste incontournable pour qui veut suivre les développements de
545 Vous suivrez les discussions de cette liste (sans poster) pendant
546 quelque temps avant de coder quoi que ce soit et vous informerez la
547 liste de votre intention de travailler sur quelque chose pour éviter de
548 dupliquer le travail d'un autre.
551 Une autre liste intéressante est &email-debian-mentors;. Voir la
552 section <ref id="mentors"> pour les détails. Le canal IRC
553 <tt>#debian</tt> pourra aussi être utile ; voir <ref
557 Quand vous avez choisi la manière dont vous contribuerez au projet
558 &debian-formal;, prenez contact avec les responsables Debian qui
559 travaillent sur des tâches similaires. Ainsi, vous pourrez apprendre
560 auprès de personnes expérimentées. Si, par exemple, vous voulez mettre
561 en paquet des logiciels existants, trouvez-vous un parrain. Un parrain
562 est une personne qui travaillera sur vos paquets avec vous et les
563 téléchargera dans l'archive Debian une fois qu'il sera satisfait de
564 votre mise en paquet. Pour trouver un parrain, envoyez une demande de
565 parrainage à la liste &email-debian-mentors; en vous présentant et en
566 décrivant votre paquet (voir <ref id="sponsoring"> et <url
567 id="&url-mentors;"> pour en savoir plus sur le sujet). Si vous préférez
568 porter Debian sur une architecture ou un noyau alternatif, abonnez-vous
569 aux listes dédiées au portage et demandez-y comment
570 démarrer. Finalement, si vous êtes intéressé par la documentation ou
571 l'assurance qualité (QA), vous pouvez contacter les responsables qui
572 travaillent déjà sur ces tâches et proposer des correctifs et des
578 Mentors et parrains Debian
581 La liste de diffusion &email-debian-mentors; a été mise en place pour
582 les responsables débutants recherchant de l'aide avec l'empaquetage
583 initial et d'autres problèmes de développeur. Chaque nouveau
584 développeur est invité à s'abonner à cette liste (voir <ref
585 id="mailing-lists"> pour les détails).
588 Ceux qui préfèrent recevoir une aide plus personnalisée (par exemple,
589 par courriels privés) devraient également envoyer des messages à cette
590 liste et un développeur expérimenté se proposera de les aider.
593 De plus, si vous avez des paquets prêts à être inclus dans Debian, mais
594 que vous attendez que votre demande pour devenir responsable soit
595 acceptée, vous pouvez trouver un parrain pour envoyer vos paquets pour
596 vous. Les parrains sont des développeurs Debian officiels qui sont
597 volontaires pour critiquer et envoyer vos paquets pour vous. Veuillez
598 lire en premier la FAQ non officielle de debian-mentors à <url
602 Si vous désirez être un mentor et/ou un parrain, vous pouvez trouver
603 plus d'informations à <ref id="newmaint">.
606 <sect id="registering">
608 S'enregistrer comme responsable Debian
611 Avant de décider de devenir responsable Debian, il vous faudra lire
612 toute la documentation disponible dans le <url id="&url-newmaint;"
613 name="coin du nouveau responsable">. Elle décrit toutes les étapes
614 préparatoires qu'il vous faudra franchir avant de déposer votre
615 candidature. Par exemple, avant d'être candidat, il vous faudra lire le
616 <url id="&url-social-contract;" name="contrat social Debian">. Devenir
617 responsable Debian implique que vous adhériez à ce contrat social et
618 que vous vous engagiez à le soutenir ; il est très important que
619 les responsables soient en accord avec les principes fondamentaux qui
620 animent le projet &debian-formal;. Lire le <url
621 id="&url-gnu-manifesto;" name="Manifeste GNU"> est aussi une bonne
625 Le processus d'enregistrement a pour but de vérifier votre identité,
626 vos intentions et vos compétences. Le nombre de personnes travaillant
627 pour &debian-formal; a atteint &number-of-maintainers; et notre système
628 est utilisé dans plusieurs endroits très importants : nous devons
629 rester vigilants pour éviter un acte malveillant. C'est pourquoi nous
630 contrôlons les nouveaux responsables avant de leur donner un compte sur
631 nos serveurs et de les autoriser à ajouter des paquets dans l'archive.
634 Pour devenir responsable, il faudra montrer que vous pouvez faire du
635 bon travail et que vous serez un bon contributeur. Pour cela, vous
636 pourrez proposer des correctifs par le système de suivi des bogues
637 (BTS) et maintenir un paquet parrainé pendant un temps. Nous attendons
638 aussi des contributeurs qu'ils soient intéressés par le projet dans son
639 ensemble et pas uniquement par leurs propres paquets. Si vous pouvez
640 aider d'autres responsables en fournissant des informations sur un
641 bogue ou même avec un correctif, faites-le !
644 Pour votre candidature, vous devrez être familiarisé avec la
645 philosophie du projet Debian et avec sa documentation technique. Il
646 vous faudra aussi une clé GnuPG signée par un responsable Debian. Si
647 votre clé GnuPG n'est pas encore signée, vous devriez essayer de
648 rencontrer un responsable Debian pour le faire. La <url
649 id="&url-gpg-coord;" name="page de coordination des signatures de clé
650 GnuPG"> devrait vous aider à trouver un responsable Debian près de chez
651 vous. (S'il n'y a pas de responsable près de chez vous, il peut y avoir
652 des moyens alternatifs pour valider votre identité en tant qu'exception
653 absolue étudiée au cas par cas. Veuillez vous reporter à la <url
654 id="&url-newmaint-id;" name="page d'identification"> pour en savoir
658 Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin
659 d'une clé OpenPGP pour signer et vérifier les mises à jour de
660 paquets. Vous lirez la documentation du logiciel de cryptographie que
661 vous utiliserez car elle contient des informations indispensables pour
662 la sécurité de votre clé. Les défaillances de sécurité sont bien plus
663 souvent dues à des erreurs humaines qu'à des problèmes logiciels ou à
664 des techniques d'espionnage avancées. Voir <ref id="key-maint"> pour
665 plus d'informations sur la gestion de votre clé publique.
668 Debian utilise <prgn>GNU Privacy Guard</prgn> (paquet
669 <package>gnupg</package> version 1 ou supérieure) comme standard de
670 base. Vous pouvez aussi utiliser une autre implémentation
671 d'OpenPGP. OpenPGP est un standard ouvert basé sur la <url
672 id="&url-rfc2440;" name="RFC 2440">.
675 Vous avez besoin d'une clé en version 4 à utiliser pour le
676 développement Debian. La longueur de votre clé doit être d'au moins
677 1024 ;bits ; il n'y a pas de raison d'utiliser une clé plus
678 petite et faire cela serait bien moins sûr. <footnote><p>Les clés en
679 version 4 sont des clés conformes au standard OpenPGP défini dans
680 la RFC 2440. La version 4 est le type de clé qui a toujours
681 été créé avec GnuPG. Les versions de PGP depuis la version 5
682 peuvent également créer des clés version 4, l'autre choix ayant
683 été des clés compatibles pgp 2.6.x (également appelées
684 « legacy RSA » par PGP).</p><p>Les clés (primaires) en
685 version 4 peuvent soit utiliser l'algorithme RSA, soit
686 l'algorithme DSA, cela n'a donc rien à voir avec la question de GnuPG à
687 propos de « quel type de clé voulez-vous : (1) DSA et
688 Elgamal, (2) DSA (signature seule), (5) RSA (signature seule). Si vous
689 n'avez pas des besoins spécifiques, choisissez simplement la valeur par
690 défaut ».</p><p>Le moyen le plus simple de dire si une clé
691 existante est une clé v4 ou une clé v3 (ou v2) est de regarder son
692 empreinte : les empreintes des clés en version 4 sont des
693 hachés SHA-1 d'une partie de la clé, il s'agit donc d'une suite de
694 40 chiffres hexadécimaux, habituellement groupés par blocs de
695 4. Les empreintes des anciennes versions de clé utilisaient MD5 et sont
696 généralement affichées par blocs de 2 chiffres hexadécimaux. Par
697 exemple, si votre empreinte ressemble à ceci :
698 <tt>5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F</tt>,
699 alors il s'agit d'une clé v4.</p><p>Une autre possibilité est d'envoyer
700 la clé dans <prgn>pgpdump</prgn>, qui dira quelque chose comme
701 « Public Key Packet - Ver 4 ».</p><p>Notez également que
702 votre clé doit être auto-signée (c.-à-d. elle doit signer tous ses
703 propres identifiants d'utilisateur ; cela empêche la falsification
704 d'identité). Tous les logiciels OpenPGP modernes font cela
705 automatiquement, mais si vous avez une ancienne clé, il se peut que
706 vous deviez ajouter manuellement ces signatures.</p></footnote>
709 Si votre clé publique n'est pas sur un serveur public tel que
710 &pgp-keyserv;, reportez-vous à la documentation disponible localement
711 dans &file-keyservs;. Cette documentation explique comment mettre votre
712 clé publique sur un serveur. L'équipe <em>New maintainer</em> mettra
713 votre clé publique sur les serveurs de clés si elle n'y est pas déjà.
716 Certains pays limitent l'usage des logiciels de cryptographie. Cela ne
717 devrait cependant pas avoir d'impact sur l'activité d'un responsable de
718 paquet car il peut être tout à fait légal d'utiliser des logiciels de
719 cryptographie pour l'authentification plutôt que pour le
720 chiffrement. Si vous vivez dans un pays où l'utilisation de la
721 cryptographie pour authentification est interdite, contactez-nous pour
722 que nous prenions des dispositions particulières.
725 Pour faire acte de candidature, il vous faut un responsable Debian qui
726 vérifiera votre candidature (un <em>avocat</em>). Après avoir contribué
727 au projet Debian pendant un temps, quand vous choisissez de devenir un
728 responsable Debian officiel, un responsable déjà enregistré avec qui
729 vous aurez travaillé dans les derniers mois devra exprimer que, d'après
730 lui, vous pouvez contribuer avec succès au projet Debian.
733 Quand vous avez trouvé un <em>avocat</em>, quand votre clé GnuPG est
734 signée et quand vous avez déjà contribué au projet, vous êtes prêt à
735 faire acte de candidature. Il vous suffit pour cela de vous enregistrer
736 sur notre <url id="&url-newmaint-apply;" name="page de
737 candidature">. Ensuite, votre avocat devra confirmer votre
738 candidature. Quand il aura accompli cette tâche, un responsable de
739 candidature<footnote><p>Application manager</p></footnote> sera désigné
740 pour vous accompagner dans le processus d'enregistrement. Vous pouvez
741 toujours consulter le <url id="&url-newmaint-db;" name="tableau de bord
742 des candidatures"> pour connaître l'état de votre candidature.
745 Pour en savoir plus, consultez le <url id="&url-newmaint;" name="coin
746 des nouveaux responsables"> sur le site Debian. Assurez-vous de bien
747 connaître les étapes nécessaires au processus d'enregistrement avant de
748 vous porter candidat. Vous gagnerez beaucoup de temps si vous êtes bien
753 <chapt id="developer-duties">
755 Les charges du responsable Debian
757 <sect id="user-maint">
759 Mise à jour de vos références Debian
762 Il existe une base de données LDAP contenant des informations
763 concernant les développeurs Debian à <url id="&url-debian-db;">. Vous
764 devriez y entrer vos informations et les mettre à jour quand elles
765 changent. Le plus important est de vous assurer que l'adresse vers
766 laquelle est redirigée votre adresse debian.org est toujours à jour, de
767 même que l'adresse à laquelle vous recevez votre abonnement à
768 debian-private si vous choisissez d'être abonné à cette liste.
771 Pour plus d'informations à propos de cette base de données, veuillez
772 consulter <ref id="devel-db">.
775 <sect id="key-maint">
777 Gérer votre clé publique
780 Soyez très vigilant en utilisant votre clé privée. Ne la placez pas sur
781 un serveur public ou sur des machines multi-utilisateurs telles que les
782 serveurs Debian (voir <ref id="server-machines">). Sauvegardez vos clés
783 et gardez-en une copie hors connexion. Lisez la documentation fournie
784 avec votre logiciel et la <url id="&url-pgp-faq;" name="FAQ PGP">.
787 Vous devez vous assurer que non seulement votre clé est à l'abri des
788 vols, mais également à l'abri d'une perte. Générez et faites une copie
789 (et également sur papier) de votre certificat de révocation ; il
790 est nécessaire si votre clé est perdue.
793 Si vous ajoutez des signatures ou des identifiants à votre clé
794 publique, vous pouvez mettre à jour le porte-clés Debian en envoyant
795 votre clé publique à <tt>&keyserver-host;</tt>.
798 Si vous voulez ajouter une nouvelle clé ou supprimer une ancienne clé,
799 vous devez faire signer la nouvelle clé par un autre développeur. Si
800 l'ancienne clé est compromise ou invalide, vous devez également ajouter
801 la certification de révocation. S'il n'y pas de vraie raison pour une
802 nouvelle clé, les responsables du trousseau de clés peuvent rejeter la
803 nouvelle clé. Vous pouvez trouver plus de détails à <url
804 id="http://keyring.debian.org/replacing_keys.html">.
807 Les mêmes routines d'extraction de clé décrites dans <ref
808 id="registering"> s'appliquent.
811 Vous pouvez trouver une présentation approfondie de la gestion de clé
812 Debian dans la documentation du paquet
813 <package>debian-keyring</package>.
821 Bien que Debian ne soit pas vraiment une démocratie, nous disposons
822 d'un processus démocratique pour élire nos chefs et pour approuver les
823 résolutions générales. Ces procédures sont définies par la <url
824 id="&url-constitution;" name="charte Debian">.
827 En dehors de l'élection annuelle du chef, les votes ne se tiennent pas
828 régulièrement et ils ne sont pas entrepris à la légère. Chaque
829 proposition est tout d'abord discutée sur la liste de diffusion
830 &email-debian-vote; et elle a besoin de plusieurs approbations avant
831 que le secrétaire du projet n'entame la procédure de vote.
834 Vous n'avez pas besoin de suivre les discussions précédant le vote car
835 le secrétaire enverra plusieurs appels au vote sur la liste
836 &email-debian-devel-announce; (et tous les développeurs devraient être
837 inscrits à cette liste). La démocratie ne fonctionne pas si les
838 personnes ne prennent pas part au vote, c'est pourquoi nous
839 encourageons tous les développeurs à voter. Le vote est conduit par
840 messages signés ou chiffrés par GPG.
843 La liste de toutes les propositions (passées et présentes) est
844 disponible à la page <url id="&url-vote;" name="Informations sur les
845 votes Debian">, ainsi que des informations complémentaires sur la
846 procédure à suivre pour effectuer une proposition, la soutenir et voter
850 <sect id="inform-vacation">
852 Prendre des vacances courtoisement
855 Il est courant pour les développeurs de s'absenter, que ce soit pour
856 des vacances prévues ou parce qu'ils sont submergés de travail. La
857 chose importante à noter est que les autres développeurs ont besoin de
858 savoir que vous êtes en vacances pour qu'ils puissent agir en
859 conséquence si un problème se produit pendant vos vacances.
862 Habituellement, cela veut dire que les autres développeurs peuvent
863 faire des NMU (voir <ref id="nmu">) sur votre paquet si un gros
864 problème (bogues empêchant l'intégration dans la distribution, mise à
865 jour de sécurité, etc.) se produit pendant que vous êtes en
866 vacances. Parfois, ce n'est pas très important, mais il est de toute
867 façon approprié d'indiquer aux autres que vous n'êtes pas disponible.
870 Il y a deux choses à faire pour informer les autres
871 développeurs. Premièrement, envoyez un courrier électronique à
872 &email-debian-private; en commençant le sujet de votre message par
873 « [VAC] »<footnote><p>Ainsi, le message peut être facilement
874 filtré par les personnes qui ne veulent pas lire ces annonces de
875 vacances.</p></footnote> et donnez la période de vos vacances. Vous
876 pouvez également donner quelques instructions pour indiquer comment
877 agir si un problème survenait.
880 L'autre chose à faire est de vous signaler comme « en
881 vacances »<footnote><p><em>on vacation</em> en
882 anglais</p></footnote> dans la <qref id="devel-db">base de données
883 Debian LDAP</qref> (l'accès à cette information est réservé aux
884 développeurs). N'oubliez pas de retirer votre indicateur « en
885 vacances » lorsque celles-ci sont terminées !
888 Idéalement, vous devriez vous connecter sur le <url
889 id="http://nm.debian.org/gpg.php" name="site de coordination GPG">
890 quand vous réservez pour des vacances et vérifier si quelqu'un
891 recherche un échange de signatures. Cela est particulièrement important
892 quand des personnes vont à des endroits exotiques où nous n'avons pas
893 encore de développeurs, mais où il y a des personnes intéressées pour
894 poser leur candidature.
897 <sect id="upstream-coordination">
899 Coordination avec les développeurs amont
902 Une grande part de votre travail de responsable Debian sera de rester
903 en contact avec les développeurs amont. Parfois, les utilisateurs
904 établissent des rapports de bogue qui ne sont pas spécifiques à
905 Debian. Vous devez transmettre ces rapports de bogue aux développeurs
906 amont pour qu'ils soient corrigés dans les prochaines versions.
909 Bien qu'il ne soit pas de votre responsabilité de corriger les bogues
910 non spécifiques à Debian, vous pouvez le faire si vous en êtes
911 capable. Quand vous faites de telles corrections, assurez-vous de les
912 envoyer également au développeur amont. Les utilisateurs et
913 responsables Debian proposent souvent des correctifs pour corriger des
914 bogues amont, il vous faudra alors évaluer ce correctif puis le
915 transmettre aux développeurs amont.
918 Si vous avez besoin de modifier les sources d'un logiciel pour
919 fabriquer un paquet conforme à la charte Debian, alors vous devriez
920 proposer un correctif aux développeurs amont pour qu'il soit inclus
921 dans leur version. Ainsi, vous n'aurez plus besoin de modifier les
922 sources lors des mises à jour amont suivantes. Quels que soient les
923 changements dont vous avez besoin, il faut toujours essayer de rester
924 dans la lignée des sources amont.
929 Comment gérer les bogues empêchant l'intégration du paquet dans la
933 Habituellement, vous devriez traiter les rapports de bogue sur vos
934 paquets tel que cela est décrit dans <ref
935 id="bug-handling">. Cependant, il y a une catégorie spéciale de bogues
936 qui nécessite particulièrement votre attention : les bogues
937 empêchant l'intégration du paquet dans la
938 distribution<footnote><p>Traduction de l'anglais <em>Release-critical
939 bug (RC Bugs)</em></p></footnote>. Tous les rapports de bogue de
940 gravité <em>critique</em>, <em>grave</em> et
941 <em>sérieuse</em><footnote><p>Respectivement <em>critical</em>,
942 <em>grave</em> et <em>serious</em> en anglais</p></footnote> sont
943 considérés comme ayant un impact sur la présence du paquet dans la
944 prochaine version stable de Debian. Ces bogues peuvent retarder la
945 diffusion d'une distribution Debian ou peuvent justifier la suppression
946 d'un paquet d'une distribution gelée. C'est pourquoi ces bogues doivent
947 être corrigés au plus vite.
950 Les développeurs faisant partie de l'équipe d'<url id="&url-debian-qa;"
951 name="assurance qualité Debian"> surveillent ces bogues et essaient de
952 vous aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas
953 corriger un bogue de ce type dans les deux semaines, vous devriez soit
954 demander de l'aide en envoyant un courrier à l'équipe d'assurance
955 qualité (<em>QA group</em>) à &email-debian-qa;, soit expliquer vos
956 difficultés et présenter un plan pour corriger le problème en répondant
957 au rapport de bogue concerné. Si rien n'est fait, des personnes de
958 l'équipe d'assurance qualité pourraient chercher à corriger votre
959 paquet (voir <ref id="nmu">) après avoir tenté de vous contacter (ils
960 pourraient attendre moins longtemps que d'habitude pour faire leur mise
961 à jour s'il n'y a pas trace d'activité récente de votre part dans le
962 système de suivi des bogues).
970 Si vous choisissez de quitter le projet Debian, procédez comme
972 <enumlist numeration="arabic">
975 abandonnez tous vos paquets comme décrit dans <ref
976 id="orphaning"> ;
981 envoyez un courrier électronique signé par GnuPG à
982 &email-debian-private; indiquant pourquoi vous quittez le
988 signalez aux responsables du porte-clés Debian que vous quittez le
989 projet en écrivant à &email-debian-keyring;.
996 <chapt id="resources">
998 Ressources pour le responsable Debian
1001 Dans ce chapitre, vous trouverez une brève description des listes de
1002 diffusion, des machines Debian qui seront à votre disposition en tant
1003 que responsable Debian ainsi que toutes les autres ressources à votre
1004 disposition pour vous aider dans votre travail de responsable.
1006 <sect id="mailing-lists">
1008 Les listes de diffusion
1011 Une grande partie des discussions entre les développeurs Debian (et les
1012 utilisateurs) est gérée par un vaste éventail de listes de diffusion
1013 que nous hébergeons à <tt><url id="http://&lists-host;/"
1014 name="&lists-host;"></tt>. Pour en savoir plus sur comment s'abonner ou
1015 se désabonner, comment envoyer un message et comment ne pas en envoyer,
1016 comment retrouver d'anciens messages et comment les rechercher, comment
1017 contacter les responsables des listes et pour savoir d'autres
1018 informations sur les listes de diffusion, veuillez lire <url
1019 id="&url-debian-lists;">. Cette section ne couvrira que les aspects des
1020 listes de diffusion qui ont un intérêt particulier pour les
1023 <sect1 id="mailing-lists-rules">
1025 Règles de base d'utilisation
1028 Lorsque vous répondez sur une liste de diffusion, veuillez ne pas
1029 envoyer de copie (<tt>CC</tt>) à l'auteur d'origine sauf s'il le
1030 demande explicitement. Toute personne envoyant un message à une liste
1031 de diffusion devrait la suivre pour voir les réponses.
1034 Le multi-postage (cross-posting) (envoyer le même message à plusieurs
1035 listes) est découragé. Comme toujours sur le net, veuillez réduire la
1036 citation des articles auxquels vous répondez. En général, veuillez
1037 adhérez aux conventions usuelles d'envoi de messages.
1040 Veuillez lire le <url id="&url-debian-lists;#codeofconduct" name="code
1041 de conduite"> pour plus d'informations.
1044 <sect1 id="core-devel-mailing-lists">
1046 Principales listes pour les responsables
1049 Les principales listes de diffusion de Debian que les développeurs
1050 devraient suivre sont :
1054 &email-debian-devel-announce;, utilisée pour les annonces
1055 importantes faites aux responsables. Tous les responsables Debian
1056 sont censés être inscrits à cette liste,
1061 &email-debian-devel;, utilisée pour discuter de diverses questions
1062 techniques relatives au développement,
1067 &email-debian-policy; où l'on discute et vote les modifications de
1073 &email-debian-project;, utilisée pour discuter de questions non
1080 Il existe d'autres listes de diffusion spécialisées dans différents
1081 thèmes. Reportez-vous à la page <url id="http://&lists-host;/"> pour
1082 en obtenir la liste complète.
1085 <sect1 id="mailing-lists-special">
1090 &email-debian-private; est une liste de diffusion destinée aux
1091 discussions privées entre développeurs Debian. Elle doit être utilisée
1092 pour tout message qui ne doit pas être publié, quelle qu'en soit la
1093 raison. C'est une liste à faible trafic et les utilisateurs sont priés
1094 de ne l'utiliser qu'en cas de réelle nécessité. De plus, il ne faut
1095 <em>jamais</em> faire suivre un courrier de cette liste à qui que ce
1096 soit. Pour des raisons évidentes, les archives de cette liste ne sont
1097 pas disponibles sur la toile. Vous pouvez les consulter en visitant le
1098 répertoire <file>~debian/archive/debian-private</file> avec votre
1099 compte sur <tt>lists.debian.org</tt>.
1102 &email-debian-email; est une liste de diffusion fourre-tout. Elle est
1103 utilisée pour les correspondances relatives à Debian qu'il serait
1104 utile d'archiver, telles que des échanges avec les auteurs amont à
1105 propos de licences, de bogues ou encore des discussions sur le projet
1106 avec d'autres personnes.
1109 <sect1 id="mailing-lists-new">
1111 Demander une nouvelle liste relative au développement
1114 Avant de demander une liste de diffusion liée au développement d'un
1115 paquet (ou d'un petit groupe de paquets liés), veuillez considérer si
1116 l'utilisation d'un alias (via un fichier .forward-aliasname sur
1117 master.debian.org, ce qui se traduit en une adresse raisonnablement
1118 agréable <var>you-aliasname@debian.org</var>) ou une liste de
1119 diffusion auto-gérée sur <qref id="alioth">Alioth</qref> serait plus
1123 Si vous décidez qu'une liste de diffusion standard sur
1124 lists.debian.org est vraiment ce que vous voulez, lancez-vous et
1125 faites une demande en suivant <url id="&url-debian-lists-new;"
1130 <sect id="irc-channels">
1135 Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont
1136 principalement hébergés sur le réseau <url id="&url-openprojects;"
1137 name="freenode"> (anciennement connu sous le nom de Open Projects
1138 Network). L'entrée DNS <tt>irc.debian.org</tt> est simplement un alias
1139 vers <tt>irc.freenode.net</tt>.
1142 Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un
1143 canal important, généraliste, où les utilisateurs peuvent trouver des
1144 nouvelles récentes dans le sujet et qui est administré par des
1145 robots. <em>#debian</em> est destiné aux anglophones ; il existe
1146 également <em>#debian.de</em>, <em>#debian-fr</em>, <em>#debian-br</em>
1147 et d'autres canaux avec des noms semblables pour les personnes parlant
1151 Le canal principal pour le développement Debian est
1152 <em>#debian-devel</em>. C'est un canal très actif avec habituellement
1153 plus de 150 personnes connectées en permanence. C'est un canal pour les
1154 personnes qui travaillent sur Debian, ce n'est pas un canal d'aide (il
1155 existe <em>#debian</em> pour cela). Il est cependant ouvert à tous ceux
1156 qui veulent écouter (et apprendre). Le sujet est toujours rempli
1157 d'informations intéressantes.
1160 Comme <em>#debian-devel</em> est un canal ouvert, vous ne devriez pas y
1161 parler de problèmes discutés sur &email-debian-private;. Il existe un
1162 canal protégé par clé <em>#debian-private</em> dans ce but. La clé est
1163 disponible dans les archives de debian-private à
1164 <file>master.debian.org:&file-debian-private-archive;</file>, effectuez
1165 simplement un <prgn>zgrep</prgn> avec <em>#debian-private</em> dans
1169 Il existe d'autres canaux dédiés à des sujets
1170 spécifiques. <em>#debian-bugs</em> est utilisé pour la coordination des
1171 <em>chasses aux bogues</em>. <em>#debian-boot</em> est utilisé pour la
1172 coordination du travail sur l'installateur Debian. <em>#debian-doc</em>
1173 est utilisé occasionnellement pour travailler sur la documentation
1174 comme celle que vous lisez actuellement. D'autres canaux sont dédiés à
1175 une architecture ou un ensemble de paquets : <em>#debian-bsd</em>,
1176 <em>#debian-kde</em>, <em>#debian-jr</em>, <em>#debian-edu</em>,
1177 <em>#debian-sf</em> (paquet SourceForge), <em>#debian-oo</em> (paquet
1181 Certains canaux pour développeurs non anglophones existent, par
1182 exemple, <em>#debian-devel-fr</em> pour les francophones intéressés
1183 dans le développement de Debian.
1186 Il existe également des canaux dédiés pour Debian sur d'autres réseaux
1187 IRC, notamment sur le réseau IRC <url id="http://www.oftc.net/"
1188 name="Open and free technology community (OFTC)">.
1191 Pour obtenir un uniforme (« cloak ») sur freenode, vous devez
1192 envoyer un courriel signé à Jörg Jaspert <joerg@debian.org>
1193 dans lequel vous indiquez quel est votre pseudonyme
1194 (« nick »). Mettez « cloak » quelque part dans le
1195 sujet. Votre pseudonyme devra être enregistré : <url
1196 id="http://freenode.net/faq.shtml#nicksetup" name="Page de
1197 configuration des pseudonymes">. Le courriel doit être signé par une
1198 clé du porte-clés Debian. Veuillez consulter la <url
1199 id="http://freenode.net/faq.shtml#projectcloak" name="documentation de
1200 Freenode"> pour plus d'informations sur les uniformes.
1203 <sect id="doc-rsrcs">
1208 Ce document contient beaucoup d'informations très utiles aux
1209 développeurs Debian, mais il ne peut pas tout contenir. La plupart des
1210 autres documents intéressants sont référencés dans le <url
1211 id="&url-devel-docs;" name="coin du développeur Debian">. Prenez le
1212 temps de parcourir tous les liens, vous apprendrez encore beaucoup de
1216 <sect id="server-machines">
1221 Debian possède plusieurs ordinateurs employés comme serveurs, dont la
1222 plupart hébergent les fonctions critiques du projet Debian. La plupart
1223 des machines sont utilisées pour des activités de portage et elles ont
1224 toutes un accès permanent à Internet.
1227 La plupart des machines peuvent être utilisées par les développeurs
1228 tant qu'ils respectent les règles définies dans la <url id="&url-dmup;"
1229 name="charte d'utilisation des machines Debian">.
1232 Dans l'ensemble, vous pouvez faire usage de ces machines pour des buts
1233 relatifs à Debian comme vous l'entendez. Veuillez cependant être gentil
1234 avec les administrateurs système et ne pas utiliser de grandes
1235 quantités d'espace disque, de ressource réseau ou CPU sans obtenir
1236 auparavant l'accord des administrateurs. Habituellement, ces machines
1237 sont administrées par des volontaires.
1240 Veuillez prendre soin de votre mot de passe Debian ainsi que des clés
1241 SSH installées sur les machines Debian. Évitez les méthodes de
1242 connexion ou d'envoi de données qui envoient les mots de passe en clair
1243 par l'Internet comme telnet, FTP, POP, etc.
1246 Veuillez ne pas déposer de données non relatives à Debian sur les
1247 serveurs Debian à moins que vous n'ayez préalablement obtenu la
1248 permission de le faire.
1251 La liste actuelle des machines Debian est disponible à <url
1252 id="&url-devel-machines;">. Cette page web contient les noms des
1253 machines, les informations de contact, les informations sur qui peut
1254 s'y connecter, les clés SSH, etc.
1257 Si vous avez un problème en utilisant un serveur Debian et si vous
1258 estimez que les administrateurs système devraient en être avertis,
1259 l'équipe des administrateurs système peut être jointe à
1260 <email>debian-admin@lists.debian.org</email>.
1263 Si votre problème est lié à un certain service ou n'est pas lié au
1264 système (paquet à supprimer de l'archive ou suggestion pour le site web
1265 par exemple), il vous faudra en général ouvrir un rapport de bogue sur
1266 un « pseudo-paquet ». Reportez-vous à la section <ref
1267 id="submit-bug"> pour connaître la procédure à suivre.
1270 Certains des serveurs de base sont à accès restreint, mais les
1271 informations de ceux-ci sont fournies par d'autres serveurs miroirs.
1273 <sect1 id="servers-bugs">
1275 Le serveur pour les rapports de bogues
1278 <tt>&bugs-host;</tt> est le serveur maître du système de suivi des
1279 bogues (BTS<footnote><p>Système de suivi des bogues se dit <em>Bug
1280 Tracking System</em> en anglais</p></footnote>).
1283 Ce serveur est à accès restreint ; un miroir est disponible sur
1287 Si vous envisagez de manipuler les rapports de bogue ou d'en faire une
1288 analyse statistique, ce sera le bon endroit pour le faire. Informez la
1289 liste &email-debian-devel; de votre intention avant d'implémenter quoi
1290 que ce soit afin d'éviter un travail en double ou un gaspillage de
1294 <sect1 id="servers-ftp-master">
1296 Le serveur ftp-master
1299 Le serveur <tt>ftp-master.debian.org</tt> est le serveur maître de
1300 l'archive Debian (exception faite des paquets non-US). En général, les
1301 mises à jour de paquets se font sur ce serveur. Reportez-vous à la
1302 section <ref id="upload"> pour en savoir plus.
1305 Ce serveur est à accès restreint ; un miroir est disponible sur
1309 Les problèmes avec l'archive Debian FTP doivent généralement être
1310 rapportés comme bogues sur le pseudo-paquet
1311 <package>ftp.debian.org</package> ou par courrier électronique à
1312 &email-ftpmaster; ; reportez-vous à la section <ref
1313 id="archive-manip"> pour connaître la procédure à suivre.
1316 <sect1 id="servers-non-us">
1321 Le serveur non-US <tt>non-us.debian.org</tt> a été interrompu avec la
1322 publication de <em>Sarge</em>. Le pseudo-paquet
1323 <package>nonus.debian.org</package> existe encore pour le moment.
1326 <sect1 id="servers-www">
1328 Le serveur www-master
1331 Le serveur web principal est <tt>www-master.debian.org</tt>. Il
1332 héberge les pages web officielles, la façade de Debian pour la plupart
1336 Si vous rencontrez un problème avec un serveur web Debian, vous devez
1337 généralement envoyer un rapport de bogue sur le pseudo-paquet
1338 <package>www.debian.org</package>. Vérifiez d'abord sur le <url
1339 id="http://&bugs-host;/www.debian.org" name="système de suivi des
1340 bogues"> que personne ne l'a déjà rapporté avant vous.
1343 <sect1 id="servers-people">
1345 Le serveur web people
1348 <tt>people.debian.org</tt> est le serveur utilisé par les développeurs
1349 pour leurs pages concernant Debian.
1352 Si vous avez des informations spécifiques Debian que vous voulez
1353 rendre disponibles sur le web, vous pouvez le faire en les plaçant
1354 dans le répertoire <file>public_html</file> de votre répertoire
1355 personnel sur <tt>people.debian.org</tt>. Elles seront accessibles à
1357 <tt>http://people.debian.org/~<var>votre-user-id</var>/</tt>.
1360 Vous ne devriez utiliser que cet emplacement particulier car il sera
1361 sauvegardé alors que sur les autres serveurs, ce ne sera pas le cas.
1364 Habituellement, la seule raison pour utiliser un serveur différent est
1365 que vous avez besoin de publier des informations soumises aux
1366 restrictions d'exportation américaines, dans ce cas, vous pouvez
1367 utiliser l'un des autres serveurs situés en dehors des États-Unis.
1370 Veuillez envoyer un courrier à &email-debian-devel; si vous avez une
1374 <sect1 id="servers-cvs">
1379 Notre serveur CVS est situé sur <tt>cvs.debian.org</tt>.
1382 Si vous avez besoin d'un serveur CVS accessible par tous pour, par
1383 exemple, coordonner le travail de plusieurs développeurs sur un
1384 paquet, vous pouvez demander un espace CVS sur ce serveur.
1387 Le serveur <tt>cvs.debian.org</tt> autorise les accès CVS locaux, les
1388 accès en lecture seule pour les connexions client-serveur anonymes et
1389 les accès client-serveur complets pour les connexions
1390 <prgn>ssh</prgn>. L'espace CVS peut aussi être consulté par la toile à
1391 l'adresse <url id="&url-cvsweb;">.
1394 Pour obtenir un espace CVS, envoyez une demande à l'adresse
1395 &email-debian-admin; en précisant le nom de l'espace, le compte Debian
1396 propriétaire du répertoire racine et pourquoi vous en avez besoin.
1399 <sect1 id="dchroot">
1401 Chroots de différentes distributions
1404 Sur certaines machines, des chroots de différentes distributions sont
1405 disponibles. Vous pouvez les utiliser comme ceci :
1407 vore% dchroot unstable
1408 Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
1410 Dans tous les chroots, les répertoires normaux des utilisateurs sont
1411 disponibles. Vous pouvez trouver quels chroots sont disponibles à
1412 <tt>&url-devel-machines;</tt>.
1416 <sect id="devel-db">
1418 La base de données des développeurs
1421 La base de données des développeurs à <url id="&url-debian-db;"> est un
1422 annuaire LDAP de gestion des informations des développeurs Debian. Vous
1423 pouvez utiliser cette ressource pour rechercher la liste des
1424 développeurs Debian. Une partie de ces informations est également
1425 disponible à travers le service <prgn>finger</prgn> sur les serveurs
1426 Debian, essayez <prgn>finger yourlogin@debian.org</prgn> pour voir ce
1430 Les développeurs peuvent <url id="&url-debian-db-login;" name="se
1431 connecter à la base de données"> pour modifier différentes informations
1432 les concernant, comme :
1436 l'adresse de suivi pour leur adresse debian.org,
1441 l'abonnement à debian-private,
1446 l'état en vacances ou non,
1451 des informations personnelles comme les adresse, pays, latitude et
1452 longitude de l'endroit où ils vivent pour utilisation dans la <url
1453 id="http://www.debian.org/devel/developers.loc" name="carte mondiale
1454 des développeurs Debian">, numéros de téléphone et de fax, surnom
1460 le mot de passe et le shell préféré sur les machines du projet
1467 La plupart des informations ne sont naturellement pas accessibles
1468 publiquement. Pour plus d'informations, veuillez lire la documentation
1469 en ligne que vous pouvez trouver à <url id="&url-debian-db-doc;">.
1472 Les développeurs peuvent également envoyer leurs clés SSH pour qu'elles
1473 soient utilisées pour autorisation sur les machines Debian officielles
1474 et même ajouter de nouvelles entrées DNS du type *.debian.net. Ces
1475 fonctionnalités sont documentées à <url id="&url-debian-db-mail-gw;">.
1483 La distribution &debian-formal; est composée d'un grand nombre de
1484 paquets (fichiers <tt>.deb</tt> : actuellement, à peu près
1485 &number-of-pkgs;) et de quelques autres fichiers (comme la
1486 documentation et des images des disquettes d'installation).
1489 Voici un exemple d'arborescence pour une archive Debian complète :
1492 &sample-dist-dirtree;
1496 Comme vous pouvez le voir, le répertoire racine contient deux
1497 répertoires, <file>dists/</file> et <file>pool/</file>. Le second est
1498 un ensemble de répertoires où sont stockés les paquets. Ceux-ci sont
1499 manipulés grâce à la base de données de l'archive et aux logiciels qui
1500 l'accompagnent. Le premier répertoire contient les distributions
1501 <em>stable</em>, <em>testing</em> et <em>unstable</em>. Les fichiers
1502 <file>Packages</file> et <file>Sources</file> qui se trouvent dans les
1503 répertoires de distribution peuvent faire référence à des fichiers du
1504 répertoire <file>pool/</file>. Le découpage en sous-répertoires est
1505 identique d'un répertoire de distribution à l'autre . Ce que nous
1506 exposerons ci-dessous pour la distribution <em>stable</em> est
1507 également applicable aux distributions <em>unstable</em> et
1511 Le répertoire <file>dists/stable</file> contient trois répertoires
1512 nommés <file>main</file>, <file>contrib</file> et
1513 <file>non-free</file>.
1516 Dans chacune de ces sections, se trouve un répertoire contenant les
1517 paquets sources (<file>source/</file>) et un répertoire pour chaque
1518 architecture acceptée (<file>binary-i386/</file>,
1519 <file>binary-m68k/</file>, etc.).
1522 La section <em>main</em> contient d'autres répertoires destinés aux
1523 images de disquettes et à plusieurs documents essentiels pour installer
1524 la distribution Debian sur une architecture particulière
1525 (<file>disk-i386/</file>, <file>disk-m68k/</file>, etc.).
1527 <sect1 id="archive-sections">
1532 La section <em>main</em> constitue la <strong>distribution
1533 &debian-formal; officielle</strong>. Elle est officielle parce qu'elle
1534 est entièrement conforme à toutes nos recommandations. Les deux autres
1535 sections divergent de ces recommandations à différents degrés, elles
1536 <strong>ne</strong> font donc <strong>pas</strong> officiellement
1537 partie de &debian-formal;.
1540 Chaque paquet de la section <em>main</em> doit être conforme aux <url
1541 id="&url-dfsg;" name="directives Debian pour le logiciel
1542 libre"><footnote><p>Debian Free Software Guidelines</p></footnote> et
1543 à toutes les autres recommandations décrites dans <url
1544 id="&url-debian-policy;" name="la charte Debian"><footnote><p>Debian
1545 Policy Manual</p></footnote>. Les DFSG<footnote><p><em>Debian Free
1546 Software Guidelines</em></p></footnote> constituent notre définition
1547 de « logiciel libre ». Reportez-vous à la <em>charte
1548 Debian</em> pour en savoir plus.
1551 Les paquets de la section <em>contrib</em> doivent être conformes aux
1552 DFSG, mais ne respectent pas d'autres contraintes. Ils peuvent, par
1553 exemple, dépendre de paquets de la section <em>non-free</em>.
1556 Les paquets qui ne sont pas conformes aux DFSG sont rangés dans la
1557 section <em>non-free</em>. Bien que nous supportions l'usage de ces
1558 paquets et qu'ils bénéficient de nos infrastructures (système de suivi
1559 des bogues, listes de diffusion, etc.), ces paquets <em>non-free</em>
1560 ne font pas partie de la distribution Debian.
1563 La <em>charte Debian</em> donne des définitions plus précises pour ces
1564 trois sections. Les paragraphes précédents ne constituent qu'une
1568 La séparation de l'archive en trois sections est importante pour toute
1569 personne qui désire distribuer Debian, que ce soit par serveur FTP ou
1570 sur cédérom. Il suffit de distribuer les sections <em>main</em> et
1571 <em>contrib</em> pour éviter tout problème légal. Certains paquets de
1572 la section <em>non-free</em> interdisent leur distribution à titre
1573 commercial par exemple.
1576 D'un autre côté, un distributeur de cédérom pourra facilement vérifier
1577 la licence de chacun des paquets de la section <em>non-free</em> et
1578 inclure tous les paquets qu'il lui sera autorisé (dans la mesure où
1579 cela varie énormément d'un distributeur à l'autre, ce travail ne peut
1580 être fait par les développeurs Debian).
1583 Notez que le terme « section » est également utilisé pour
1584 faire référence aux catégories qui simplifient l'organisation des
1585 paquets disponibles et leur recherche, e.g. <em>admin</em>,
1586 <em>net</em>, <em>utils</em> etc. Il fut un temps où ces sections
1587 (sous-sections, plutôt) existaient sous la forme de sous-répertoires
1588 dans l'archive Debian. Actuellement, elles n'existent plus que dans le
1589 champ en-tête « Section » des paquets.
1597 À ses débuts, le noyau Linux existait uniquement pour les
1598 architectures Intel x86 ; il en était de même pour Debian. Linux
1599 devenant de plus en plus populaire, il a été porté vers d'autres
1603 Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha,
1604 SPARC, Motorola, 680x0 (Atari, Amiga, et Macintosh), MIPS et
1605 PowerPC. Le noyau 2.2 reconnaît de nouvelles architectures, comme ARM
1606 et UltraSPARC. Puisque Linux reconnaît ces architectures, le projet
1607 Debian a décidé qu'il devait également les accepter. C'est pourquoi
1608 plusieurs portages sont en cours ; en fait, il y a aussi des
1609 portages vers d'autres noyaux non-Linux. À côté d'<em>i386</em> (notre
1610 nom pour Intel x86), nous avons, au moment où j'écris, <em>m68k</em>,
1611 <em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
1612 <em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>,
1613 <em>mips</em>, <em>mipsel</em> et <em>sh</em>.
1616 &debian-formal; 1.3 est disponible uniquement pour
1617 <em>i386</em>. Debian 2.0 reconnaît les architectures <em>i386</em> et
1618 <em>m68k</em>. Debian 2.1 reconnaît les architectures <em>i386</em>,
1619 <em>m68k</em>, <em>alpha</em> et <em>sparc</em>. Debian 2.2 accepte en
1620 plus les architectures <em>powerpc</em> et <em>arm</em>. Debian 3.0 a
1621 ajouté cinq nouvelles architectures : <em>ia64</em>,
1622 <em>hppa</em>, <em>s390</em>, <em>mips</em> et <em>mipsel</em>.
1625 Pour chaque portage, vous trouverez des informations destinées aux
1626 développeurs et utilisateurs sur la page <url id="&url-debian-ports;"
1627 name="Portage Debian">.
1635 Il existe deux types de paquets Debian : les paquets sources et
1636 les paquets binaires.
1639 Les paquets sources sont constitués de deux ou trois fichiers :
1640 un fichier <file>.dsc</file> et soit un fichier <file>.tar.gz</file>,
1641 soit un fichier <file>.orig.tar.gz</file> et un fichier
1642 <file>.diff.gz</file>.
1645 Si un paquet est développé spécifiquement pour le projet Debian et
1646 n'est pas distribué en dehors de Debian, il n'y a qu'un fichier
1647 <file>.tar.gz</file> qui contient les sources du programme. Si un
1648 paquet est distribué ailleurs, le fichier <file>.orig.tar.gz</file>
1649 contient ce que l'on appelle <em>code source amont</em>, c'est-à-dire,
1650 le code source distribué par le <em>responsable amont</em> (il s'agit
1651 souvent de l'auteur du logiciel). Dans ce cas, le fichier
1652 <file>.diff.gz</file> contient les modifications faites par le
1656 Le fichier <file>.dsc</file> liste tous les fichiers sources avec
1657 leurs sommes de contrôle (<prgn>md5sums</prgn>) et quelques
1658 informations supplémentaires concernant le paquet (responsable,
1667 L'organisation des répertoires présentée précédemment est elle-même
1668 englobée par les <em>répertoires des distributions</em>. Chaque
1669 distribution est incluse dans le répertoire <file>pool</file> à la
1670 racine de l'archive Debian.
1673 Pour résumer, une archive Debian a un répertoire racine sur un serveur
1674 FTP. Par exemple, sur le site miroir
1675 <ftpsite>ftp.us.debian.org</ftpsite>, l'archive Debian se trouve dans
1676 <ftppath>/debian</ftppath> ce qui est un emplacement courant. Un autre
1677 emplacement courant est <file>/pub/debian</file>.
1680 Une distribution est composée de paquets sources et binaires et des
1681 fichiers <file>Sources</file> et <file>Packages</file> correspondants
1682 qui contiennent toutes les méta-informations sur les paquets. Les
1683 premiers sont conservés dans le répertoire <file>pool/</file> tandis
1684 que les seconds sont conservés dans le répertoire <file>dists/</file>
1685 de l'archive (pour compatibilité descendante).
1687 <sect2 id="sec-dists">
1689 <em>Stable</em>, <em>testing</em> et <em>unstable</em>
1692 Il y a toujours une distribution appelée <em>stable</em> (dans le
1693 répertoire <file>dists/stable</file>), une distribution appelée
1694 <em>testing</em> (dans le répertoire <file>dists/testing</file>) et
1695 une distribution appelée <em>unstable</em> (dans le répertoire
1696 <file>dists/unstable</file>). Ceci reflète le processus de
1697 développement du projet Debian.
1700 Les développements se font sur la distribution
1701 <em>unstable</em><footnote><p><em>unstable</em> signifie
1702 « instable »</p></footnote> (c'est pourquoi elle est aussi
1703 appelée <em>distribution de développement</em>). Chaque développeur
1704 Debian peut modifier ses paquets à tout moment dans cette
1705 distribution. Ainsi son contenu change tous les jours. Comme aucun
1706 effort particulier n'est fait pour s'assurer que tout fonctionne
1707 correctement dans cette distribution, elle est parfois littéralement
1708 « instable ».
1711 La distribution <qref id="testing">« testing »</qref> est
1712 générée automatiquement en prenant les paquets d'<em>unstable</em>
1713 s'ils satisfont à certains critères. Ces critères garantissent que
1714 les paquets de <em>testing</em> sont de bonne qualité. La mise à jour
1715 de <em>testing</em> est lancée chaque jour après que les nouveaux
1716 paquets ont été installés. Voir <ref id="testing">.
1719 Après une période de développement, quand le responsable de
1720 distribution<footnote><p><em>Release manager</em></p></footnote> le
1721 juge opportun, la distribution <em>testing</em> est gelée, ce qui
1722 signifie que les conditions à remplir pour qu'un paquet passe
1723 d'<em>unstable</em> à <em>testing</em> sont durcies. Les paquets trop
1724 bogués sont supprimés et les seules mises à jours autorisées
1725 concernent les corrections de bogues. Après quelque temps, selon
1726 l'avancement, la distribution <em>testing</em> est gelée encore
1727 plus. Les détails de la gestion de la distribution <em>testing</em>
1728 sont publiées par l'équipe de publication sur la liste
1729 debian-devel-announce. Après la résolution des problèmes restants à
1730 la satisfaction de l'équipe de publication, la distribution est
1731 publiée. La publication veut dire que <em>testing</em> est renommée
1732 en <em>stable</em>, une nouvelle copie est créée pour la nouvelle
1733 <em>testing</em> et l'ancienne <em>stable</em> est renommée en
1734 <em>oldstable</em> et y reste jusqu'à ce qu'elle soit finalement
1735 archivée. Lors de l'archivage, son contenu est déplacé sur
1736 <tt>&archive-host;</tt>.
1739 Ce cycle de développement est basé sur l'idée que la distribution
1740 <em>unstable</em> devient <em>stable</em> après une période de test
1741 (<em>testing</em>). Une distribution contient inévitablement des
1742 bogues, même si elle est classée stable. C'est pourquoi les
1743 distributions stables sont mises à jour de temps en temps. Les
1744 corrections introduites sont testées avec une grande attention et
1745 sont ajoutées une à une à l'archive pour diminuer les risques
1746 d'introduire de nouveaux bogues. Vous pouvez trouver des paquets
1747 proposés pour les mises à jour de <em>stable</em> dans le répertoire
1748 <file>proposed-updates</file>. De temps en temps, les paquets de ce
1749 répertoire qui ne présentent pas de problème sont installés dans la
1750 distribution <em>stable</em> et le numéro de révision de cette
1751 distribution est incrémenté (« 3.0 » devient
1752 « 3.0r1 », « 2.2r4 » devient « 2.2r5 »
1753 et ainsi de suite). Veuillez vous référer aux <qref
1754 id="upload-stable">envois dans la distribution <em>stable</em></qref>
1755 pour plus de détails.
1758 Notez que, pendant la période de gel, les développements continuent
1759 sur la distribution <em>unstable</em> car cette distribution reste en
1765 Informations complémentaires sur la distribution
1766 « testing »
1769 Les paquets sont habituellement installés dans la distribution
1770 <em>testing</em> après avoir atteint un certain degré de test dans
1774 Pour plus de détails, veuillez consulter les <qref
1775 id="testing">informations à propos de la distribution
1776 <em>testing</em></qref>.
1779 <sect2 id="experimental">
1784 La distribution <em>experimental</em> est une distribution
1785 particulière. Ce n'est pas une distribution à part entière comme le
1786 sont <em>stable</em> et <em>unstable</em>. Elle est prévue pour
1787 servir de plate-forme de développement pour les projets expérimentaux
1788 qui risquent vraiment de détruire le système ou bien pour des
1789 logiciels qui sont vraiment trop instables pour être inclus dans la
1790 distribution <em>unstable</em> (mais pour lesquels une mise en paquet
1791 est justifiée). Les utilisateurs qui téléchargent et installent des
1792 paquets depuis <em>experimental</em> sont prévenus : on ne peut
1793 pas faire confiance à la distribution <em>experimental</em>.
1796 Voici les lignes de <manref section="5" name="sources.list"> pour
1797 <em>experimental</em> :
1799 deb http://ftp.<var>xy</var>.debian.org/debian/ experimental main
1800 deb-src http://ftp.<var>xy</var>.debian.org/debian/ experimental main
1804 Si un logiciel peut causer des dégâts importants, il sera sûrement
1805 préférable de le mettre dans la distribution
1806 <em>experimental</em>. Un système de fichiers compacté expérimental,
1807 par exemple, devrait probablement aller dans <em>experimental</em>.
1810 Une nouvelle version amont qui ajoute de nouvelles fonctions tout en
1811 supprimant de nombreuses autres ne devra pas être téléchargée dans
1812 l'archive Debian, elle pourra cependant être téléchargée dans
1813 <em>experimental</em>. Une nouvelle version non finalisée d'un
1814 logiciel qui utilise une méthode de configuration complètement
1815 différente pourrait aller dans <em>experimental</em> au gré du
1816 responsable. Si vous travaillez sur un cas de mise à jour complexe ou
1817 incompatible, vous pouvez aussi utiliser <em>experimental</em> comme
1818 plate-forme d'intégration et ainsi fournir un accès aux testeurs.
1821 Quelques logiciels expérimentaux peuvent cependant aller dans
1822 <em>unstable</em>, avec un avertissement dans la description, mais ce
1823 n'est pas recommandé car les paquets d'<em>unstable</em> se propagent
1824 dans <em>testing</em> et aboutissent dans <em>stable</em>. Vous ne
1825 devriez pas avoir peur d'utiliser <em>experimental</em> car ceci ne
1826 cause aucun souci aux ftpmasters, les paquets expérimentaux sont
1827 automatiquement enlevés quand vous envoyez le paquet dans
1828 <em>unstable</em> avec un numéro de version supérieur.
1831 Un nouveau logiciel qui ne risque pas d'endommager le système ira
1832 directement dans <em>unstable</em>.
1835 Une solution de rechange à <em>experimental</em> consiste à utiliser
1836 vos pages personnelles sur le serveur <tt>people.debian.org</tt>.
1839 Veuillez considérer l'utilisation de l'option <tt>-v</tt> de
1840 <prgn>dpkg-buildpackage</prgn> si l'envoi d'un paquet dans
1841 <em>unstable</em> ferme finalement des bogues qui ont d'abord été
1842 corrigés dans <em>experimental</em>. Lors de l'envoi vers
1843 <em>unstable</em> d'un paquet contenant des bogues corrigés dans
1844 <em>experimental</em>, veuillez considérer l'utilisation de l'option
1845 <tt>-v</tt> de <prgn>dpkg-buildpackage</prgn> pour qu'ils soient
1850 <sect1 id="codenames">
1852 Les noms de distribution
1855 Chaque distribution Debian diffusée a un <em>nom de code</em> :
1856 Debian 1.1 s'appelle « Buzz » ; Debian 1.2,
1857 « Rex » ; Debian 1.3, « Bo » ;
1858 Debian 2.0, « Hamm » ; Debian 2.1,
1859 « Slink »; Debian 2.2, « Potato » ;
1860 Debian 3.0, « Woody » ; Debian 3.1,
1861 « Sarge » ; Debian (nombre à déterminer)
1862 « Etch ». Il y a aussi une pseudo-distribution nommée
1863 « Sid », il s'agit de la distribution
1864 <em>unstable</em> ; comme les paquets vont d'<em>unstable</em> à
1865 <em>testing</em> quand ils approchent de la stabilité, la distribution
1866 « Sid » n'est jamais diffusée. En plus du contenu habituel
1867 d'une distribution Debian, « Sid » contient des paquets pour
1868 des architectures qui ne sont pas encore officiellement prises en
1869 charge ou pour lesquelles la distribution n'a pas encore été
1870 publiée. Ces architectures seront intégrées ultérieurement à la
1871 distribution principale.
1874 Comme Debian est un projet de développement ouvert (i.e. tout le monde
1875 peut participer et suivre les développements), même les distributions
1876 <em>unstable</em> et <em>testing</em> sont disponibles sur les
1877 serveurs HTTP et FTP de Debian. Si nous avions nommé le répertoire qui
1878 contient la prochaine distribution à diffuser « testing »,
1879 il aurait fallu changer son nom en « stable » au moment de
1880 la diffusion, ce qui aurait forcé les miroirs FTP à télécharger à
1881 nouveau la distribution complète (qui est plutôt volumineuse).
1884 D'un autre côté, si une distribution s'appelait <em>Debian-x.y</em>
1885 dès le départ, des personnes pourraient s'imaginer que la distribution
1886 Debian <em>x.y</em> est disponible. (Cela s'est produit par le passé,
1887 un distributeur avait gravé des cédéroms Debian 1.0 en utilisant une
1888 version de développement pré-1.0. C'est pour cette raison que la
1889 première version officielle était la version 1.1 et non la 1.0).
1892 En conséquence, les noms de répertoire des distributions dans
1893 l'archive sont déterminés par leur nom de code et non par leur statut
1894 (exemple : slink). Ces noms sont identiques pendant la période de
1895 développement et une fois la distribution diffusée ; des liens
1896 symboliques, qui peuvent être modifiés facilement, indiquent la
1897 distribution stable actuelle. Tout ceci explique pourquoi les
1898 répertoires des distributions sont nommés à partir des noms de code
1899 des distributions alors que <em>stable</em>, <em>testing</em> et
1900 <em>unstable</em> sont des liens symboliques qui pointent vers les
1901 répertoires appropriés.
1910 Les différentes archives de téléchargement et le site web disposent de
1911 plusieurs miroirs pour soulager les serveurs principaux d'une lourde
1912 charge. En fait, certains de ces serveurs ne sont pas
1913 publics — la charge est répartie sur une première série de
1914 serveurs. De cette façon, les utilisateurs ont toujours accès aux
1915 miroirs et s'y habituent, ce qui permet à Debian de mieux répartir les
1916 besoins en bande passante sur plusieurs serveurs et plusieurs réseaux
1917 différents et évite aux utilisateurs de surcharger l'emplacement
1918 primaire. Notez que, dans cette première série, les serveurs sont aussi
1919 à jour que possible car la mise à jour est déclenchée par les sites
1923 Toutes les informations sur les miroirs Debian peuvent être trouvées à
1924 <url id="&url-debian-mirrors;">, y compris une liste des miroirs
1925 publics disponibles FTP/HTTP. Cette page utile inclut également des
1926 informations et des outils pour créer son propre miroir, soit en
1927 interne soit pour un accès public.
1930 Les miroirs sont en général mis en œuvre par des tiers qui
1931 veulent aider Debian. C'est pourquoi les développeurs n'ont en général
1932 pas de compte sur ces machines.
1935 <sect id="incoming-system">
1940 Le système Incoming est responsable de la collecte des paquets mis à
1941 jour et de leur installation dans l'archive Debian. Il est constitué
1942 d'un ensemble de répertoires et de scripts qui sont installés sur
1943 <tt>&ftp-master-host;</tt>.
1946 Les paquets sont envoyés par tous les responsables Debian dans un
1947 répertoire nommé <file>UploadQueue</file>. Ce répertoire est parcouru
1948 toutes les quelques minutes par un démon appelé <prgn>queued</prgn>,
1949 les fichiers <file>*.command</file> sont exécutés et les fichiers
1950 <file>*.changes</file> restants et correctement signés sont déplacés
1951 avec leurs fichiers correspondants dans le répertoire
1952 <file>unchecked</file>. Ce répertoire n'est pas visible de la plupart
1953 des développeurs car ftp-master est à accès restreint ; il est
1954 parcouru toutes les 15 minutes par le script <prgn>katie</prgn> qui
1955 vérifie l'intégrité des paquets envoyés et leurs signatures de
1956 chiffrage. Si le paquet est considéré comme prêt à être installé, il
1957 est déplacé dans le répertoire <file>accepted</file>. S'il s'agit du
1958 premier envoi du paquet (ou s'il a de nouveaux paquets binaire), il est
1959 déplacé dans le répertoire <file>new</file> où il attend l'approbation
1960 des ftpmasters. Si le paquet contient des fichiers devant être
1961 installés <em>à la main</em>, il est déplacé dans le répertoire
1962 <file>byhand</file> où il attend une installation manuelle par les
1963 ftpmasters. Sinon, si une erreur a été détectée, le paquet est refusé
1964 et il est déplacé dans le répertoire <file>reject</file>.
1967 Une fois que le paquet est accepté, le système envoie une confirmation
1968 par courrier au responsable et ferme les bogues corrigés par l'envoi,
1969 puis les compilateurs automatiques peuvent commencer la
1970 recompilation. Le paquet est maintenant accessible publiquement à <url
1971 id="&url-incoming;"> jusqu'à ce qu'il soit vraiment installé dans
1972 l'archive Debian. Cela se produit seulement une fois par jour (et c'est
1973 également appelé une « exécution dinstall » pour des raisons
1974 historiques) ; le paquet est alors supprimé de
1975 <file>Incoming</file> et installé dans le pool avec les autres
1976 paquets. Une fois que toutes les autres mises à jour (fabrication des
1977 nouveaux fichiers d'index <file>Packages</file> et <file>Sources</file>
1978 par exemple) ont été effectuées, un script spécial est appelé pour
1979 demander aux miroirs primaires de se mettre à jour.
1982 Le logiciel de maintenance de l'archive enverra également le fichier
1983 <file>.changes</file> signé avec OpenPGP/GnuPG que vous avez envoyé, à
1984 la liste de diffusion appropriée. Si un paquet est diffusé avec le
1985 champ <tt>Distribution:</tt> positionné à « stable »,
1986 l'annonce sera envoyée à &email-debian-changes;. Si un paquet est
1987 diffusé avec le champ <tt>Distribution:</tt> positionné à
1988 « unstable » ou « experimental », l'annonce sera à
1989 la place envoyée à &email-debian-devel-changes;.
1992 Bien que ftp-master soit à accès restreint, une copie de l'installation
1993 est disponible à tous les développeurs sur
1994 <tt>&ftp-master-mirror;</tt>.
1997 <sect id="pkg-info">
1999 Informations sur un paquet
2003 <sect1 id="pkg-info-web">
2008 Chaque paquet a plusieurs pages web
2009 dédiées. <tt>http://&packages-host;/<var>nom-paquet</var></tt> affiche
2010 chaque version du paquet disponible dans les différentes
2011 distributions. Les informations détaillées par version incluent la
2012 description du paquet, les dépendances et des liens pour télécharger
2016 Le système de suivi des bogues trie les bogues par paquet. Vous pouvez
2017 regarder les bogues de chaque paquet à
2018 <tt>http://&bugs-host;/<var>nom-paquet</var></tt>.
2021 <sect1 id="madison">
2023 L'outil <prgn>madison</prgn>
2026 <prgn>madison</prgn> est un outil en ligne de commande qui est
2027 disponible sur <tt>&ftp-master-host;</tt> et sur le miroir
2028 <tt>&ftp-master-mirror;</tt>. Il utilise un seul argument qui
2029 correspond au nom du paquet. Il affiche comme résultat quelle version
2030 du paquet est disponible pour chaque combinaison d'architecture et de
2031 distribution. Un exemple l'expliquera mieux.
2035 $ madison libdbd-mysql-perl
2036 libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
2037 libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
2038 libdbd-mysql-perl | 1.2216-2.0.1| testing | alpha
2039 libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
2043 Dans cet exemple, vous pouvez voir que la version dans
2044 <em>unstable</em> diffère de celle de <em>testing</em> et qu'il y a eu
2045 une NMU binaire seulement pour l'architecture alpha. Chaque version du
2046 paquet a été recompilée sur la plupart des architectures.
2050 <sect id="pkg-tracking-system">
2052 Système de suivi des paquets
2055 Le système de suivi des paquets (PTS)<footnote><p>« Package
2056 Tracking System »</p></footnote> est un outil pour suivre par
2057 courrier l'activité concernant un paquet source. Cela veut vraiment
2058 dire que vous pourrez recevoir les mêmes courriers que le responsable,
2059 simplement en vous inscrivant au paquet dans le PTS.
2062 Chaque courrier envoyé par le PTS est classé sous l'un des mots-clés
2063 listés ci-dessous. Ceci vous permettra de sélectionner les courriers
2064 que vous voulez recevoir.
2067 Par défaut, vous recevrez :
2074 Tous les rapports de bogue et les discussions qui suivent.
2078 <tt>bts-control</tt>
2082 Les courriers de notification de
2083 <email>control@bugs.debian.org</email> sur les changement d'état de
2084 l'un des rapports de bogue.
2088 <tt>upload-source</tt>
2092 Le courrier de notification de <prgn>katie</prgn> quand un paquet
2093 source envoyé a été accepté.
2097 <tt>katie-other</tt>
2101 Les autres courriers d'avertissement et d'erreur de
2102 <prgn>katie</prgn> (comme une incohérence de passage en force pour
2103 les champs section ou priorité).
2111 Tout courrier non automatique envoyé au PTS par les personnes qui
2112 veulent contacter les inscrits au paquet. Ceci peut être fait en
2113 envoyant un courrier à
2114 <tt><var>paquet-source</var>@&pts-host;</tt>. Pour prévenir l'envoi
2115 de pourriels, tous les courriers envoyés à ces adresses doivent
2116 contenir l'en-tête <tt>X-PTS-Approved</tt> avec une valeur non vide.
2124 (Ceci est une extension prévue). Les courriers de résumé réguliers
2125 sur l'état du paquet (statistiques sur les bogues, vue générale du
2126 portage, progression dans <em>testing</em>, etc.).
2132 Vous pouvez également décider de recevoir des informations
2133 supplémentaires :
2136 <tt>upload-binary</tt>
2140 Le courrier d'information de <prgn>katie</prgn> quand un paquet
2141 binaire envoyé est accepté. En d'autres termes, à chaque fois qu'un
2142 démon de compilation ou un porteur envoie votre paquet pour une
2143 autre architecture, vous recevez un courrier pour suivre comment
2144 votre paquet est recompilé pour toutes les architectures.
2152 Les notifications de modifications CVS<footnote><p><em>CVS
2153 commits</em></p></footnote> si le responsable a mis en place un
2154 système pour faire suivre les notifications de modifications vers le
2163 Les traductions des descriptions ou des questionnaires debconf
2164 soumis au Projet de traduction des descriptions de paquets
2165 Debian<footnote><p><em>Debian Description Translation Project,
2166 DDTP</em></p></footnote>.
2171 <sect1 id="pts-commands">
2173 L'interface de courrier du PTS
2176 Vous pouvez contrôler votre (vos) inscription(s) au PTS en envoyant
2177 différentes commandes à <email>pts@qa.debian.org</email>.
2180 <tt>subscribe <paquet source> [<adresse>]</tt>
2184 Inscrit <var>adresse</var> aux communications liées au paquet
2185 source <var>paquet source</var>. L'adresse de l'expéditeur est
2186 utilisée si le second argument n'est pas présent. Si <var>paquet
2187 source</var> n'est pas un paquet source valide, vous obtiendrez un
2188 avertissement. Cependant, s'il s'agit d'un paquet binaire valide,
2189 le PTS vous inscrira pour le paquet source correspondant.
2193 <tt>unsubscribe <paquet source> [<adresse>]</tt>
2197 Supprime une inscription précédente au paquet source <var>paquet
2198 source</var> en utilisant l'adresse spécifiée ou l'adresse de
2199 l'expéditeur si le second argument n'est pas rempli.
2203 <tt>which [<adresse>]</tt>
2207 Liste les inscriptions pour l'expéditeur ou pour l'adresse indiquée
2208 si elle est spécifiée.
2212 <tt>keyword [<adresse>]</tt>
2216 Donne les mots-clés que vous acceptez. Pour une explication des ces
2217 mots-clés, <qref id="pkg-tracking-system">voir
2218 ci-dessus</qref>. Voici un rapide résumé :
2222 <tt>bts</tt> : courriers venant du système de gestion de
2228 <tt>bts-control</tt> : réponses aux courriers envoyés à
2229 &bugs-host;&email-bts-control;
2234 <tt>summary</tt> : courriers de résumé automatique sur
2240 <tt>cvs</tt> : notifications de modifications CVS
2245 <tt>ddtp</tt> : traductions des descriptions et
2246 questionnaires debconf
2251 <tt>upload-source</tt> : annonce d'un nouvel envoi de
2252 paquet source qui a été accepté
2257 <tt>upload-binary</tt> : annonce d'un nouvel envoi de
2258 binaire seulement (portage)
2263 <tt>katie-other</tt> : autres courriers des ftpmasters
2264 (incohérence de passage en force, etc.)
2269 <tt>default</tt> : tous les autres courriers (ceux qui ne
2270 sont pas automatiques)
2277 <tt>keyword <paquet source> [<adresse>]</tt>
2281 Identique à l'élément précédent, mais pour un paquet source donné
2282 car vous pouvez sélectionner un ensemble de mots-clés différent
2283 pour chaque paquet source.
2287 <tt>keyword [<adresse>] {+|-|=} <liste de
2292 Accepte (+) ou refuse (-) les courriers classés sous le(s)
2293 mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés.
2297 <tt>keyword <paquet source> [<adresse>] {+|-|=}
2298 <liste de mots-clés></tt>
2302 Identique à l'élément précédent, mais remplace la liste des
2303 mots-clés pour le paquet source indiqué.
2307 <tt>quit | thanks | --</tt>
2311 Arrête le traitement des commandes. Toutes les lignes suivantes
2312 sont ignorées par le robot.
2318 <sect1 id="pts-mail-filtering">
2320 Filtrer les courriers du PTS
2323 Une fois que vous vous êtes inscrit à un paquet, vous recevrez les
2324 courriers envoyés à <tt><var>paquet
2325 source</var>@packages.qa.debian.org</tt>. Ces courriers ont des
2326 en-têtes spéciaux ajoutés pour vous permettre de les filtrer dans des
2327 boîtes aux lettres (par exemple, avec <prgn>procmail</prgn>). Les
2328 en-têtes ajoutés sont <tt>X-Loop</tt>, <tt>X-PTS-Package</tt>,
2329 <tt>X-PTS-Keyword</tt> et <tt>X-Unsubscribe</tt>.
2332 Voici un exemple d'en-têtes ajoutés pour une notification d'envoi de
2333 source sur le paquet <package>dpkg</package> :
2335 X-Loop: dpkg@&pts-host;
2337 X-PTS-Keyword: upload-source
2338 X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
2342 <sect1 id="pts-cvs-commit">
2344 Faire suivre les modifications de CVS vers le PTS
2347 Si vous utilisez un référentiel CVS accessible publiquement pour
2348 maintenir votre paquet Debian, vous pouvez vouloir faire suivre les
2349 notifications de modifications vers le PTS pour que les inscrits
2350 (ainsi que des possibles co-responsables) puissent suivre de près
2351 l'évolution du paquet.
2354 Une fois que votre référentiel génère des notifications de
2355 modifications, vous devez simplement vous assurer qu'il envoie une
2356 copie de tous ces courriers à <tt><var>paquet
2357 source</var>_cvs@&pts-host;</tt>. Seules les personnes qui ont accepté
2358 le mot-clé <em>cvs</em> recevront les notifications.
2361 <sect1 id="pts-web">
2363 L'interface web du PTS
2366 Le PTS possède une interface web à <url id="http://&pts-host;/"> qui
2367 réunit beaucoup d'informations au même endroit à propos de chaque
2368 paquet source. Il propose plusieurs liens utiles (BTS, statistiques
2369 QA, informations de contact, état de traduction DDTP, journaux de
2370 compilation automatique) et il regroupe beaucoup d'autres informations
2371 provenant de différents endroits (les 30 dernières entrées de
2372 changelog, l'état dans <em>testing</em>, etc.). Il s'agit d'un outil
2373 très pratique si vous désirez connaître ce qu'il en est d'un paquet
2374 source spécifique. De plus, il y a un formulaire qui permet de
2375 facilement s'inscrire au PTS par courrier.
2378 Vous pouvez aller directement à la page web concernant un paquet
2379 source avec une URL comme <tt>http://&pts-host;/<var>paquet
2383 Cette interface a été conçue comme un portail pour le développements
2384 des paquets : vous pouvez ajouter du contenu personnalisé aux
2385 pages de vos paquets. Vous pouvez ajouter des « informations
2386 statiques »<footnote><p><em>Static
2387 information</em></p></footnote> (des annonces qui sont destinées à
2388 rester disponibles indéfiniment) et des nouvelles dans la section
2389 « dernières nouvelles »<footnote><p><em>Latest
2390 news</em></p></footnote>.
2393 Les annonces statiques peuvent être utilisées pour indiquer :
2397 la disponibilité d'un projet hébergé sur <qref
2398 id="alioth">Alioth</qref> pour la co-maintenance du paquet,
2403 un lien vers le site web amont,
2408 un lien vers le suivi de bogues amont,
2413 l'existence d'un canal IRC dédié au logiciel,
2418 toute autre ressource disponible qui peut être utile à la
2419 maintenance du paquet.
2423 Les nouvelles usuelles peuvent être utilisées pour annoncer que :
2427 des paquets bêta sont disponibles pour test,
2432 des paquets finaux sont attendus pour la semaine prochaine,
2437 l'empaquetage est sur le point d'être intégralement refait,
2442 des rétroportages sont disponibles,
2447 le responsable est en vacance (s'il désire publier cette
2453 une mise à jour indépendante (NMU) est en cours de réalisation,
2458 quelque chose d'important va affecter le paquet.
2464 Les deux types d'informations sont fabriqués de façon similaire :
2465 il vous suffit d'envoyer un courrier soit à
2466 <email>pts-static-news@qa.debian.org</email> (pour les annonces
2467 statiques), soit à <email>pts-news@qa.debian.org</email> (pour les
2468 nouvelles usuelles). Le courrier devrait indiquer quel paquet est
2469 concerné par la nouvelle en donnant le nom du paquet source dans un
2470 en-tête de courrier <tt>X-PTS-Package</tt> ou dans un pseudo-en-tête
2471 <tt>Package</tt> (comme pour les rapports de bogue du BTS). Si une URL
2472 est disponible dans l'en-tête de courrier <tt>X-PTS-Url</tt> ou dans
2473 un pseudo-en-tête <tt>Url</tt>, le résultat est un lien vers cette URL
2474 au lieu d'une nouvelle complète.
2477 Voici quelques exemples de courriers valides utilisés pour générer des
2478 nouvelles dans le PTS. Le premier ajoute un lien vers l'interface
2479 cvsweb de debian-cd dans la section « Informations
2480 statiques » :
2482 From: Raphael Hertzog <hertzog@debian.org>
2483 To: pts-static-news@qa.debian.org
2484 Subject: Browse debian-cd CVS repository with cvsweb
2487 Url: http://cvs.debian.org/debian-cd/
2491 Le second est une annonce envoyée à une liste de diffusion et
2492 également envoyée au PTS pour qu'elle soit publiée sur la page web du
2493 PTS du paquet. Notez l'utilisation du champ BCC pour éviter que des
2494 réponses ne soient envoyées par erreur au PTS.
2496 From: Raphael Hertzog <hertzog@debian.org>
2497 To: debian-gtk-gnome@lists.debian.org
2498 Bcc: pts-news@qa.debian.org
2499 Subject: Galeon 2.0 backported for woody
2500 X-PTS-Package: galeon
2504 I'm glad to announce that galeon has been backported for woody. You'll find
2510 Réfléchissez-y à deux fois avant d'ajouter une nouvelle au PTS car
2511 vous ne pourrez pas l'enlever par la suite et vous ne pourrez pas non
2512 plus l'éditer. La seule chose que vous puissiez faire est d'envoyer
2513 une deuxième nouvelle qui va déprécier l'information contenue dans la
2520 Vue d'ensemble des paquets d'un développeur
2523 Un portail web pour l'Assurance Qualité (QA) est disponible à <url
2524 id="&url-ddpo;"> qui affiche un tableau de tous les paquets d'un
2525 développeur (y compris ceux pour lequel il est co-responsable). Le
2526 tableau donne un bon résumé sur les paquets d'un développeur :
2527 nombre de bogues par gravité, liste des versions disponibles, état des
2528 tests et des liens vers d'autres informations utiles.
2531 C'est une bonne idée de vérifier régulièrement vos données pour ne pas
2532 oublier de bogues ouverts et pour ne pas oublier quels paquets sont
2533 sous votre responsabilité.
2538 Debian *Forge : Alioth
2541 Alioth est un service de Debian plutôt récent, basé sur une version
2542 légèrement modifiée du logiciel GForge (qui a évolué à partir de
2543 SourceForge). Ce logiciel offre aux développeurs l'accès à des outils
2544 faciles d'utilisation comme un gestionnaire de suivi de bogues, un
2545 gestionnaire de correctifs, un gestionnaire de tâches et de projets, un
2546 service d'hébergement de fichiers, des listes de diffusion, des dépôts
2547 CVS, etc. Tous ces outils sont gérés par une interface web.
2550 Alioth est destiné à fournir des facilités pour des projets de
2551 logiciels soutenus ou dirigés par Debian, à faciliter les contributions
2552 de développeurs externes aux projets initiés par Debian et à aider des
2553 projets dont les buts sont de promouvoir Debian ou ses dérivés.
2556 Tous les développeurs Debian ont automatiquement un compte sur
2557 Alioth. Ils peuvent l'activer en utilisant la fonctionnalité de
2558 récupération des mots de passe. Les développeurs externes peuvent
2559 demander un compte invité sur Alioth.
2562 Pour plus d'informations, veuillez visiter <url id="&url-alioth;">.
2565 <sect id="developer-misc">
2567 « Goodies » pour les développeurs
2576 Depuis octobre 2002, HP parraine l'abonnement à LWN pour tous les
2577 développeurs Debian intéressés. Les détails sur les moyens d'accéder à
2578 cet avantage sont expliqués dans <url
2579 id="http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html">.
2589 Ce chapitre contient des informations relatives à la création, l'envoi,
2590 la maintenance et le portage des paquets.
2592 <sect id="newpackage">
2597 Si vous voulez créer un nouveau paquet pour la distribution Debian,
2598 vous devriez commencer par consulter la liste des <url id="&url-wnpp;"
2599 name="paquets en souffrance et paquets souhaités">. Vous pourrez ainsi
2600 vérifier que personne ne travaille déjà sur ce paquet et éviter un
2601 double travail. Consultez aussi cette page si vous voulez en savoir
2605 Supposons que personne ne travaille sur le paquet que vous visez, vous
2606 devez alors envoyer un rapport de bogue (voir <ref id="submit-bug">)
2607 concernant le pseudo-paquet <package>wnpp</package>. Ce courrier devra
2608 décrire le paquet que vous projetez de créer, la licence de ce paquet
2609 et l'URL à laquelle le source peut être téléchargé. Cette liste n'est
2613 Le sujet de votre rapport de bogue devra être
2614 <ITP<footnote><p><em>Intent To Package</em> : intention
2615 d'empaquetage</p></footnote> : <var>NomDuPaquet</var> —
2616 <var>courte description</var>>, en remplaçant <var>NomDuPaquet</var>
2617 par le nom du paquet. La gravité du bogue sera <em>wishlist</em>. Si
2618 vous le jugez nécessaire, envoyez une copie à &email-debian-devel; en
2619 mettant cette adresse dans le champ <tt>X-Debbugs-CC:</tt> de l'en-tête
2620 du message. N'utilisez pas le champ <tt>CC:</tt> car de cette manière
2621 le sujet du message ne contiendrait pas le numéro du bogue.
2624 Il faudra aussi ajouter une entrée <tt>Closes:
2625 bug#<var>nnnnn</var></tt> dans le fichier <file>changelog</file> du
2626 nouveau paquet. Cette indication fermera automatiquement le rapport de
2627 bogue à l'installation du nouveau paquet sur les serveurs d'archivage
2628 (voir <ref id="upload-bugfix">).
2631 Plusieurs raisons nous poussent à demander aux responsables d'annoncer
2632 leur intention :
2633 <list compact="compact">
2636 Les responsables ont ainsi la possibilité de puiser dans
2637 l'expérience des autres responsables et cela leur permet de savoir
2638 si une autre personne travaille déjà dessus.
2643 D'autres personnes qui envisagent de travailler sur le même paquet
2644 apprendront ainsi qu'il existe déjà un volontaire, l'effort peut
2650 Cela permet aux autres responsables de connaître le nouveau paquet
2651 mieux que ne le permettent la description d'une ligne et
2652 l'habituelle entrée de type changelog <em>Initial release</em>
2653 postée sur <tt>debian-devel-changes</tt>.
2658 C'est une information utile pour les gens qui utilisent la
2659 distribution <em>unstable</em> et qui sont nos premiers
2660 testeurs. Nous devons leur faciliter la tâche.
2665 Avec ces annonces, les développeurs Debian et toutes les autres
2666 personnes intéressées peuvent se faire une meilleure idée des
2667 évolutions et des nouveautés du projet.
2673 <sect id="changelog-entries">
2675 Enregistrer les modifications dans le paquet
2678 Les modifications que vous apportez au paquet doivent être notifiées
2679 dans le fichier <file>debian/changelog</file>. Ces notes doivent donner
2680 une description concise des changements, expliquer les raisons de
2681 ceux-ci (si ce n'est pas clair) et indiquer si des rapports de bogue
2682 ont été clos. Il faut aussi indiquer quand le paquet a été terminé. Ce
2683 fichier sera installé dans
2684 <file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
2685 <file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un
2689 Le fichier <file>debian/changelog</file> a une structure précise
2690 comportant différents champs. Le champ <em>distribution</em> est décrit
2691 dans <ref id="distribution">. Vous trouverez plus d'informations sur la
2692 structure de ce fichier dans la section
2693 « <file>debian/changelog</file> » de la <em>charte
2697 Les entrées du fichier <file>changelog</file> peuvent être utilisées
2698 pour fermer des rapports de bogue au moment où le paquet est installé
2699 dans l'archive. Voir la section <ref id="upload-bugfix">.
2702 Par convention, l'entrée changelog d'un paquet contenant une nouvelle
2703 version amont ressemble à :
2705 * new upstream version
2709 Quelques outils peuvent vous aider à créer des entrées et à finaliser
2710 le fichier <file>changelog</file> pour une livraison — voir les
2711 sections <ref id="devscripts"> et <ref id="dpkg-dev-el">.
2714 Voir aussi <ref id="bpp-debian-changelog">.
2717 <sect id="sanitycheck">
2722 Avant d'envoyer votre paquet, vous devriez faire quelques tests de
2723 base. Vous devriez au moins faire les tests suivants (il vous faut une
2724 ancienne version du paquet) :
2728 Installez le paquet et vérifiez que le logiciel fonctionne. Si le
2729 paquet existait déjà dans une version plus ancienne, faites une mise
2735 Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
2736 <prgn>lintian</prgn> comme suit : <tt>lintian -v
2737 <var>version-paquet</var>.changes</tt>. Ce programme fera une
2738 vérification sur les paquets source et binaire. Si vous ne comprenez
2739 pas les messages retournés par <prgn>lintian</prgn>, essayez
2740 l'option <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn>
2741 beaucoup plus bavard dans sa description du problème.
2744 En principe, un paquet pour lequel <prgn>lintian</prgn> renvoie des
2745 erreurs (elles commencent par <tt>E</tt>) <em>ne doit pas</em> être
2746 installé dans l'archive.
2749 Pour en savoir plus sur <prgn>lintian</prgn>, reportez-vous à la
2750 section <ref id="lintian">.
2755 Vous pouvez facultativement exécuter <ref id="debdiff"> pour
2756 analyser les modifications depuis une ancienne version si celle-ci
2762 Faites régresser le paquet vers sa version précédente si elle existe
2763 — cela permet de tester les scripts <file>postrm</file> et
2769 Désinstallez le paquet et réinstallez-le.
2774 Copiez le paquet source dans une répertoire différent et tentez de
2775 le décompacter et de le reconstruire. Ceci teste si le paquet repose
2776 sur des fichiers existants en dehors de ceux du paquet ou s'il
2777 repose sur des permissions préservées des fichiers livrés dans le
2784 <sect id="sourcelayout">
2786 Disposition du paquet source
2789 Il existe deux types de paquets source Debian :
2793 les paquets appelés <em>natifs</em> pour lesquels il n'y a pas de
2794 distinction entre les sources d'origine et les correctifs appliqués
2800 les paquets (plus courants) où il y a un fichier archive source
2801 d'origine accompagné par un autre fichier contenant les correctifs
2808 Pour les paquets natifs, le paquet source inclut un fichier de contrôle
2809 source Debian (<tt>.dsc</tt>) et l'archive source
2810 (<tt>.tar.gz</tt>). Un paquet source d'un paquet non natif inclut un
2811 fichier de contrôle source Debian, l'archive source d'origine
2812 (<tt>.orig.tar.gz</tt>) et les correctifs Debian (<tt>.diff.gz</tt>).
2815 Le caractère natif d'un paquet est déterminé lorsqu'il est construit
2816 par <manref section="1" name="dpkg-buildpackage">. Le reste de cette
2817 section ne se rapporte qu'aux paquets non natifs.
2820 La première fois qu'un paquet est installé dans l'archive pour une
2821 version amont donnée, le fichier <file>tar</file> de cette version
2822 amont doit être téléchargé et mentionné dans le fichier
2823 <file>.changes</file>. Par la suite, ce fichier <file>tar</file> sera
2824 utilisé pour générer les fichiers <file>diff</file> et
2825 <file>.dsc</file> et il ne sera pas nécessaire de le télécharger à
2829 Par défaut, <prgn>dpkg-genchanges</prgn> et
2830 <prgn>dpkg-buildpackage</prgn> incluront le fichier <file>tar</file>
2831 amont si et seulement si le numéro de révision du paquet source est 0
2832 ou 1, ce qui indique une nouvelle version amont. Ce comportement peut
2833 être modifié en utilisant <tt>-sa</tt> pour l'inclure systématiquement
2834 ou <tt>-sd</tt> pour ne jamais l'inclure.
2837 Si la mise à jour ne contient pas le fichier <file>tar</file> des
2838 sources originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour
2839 construire les fichiers <file>.dsc</file> et <file>diff</file> de la
2840 mise à jour, utiliser un fichier <tt>tar</tt> identique à l'octet près
2841 à celui déjà présent dans l'archive.
2844 Veuillez noter que, dans des paquets non natifs, les permissions sur
2845 des fichiers qui ne sont pas présents dans l'archive .orig.tar.gz ne
2846 seront pas préservées car diff ne stocke pas les permissions de fichier
2850 <sect id="distribution">
2852 Choisir une distribution
2855 Chaque envoi doit spécifier à quelle distribution le paquet est
2856 destiné. Le processus de construction de paquet extrait cette
2857 information à partir de la première ligne du fichier
2858 <file>debian/changelog</file> et la place dans le champ
2859 <tt>Distribution</tt> du fichier <tt>.changes</tt>.
2862 Il existe plusieurs valeurs possibles pour ce champ :
2863 « stable », « unstable »,
2864 « testing-proposed-updates » et « experimental ».
2867 En fait, il y a deux autres possibilités :
2868 « stable-security » et « testing-security », mais
2869 veuillez lire <ref id="bug-security"> pour plus d'informations sur
2873 Il n'est pas possible d'envoyer un paquet dans plusieurs distributions
2876 <sect1 id="upload-stable">
2878 Cas spécial : mise à jour d'un paquet de la distribution
2882 Livrer un paquet pour la distribution <em>stable</em> signifie que le
2883 paquet sera dirigé vers le répertoire
2884 <file>stable-proposed-updates</file> des archives Debian pour y être
2885 testé avant d'être effectivement inclus dans <em>stable</em>.
2888 Une livraison pour la distribution <em>stable</em> requiert des soins
2889 supplémentaires. Un paquet de cette distribution ne devrait être mis à
2890 jour que dans les cas suivants :
2894 un problème fonctionnel vraiment critique,
2899 un paquet devenu non installable,
2904 un paquet indisponible pour une architecture.
2910 Par le passé, des envois vers <em>stable</em> étaient également
2911 utilisés pour corriger les problèmes de sécurité. Cependant, cette
2912 pratique est dépréciée car les envois utilisés pour les avis de
2913 sécurité Debian<footnote><p>Debian security advisory</p></footnote>
2914 sont automatiquement copiés dans l'archive
2915 <file>proposed-updates</file> appropriée quand l'avis est
2916 publié. Reportez-vous à <ref id="bug-security"> pour des informations
2917 plus détaillées sur la gestion des problèmes de sécurité.
2920 Il est fortement déconseillé de changer quoi que ce soit si ce n'est
2921 pas important car même une modification triviale peut provoquer un
2925 Les paquets livrés pour <em>stable</em> doivent être compilés avec la
2926 distribution <em>stable</em> pour que leurs dépendances se limitent
2927 aux bibliothèques (et autres paquets) disponibles dans
2928 <em>stable</em> ; un paquet livré pour la distribution
2929 <em>stable</em> qui dépend d'une bibliothèque qui n'est disponible que
2930 dans <em>unstable</em> sera rejeté. Modifier les dépendances d'autres
2931 paquets (en manipulant le champ <tt>Provides</tt> ou les fichiers
2932 shlibs) et, peut-être, rendre ces paquets non installables, est
2933 fortement déconseillé.
2936 L'équipe responsable de la distribution<footnote><p><em>the Release
2937 team</em></p></footnote> (joignable à l'adresse
2938 &email-debian-release;) évaluera régulièrement le contenu de
2939 <em>stable-proposed-updates</em> et décidera si votre paquet peut être
2940 inclus dans la distribution <em>stable</em>. Soyez précis (et, si
2941 nécessaire, prolixe) quand vous décrivez, dans le fichier changelog,
2942 vos changements pour une livraison vers <em>stable</em>, sinon le
2943 paquet ne sera pas pris en considération.
2946 Il est fortement conseillé de discuter avec le responsable de la
2947 version stable <em>avant</em> de réaliser un envoi dans
2948 <em>stable</em>/<em>stable-proposed-updates</em>, pour que le paquet
2949 envoyé corresponde aux besoins de la prochaine révision de
2953 <sect1 id="upload-t-p-u">
2955 Cas spécial : mise à jour d'un paquet de la distribution
2956 <em>testing</em>/<em>testing-proposed-updates</em>
2959 Veuillez consulter les informations dans la <qref id="t-p-u">section
2960 sur <em>testing</em></qref> pour des détails.
2966 Mettre à jour un paquet
2968 <sect1 id="upload-ftp-master">
2970 Installer un paquet sur <tt>ftp-master</tt>
2973 Pour installer un paquet, vous devez envoyer les fichiers (y compris
2974 les fichiers changes et dsc signés) par ftp anonyme sur
2975 <ftpsite>&ftp-master-host;</ftpsite> dans le répertoire
2976 &upload-queue;. Pour que les fichiers y soient traités, ils doivent
2977 être signés avec une clé du porte-clés (<em>keyring</em>) Debian.
2980 Attention, il est préférable de transférer le fichier <tt>changes</tt>
2981 en dernier. Dans le cas contraire, votre livraison pourrait être
2982 rejetée car l'outil de maintenance de l'archive pourrait lire le
2983 fichier <tt>changes</tt> et constater que les fichiers ne sont pas
2987 Les paquets <ref id="dupload"> ou <ref id="dput"> pourront vous
2988 faciliter le travail lors du téléchargement. Ces programmes bien
2989 pratiques aident à automatiser le processus d'envoi de paquets vers
2993 Pour supprimer des paquets, veuillez lire le fichier README dans ce
2994 répertoire FTP et le paquet Debian <ref id="dcut">.
2997 <sect1 id="upload-non-us">
2999 Installer un paquet sur <tt>non-US</tt>
3002 <em>Note :</em> non-us a été interrompu avec la publication de
3006 <sect1 id="delayed-incoming">
3011 Les envois différés sont pour le moment réalisés <em>via</em> la file
3012 différée sur gluck. Le répertoire d'envoi est
3013 <ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>. 0-day est
3014 envoyé approximativement une heure avant l'exécution de dinstall.
3017 Avec une version assez récente de dput, cette section
3021 fqdn = gluck.debian.org
3024 dans votre fichier ~/.dput.cf devrait fonctionner correctement pour
3025 réaliser des envois dans la file DELAYED.
3028 <em>Note :</em> Comme la file d'envoi va sur <tt>ftp-master</tt>,
3029 la prescription que l'on trouve dans <ref id="upload-ftp-master">
3030 s'applique également ici.
3038 N'envoyez PAS un paquet vers la file d'envoi de sécurité
3039 (<em>oldstable-security</em>, <em>stable-security</em>, etc.) sans
3040 avoir obtenu au préalable l'autorisation de l'équipe de sécurité. Si
3041 le paquet ne correspond pas tout à fait aux besoins de cette équipe,
3042 il entraînera beaucoup de problèmes et de délais dans la gestion de
3043 cet envoi non désiré. Pour plus de détails, consultez la section <ref
3049 Les autres files d'envoi
3052 Les files scp sur ftp-master et security sont pratiquement
3053 inutilisables à cause des restrictions de connexion sur ces hôtes.
3056 Les files anonymes sur ftp.uni-erlangen.de et ftp.uk.debian.org sont
3057 actuellement arrêtées. Un travail est en cours pour les restaurer.
3060 Les files sur master.debian.org, samosa.debian.org,
3061 master.debian.or.jp et ftp.chiark.greenend.org.uk sont arrêtées de
3062 façon permanente et ne seront pas restaurées. La file du Japon sera
3063 remplacée par une nouvelle file sur hp.debian.or.jp un jour.
3066 À l'heure actuelle, la file en ftp anonyme sur auric.debian.org (le
3067 précédent ftp-master) fonctionne, mais elle est déconseillée et sera
3068 supprimée à un moment donné.
3071 <sect1 id="upload-notification">
3073 Notification de l'installation d'un nouveau paquet
3076 Les administrateurs de l'archive Debian sont responsables de
3077 l'installation des mises à jour. La plupart des mises à jour sont
3078 gérées quotidiennement par le logiciel de gestion de l'archive
3079 <prgn>katie</prgn>. Les mises à jour de paquets sur la distribution
3080 <em>unstable</em> sont installées ainsi. Dans les autres cas et
3081 notamment dans le cas d'un nouveau paquet, celui-ci sera installé
3082 manuellement. Il peut s'écouler jusqu'à un mois entre le
3083 téléchargement d'un paquet vers un serveur et son installation
3084 effective. Soyez patient.
3087 Dans tous les cas, vous recevrez un accusé de réception par courrier
3088 électronique indiquant que votre paquet a été installé et quels
3089 rapports de bogues ont été clos. Lisez attentivement ce courrier et
3090 vérifiez que tous les rapports de bogue que vous vouliez clore sont
3091 bien dans cette liste.
3094 L'accusé de réception indique aussi la section dans laquelle le paquet
3095 a été installé. S'il ne s'agit pas de votre choix, vous recevrez un
3096 second courrier qui vous informera de cette différence (voir
3100 Notez que si vous envoyez <em>via</em> les files, le logiciel de démon
3101 de file vous enverra également une notification par courriel.
3105 <sect id="override-file">
3107 Spécifier la section, la sous-section et la priorité d'un paquet
3110 Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
3111 <file>debian/control</file> n'indiquent ni où le paquet sera installé
3112 dans l'archive Debian, ni sa priorité. Afin de conserver la cohérence
3113 de l'archive, ce sont les administrateurs qui contrôlent ces
3114 champs. Les valeurs du fichier <file>debian/control</file> sont juste
3118 Les administrateurs de l'archive indiquent les sections et priorités
3119 des paquets dans le fichier <em>override</em>. Si ce fichier
3120 <em>override</em> et le fichier <file>debian/control</file> de votre
3121 paquet diffèrent, vous en serez informé par courrier électronique quand
3122 votre paquet sera installé dans l'archive. Vous pourrez corriger votre
3123 fichier <em>debian/control</em> avant votre prochain téléchargement ou
3124 alors vous pourrez vouloir modifier le fichier <em>override</em>.
3127 Pour modifier la section dans laquelle un paquet est archivé, vous
3128 devez d'abord vérifier que fichier <file>debian/control</file> est
3129 correct. Ensuite, envoyez un courrier à &email-override; ou un rapport
3130 de bogue sur le pseudo-paquet <package>ftp.debian.org</package>
3131 demandant la modification de la section ou de la priorité de votre
3132 paquet. Exposez bien les raisons qui vous amènent à demander ces
3136 Pour en savoir plus sur les <em>fichiers override</em>, reportez-vous à
3137 <manref section="1" name="dpkg-scanpackages"> et <url
3138 id="&url-bts-devel;#maintincorrect">.
3141 Notez que le champ <tt>Section</tt> décrit à la fois la section et la
3142 sous-section, comme décrit dans <ref id="archive-sections">. Si la
3143 section est « main », elle devrait être omise. La liste des
3144 sous-sections autorisées peut être trouvée dans <url
3145 id="&url-debian-policy;ch-archive.html#s-subsections">.
3148 <sect id="bug-handling">
3153 Chaque développeur doit être capable de travailler avec le <url
3154 id="&url-bts;" name="système de suivi des bogues"> Debian. Il faut
3155 savoir comment remplir des rapports de bogue correctement (voir <ref
3156 id="submit-bug">), comment les mettre à jour et les réordonner et
3157 comment les traiter et les fermer.
3160 Les fonctionnalités du système de suivi des bogues sont décrites dans
3161 la <url id="&url-bts-devel;" name="documentation du BTS pour les
3162 développeurs">. Ceci inclut la fermeture des bogues, l'envoi des
3163 messages de suivi, l'assignation des niveaux de gravité et des marques,
3164 l'indication que les bogues ont été envoyés au développeur amont et
3168 Des opérations comme réassigner des bogues à d'autres paquets, réunir
3169 des rapports de bogues séparés traitant du même problème ou rouvrir des
3170 bogues quand ils ont été prématurément fermés, sont gérées en utilisant
3171 le serveur de courrier de contrôle. Toutes les commandes disponibles
3172 pour ce serveur sont décrites dans la <url id="&url-bts-control;"
3173 name="documentation du serveur de contrôle du BTS">.
3175 <sect1 id="bug-monitoring">
3177 Superviser les rapports de bogue
3180 Si vous voulez être un bon responsable, consultez régulièrement la
3181 page du <url id="&url-bts;" name="système de suivi des bogues">. Cette
3182 page contient tous les rapports de bogue qui concernent vos
3183 paquets. Vous pouvez les vérifier avec cette page :
3184 <tt>http://&bugs-host;/<var>votre_compte</var>@debian.org</tt>.
3187 Les responsables interagissent avec le système de suivi des bogues en
3188 utilisant l'adresse électronique <tt>&bugs-host;</tt>. Vous trouverez
3189 une documentation sur les commandes disponibles à l'adresse <url
3190 id="&url-bts;"> ou, si vous avez installé le paquet
3191 <package>doc-debian</package>, dans les fichiers locaux
3195 Certains trouvent utile de recevoir régulièrement une synthèse des
3196 rapports de bogues ouverts. Si vous voulez recevoir une synthèse
3197 hebdomadaire relevant tous les rapports de bogue ouverts pour vos
3198 paquets, vous pouvez configurer <prgn>cron</prgn> comme suit :
3200 # Synthèse hebdomadaire des rapports de bogue qui me concernent
3203 Remplacez <var>address</var> par votre adresse officielle de
3207 <sect1 id="bug-answering">
3209 Répondre à des rapports de bogue
3212 Lorsque vous répondez à des rapports de bogue, assurez-vous que toutes
3213 vos discussions concernant les bogues sont envoyées au rapporteur du
3214 bogue et au bogue lui-même (<email>123@&bugs-host;</email> par
3215 exemple). Si vous rédigez un nouveau courrier et si vous ne vous
3216 souvenez plus de l'adresse du rapporteur de bogue, vous pouvez
3217 utiliser l'adresse <email>123-submitter@&bugs-host;</email> pour
3218 contacter le rapporteur <em>et</em> enregistrer votre courrier dans le
3219 journal du bogue (ce qui veut dire que vous n'avez pas besoin
3220 d'envoyer une copie du courrier à <email>123@&bugs-host;</email>).
3223 Si vous recevez un bogue mentionnant « FTBFS », cela veut
3224 dire « Fails To Build From Source » (Erreur de construction
3225 à partir du source). Les porteurs emploient fréquemment cet acronyme.
3228 Une fois que vous avez traité un rapport de bogue (i.e. que vous
3229 l'avez corrigé), marquez-le comme <em>done</em> (fermez-le) en
3230 envoyant un message d'explication à
3231 <email>123-done@&bugs-host;</email>. Si vous corrigez un bogue en
3232 changeant et en envoyant une nouvelle version du paquet, vous pouvez
3233 fermer le bogue automatiquement comme décrit dans <ref
3234 id="upload-bugfix">.
3237 Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant
3238 la commande <tt>close</tt> à l'adresse &email-bts-control;.Si vous le
3239 faites, le rapporteur n'aura aucune information sur la clôture de son
3243 <sect1 id="bug-housekeeping">
3245 Gestion générale des bogues
3248 En tant que responsable de paquet, vous trouverez fréquemment des
3249 bogues dans d'autres paquets ou vous aurez des bogues sur vos paquets
3250 qui sont en fait des bogues sur d'autres paquets. Les fonctions
3251 intéressantes du système de suivi des bogues sont décrites dans la
3252 <url id="&url-bts-devel;" name="documentation du BTS pour les
3253 développeurs Debian">. Les <url id="&url-bts-control;"
3254 name="instructions du serveur de contrôle du BTS"> documentent les
3255 opérations techniques du BTS, telles que comment remplir, réassigner,
3256 regrouper et marquer des bogues. Cette section contient des lignes
3257 directrices pour gérer vos propres bogues, définies à partir de
3258 l'expérience collective des développeurs Debian.
3261 Remplir des rapports de bogue pour des problèmes que vous trouvez dans
3262 d'autres paquet est l'une des « obligations civiques » du
3263 responsable, reportez-vous à <ref id="submit-bug"> pour les
3264 détails. Cependant, gérer les bogues de vos propres paquets est encore
3268 Voici une liste des étapes que vous pouvez suivre pour gérer un
3269 rapport de bogue :
3270 <enumlist numeration="arabic">
3273 Décider si le rapport correspond à un bogue réel ou non. Parfois,
3274 les utilisateurs exécutent simplement un programme de la mauvaise
3275 façon car ils n'ont pas lu la documentation. Si c'est votre
3276 diagnostic, fermez simplement le bogue avec assez d'informations
3277 pour laisser l'utilisateur corriger son problème (donnez des
3278 indications vers la bonne documentation et ainsi de suite). Si le
3279 rapport de bogue revient régulièrement, vous devriez vous demander
3280 si la documentation est assez bonne ou si le programme ne devrait
3281 pas détecter une mauvaise utilisation pour donner un message
3282 d'erreur informatif. Il s'agit d'un problème qui peut être discuté
3283 avec l'auteur amont.
3286 Si le rapporteur de bogue n'est pas d'accord avec votre décision de
3287 fermeture du bogue, il peut le ré-ouvrir jusqu'à ce que vous
3288 trouviez un accord sur la façon de le gérer. Si vous n'en trouvez
3289 pas, vous pouvez marquer le bogue avec <tt>wontfix</tt> pour
3290 indiquer aux personnes que le bogue existe, mais ne sera pas
3291 corrigé. Si cette situation n'est pas acceptable, vous (ou le
3292 rapporteur) pouvez vouloir demander une décision par le comité
3293 technique en réattribuant le bogue à <package>tech-ctte</package>
3294 (vous pouvez utiliser la commande <tt>clone</tt> du BTS si vous
3295 désirez garder le bogue comme rapporté sur votre paquet). Avant de
3296 faire cela, veuillez lire la <url id="&url-tech-ctte;"
3297 name="procédure recommandée">.
3302 Si le bogue est réel, mais est causé par un autre paquet,
3303 réattribuez simplement le bogue à l'autre paquet. Si vous ne savez
3304 pas à quel paquet il doit être réattribué, vous pouvez demander de
3305 l'aide sur <qref id="irc-channels">IRC</qref> ou sur
3306 &email-debian-devel;. Veuillez vous assurer que le (ou les)
3307 responsable(s) du paquet sur lequel est réattribué le paquet sait
3308 pourquoi vous l'avez ainsi réattribué.
3311 Parfois, vous devez également ajuster la gravité du bogue pour
3312 qu'elle corresponde à notre définition de gravité des bogues. C'est
3313 dû au fait que les gens tendent à augmenter la gravité des bogues
3314 pour s'assurer que leurs bogues seront corrigés rapidement. La
3315 gravité de certains bogues peut même être rétrogradée en
3316 <em>wishlist</em> (souhait) quand le changement demandé est
3317 seulement d'ordre cosmétique.
3322 Si le bogue est réel, mais que le problème a déjà été rapporté par
3323 quelqu'un d'autre, les deux rapports de bogues pertinents devraient
3324 être fusionnés en un seul en utilisant la commande <tt>merge</tt>
3325 (fusion) du BTS. Ainsi, quand le bogue sera corrigé, tous les
3326 créateurs de rapport de bogue en seront informés (notez, cependant,
3327 que les courriels envoyés à l'un des créateurs de rapport de bogue
3328 ne seront pas automatiquement envoyés aux autres créateurs de
3329 rapport de bogue). Pour plus de détails sur les technicités de la
3330 commande de fusion et sa voisine, la commande <tt>unmerge</tt>
3331 (séparation), veuillez consulter la documentation du serveur de
3337 Le rapporteur de bogue peut avoir oublié de fournir certaines
3338 informations. Dans ce cas, vous devez lui demander les informations
3339 nécessaires. Vous pouvez utiliser la marque <tt>moreinfo</tt> (plus
3340 d'information) sur le bogue. De plus, si vous ne pouvez pas
3341 reproduire le bogue, vous pouvez le marquer comme
3342 <tt>unreproducible</tt> (non reproductible). Une personne qui
3343 arriverait à reproduire le bogue est alors invitée à fournir plus
3344 d'informations sur la façon de le reproduire. Après quelques mois,
3345 si cette information n'a été envoyée par personne, le bogue peut
3351 Si le bogue est lié à l'empaquetage, vous devez simplement le
3352 corriger. Si vous ne pouvez pas le corriger vous-même, marquez
3353 alors le bogue avec <tt>help</tt> (aide). Vous pouvez également
3354 demander de l'aide sur &email-debian-devel; ou
3355 &email-debian-qa;. S'il s'agit d'un problème amont, vous devez
3356 faire suivre le rapport à l'auteur amont. Faire suivre un bogue
3357 n'est pas suffisant, vous devez vérifier à chaque version si le
3358 bogue a été corrigé ou non. S'il a été corrigé, vous le fermez
3359 simplement, sinon vous devez le rappeler à l'auteur. Si vous avez
3360 les compétences nécessaires, vous pouvez préparer un correctif pour
3361 corriger le bogue et l'envoyer en même temps à
3362 l'auteur. Assurez-vous d'envoyer le correctif au BTS et marquez le
3363 bogue avec <tt>patch</tt> (correctif).
3368 Si vous avez corrigé un bogue sur votre copie locale ou si un
3369 correctif a été inclus dans le référentiel CVS, vous pouvez marquer
3370 le bogue avec <tt>pending</tt> (en attente) pour informer que le
3371 bogue est corrigé et qu'il sera fermé lors du prochain envoi
3372 (ajoutez le <tt>closes:</tt> dans le <file>changelog</file>). C'est
3373 particulièrement utile si plusieurs développeurs travaillent sur le
3379 Une fois que le paquet corrigé est disponible dans la distribution
3380 <em>unstable</em>, vous pouvez fermer le bogue. Ceci peut être fait
3381 automatiquement, pour cela, reportez-vous à <ref
3382 id="upload-bugfix">.
3388 <sect1 id="upload-bugfix">
3390 Quand les rapports de bogue sont-ils fermés par une mise à jour ?
3393 Au fur et à mesure que les bogues et problèmes sont corrigés dans vos
3394 paquets, il est de votre responsabilité en tant que responsable du
3395 paquet de fermer les rapports de bogue associés. Cependant, vous ne
3396 devez pas les fermer avant que le paquet n'ait été accepté dans
3397 l'archive Debian. C'est pourquoi, vous pouvez et vous devez clore les
3398 rapports dans le système de suivi des bogues une fois que vous avez
3399 reçu l'avis indiquant que votre nouveau paquet a été installé dans
3403 Cependant, il est possible d'éviter d'avoir à fermer manuellement les
3404 bogues après l'envoi — indiquez simplement les bogues corrigés
3405 dans le fichier <file>changelog</file> en suivant une syntaxe
3406 précise. Par exemple :
3408 acme-cannon (3.1415) unstable; urgency=low
3410 * Frobbed with options (closes: Bug#98339)
3411 * Added safety to prevent operator dismemberment, closes: bug#98765,
3413 * Added man page. Closes: #98725.
3415 Techniquement parlant, l'expression rationnelle Perl suivante décrit
3416 comment les lignes de <em>changelogs</em> de fermeture de bogues sont
3419 /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
3421 Nous préférons la syntaxe <tt>closes: #<var>XXX</var></tt>, car c'est
3422 l'entrée la plus concise et la plus facile à intégrer dans le texte du
3423 fichier <file>changelog</file>.
3426 Si un envoi est identifié comme une <qref id="nmu">mise à jour
3427 indépendante (NMU)</qref> (et c'est le cas si le nom de la personne
3428 qui a réalisé ce changement n'est pas exactement le même que celui de
3429 l'un des responsables ou expéditeurs, sauf si le responsable est le
3430 groupe d'Assurance Qualité), le bogue est alors marqué <tt>fixed</tt>
3431 (corrigé) au lieu d'être fermé. Si un envoi de responsable a pour
3432 cible <em>experimental</em>, l'étiquette
3433 <tt>fixed-in-experimental</tt> est alors ajoutée au bogue ; pour
3434 les mises à jour indépendantes, l'étiquette <tt>fixed</tt> (corrigé)
3435 est utilisée (il est attendu que la règle spéciale pour
3436 <em>experimental</em> sera modifiée dès que le suivi des versions sera
3437 ajouté au système de suivi des bogues).
3440 Si vous entrez un numéro de bogue incorrect ou si vous oubliez un
3441 bogue dans les entrées du fichier <file>changelog</file>, n'hésitez
3442 pas à annuler tout dommage que l'erreur a entraîné. Pour rouvrir un
3443 bogue fermé par erreur, envoyez une commande <tt>reopen
3444 <var>XXX</var></tt> à l'adresse de contrôle du système de suivi des
3445 bogues, &email-bts-control;. Pour fermer tous les bogues restants qui
3446 ont été corrigés par votre envoi, envoyez le fichier
3447 <file>.changes</file> à <email>XXX-done@&bugs-host;</email> où
3448 <var>XXX</var> est le numéro du bogue.
3451 Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en
3452 utilisant le <file>changelog</file> tel que décrit ci-dessus. Si vous
3453 désirez simplement fermer les bogues qui n'ont rien à voir avec l'un
3454 de vos envois, faites-le simplement en envoyant une explication à
3455 <email>XXX-done@&bugs-host;</email>. Vous <strong>ne devez
3456 pas</strong> pas fermer des bogues dans une entrée de changelog d'une
3457 version si les changements dans cette version n'ont rien à voir avec
3461 Pour une information plus générale sur ce qu'il faut mettre dans les
3462 entrées de changelog, veuillez vous reporter aux <ref
3463 id="bpp-debian-changelog">.
3466 <sect1 id="bug-security">
3468 Gérer les bogues de sécurité
3471 À cause de leur nature sensible, les bogues liés à la sécurité doivent
3472 être soigneusement traités. L'équipe de sécurité de Debian est là pour
3473 coordonner cette activité, pour faire le suivi des problèmes de
3474 sécurité en cours, pour aider les responsables ayant des problèmes de
3475 sécurité ou pour les corriger elle-même, pour envoyer les annonces de
3476 sécurité et pour maintenir le site security.debian.org.
3479 Si vous prenez connaissance d'un bogue lié à un problème de sécurité
3480 sur un paquet Debian, que vous soyez ou non le responsable, regroupez
3481 les informations pertinentes sur le problème et contactez rapidement
3482 l'équipe de sécurité à &email-security-team; dès que
3483 possible. <strong>N'ENVOYEZ PAS</strong> de paquet pour
3484 <em>stable</em> ; l'équipe de sécurité le fera. Les informations
3485 utiles incluent, par exemple :
3486 <list compact="compact">
3489 les versions du paquet connues pour être affectées par le
3490 bogue. Vérifiez chaque version présente dans les distributions
3491 maintenues par Debian ainsi que dans <em>testing</em> et dans
3497 la nature d'une solution si elle est disponible (les correctifs
3498 sont particulièrement utiles),
3503 tout paquet corrigé que vous avez vous-même préparé (envoyez
3504 seulement les fichiers <file>.diff.gz</file> et <file>.dsc</file>
3505 et lisez d'abord <ref id="bug-security-building">),
3510 toute assistance que vous pouvez fournir pour aider les tests
3511 (exploits, tests de régression, etc.),
3516 toute information nécessaire pour l'annonce de sécurité (voir <ref
3517 id="bug-security-advisories">).
3522 <sect2 id="bug-security-confidentiality">
3527 À la différence de la plupart des autres activités au sein de Debian,
3528 les informations sur les problèmes de sécurité doivent parfois être
3529 gardées en privé pour un certain temps. Ceci permet aux distributeurs
3530 de logiciels de coordonner leur dévoilement afin de minimiser
3531 l'exposition de leurs utilisateurs. Cette décision dépend de la
3532 nature du problème et de l'existence d'une solution correspondante et
3533 également s'il s'agit d'un fait connu publiquement.
3536 Il existe plusieurs façons pour un développeur de prendre
3537 connaissance d'un problème de sécurité :
3538 <list compact="compact">
3541 il le remarque sur un forum public (liste de diffusion, site web,
3547 quelqu'un remplit un rapport de bogue,
3552 quelqu'un l'informe par courrier privé.
3556 Dans les deux premiers cas, l'information est publique et il est
3557 important d'avoir une solution le plus vite possible. Dans le dernier
3558 cas, cependant, ce n'est peut-être pas une information publique. Dans
3559 ce cas, il existe quelques options possibles pour traiter le
3564 si l'exposition de sécurité est mineure, il n'y a parfois pas
3565 besoin de garder le secret sur le problème et une correction
3566 devrait être effectuée et diffusée,
3571 si le problème est grave, il est préférable de partager cette
3572 information avec d'autres vendeurs et de coordonner une
3573 diffusion. L'équipe de sécurité garde des contacts avec les
3574 différentes organisations et individus et peut prendre soin des
3581 Dans tous les cas, si la personne qui indique le problème demande à
3582 ce que l'information ne soit pas diffusée, cela devrait être respecté
3583 avec l'évidente exception d'informer l'équipe de sécurité pour qu'une
3584 correction puisse être effectuée pour la version stable de
3585 Debian. Quand vous envoyez des informations confidentielles à
3586 l'équipe de sécurité, assurez-vous de bien mentionner ce fait.
3589 Veuillez noter que si le secret est nécessaire, vous ne pourrez pas
3590 envoyer un correctif vers <em>unstable</em> (ou ailleurs) puisque les
3591 informations de changelog et de diff sont publiques pour
3595 Il existe deux raisons pour diffuser l'information même si le secret
3596 est demandé : le problème est connu depuis un certain temps ou
3597 le problème ou son exploitation est devenu public.
3600 <sect2 id="bug-security-advisories">
3602 Annonces de sécurité
3605 Les annonces de sécurité ne sont émises que pour la distribution
3606 actuelle diffusée <em>stable</em>, <em>PAS</em> pour <em>testing</em>
3607 ou <em>unstable</em>. Quand elle est diffusée, l'annonce est envoyée
3608 à la liste de diffusion &email-debian-security-announce; et elle est
3609 postée sur <url id="&url-debian-security-advisories;" name="la page
3610 de sécurité">. Les annonces de sécurité sont écrites et postées par
3611 les membres de l'équipe de sécurité. Cependant, ils ne verront aucun
3612 inconvénient à ce qu'un responsable leur apporte des informations ou
3613 écrive une partie du texte. Les informations qui devraient être
3614 présentes dans une annonce incluent :
3615 <list compact="compact">
3618 une description du problème et de sa portée, y compris :
3622 le type du problème (usurpation de privilège, déni de service,
3628 quels sont les privilèges obtenus et par quels utilisateurs (si
3634 comment il peut être exploité,
3639 si le problème peut être exploité à distance ou localement,
3644 comment le problème a été corrigé,
3648 Ces informations permettent aux utilisateurs d'estimer la menace
3649 pesant sur leurs systèmes.
3654 les numéros de version des paquets affectés,
3659 les numéros de version des paquets corrigés,
3664 une information sur la façon de récupérer les paquets mis à jour
3665 (habituellement l'archive de sécurité Debian),
3670 des références à des annonces amont, des identifiants <url
3671 id="http://cve.mitre.org" name="CVE"> et toute autre information
3672 utile pour recouper les références de la vulnérabilité.
3678 <sect2 id="bug-security-building">
3680 Préparer les paquets pour corriger des problèmes de sécurité
3683 Une façon d'aider l'équipe de sécurité dans ses travaux est de lui
3684 fournir des paquets corrigés convenables pour une annonce de sécurité
3685 pour la version <em>stable</em> de Debian
3688 Quand une mise à jour de la version <em>stable</em> est effectuée, un
3689 soin particulier doit être apporté pour éviter de modifier le
3690 comportement du système ou d'introduire de nouveaux bogues. Pour
3691 cela, faites le moins de changements possibles pour corriger le
3692 bogue. Les utilisateurs et les administrateurs s'attendent à un
3693 comportement identique dans une version lorsque celle-ci est
3694 diffusée, donc tout changement qui est fait est susceptible de casser
3695 le système de quelqu'un. Ceci est spécialement vrai pour les
3696 bibliothèques : assurez-vous ne de jamais changer l'API ou
3697 l'ABI, aussi minimal que soit le changement.
3700 Cela veut dire que passer à une version amont supérieure n'est pas
3701 une bonne solution. À la place, les changements pertinents devraient
3702 être rétroportés vers la version présente dans la distribution
3703 <em>stable</em> de Debian. Habituellement, les développeurs amont
3704 veulent bien aider. Sinon, l'équipe de sécurité Debian peut le faire.
3707 Dans certains cas, il n'est pas possible de rétroporter un correctif
3708 de sécurité, par exemple, quand de grandes quantités de code source
3709 doivent être modifiées ou récrites. Si cela se produit, il peut être
3710 nécessaire de passer à une nouvelle version amont. Cependant, ceci
3711 n'est fait que dans des situations extrêmes et vous devez toujours
3712 coordonner cela avec l'équipe de sécurité au préalable.
3715 Il existe une autre règle de conduite liée à cela : testez
3716 toujours vos changements. Si une exploitation du problème existe,
3717 essayez-la et vérifiez qu'elle réussit sur le paquet non corrigé et
3718 échoue sur le paquet corrigé. Testez aussi les autres actions
3719 normales car parfois un correctif de sécurité peut casser de manière
3720 subtile des fonctionnalités qui ne semblent pas liées.
3723 N'incluez <strong>PAS</strong> de changements dans votre paquet qui
3724 ne soient pas liés directement à la correction de la
3725 vulnérabilité. Ceux-ci devraient être ensuite enlevés et cela perd du
3726 temps. S'il y a d'autres bogues dans votre paquet que vous aimeriez
3727 corriger, faites un envoi vers proposed-updates de la façon
3728 habituelle, après l'envoi de l'alerte de sécurité. Le mécanisme de
3729 mise à jour de sécurité n'est pas un moyen d'introduire des
3730 changements dans votre paquet qui seraient sinon rejetés de la
3731 distribution stable, n'essayez donc pas de faire cela, s'il vous
3735 Examinez et testez autant que possible vos changements. Vérifiez les
3736 différences avec la version précédente de manière répétée
3737 (<prgn>interdiff</prgn> du paquet <package>patchutils</package> et
3738 <prgn>debdiff</prgn> du paquet <package>devscripts</package> sont des
3739 outils utiles pour cela, voir <ref id="debdiff">).
3742 Assurez-vous de conserver les points suivants à l'esprit :
3746 Ciblez la bonne distribution dans votre fichier
3747 <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de
3748 <tt>stable-security</tt> et pour <em>testing</em>, c'est
3749 <tt>testing-security</tt> et pour l'ancienne distribution stable,
3750 c'est <tt>oldstable-security</tt>. Ne ciblez ni
3751 <var>distribution</var>-proposed-updates, ni
3752 <tt>stable</tt> !
3757 L'envoi devra avoir « urgency=high ».
3762 Fournissez des entrées de changelog descriptives et
3763 complètes. D'autres personnes se baseront dessus pour déterminer
3764 si un bogue particulier a été corrigé. Incluez toujours une
3765 référence externe, de préférence un identifiant CVE, pour qu'elle
3766 puisse être recoupée. Incluez la même information dans le
3767 changelog pour <em>unstable</em> pour qu'il soit clair que le même
3768 bogue a été corrigé car cela est très utile pour vérifier que le
3769 bogue a été corrigé pour la prochaine version stable. Si aucun
3770 identifiant CVE n'a encore été assigné, l'équipe de sécurité en
3771 demandera un pour qu'il puisse être inclus dans le paquet et dans
3777 Assurez-vous que le numéro de version est correct. Il doit être
3778 plus élevé que celui du paquet actuel, mais moins que ceux des
3779 paquets des versions des distributions suivantes. En cas de doute,
3780 testez-le avec <tt>dpkg --compare-versions</tt>. Soyez attentif à
3781 ne pas ré-utiliser un numéro de version que vous auriez déjà
3782 utilisé pour un précédent envoi. Pour <em>testing</em>, il doit y
3783 avoir un numéro de version supérieur dans <em>unstable</em>. S'il
3784 n'y en a pas encore (par exemple, si <em>testing</em> et
3785 <em>unstable</em> ont la même version), vous devez envoyer une
3786 nouvelle version vers <em>unstable</em> en premier.
3791 Ne faites pas d'envoi de source seul si votre paquet possède un ou
3792 plusieurs paquets binary-all (n'utilisez pas l'option <tt>-S</tt>
3793 de <prgn>dpkg-buildpackage</prgn>). L'infrastructure
3794 <prgn>buildd</prgn> ne construira pas ceux-ci. Ce point s'applique
3795 aux envois de paquets normaux également.
3800 Sauf si la source amont a été envoyée auparavant à
3801 security.debian.org (par une précédente mise à jour de sécurité),
3802 construisez le paquet avec la source amont complète
3803 (<tt>dpkg-buildpackage -sa</tt>). S'il y a déjà eu un précédent
3804 envoi à security.debian.org, vous pouvez faire un envoi sans le
3805 paquet source (<tt>dpkg-buildpackage -sd</tt>).
3810 Assurez-vous d'utiliser exactement le même nom
3811 <file>*.orig.tar.gz</file> que celui utilisé dans l'archive
3812 normale, sinon il ne sera pas possible de déplacer plus tard le
3813 correctif de sécurité dans l'archive principale.
3818 Compilez le paquet sur un système propre, dont tous les paquets
3819 appartiennent à la distribution pour laquelle vous construisez le
3820 paquet. Si vous n'avez pas un tel système, vous pouvez utiliser
3821 l'une des machines de debian.org (voir <ref id="server-machines">)
3822 ou mettez en place un chroot (voir <ref id="pbuilder"> et <ref
3829 <sect2 id="bug-security-upload">
3831 Mettre à jour le paquet corrigé
3834 Vous <em>NE</em> devez <em>PAS</em> envoyer un paquet dans la file
3835 d'attente des envois de sécurité (oldstable-security,
3836 stable-security, etc.) sans l'accord préalable de l'équipe de
3837 sécurité. Si le paquet ne remplit pas exactement les exigences de
3838 l'équipe, il causera beaucoup de problèmes, ainsi que des délais dans
3839 la gestion de l'envoi indésirable.
3842 Vous <em>NE</em> devez <em>PAS</em> envoyer votre correction dans
3843 <em>proposed-updates</em> sans vous coordonner avec l'équipe de
3844 sécurité. Les paquets seront copiés de security.debian.org dans le
3845 répertoire <file>proposed-updates</file> automatiquement. Si un
3846 paquet avec le même numéro de version ou un numéro plus grand est
3847 déjà installé dans l'archive, la mise à jour de sécurité sera rejetée
3848 par le système d'archive. Ainsi, la distribution <em>stable</em> se
3849 retrouvera à la place sans la mise à jour de sécurité de ce paquet.
3852 Une fois que vous avez créé et testé le nouveau paquet et qu'il a été
3853 approuvé par l'équipe de sécurité, il doit être envoyé pour être
3854 installé dans les archives. Pour les envois de sécurité, l'adresse
3856 <tt>ftp://security-master.debian.org/pub/SecurityUploadQueue/</tt>.
3859 Une fois que l'envoi vers la file d'attente de sécurité a été
3860 accepté, le paquet sera automatiquement recompilé pour toutes les
3861 architectures et stocké pour vérification par l'équipe de sécurité.
3864 Les envois en attente d'acceptation ou de vérification ne sont
3865 accessibles que par l'équipe de sécurité. C'est nécessaire car il
3866 pourrait y avoir des correctifs pour des problèmes de sécurité qui ne
3867 peuvent pas encore être diffusés.
3870 Si une personne de l'équipe de sécurité accepte un paquet, il sera
3871 installé sur security.debian.org ainsi que dans le répertoire
3872 <var>distribution</var>-proposed-updates qui convient sur ftp-master
3873 ou dans l'archive non-US.
3878 <sect id="archive-manip">
3880 Déplacer, effacer, changer le nom, adopter et abandonner des paquets
3883 Certaines manipulations de l'archive ne sont pas possibles avec le
3884 processus de mise à jour automatisé. Elles sont appliquées manuellement
3885 par les développeurs. Ce chapitre décrit ce qu'il faut faire dans ces
3888 <sect1 id="moving-pkgs">
3890 Déplacer des paquets
3893 Il se peut qu'un paquet puisse changer de section. Une nouvelle
3894 version d'un paquet de la section <tt>non-free</tt> pourrait, par
3895 exemple, être distribuée sous licence GNU GPL ; dans ce cas, le
3896 paquet doit être déplacé dans la section <tt>main</tt> ou
3897 <tt>contrib</tt><footnote><p>Reportez-vous à la <url
3898 id="&url-debian-policy;" name="charte Debian"> pour savoir dans quelle
3899 section un paquet doit être classé.</p></footnote>.
3902 Si vous avez besoin de modifier la section de l'un de vos paquets,
3903 modifiez les informations de contrôle du paquet pour le placer dans la
3904 section désirée et téléchargez à nouveau votre paquet dans
3905 l'archive. Reportez-vous à la <url id="&url-debian-policy;"
3906 name="charte Debian"> pour en savoir plus. Si votre nouvelle section
3907 est valide, il sera déplacé automatiquement. Si ce n'est pas le cas,
3908 contactez les responsables ftp pour comprendre ce qui s'est passé.
3911 Si vous avez besoin de modifier la sous-section de l'un de vos paquets
3912 (<tt>devel</tt> ou <tt>admin</tt> par exemple), la procédure est
3913 légèrement différente. Modifiez la sous-section dans le fichier de
3914 contrôle de votre paquet et téléchargez-le. Il vous faudra ensuite
3915 demander la modification du fichier <em>override</em> comme décrit
3916 dans la section <ref id="override-file">.
3919 <sect1 id="removing-pkgs">
3921 Supprimer des paquets
3924 Si, pour une raison ou une autre, vous avez besoin de supprimer
3925 complètement un paquet de l'archive (disons qu'il s'agit d'une vieille
3926 bibliothèque devenue inutile que l'on conservait pour des raisons de
3927 compatibilité), il vous faudra envoyer un rapport de bogue concernant
3928 le pseudo-paquet <tt>ftp.debian.org</tt> et demander sa
3929 suppression ; comme pour tous les bogues, ce bogue devrait être
3930 de gravité normale. N'oubliez pas de préciser de quelle distribution
3931 le paquet doit être supprimé. Normalement, vous ne devriez avoir à
3932 supprimer que des paquets d'<em>unstable</em> ou
3933 d'<em>experimental</em>. Les paquets de <em>testing</em> ne sont pas
3934 supprimés directement. Ils sont plutôt enlevés automatiquement après
3935 que le paquet a été supprimé d'<em>unstable</em> et si aucun paquet de
3936 <em>testing</em> n'en dépend.
3939 Vous devez également détailler les raisons justifiant cette
3940 demande. Ceci a pour but d'éviter les suppressions non désirées et de
3941 garder une trace de la raison pour laquelle un paquet a été
3942 supprimé. Par exemple, vous pouvez fournir le nom du paquet qui
3943 remplace celui à supprimer.
3946 Vous ne pouvez demander la suppression d'un paquet que si vous en êtes
3947 le responsable. Si vous voulez supprimer un autre paquet, vous devez
3948 obtenir l'accord de son responsable.
3951 Si vous ne savez pas bien si un paquet peut être supprimé, demandez
3952 l'avis des autres développeurs sur la liste &email-debian-devel;. Le
3953 programme <prgn>apt-cache</prgn> du paquet <package>apt</package>
3954 pourra aussi vous être utile. La commande <tt>apt-cache showpkg
3955 <var>paquet</var> </tt> vous indiquera, entre autres, les paquets qui
3956 dépendent de <var>paquet</var>. Le retrait de paquets orphelins est
3957 discuté sur &email-debian-qa;.
3960 Une fois que le paquet a été supprimé, les bogues du paquet doivent
3961 être gérés. Soit ils sont réattribués à un autre paquet dans le cas où
3962 le code actuel a évolué en un autre paquet (par exemple,
3963 <tt>libfoo12</tt> a été supprimé parce que <tt>libfoo13</tt> le
3964 remplace) ou ils sont fermés si le logiciel ne fait simplement plus
3969 Supprimer des paquets dans <tt>Incoming</tt>
3972 Par le passé, il était possible de supprimer un paquet de
3973 <file>Incoming</file>. Cependant, ce n'est plus possible depuis la
3974 mise en place du nouveau système de file d'attente. Il vous faudra
3975 télécharger une nouvelle version de votre paquet avec un numéro de
3976 version plus élevé que celui que vous voulez remplacer. Les deux
3977 versions seront installées dans l'archive mais seule la plus récente
3978 sera accessible dans <em>unstable</em> car la précédente sera
3979 immédiatement remplacée par la nouvelle. Toutefois, si vous testez
3980 correctement vos paquets, le besoin d'en remplacer un ne devrait pas
3987 Remplacer un paquet ou changer son nom
3990 Si vous vous trompez en nommant un paquet, vous devrez intervenir en
3991 deux étapes pour changer son nom. D'abord, modifiez votre fichier
3992 <file>debian/control</file> pour que votre nouveau paquet remplace et
3993 entre en conflit avec l'ancien paquet que vous voulez remplacer
3994 (reportez-vous à la <url id="&url-debian-policy;" name="charte
3995 Debian"> pour les détails). Une fois que votre paquet est installé
3996 dans l'archive, faites un rapport de bogue concernant le pseudo-paquet
3997 <tt>ftp.debian.org</tt> et demandez la suppression du paquet mal
3998 nommé. N'oubliez pas de réattribuer correctement les bogues du paquet
4002 D'autres fois, vous pouvez commettre une erreur en construisant le
4003 paquet et vous désirez le remplacer. La seule façon de faire est
4004 d'incrémenter le numéro de version et d'envoyer une nouvelle
4005 version. L'ancienne version expirera de la façon habituelle. Notez que
4006 ceci s'applique à chaque partie de votre paquet, y compris les
4007 sources : si vous désirez remplacer l'archive source amont de
4008 votre paquet, vous devez l'envoyer avec un numéro de version
4009 différent. Une possibilité simple est de remplacer
4010 <file>foo_1.00.orig.tar.gz</file> par
4011 <file>foo_1.00+0.orig.tar.gz</file>. Cette restriction donne à chaque
4012 fichier du site ftp un nom unique, ce qui aide à garantir la
4013 consistance dans le réseau des miroirs.
4016 <sect1 id="orphaning">
4018 Abandonner un paquet
4021 Si vous ne pouvez plus maintenir un paquet, vous devez en informer les
4022 autres et faire le nécessaire pour qu'il soit marqué
4023 <em>abandonné</em> (i.e. <em>orphaned</em>). Vous devriez aussi
4024 remplacer votre nom par <tt>Debian QA Group &orphan-address;</tt> dans
4025 le champ <tt>maintainer</tt> du paquet et faire un rapport de bogue
4026 sur le pseudo-paquet <package>wnpp</package>. Le titre de votre
4027 rapport de bogue devrait être
4028 « <tt>O<footnote><p><em>Orphaned</em> :
4029 abandonné.</p></footnote>: <var>paquet</var> — <var>courte
4030 description</var></tt> » pour indiquer que le paquet est
4031 abandonné. La gravité du bogue sera <em>normale</em> ; si le
4032 paquet a une priorité standard ou supérieure, elle devrait être
4033 <em>importante</em>. Si vous le jugez nécessaire, envoyez une copie à
4034 &email-debian-devel; en mettant cette adresse dans le champ
4035 X-Debbugs-CC: de l'en-tête du message. N'utilisez pas le champ CC: car
4036 de cette manière le sujet du message ne contiendra pas le numéro du
4040 Si vous avez simplement l'intention de donner le paquet, mais que vous
4041 pouvez conserver sa maintenance pour le moment, vous devriez à la
4042 place soumettre un rapport de bogue sur <package>wnpp</package> et
4043 l'intituler <tt>RFA: <var>paquet</var> -- <var>description
4044 courte</var></tt>. <tt>RFA</tt> veut dire <em>Request For
4045 Adoption</em> (demande d'adoption).
4048 Vous pouvez trouver plus d'informations sur les <url id="&url-wnpp;"
4049 name="pages web WNPP"><footnote><p><em>Work-needing and prospective
4050 packages</em> : paquets en souffrance et paquets
4051 souhaités.</p></footnote>.
4054 <sect1 id="adopting">
4059 Une liste des paquets en attente de nouveau responsable est disponible
4060 à la page <url id="&url-wnpp;" name="paquets en souffrance et paquets
4061 souhaités">. Si vous voulez prendre en charge un paquet de cette
4062 liste, reportez-vous à la page mentionnée ci-dessus pour connaître la
4066 Prendre un paquet parce qu'il vous semble que celui-ci est négligé
4067 n'est pas correct — ce serait un détournement de
4068 paquet. Vous pouvez prendre contact avec le responsable actuel et lui
4069 demander si vous pouvez prendre en charge ce paquet. Si vous avez le
4070 sentiment qu'un responsable est parti sans prévenir depuis un moment,
4071 veuillez vous reporter à <ref id="mia-qa">).
4074 Généralement, vous ne pouvez pas adopter un paquet sans l'accord du
4075 responsable actuel. Même s'il vous ignore, ce n'est pas une raison
4076 pour le faire. Les plaintes à propos des responsables devraient être
4077 portées sur la liste de diffusion des développeurs. Si la discussion
4078 ne se termine pas par une conclusion positive et que le problème est
4079 de nature technique, envisagez de porter le cas à l'attention du
4080 comité technique (voir la <url id="&url-tech-ctte;" name="page web du
4081 comité technique"> pour plus d'information).
4084 Si vous reprenez un vieux paquet, vous voudrez sûrement que le système
4085 de suivi des bogues indique que vous êtes le responsable du
4086 paquet. Cela se produira automatiquement une fois que vous aurez
4087 installé une nouvelle version du paquet dans l'archive avec le champ
4088 <tt>Maintainer</tt> à jour. Cela peut prendre quelques heures après le
4089 téléchargement. Si vous pensez ne pas avoir de mise à jour à faire
4090 pour un moment, vous pouvez utiliser le <ref id="pkg-tracking-system">
4091 pour recevoir les rapports de bogue. Cependant, assurez-vous que cela
4092 ne pose aucun problème à l'ancien responsable de continuer à recevoir
4093 les bogues durant ce temps.
4102 Debian accepte un nombre croissant d'architectures. Même si vous n'êtes
4103 pas un porteur et même si vous n'utilisez qu'une architecture, il est
4104 de votre responsabilité de développeur d'être attentif aux questions de
4105 portabilité. C'est pourquoi il est important que vous lisiez ce
4106 chapitre même si vous n'êtes pas un porteur.
4109 Porter un paquet consiste à faire un paquet binaire pour des
4110 architectures différentes de celle du paquet binaire fait par le
4111 responsable du paquet. C'est une activité remarquable et
4112 essentielle. En fait, les porteurs sont à l'origine de la plupart des
4113 compilations de paquets Debian. Pour un paquet binaire <em>i386</em>,
4114 par exemple, il faut compter une recompilation pour chaque autre
4115 architecture, soit un total de &number-of-arches; recompilations.
4117 <sect1 id="kind-to-porters">
4119 Être courtois avec les porteurs
4122 Les porteurs ont une tâche remarquable et difficile car ils doivent
4123 gérer un grand nombre de paquets. Idéalement, tout paquet source
4124 devrait compiler sans modification. Malheureusement, c'est rarement le
4125 cas. Cette section contient une liste d'erreurs commises régulièrement
4126 par les responsables Debian — problèmes courants qui bloquent
4127 souvent les porteurs et compliquent inutilement leur travail.
4130 Ici, la première et la plus importante chose est de répondre
4131 rapidement aux rapports de bogues et remarques soulevées par les
4132 porteurs. Traitez-les courtoisement, comme s'ils étaient
4133 co-responsables de vos paquets (ce qu'ils sont d'une certaine
4134 manière). Merci pour votre indulgence envers des rapports de bogue
4135 succincts ou peu clairs ; faites de votre mieux pour éliminer le
4139 Les problèmes les plus couramment rencontrés par les porteurs sont
4140 causés par des erreurs de mise en paquet dans le paquet source. Voici
4141 un pense-bête pour les choses auxquelles vous devez être
4143 <enumlist numeration="arabic">
4146 Vérifiez que les champs <tt>Build-Depends</tt> et
4147 <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file>
4148 sont corrects. Le meilleur moyen de le vérifier est d'utiliser le
4149 paquet <package>debootstrap</package> pour créer un environnement
4150 <em>unstable</em> <em>chrooté</em> (voir <ref
4151 id="debootstrap">). Dans cet environnement <em>chrooté</em>, il
4152 faudra installer le paquet <package>build-essential</package> et
4153 tous les paquets mentionnés dans les champs <tt>Build-Depends</tt>
4154 et <tt>Build-Depends-Indep</tt>. Ensuite, vous essayerez de
4155 fabriquer votre paquet dans cet environnement. Ces étapes peuvent
4156 être automatisées en utilisant le programme <prgn>pbuilder</prgn>
4157 qui est fourni par le paquet de même nom (voir <ref
4161 Si vous n'arrivez pas à installer un environnement
4162 <em>chrooté</em>, <prgn>dpkg-depcheck</prgn> pourra peut-être vous
4163 aider (voir <ref id="dpkg-depcheck">).
4166 Consultez la <url id="&url-debian-policy;" name="charte Debian">
4167 pour en savoir plus sur les dépendances de fabrication.
4172 Ne choisissez pas d'autres valeurs que <em>all</em> ou <em>any</em>
4173 pour le champ architecture sans avoir de bonnes raisons pour le
4174 faire. Trop souvent, les développeurs ne respectent pas les
4175 instructions de la <url id="&url-debian-policy;" name="charte
4176 Debian">. Choisir la valeur « i386 » est la plupart du
4182 Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
4183 <var>paquet</var>.dsc</tt> pour vous assurer que le paquet se
4184 décompresse correctement. En utilisant le résultat de ce test,
4185 construisez votre paquet binaire à l'aide de la commande
4186 <prgn>dpkg-buildpackage</prgn>.
4191 Vérifiez que les fichiers <file>debian/files</file> et
4192 <file>debian/substvars</file> ne sont pas dans votre paquet
4193 source. Ils doivent être effacés par la cible <em>clean</em> de
4194 <file>debian/rules</file>.
4199 Assurez-vous que vous ne vous appuyez pas sur des éléments de
4200 configuration ou des logiciels installés ou modifiés
4201 localement. Par exemple, vous ne devriez jamais appeler des
4202 programmes du répertoire <file>/usr/local/bin</file> ou de
4203 répertoires équivalents. Essayez de ne pas vous appuyer sur des
4204 logiciels configurés de manière spéciale. Essayez de construire
4205 votre paquet sur une autre machine, même s'il s'agit de la même
4211 Ne vous appuyez pas sur une installation préexistante de votre
4212 paquet (un sous-cas de la remarque précédente).
4217 Si possible, ne vous appuyez pas sur une particularité présente
4218 dans un compilateur précis ou dans une certaine version d'un
4219 compilateur. Si vous ne pouvez pas faire autrement, assurez-vous
4220 que les dépendances de fabrication reflètent bien cette
4221 restriction. Dans ce cas, vous cherchez sûrement les problèmes car
4222 quelques architectures pourraient choisir un compilateur différent.
4227 Vérifiez que votre fichier <file>debian/rules</file> distingue les
4228 cibles <em>binary-arch</em> et <em>binary-indep</em> comme l'exige
4229 la charte Debian. Vérifiez que ces cibles sont indépendantes l'une
4230 de l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer
4231 l'une de ces cibles avant d'invoquer l'autre. Pour vérifier cela,
4232 essayez d'exécuter <tt>dpkg-buildpackage -B</tt>.
4238 <sect1 id="porter-guidelines">
4240 Instructions pour les mises à jour des porteurs
4243 Si le paquet se construit tel quel sur l'architecture que vous visez,
4244 vous avez de la chance et votre travail est facile. Cette section
4245 s'applique dans ce cas ; elle décrit comment construire et
4246 installer correctement votre paquet binaire dans l'archive Debian. Si
4247 vous devez modifier le paquet pour le rendre compilable sur votre
4248 architecture cible vous devez faire une mise à jour des sources,
4249 consultez la section <ref id="nmu-guidelines">.
4252 Pour un envoi de portage, ne faites pas de changement dans les
4253 sources. Vous n'avez pas besoin de modifier les fichiers du paquet
4254 source (cela inclut le fichier <file>debian/changelog</file>).
4257 La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la
4258 suivante : <tt>dpkg-buildpackage -B
4259 -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
4260 <var>adresse-porteur</var> par votre adresse électronique. Cette
4261 commande construira les parties du paquet qui dépendent de
4262 l'architecture, en utilisant la cible <em>binary-arch</em> de
4263 <file>debian/rules</file>.
4266 Si vous travaillez sur une machine Debian pour vos efforts de portage
4267 et que vous devez signer votre envoi localement pour son acceptation
4268 dans l'archive, vous pouvez exécuter <prgn>debsign</prgn> sur votre
4269 fichier <file>.changes</file> pour qu'il soit signé de manière commode
4270 ou utilisez le mode de signature à distance de <prgn>dpkg-sig</prgn>.
4272 <sect2 id="binary-only-nmu">
4274 Mises à jour indépendantes binaires ou recompilations
4277 Parfois, l'envoi du portage initial pose problème car l'environnement
4278 dans lequel le paquet a été construit n'était pas bon (bibliothèques
4279 plus à jour ou obsolètes, mauvais compilateur, etc.). Il se peut que
4280 vous ayez à le recompiler dans un environnement mis à
4281 jour. Cependant, dans ce cas, vous devez changer le numéro de version
4282 pour que les mauvais anciens paquets soient remplacés dans l'archive
4283 Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
4284 s'ils n'ont pas un numéro de version supérieur à celui actuellement
4288 Vous devez vous assurer que votre mise à jour indépendante binaire ne
4289 rend pas le paquet non installable. Cela peut arriver si un paquet
4290 source génère des paquets dépendants et indépendants de
4291 l'architecture qui dépendent les uns des autres <em>via</em>
4295 Malgré les modifications nécessaires du changelog, ce type de mise à
4296 jour reste une mise à jour indépendante binaire — il n'est
4297 pas nécessaire de reconsidérer le statut des paquets binaires des
4298 autres architectures pour les marquer périmés ou à recompiler.
4301 Ces recompilations nécessitent des numéros de version
4302 « magiques » pour que le système de maintenance de
4303 l'archive comprenne que, bien qu'il y ait une nouvelle version, il
4304 n'y a pas eu de modification des sources. Si vous ne faites pas cela
4305 correctement, les administrateurs de l'archive rejetteront votre mise
4306 à jour (car il n'y aura pas de code source associé).
4309 La « magie » d'une mise à jour indépendante par
4310 recompilation uniquement est déclenchée par l'utilisation d'un
4311 suffixe ajouté au numéro de version du paquet de la forme
4312 b<numéro>. Par exemple, si la dernière version que vous avez
4313 recompilée était la version 2.9.3, votre mise à jour indépendante
4314 aura le numéro de version 2.9-3+b1. Si la dernière version était
4315 3.4+b1 (i.e. un paquet natif avec une précédente mise à jour
4316 indépendante par recompilation), votre mise à jour indépendant aura
4317 le numéro de version 3.4+b2. <footnote><p>Par le passé, de telles
4318 mises à jour indépendantes utilisaient le numéro de troisième niveau
4319 de la partie Debian de la révision pour dénoter l'état de
4320 recompilation uniquement ; cependant, cette syntaxe était
4321 ambigüe pour les paquets natifs et ne permettait pas un ordre correct
4322 des mises à jour indépendantes par recompilation uniquement, des
4323 mises à jour indépendantes de source et des mises à jour
4324 indépendantes de sécurité sur le même paquet et elle a donc été
4325 abandonnée en faveur de cette nouvelle syntaxe.</p></footnote>
4328 De manière similaire aux envois du porteur initial, la façon correcte
4329 d'invoquer <prgn>dpkg-buildpackage</prgn> est <tt>dpkg-buildpackage
4330 -B</tt> pour ne construire que les parties dépendant de
4331 l'architecture du paquet.
4334 <sect2 id="source-nmu-when-porter">
4336 Quand faire une mise à jour indépendante source pour un
4340 Les porteurs qui font des mises à jour indépendantes sources suivent
4341 généralement les instructions de la section <ref id="nmu"> tout comme
4342 les non-porteurs. Les délais d'attente sont cependant plus courts car
4343 les porteurs doivent manipuler un grand nombre de paquets. À nouveau,
4344 la situation diffère selon la distribution visée. Elle varie
4345 également selon que l'architecture est candidate pour inclusion dans
4346 la prochaine version stable ; les responsables de diffusion
4347 décident et annoncent quelles architectures sont candidates.
4350 Si vous êtes porteur et faites une mise à jour pour
4351 <em>unstable</em>, les instructions précédentes sont applicables à
4352 deux différences près. Tout d'abord, le temps d'attente raisonnable
4353 — délai entre le moment où vous envoyez un rapport au
4354 système de suivi des bogues et le moment où vous pouvez faire une
4355 mise à jour indépendante <em>(NMU)</em> — est de sept
4356 jours. Ce délai peut être raccourci si le problème est crucial et met
4357 l'effort de portage en difficulté : c'est à la discrétion de l'équipe
4358 de portage. (Souvenez-vous, il ne s'agit pas d'un règlement, mais de
4359 recommandations communément acceptées). Pour les envois de
4360 <em>stable</em> ou <em>testing</em>, veuillez tout d'abord vous
4361 coordonner avec l'équipe de diffusion appropriée.
4364 Deuxième différence, les porteurs qui font des mises à jour
4365 indépendantes sources doivent choisir une gravité <em>sérieuse</em>
4366 (i.e. <em>serious</em>) ou supérieure quand ils envoient leur rapport
4367 au système de suivi des bogues. Ceci assure qu'un paquet source
4368 unique permet de produire un paquet binaire pour chaque architecture
4369 supportée au moment de la sortie de la distribution. Il est très
4370 important d'avoir un paquet source et un paquet binaire pour toutes
4371 les architectures pour être conforme à plusieurs licences.
4374 Les porteurs doivent éviter d'implémenter des contournements pour des
4375 bogues de l'environnement de compilation, du noyau ou de la
4376 libc. Quelques fois, ces contournements sont inévitables. Si vous
4377 devez faire quelque chose de ce genre, marquez proprement vos
4378 modifications avec des <tt>#ifdef</tt> et documentez votre
4379 contournement pour que l'on sache le retirer une fois que le problème
4383 Les porteurs peuvent aussi avoir une adresse où ils publient le
4384 résultat de leur travail pendant le délai d'attente. Ainsi, d'autres
4385 personnes peuvent bénéficier du travail du porteur même pendant ce
4386 délai. Bien sûr, ces adresses n'ont rien d'officiel, alors soyez sur
4387 vos gardes si vous les utilisez.
4391 <sect1 id="porter-automation">
4393 Infrastructure de portage et automatisation
4396 Il existe une infrastructure et plusieurs outils pour faciliter
4397 l'automatisation du portage des paquets. Cette section contient un
4398 bref aperçu de cette automatisation et du portage de ces outils ;
4399 veuillez vous reporter à la documentation des paquets ou les
4400 références pour une information complète.
4404 Listes de diffusion et pages web
4407 Les pages web contenant l'état de chaque portage peuvent être
4408 trouvées à <url id="&url-debian-ports;">.
4411 Chaque portage de Debian possède sa propre liste de diffusion. La
4412 liste des listes de diffusion de portage peut être trouvée à <url
4413 id="&url-debian-port-lists;">. Ces listes sont utilisées pour
4414 coordonner les porteurs et pour mettre en relation les utilisateurs
4415 d'un portage donné avec les porteurs.
4420 Outils pour les porteurs
4423 Les descriptions de plusieurs outils de portage peuvent être trouvées
4424 dans les <ref id="tools-porting">.
4429 <package>buildd</package>
4432 Le système <package>buildd</package> est un système distribué pour la
4433 compilation d'une distribution. Il est habituellement utilisé en
4434 conjonction avec des automates de compilation ; ce sont des
4435 machines « esclaves » qui récupèrent des paquets sources et
4436 tentent de les compiler. Il est aussi possible d'interagir par
4437 courrier électronique avec ce système. Cette interface est utilisée
4438 par les porteurs pour récupérer un paquet source (en général, un
4439 paquet qui ne peut être compilé automatiquement) et travailler
4443 <package>buildd</package> n'est pas disponible sous forme de
4444 paquet ; pourtant, la plupart des équipes de porteurs
4445 l'utilisent aujourd'hui ou ont prévu de l'utiliser bientôt. L'outil
4446 de construction automatisé réel est dans le paquet
4447 <package>sbuild</package>, voir la description dans <ref
4448 id="sbuild">. Le système <package>buildd</package> regroupe également
4449 un ensemble de composants très utiles, continuellement utilisés, mais
4450 non encore mis en paquet, tels que <prgn>andrea</prgn> et
4451 <prgn>wanna-build</prgn>.
4454 Une partie des informations produites par <package>buildd</package>
4455 — utiles pour les porteurs — est disponible sur
4456 la toile à l'adresse <url id="&url-buildd;">. Ces informations
4457 incluent les résultats produits toutes les nuits par
4458 <prgn>andrea</prgn> (dépendances des sources) et
4459 <prgn>quinn-diff</prgn> (paquets à recompiler).
4462 Nous sommes très fiers de ce système car il a de nombreux usages
4463 potentiels. Des groupes de développeurs indépendants peuvent utiliser
4464 ce système pour créer différentes saveurs de Debian — qui
4465 peuvent être ou ne pas être intéressantes pour tous (par exemple, une
4466 version de Debian compilée avec des vérifications relatives à
4467 <prgn>gcc</prgn>). Ce système nous permettra aussi de recompiler
4468 rapidement toute une distribution.
4471 Les administrateurs des buildds pour chaque architecture peuvent être
4472 contactés à l'adresse électronique $arch@buildd.debian.org.
4476 <sect1 id="packages-arch-specific">
4478 Quand votre paquet <em>n'est pas</em> portable
4481 Certains paquets ont encore des problèmes pour être construits et/ou
4482 pour fonctionner sur certaines des architectures prises en charge par
4483 Debian et ne peuvent pas du tout être portés, ou pas dans un laps de
4484 temps raisonnable. Un exemple est un paquet qui est spécifique SGVA
4485 (i386 seulement) ou qui utilise des fonctionnalités spécifiques au
4486 matériel qui ne sont pas gérées sur toutes les architectures.
4489 Pour éviter que des paquets cassés soient envoyés dans l'archive et
4490 qu'ils fassent perdre du temps des buildd, vous devez faire plusieurs
4497 Tout d'abord, assurez-vous que votre paquet <em>échoue</em> à la
4498 compilation sur les architectures qu'il ne gère pas. Il y a
4499 plusieurs moyens de faire cela. Le moyen préféré est d'avoir une
4500 petite suite de tests pendant la construction qui testera la
4501 fonctionnalité et qui échouera si cela ne fonctionne pas. C'est de
4502 toute façon une bonne idée et empêchera des (certains) envois
4503 cassés pour toutes les architectures, et cela permettra également
4504 au paquet d'être construit dès que la fonctionnalité nécessaire est
4508 De plus, si vous croyez que la liste des architectures gérées est
4509 plutôt constante, vous devriez changer « any » en une
4510 liste des architectures gérées dans le fichier
4511 <file>debian/control</file>. Ainsi, la construction échouera
4512 également et l'indiquera à un lecteur humain sans vraiment essayer.
4517 Pour empêcher les compilateurs automatiques de tenter sans raison
4518 de construire votre paquet, il doit être inclus dans
4519 <file>packages-arch-specific</file>, une liste utilisée par le
4520 script <prgn>wanna-build</prgn>. La version actuelle est disponible
4522 id="http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak"> ;
4523 veuillez consulter le début du fichier pour savoir qui contacter
4530 Veuillez noter qu'il est insuffisant de simplement ajouter votre
4531 paquet à Packages-arch-specific sans le faire également échouer lors
4532 de compilation sur les architectures non gérées : un porteur ou
4533 toute autre personne essayant de construire votre paquet peut
4534 accidentellement l'envoyer sans remarquer qu'il ne fonctionne pas. Si
4535 dans le passé, certains paquets binaires ont été envoyés pour des
4536 architectures non gérées, demandez leur suppression en remplissant un
4537 bogue sur <package>ftp.debian.org</package>.
4543 Mise à jour indépendante
4546 Dans certaines circonstances, il est nécessaire qu'une personne autre
4547 que le responsable d'un paquet fasse une mise à jour de ce paquet. Ce
4548 type de mise à jour est désigné en anglais par l'expression
4549 <em>non-maintainer upload (NMU)</em>. Dans le présent document, nous
4550 traduisons librement cette expression par « mise à jour
4551 indépendante ».
4554 Cette section ne traite que des mises à jour indépendantes de source,
4555 c.-à-d., les mises à jour qui envoient une nouvelle version d'un
4556 paquet. Pour les mises à jour indépendantes par des porteurs ou des
4557 membres de la QA, veuillez consulter <ref id="binary-only-nmu">. Si un
4558 buildd construit et envoie un paquet, cela est également à strictement
4559 parler une NMU binaire. Veuillez consulter <ref id="buildd"> pour plus
4563 La raison principale pour laquelle une mise à jour indépendante est
4564 réalisée est quand un développeur a besoin de corriger des paquets d'un
4565 autre développeur pour résoudre des problèmes sérieux ou des bogues
4566 paralysants ou quand le responsable d'un paquet ne peut pas fournir une
4567 correction dans un délai raisonnable.
4570 Tout d'abord, il est capital que ces mises à jour indépendantes soient
4571 aussi peu intrusives que possible. Ne faites pas de ménage, ne modifiez
4572 pas le nom des modules ou des fichiers, ne déplacez pas les
4573 répertoires ; plus généralement, ne corrigez pas ce qui n'est pas
4574 cassé. Faites un correctif aussi petit que possible. Si certaines
4575 choses froissent votre sens de l'esthétique, parlez-en au responsable
4576 du paquet, au responsable amont ou soumettez un rapport de
4577 bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
4578 pas</em> être effectués lors d'une mise à jour indépendante.
4581 Et souvenez-vous du Serment d'Hippocrate « Par dessus tout,
4582 ne pas faire de mal ». Il est préférable de laisser un paquet avec
4583 un bogue ouvert grave plutôt qu'appliquer un correctif non fonctionnel
4584 ou un correctif qui cache le bogue sans le résoudre.
4586 <sect1 id="nmu-guidelines">
4588 Comment faire une mise à jour indépendante ?
4591 Les mises à jour indépendantes qui corrigent des bogues de gravité
4592 importante, sérieuse et plus élevée sont encouragées et
4593 acceptées. Vous devriez vous efforcer de contacter le responsable
4594 actuel du paquet : il est peut-être sur le point d'envoyer un
4595 correctif pour le problème ou il a peut-être une meilleure solution.
4598 Les mises à jour indépendantes doivent être réalisées pour assister un
4599 responsable de paquet à résoudre des bogues. Les responsables
4600 devraient être reconnaissants pour cette aide et les personnes faisant
4601 la mise à jour indépendante devraient respecter les décisions du
4602 responsable et tenter d'aider personnellement le responsable dans son
4606 Une mise à jour indépendante devrait suivre toutes les conventions
4607 décrites dans cette section. Pour un envoi vers <em>testing</em> ou
4608 <em>unstable</em>, l'ordre suivant des étapes est recommandé :
4614 Vérifiez que les bogues du paquet qui devraient être corrigés par
4615 la mise à jour indépendante sont bien référencés dans le système de
4616 suivi des bogues. S'ils n'y sont pas, faites des rapports de bogue
4622 Attendez la réponse du responsable quelques jours. Si vous
4623 n'obtenez aucune réponse, vous pouvez l'aider en lui envoyant le
4624 correctif qui corrige le bogue. N'oubliez pas de marquer le bogue
4625 avec le mot-clé « patch ».
4630 Patientez quelques jours. Si vous n'avez toujours aucune réponse du
4631 responsable, envoyez-lui un courrier annonçant votre intention
4632 d'effectuer une mise à jour indépendante du paquet. Préparez la NMU
4633 comme décrit dans cette section et testez-la soigneusement sur
4634 votre machine (cf. <ref id="sanitycheck">). Re-vérifiez que votre
4635 correctif n'a aucun effet de bord inattendu. Assurez-vous que votre
4636 correctif est aussi minimaliste et non intrusif que possible.
4641 Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file>
4642 (cf. <ref id="delayed-incoming">), envoyez le correctif final au
4643 responsable par le BTS et expliquez-lui qu'il a 7 jours pour réagir
4644 s'il veut annuler la NMU.
4649 Suivez ce qui se passe, vous êtes responsable pour tout bogue que
4650 vous auriez introduit avec votre NMU. Vous devriez probablement
4651 utiliser le <ref id="pkg-tracking-system"> (PTS) pour vous tenir
4652 informé de l'état du paquet après votre NMU.
4658 Parfois, le responsable de version ou un groupe organisé de
4659 développeurs peut annoncer une certaine période de temps au cours de
4660 laquelle les règles de mise à jour indépendante seront plus
4661 souples. Ceci implique habituellement une période plus courte
4662 d'attente avant d'envoyer des correctifs et une période de délai plus
4663 courte. Il est important de noter que, même au cours de ces
4664 « chasses aux bogues », la personne désirant faire la mise à
4665 jour indépendante doit remplir des bogues et contacter en premier le
4666 développeur, et ensuite seulement passer à l'action. Veuillez vous
4667 reporter à <ref id="qa-bsp"> pour des détails.
4670 Pour la distribution <em>testing</em>, les règles peuvent être
4671 changées par les responsables de diffusion. Veuillez porter une
4672 attention spéciale au fait que le moyen habituel pour un paquet
4673 d'entrer dans <em>testing</em> est de passer par <em>unstable</em>.
4676 Pour la distribution <em>stable</em>, veuillez y apporter une
4677 attention supplémentaire. Bien sûr, les responsables de publication
4678 peuvent également modifier les règles ici. Veuillez vérifier avant
4679 votre envoi que tous vos changements sont acceptables pour inclusion
4680 dans la prochaine version stable par le responsable de publication.
4683 Quand un bogue de sécurité est détecté, l'équipe de sécurité peut
4684 effectuer une mise à jour indépendante en utilisant ses propres
4685 règles. Veuillez vous référer à <ref id="bug-security"> pour plus
4689 Pour les différences concernant les mises à jour indépendantes par les
4690 porteurs, veuillez voir <ref id="source-nmu-when-porter">.
4693 Bien sûr, il est toujours possible de s'accorder avec un responsable
4694 pour des règles spéciales (comme quand le responsable demande
4695 « merci d'envoyer le correctif directement pour moi et pas de
4696 diff nécessaire »).
4699 <sect1 id="nmu-version">
4701 Numéro de version pour les mises à jour indépendantes
4704 Chaque fois que vous modifiez un paquet, le numéro de version de ce
4705 paquet doit changer, même pour la plus triviale des
4706 modifications. Notre système de gestion de paquets s'appuie sur ces
4710 Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez
4711 ajouter un numéro de version mineur à la partie
4712 <var>révision-debian</var> du numéro de version (la partie qui suit le
4713 dernier trait d'union). Ce numéro supplémentaire débutera à
4714 « 1 ». Prenons pour exemple le paquet « foo » qui
4715 porte le numéro de version 1.1-3. Dans l'archive, le fichier de
4716 contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
4717 version amont est « 1.1 » et la révision Debian est
4718 « 3 ». La mise à jour indépendante suivante ajouterait le
4719 numéro de version mineur « .1 » au numéro de révision
4720 Debian ; le nouveau fichier de contrôle du paquet source serait
4721 alors <file>foo_1.1-3.1.dsc</file>.
4724 Le numéro de révision mineur est nécessaire pour éviter de prendre un
4725 numéro de version au responsable officiel du paquet, ce qui pourrait
4726 perturber son travail. Cela a aussi l'avantage de montrer clairement
4727 que le paquet n'a pas été livré par le responsable officiel.
4730 S'il n'y a pas de partie <var>révision-debian</var> dans le numéro de
4731 version du paquet, il faut en créer une en démarrant à
4732 « 0.1 ». S'il est absolument nécessaire qu'une personne qui
4733 n'est pas responsable d'un paquet fasse une livraison basée sur une
4734 nouvelle version amont, cette personne doit choisir « 0.1 »
4735 comme numéro de révision Debian. Le responsable du paquet doit, lui,
4736 démarrer sa numérotation à « 1 ».
4739 Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>,
4740 vous devrez parfois créer une branche (« fork ») dans
4741 l'arbre de numéro des version. Pour cela, vous pouvez utiliser des
4742 numéros de version comme 1.1-3sarge0.1.
4745 <sect1 id="nmu-changelog">
4747 Les mises à jour indépendantes sources doivent être mentionnées dans
4748 le fichier changelog
4751 Une personne qui fait une mise à jour indépendante source doit ajouter
4752 une entrée dans le fichier <file>changelog</file> qui indique les
4753 bogues corrigés et qui précise pourquoi cette mise à jour était
4754 nécessaire. Cette entrée comportera l'adresse de la personne ayant
4755 fait la mise à jour ainsi que la version livrée.
4758 Par convention, dans le cas d'une mise à jour indépendante source
4759 <em>(NMU)</em>, l'entrée du fichier changelog débute par la
4762 * Non-maintainer upload
4766 <sect1 id="nmu-patch">
4768 Mise à jour indépendante source et système de suivi des bogues
4771 Un développeur qui n'est pas responsable d'un paquet doit faire aussi
4772 peu de modifications que possible et doit toujours envoyer ses
4773 modifications au système de suivi des bogues au format diff unifié
4777 Et si vous recompilez simplement le paquet ? Si vous avez
4778 simplement besoin de recompiler le paquet pour une seule architecture,
4779 vous pouvez faire une NMU binaire seulement comme décrit dans <ref
4780 id="binary-only-nmu"> qui ne nécessite pas qu'un correctif soit
4781 envoyé. Si vous désirez que le paquet soit recompilé pour toutes les
4782 architectures, vous devez alors faire une NMU source et vous devrez
4783 envoyer un correctif.
4786 Si la mise à jour indépendante source (<em>source NMU</em>) corrige
4787 des bogues, ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans
4788 le système de suivi des bogues plutôt que clos. Par convention, seul
4789 le responsable du paquet et la personne qui a ouvert le rapport de
4790 bogue ferment les rapports. Heureusement, le système d'archivage
4791 Debian reconnaît les mises à jours indépendantes et positionne
4792 correctement le statut des bogues à <em>fixed</em> si la personne qui
4793 fait la mise à jour a listé tous les bogues dans le fichier changelog
4794 en utilisant la syntaxe <tt>Closes: bug#<var>nnnnn</var></tt> (voir
4795 <ref id="upload-bugfix"> pour en savoir plus sur la fermeture de bogue
4796 par le fichier <file>changelog</file>). Ce passage au statut
4797 <em>fixed</em> assure que chacun sait que le bogue est corrigé par une
4798 mise à jour indépendante tout en laissant le rapport de bogue ouvert
4799 jusqu'à ce que le responsable du paquet incorpore les modifications de
4800 cette mise à jour dans la version officielle du paquet.
4803 Après avoir fait une mise à jour indépendante, il vous faudra aussi
4804 envoyer cette information aux bogues existants que vous avez corrigés
4805 par votre NMU en incluant le diff unifié. Sinon, vous pouvez créer un
4806 nouveau rapport de bogue et inclure un correctif comprenant toutes les
4807 modifications que vous avez réalisées. Le responsable officiel pourra
4808 choisir d'appliquer le correctif, il pourra aussi employer une autre
4809 méthode pour régler le problème. Certains bogues sont corrigés dans la
4810 version amont, ce qui est une bonne raison pour annuler les
4811 modifications d'une mise à jour indépendante. Si le responsable
4812 choisit de mettre à jour le paquet plutôt que d'utiliser les
4813 correctifs de la mise à jour indépendante, il devra s'assurer que
4814 cette nouvelle version corrige effectivement chacun des bogues
4815 corrigés dans la mise à jour indépendante.
4818 De plus, le responsable officiel devrait <em>toujours</em> conserver
4819 les entrées documentant une mise à jour indépendante dans le fichier
4820 <file>changelog</file> — et bien sûr, également conserver les
4821 modifications. Si vous annulez certaines des modifications, veuillez
4822 réouvrir les rapports de bogue correspondants.
4825 <sect1 id="nmu-build">
4827 Fabriquer une mise à jour indépendante source
4830 Les paquets faisant l'objet d'une mise à jour indépendante source sont
4831 construits comme les autres. Sélectionnez une distribution en
4832 utilisant les règles décrites dans la section <ref id="distribution">
4833 en suivant toutes les prescriptions de la section <ref id="upload">.
4836 Vérifiez que vous n'avez pas modifié la valeur du champ
4837 <tt>maintainer</tt> dans le fichier <file>debian/control</file>. Votre
4838 nom, mentionné dans l'entrée du fichier <file>debian/changelog</file>
4839 concernant la mise à jour, sera utilisé pour signer le fichier
4840 <file>.changes</file>.
4843 <sect1 id="ack-nmu">
4845 Valider une mise à jour indépendante
4848 Si l'un de vos paquets a subi une mise à jour indépendante, vous devez
4849 récupérer les changements dans votre copie des sources. Ceci est aisé,
4850 vous avez simplement à appliquer le correctif qui vous a été
4851 envoyé. Une fois ceci fait, vous devez fermer les bogues qui ont été
4852 marqués comme fixés par la mise à jour. Le moyen le plus simple est
4853 d'utiliser l'option <tt>-v</tt> de <prgn>dpkg-buildpackage</prgn> car
4854 cela vous permet d'inclure tous les changements depuis votre dernier
4855 envoi de responsable. Sinon, vous pouvez soit les fermer manuellement
4856 en envoyant les courriers nécessaires au BTS soit ajouter les
4857 <tt>closes: #nnnn</tt> nécessaires dans l'entrée du changelog de votre
4861 Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une
4862 NMU n'est pas une attaque personnelle contre le responsable. C'est une
4863 preuve que le paquet est important pour quelqu'un et qu'il est
4864 désireux de vous aider dans votre travail, vous devriez donc lui être
4865 reconnaissant. Vous pouvez également lui demander s'il serait
4866 intéressé pour vous aider sur une base plus régulière comme
4867 co-responsable ou responsable de secours (cf. <ref
4868 id="collaborative-maint">).
4871 <sect1 id="nmu-vs-qa">
4873 Mise à jour indépendante ou envoi de QA ?
4876 Sauf si vous savez que le responsable est toujours actif, il est sage
4877 de vérifier le paquet pour voir s'il n'a pas été abandonné. La liste
4878 actuelle des paquets orphelins pour lesquels le champ responsable n'a
4879 pas été positionné correctement est disponible à <url
4880 id="&url-debian-qa-orphaned;">. Si vous effectuez une mise à jour
4881 indépendante sur un paquet incorrectement orphelin, veuillez
4882 positionner le responsable à « Debian QA Group
4883 <packages@qa.debian.org> ». Dans ce cas, les bogues du
4884 paquet sont fermés et pas simplement marqués comme corrigés.
4887 <sect1 id="nmu-who">
4889 Qui peut faire une mise à jour indépendante ?
4892 Seuls les responsables Debian officiels peuvent faire des mises à jour
4893 indépendantes binaire ou source. Un responsable officiel est une
4894 personne dont la clé est dans le porte-clés Debian. Tout autre
4895 personne est toutefois invitée à télécharger les paquets sources pour
4896 corriger des bogues ; au lieu de faire des mises à jour
4897 indépendantes, ils pourront soumettre les correctifs qui le méritent
4898 au système de suivi des bogues. Les responsables apprécient presque
4899 toujours les correctifs et les rapports de bogue soignés.
4902 <sect1 id="nmu-katie">
4904 Comment dak détecte les mises à jour indépendantes
4907 Le fait qu'un envoi soit traité par les scripts d'archive et par le
4908 système de suivi des bogues (voir <ref id="nmu-patch">) comme une mise
4909 à jour indépendante ou comme un envoi par le responsable <em>n'est
4910 pas</em> décidé en regardant le numéro de version (voir <ref
4911 id="nmu-version">). Au lieu de cela, un envoi est géré comme une mise
4912 à jour indépendante si l'adresse du responsable dans le fichier
4913 <tt>.changes</tt> n'est pas la même binairement que l'adresse du champ
4914 <tt>Maintainer</tt> ou que l'une des adresses du champ
4915 <tt>Uploaders</tt> du fichier <tt>dsc</tt> et également si l'adresse
4916 du responsable n'est pas spéciale (c.-à-d. elle n'est pas positionnée
4917 à l'adresse du groupe d'Assurance Qualité).
4920 <sect1 id="nmu-terms">
4925 Deux nouvelles expressions sont introduites dans cette section :
4926 « mise à jour indépendante source » et « mise à jour
4927 indépendante binaire ». Ces deux expressions ont une
4928 signification technique précise dans ce document. Elles correspondent
4929 toutes deux au même type d'activité ; elles impliquent toutes
4930 deux qu'une personne fait une mise à jour d'un paquet alors qu'elle
4931 n'est pas officiellement responsable de ce paquet. C'est pourquoi nous
4932 qualifions ces mises à jours
4933 d'<em>indépendantes</em><footnote><p>Contrairement à ce que pourrait
4934 laisser entendre cette traduction de <em>non-maintainer upload</em>,
4935 il n'est pas question d'agir sans prévenir le responsable au préalable
4936 (voir <ref id="nmu-guidelines">).</p></footnote>.
4939 Une mise à jour indépendante source est une livraison de paquet faite
4940 par une personne qui n'est pas le responsable officiel de ce paquet
4941 avec pour objectif de corriger un bogue dans le paquet. Une mise à
4942 jour indépendante source implique toujours une modification des
4943 sources du paquet, même s'il ne s'agit que d'un changement dans le
4944 fichier <file>debian/changelog</file>. Ce changement peut tout aussi
4945 bien concerner la partie amont du source que la partie spécifique à
4946 Debian. Une mise à jour indépendante source peut aussi inclure des
4947 paquets spécifiques à une architecture tout comme un fichier
4948 <em>diff</em> modifié.
4951 Une mise à jour indépendante binaire est constituée par la
4952 recompilation et l'archivage d'un paquet pour une architecture
4953 donnée. Il s'agit souvent du résultat d'un effort de portage. Une mise
4954 à jour indépendante binaire est la livraison d'un paquet compilé
4955 (souvent pour une autre architecture) à condition que cette
4956 compilation n'ait pas nécessité de modifications des sources. Dans de
4957 nombreux cas, les porteurs sont obligés de modifier les sources pour
4958 les rendre compilables sur leur architecture cible ; il s'agira
4959 alors d'une mise à jour indépendante source et non d'une mise à jour
4960 indépendante binaire. Comme vous pouvez le remarquer, nous ne faisons
4961 pas de distinction entre les mises à jour indépendantes faites par des
4962 porteurs et les autres mises à jour indépendantes.
4965 Les mises à jour indépendantes sources et binaires sont toutes deux
4966 couvertes par l'expression « mise à jour indépendante »
4967 (NMU<footnote><p>Non-maintainer upload</p></footnote>). Pourtant, cela
4968 conduit souvent à des confusions car beaucoup associent « mise à
4969 jour indépendante » et « mise à jour indépendante
4970 source ». Il faut donc rester vigilant : utilisez toujours
4971 « mise à jour indépendante binaire » ou «NMU binaire »
4972 pour les mises à jour indépendantes de binaires seuls.
4976 <sect id="collaborative-maint">
4978 Maintenance collective
4981 « Maintenance collective » est un terme décrivant le partage
4982 des devoirs de la maintenance d'un paquet Debian par plusieurs
4983 personnes. Cette collaboration est presque toujours une bonne idée car
4984 il en résulte généralement une meilleure qualité et un temps de
4985 correction de bogues plus petit. Il est fortement recommandé que les
4986 paquets de priorité <tt>Standard</tt> ou qui font partie de la base
4987 aient des co-responsables.
4990 Habituellement, il y a un responsable principal et un ou plusieurs
4991 co-responsables. Le responsable principal est la personne dont le nom
4992 est indiqué dans le champ <tt>Maintainer</tt> du fichier
4993 <file>debian/control</file>. Les co-responsables sont tous les autres
4997 Dans sa forme la plus simple, ajouter un nouveau co-responsable est
5002 Donner au co-responsable un accès aux sources à partir desquelles
5003 vous construisez le paquet. Habituellement, cela implique que vous
5004 utilisiez un système de contrôle de version comme <prgn>CVS</prgn>
5005 ou <prgn>Subversion</prgn>.
5010 Ajouter les nom et adresse correctes du co-responsable au champ
5011 <tt>Uploaders</tt> dans la partie globale du fichier
5012 <file>debian/control</file>.
5014 Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
5020 En utilisant le PTS (<ref id="pkg-tracking-system">), les
5021 co-responsables devraient s'inscrire eux-mêmes aux paquets sources
5028 La maintenance collective peut souvent être facilitée par l'utilisation
5029 d'outils sur Alioth (voir <ref id="alioth">).
5034 La distribution <em>testing</em>
5038 <sect1 id="testing-basics">
5043 Les paquets sont habituellement installés dans la distribution
5044 <em>testing</em> après avoir atteint un certain degré de test dans
5048 Ils doivent être en synchronisation pour toutes les architectures et
5049 ne doivent pas avoir de dépendances qui les rendraient non
5050 installables ; ils doivent également n'avoir aucun bogue bloquant
5051 l'inclusion du paquet dans une version stable
5052 (« release-critical ») au moment où ils sont installés dans
5053 <em>testing</em>. Ainsi, <em>testing</em> devrait toujours être prête
5054 pour être une version candidate stable. Veuillez voir ci-dessous pour
5058 <sect1 id="testing-unstable">
5060 Mises à jour depuis <em>unstable</em>
5063 Les scripts qui mettent à jour la distribution <em>testing</em> sont
5064 exécutés chaque jour après l'installation des paquets mis à
5065 jour ; ces scripts sont appelés <em>britney</em>. Ils fabriquent
5066 les fichiers <file>Packages</file> pour la distribution
5067 <em>testing</em>, mais ils le font d'une manière intelligente pour
5068 éviter toute incohérence et essayer de n'utiliser que des paquets sans
5072 L'inclusion d'un paquet d'<em>unstable</em> est soumise aux conditions
5077 Le paquet doit avoir été disponible dans <em>unstable</em> depuis
5078 2, 5 ou 10 jours selon le champ d'urgence de l'envoi (élevée,
5079 moyenne ou basse). Veuillez noter que cette urgence est
5080 « collante » (« sticky »), ce qui veut dire que
5081 l'envoi avec l'urgence la plus élevée depuis la précédente
5082 transition dans <em>testing</em> est prise en compte. Ces délais
5083 peuvent être doublés lors d'un gel de distribution, ou les
5084 transitions dans <em>testing</em> peuvent être complètement
5090 Il doit avoir autant ou moins de bogues empêchant l'intégration
5091 dans la distribution que la version actuellement disponible dans
5092 <em>testing</em> ;
5097 Il doit être disponible pour toutes les architectures pour
5098 lesquelles il a été auparavant construit. <ref id="madison"> peut
5099 être intéressant pour vérifier cette information ;
5104 Il ne doit pas casser les dépendances d'un paquet qui est déjà
5105 disponible dans <em>testing</em> ;
5110 Les paquets dont il dépend doivent soit être déjà disponibles dans
5111 <em>testing</em> soit être acceptés dans <em>testing</em> au même
5112 moment (et ils doivent remplir tous les critères nécessaires).
5118 Pour savoir si un paquet a progressé ou non dans <em>testing</em>,
5119 veuillez voir la sortie du script de <em>testing</em> sur la <url
5120 id="&url-testing-maint;" name="page web de la distribution testing">
5121 ou utilisez le programme <prgn>grep-excuses</prgn> inclus dans le
5122 paquet <package>devscripts</package>. Si vous voulez rester informé de
5123 la progression de vos paquets dans <em>testing</em>, vous pouvez
5124 facilement le mettre dans la <manref section="5" name="crontab">.
5127 Le fichier <file>update_excuses</file> ne donne pas toujours la raison
5128 précise pour laquelle un paquet est refusé ; on peut avoir à la
5129 chercher soi-même en regardant ce qui serait cassé avec l'inclusion du
5130 paquet. La <url id="&url-testing-maint;" name="page web de la
5131 distribution testing"> donne plus d'informations à propos des
5132 problèmes courants qui peuvent occasionner cela.
5135 Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce
5136 que le jeu des inter-relations est trop compliqué et ne peut être
5137 résolu par le script. Voir ci-dessous pour des détails.
5140 Des analyses de dépendances plus avancées sont présentées sur <url
5141 id="http://bjorn.haxx.se/debian/"> — mais, attention, cette page
5142 affiche également les dépendances de construction qui ne sont pas
5143 considérées par britney.
5145 <sect2 id="outdated">
5150 Pour le script de migration dans <em>testing</em>,
5151 « désynchronisé » (<em>outdated</em> veut dire ceci :
5152 il y a différentes versions dans <em>unstable</em> pour les
5153 architectures de version (à l'exception des architectures dans
5154 fuckedarches ; fuckedarches est une liste des architectures qui
5155 ne suivent pas le rythme (dans update_out.py), mais actuellement
5156 cette liste est vide). « Désynchronisé » n'a rien à voir
5157 avec les architectures que le paquet fournit pour <em>testing</em>.
5160 Considérons cet exemple :
5165 ---------+-------+----
5171 Le paquet est désynchronisé pour alpha dans <em>unstable</em> et
5172 n'entrera pas dans <em>testing</em>. Supprimer foo de
5173 <em>testing</em> n'aiderait en rien, le paquet serait toujours
5174 désynchronisé pour alpha et ne se propagerait pas dans
5178 Cependant, si ftp-master supprime un paquet d'<em>unstable</em> (ici
5183 foo | alpha | arm | hurd-i386
5184 ---------+-------+-----+----------
5186 unstable | 2 | - | 1
5190 Dans ce cas, le paquet est synchronisé pour toutes les architectures
5191 de version dans <em>unstable</em> (et l'architecture supplémentaire
5192 hurd-i386 ne compte pas car ce n'est pas une architecture de
5196 Quelquefois, la question est soulevée pour savoir s'il est possible
5197 de permettre à des paquets de passer dans <em>testing</em> qui ne
5198 sont pas encore construits pour toutes les architectures :
5199 non. Simplement non. (Excepté si vous êtes responsable de glibc ou
5203 <sect2 id="removals">
5205 Suppressions de <em>testing</em>
5208 Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre
5209 paquet : ceci ne se produit que pour permettre à un
5210 <em>autre</em> paquet d'entrer, ce dernier doit être prêt pour tous
5211 les autres critères. Considérons, par exemple, qu'un paquet
5212 <em>a</em> est en conflit avec la nouvelle version de
5213 <em>b</em> alors <em>a</em> peut être supprimé pour permettre
5214 l'entrée de <em>b</em>.
5217 Bien sûr, il existe une autre raison pour supprimer un paquet de
5218 <em>testing</em> : le paquet est trop bogué (et avoir un seul
5219 bogue RC est suffisant pour être dans cet état).
5222 <sect2 id="circular">
5224 Dépendances circulaires
5227 Une situation qui n'est pas très bien gérée par britney est si un
5228 paquet <em>a</em> dépend de la nouvelle version d'un paquet
5229 <em>b</em> et vice versa.
5232 Voici un exemple :
5236 | testing | unstable
5237 --+-----------------+------------
5238 a | 1; dépend: b=1 | 2; dépend: b=2
5239 b | 1; dépend: a=1 | 2; dépend: a=2
5243 Aucun des paquets <em>a</em> et <em>b</em> ne sera considéré pour
5247 Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de
5248 diffusion. Veuillez les contacter en envoyant un courrier
5249 électronique à debian-release@lists.debian.org si cela se produit
5250 pour l'un de vos paquets.
5255 Influence d'un paquet dans <em>testing</em>
5258 Généralement, l'état d'un paquet dans <em>testing</em> ne change rien
5259 pour la transition de la prochaine version d'<em>unstable</em> vers
5260 <em>testing</em>, avec deux exceptions : si le nombre de bogues
5261 RC du paquet est réduit, le paquet peut migrer même s'il a encore des
5262 bogues RC. La seconde exception est que si la version du paquet dans
5263 <em>testing</em> est désynchronisée entre les différentes
5264 architectures, alors toute architecture peut être mise à jour vers la
5265 version du paquet source ; cependant, cela ne peut se produire
5266 que si le paquet a été précédemment forcé, si l'architecture est dans
5267 fuckedarches ou s'il n'y avait pas du tout de paquet binaire de cette
5268 architecture présent dans <em>unstable</em> lors de la migration dans
5272 En résumé, cela veut dire : la seule influence qu'un paquet de
5273 <em>testing</em> a sur la nouvelle version du même paquet est que la
5274 nouvelle version peut rentrer plus facilement.
5277 <sect2 id="details">
5282 Si vous êtes intéressé par les détails, voici comment fonctionne
5286 Les paquets sont examinés pour savoir si ce sont des candidats
5287 valides. Cela donne le fichier « update excuses ». Les
5288 raisons les plus communes pour lesquelles un paquet n'est pas
5289 considéré sont la jeunesse du paquet, le nombre de bogues RC et la
5290 désynchronisation pour certaines architectures. Pour cette partie,
5291 les responsables de version ont des marteaux de toute taille pour
5292 forcer britney à considérer un paquet. (Le gel de la base est
5293 également codé dans cette partie de britney.) (Il y a une chose
5294 semblable pour les mises à jour binaires pures, mais cela n'est pas
5295 décrit ici. Si vous êtes intéressé par cela, veuillez étudier
5296 attentivement le code.)
5299 Maintenant, la partie la plus complexe se produit : britney
5300 tente de mettre à jour <em>testing</em> avec des candidats
5301 valides ; en premier, chaque paquet individuellement, puis des
5302 groupes de plus en plus larges de paquets ensemble. Chaque tentative
5303 est acceptée si <em>testing</em> n'est pas moins non installable
5304 après la mise à jour qu'avant celle-ci. (Avant et après cette partie,
5305 certains coups de pouce (« hints ») sont traités ;
5306 mais, comme seuls les responsables de version peuvent positionner des
5307 coups de pouce, cela n'est probablement pas très important pour
5311 Si vous voulez voir plus de détails, vous pouvez le voir dans
5312 merkel:/org/ftp.debian.org/testing/update_out/ (ou dans
5313 ~aba/testing/update_out pour voir une configuration avec un fichier
5314 de paquets plus petit). Par le web, c'est à <url
5315 id="http://ftp-master.debian.org/testing/update_out_code/">.
5318 Les coups de pouce sont visibles sur <url
5319 id="http://ftp-master.debian.org/testing/hints/">.
5325 Mises à jour directes dans <em>testing</em>
5328 La distribution <em>testing</em> est peuplée avec des paquets en
5329 provenance d'<em>unstable</em> selon des règles expliquées
5330 ci-dessus. Cependant, dans certains cas, il est nécessaire d'envoyer
5331 des paquets construits seulement pour <em>testing</em>. Pour cela,
5332 vous pouvez envoyer vos paquets vers
5333 <em>testing-proposed-updates</em>.
5336 Souvenez-vous que les paquets envoyés là ne sont pas traités
5337 automatiquement, ils doivent passer entre les mains du responsable de
5338 distribution. Vous devez donc avoir une bonne raison pour les y
5339 envoyer. Pour savoir ce que représente une bonne raison aux yeux des
5340 responsables de distribution, vous devriez lire les instructions
5341 données qu'ils envoient régulièrement sur
5342 &email-debian-devel-announce;.
5345 Vous ne devriez pas envoyer un paquet à
5346 <em>testing-proposed-updates</em> quand vous pouvez le mettre à jour
5347 par <em>unstable</em>. Si vous ne pouvez faire autrement (par exemple,
5348 parce que vous avez une nouvelle version de développement dans
5349 <em>unstable</em>), vous pouvez utiliser cette facilité, mais il est
5350 recommandé de demander l'autorisation du responsable de distribution
5351 auparavant. Même si un paquet est gelé, des mises à jour par
5352 <em>unstable</em> sont possibles si l'envoi dans <em>unstable</em> ne
5353 tire pas de nouvelles dépendances.
5356 Les numéros de version sont habituellement choisis en ajoutant le nom
5357 de code de la distribution <em>testing</em> et un numéro incrémenté,
5358 comme 1.2sarge1 pour le premier envoi dans
5359 <em>testing-proposed-updates</em> du paquet en version 1.2.
5362 Veuillez vous assurer que vous n'oubliez aucun des éléments suivants
5363 lors de votre envoi :
5367 vérifiez que votre paquet doit vraiment aller dans
5368 <em>testing-proposed-updates</em> et ne peut pas passer par
5369 <em>unstable</em> ;
5374 vérifiez que vous n'incluez que le minimum de changements ;
5379 vérifiez que vous incluez une explication appropriée dans le
5385 vérifiez que vous avez bien indiqué <em>testing</em> ou
5386 <em>testing-proposed-updates</em> comme votre distribution
5392 vérifiez que vous avez construit et testé votre paquet dans
5393 <em>testing</em> et non dans <em>unstable</em> ;
5398 vérifiez que votre numéro de version est plus élevé que les
5399 versions de <em>testing</em> et de
5400 <em>testing-proposed-updates</em> et moins élevé que celle de
5401 <em>unstable</em> ;
5406 après l'envoi et la construction réussie sur toutes les
5407 plates-formes, contactez l'équipe de diffusion à
5408 &email-debian-release; et demandez-leur d'approuver votre envoi.
5416 Questions fréquemment posées
5422 Quels sont les bogues bloquant l'intégration dans la version stable
5423 et comment sont-ils comptés ?
5426 Tous les bogues de gravité assez élevée sont par défaut considérés
5427 comme bloquant l'intégration du paquet dans la version stable ;
5428 actuellement, ce sont les bogues critiques, graves et sérieux.
5431 Certains bogues sont supposés avoir un impact sur les chances que le
5432 paquet a d'être diffusé dans la version stable de Debian : en
5433 général, si un paquet a des bogues bloquants, il n'ira pas dans
5434 <em>testing</em> et par conséquent, ne pourra pas être diffusé dans
5438 Le compte des bogues d'<em>unstable</em> est effectué avec tous les
5439 bogues bloquants sans étiquette de version (comme <em>potato</em>,
5440 <em>woody</em>) ou avec une étiquette <em>sid</em> et également s'ils
5441 ne sont ni corrigés ou marqués avec <em>sarge-ignore</em>. Le compte
5442 des bogues de <em>testing</em> pour un paquet est considéré comme à
5443 peu près le nombre de bogues d'<em>unstable</em> lors du dernier
5444 pointage quand la version <em>testing</em> a été égale à la version
5448 Cela changera après la sortie de <em>Sarge</em> dès que nous aurons
5449 des versions dans le système de suivi des bogues.
5454 Comment est-ce que l'installation d'un paquet dans <em>testing</em>
5455 peut casser d'autres paquets ?
5458 La structure des archives de la distribution est faite de telle façon
5459 qu'elles ne peuvent contenir qu'une version d'un paquet ; un
5460 paquet est défini par son nom. Donc, quand le paquet source acmefoo
5461 est installé dans <em>testing</em> avec ses paquets binaires
5462 acme-foo-bin, acme-bar-bin, libacme-foo1 et libacme-foo-dev,
5463 l'ancienne version est supprimée.
5466 Cependant, l'ancienne version pouvait fournir à un paquet binaire un
5467 vieux soname d'une bibliothèque, comme libacme-foo0. Supprimer
5468 l'ancien acmefoo va supprimer libacme-foo0, ce qui va casser tout
5469 paquet qui en dépend.
5472 Évidemment, cela touche principalement des paquets qui fournissent
5473 des jeux changeant de paquets binaires dans différentes versions (par
5474 suite, principalement des bibliothèques). Cependant, cela va aussi
5475 toucher des paquets sur lesquels une dépendance versionnée a été
5476 déclarée du type ==, <= ou <<.
5479 Quand le jeu de paquets binaires fournis par un paquet source change
5480 de cette façon, tous les paquets qui dépendent des anciens binaires
5481 doivent être mis à jour pour dépendre de la nouvelle version à la
5482 place. Comme l'installation d'un tel paquet source dans
5483 <em>testing</em> casse tous les paquets qui en dépendent dans
5484 <em>testing</em>, une certaine attention doit y être portée :
5485 tous les paquets en dépendant doivent être mis à jour et prêts à être
5486 installés eux-même pour qu'ils ne cassent pas et, une fois que tout
5487 est prêt, une intervention manuelle du responsable de version ou d'un
5488 de ses assistants est normalement requise.
5491 Si vous avez des problèmes avec des groupes compliqués de paquets
5492 comme ceci, contactez debian-devel ou debian-release en demandant de
5499 <chapt id="best-pkging-practices">
5501 Les meilleurs pratiques pour la construction des paquets
5504 La qualité de Debian est principalement due à la <url
5505 id="&url-debian-policy;" name="charte Debian"> qui définit explicitement
5506 les obligations que tous les paquets doivent suivre. Mais c'est
5507 également grâce à une histoire partagée d'expériences qui va au-delà de
5508 la charte Debian, une accumulation d'années d'expérience pour la
5509 construction des paquets ; des développeurs de grand talent ont
5510 créé de bons outils qui vous aideront, vous, responsable Debian, à créer
5511 et maintenir d'excellents paquets.
5514 Ce chapitre fournit les meilleurs pratiques pour les développeurs
5515 Debian. Ce ne sont que des recommandations, non pas des obligations ou
5516 des règles. Ce sont seulement des astuces et conseils subjectifs et des
5517 liens collectés pour les développeurs Debian. Prenez et choisissez ce
5518 qui vous convient le mieux.
5520 <sect id="bpp-debian-rules">
5522 Les meilleures pratiques pour le fichier <file>debian/rules</file>
5525 Les recommandations suivantes s'appliquent au fichier
5526 <file>debian/rules</file>. Comme ce fichier contrôle le processus de
5527 compilation et qu'il sélectionne les fichiers inclus dans le paquet
5528 (directement ou indirectement), il s'agit habituellement du fichier sur
5529 lequel les responsables passent le plus de temps.
5531 <sect1 id="helper-scripts">
5536 La raison sous-jacente à l'utilisation des scripts d'aide dans le
5537 fichier <file>debian/rules</file> est que cela permet aux responsables
5538 d'utiliser et de partager une logique commune pour un grand nombre de
5539 paquets. Prenez, par exemple, la question de l'installation des
5540 entrées de menu : vous avez besoin de placer un fichier dans
5541 <file>/usr/share/menu</file> (ou <file>/usr/lib/menu</file> pour des
5542 fichiers de menu binaires exécutables, si nécessaire) et d'ajouter des
5543 commandes aux scripts de maintenance pour enregistrer et
5544 désenregistrer ces entrées de menu. Comme il s'agit d'une chose très
5545 commune, pourquoi chaque responsable devrait-il écrire sa propre
5546 version, parfois avec des bogues ? Supposons également que le
5547 répertoire de menu soit modifié, chaque paquet devrait être modifié.
5550 Les scripts d'aide peuvent résoudre ces problèmes. En supposant que
5551 vous vous conformiez aux conventions attendues par le script d'aide,
5552 celui-ci prend soin de tous les détails. Les changements dans la
5553 charte peuvent alors être faits dans le script d'aide ; les
5554 paquets ont alors simplement besoin d'être reconstruits avec la
5555 nouvelle version du script et sans aucun changement supplémentaire.
5558 L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus courant
5559 et le meilleur (à notre avis) système est
5560 <package>debhelper</package>. Les précédents systèmes d'aide comme
5561 <package>debmake</package> étaient « monolithiques » :
5562 vous ne pouviez pas choisir quelles parties intéressantes vous pouviez
5563 utiliser, mais vous étiez obligé de choisir le système pour tout
5564 faire. <package>debhelper</package>, à l'inverse, consiste en un
5565 certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple,
5566 <prgn>dh_installman</prgn> installe et compacte les pages de manuel,
5567 <prgn>dh_installmenu</prgn> installe les fichiers de menu et ainsi de
5568 suite. Ainsi, il offre une flexibilité suffisante pour pouvoir
5569 utiliser les scripts d'aide quand ils sont utiles, en complément de
5570 commandes définies manuellement dans le fichier
5571 <file>debian/rules</file>.
5574 Vous pouvez débuter avec <package>debhelper</package> en lisant
5575 <manref section="1" name="debhelper"> et en regardant les exemples
5576 fournis avec le paquet. <prgn>dh_make</prgn> du paquet
5577 <package>dh-make</package> (voir <ref id="dh-make">) peut être utilisé
5578 pour convertir un paquet source « vierge » en une version
5579 utilisant <package>debhelper</package>. Ce raccourci ne devrait
5580 cependant pas vous faire croire que vous n'avez pas besoin de
5581 comprendre les scripts individuels <prgn>dh_*</prgn>. Si vous comptez
5582 utiliser un système d'aide, vous devez prendre le temps d'apprendre à
5583 utiliser ce système pour savoir ce que vous pouvez en attendre ainsi
5584 que son comportement.
5587 Plusieurs personnes pensent que des fichiers <file>debian/rules</file>
5588 vierges sont préférables car vous n'avez pas à apprendre les détails
5589 internes d'un quelconque système d'aide. La décision vous appartient
5590 complètement. Utilisez ce qui vous convient. Plusieurs exemples de
5591 fichiers <file>debian/rules</file> sont disponibles à <url
5592 id="&url-rules-files;">.
5595 <sect1 id="multiple-patches">
5597 Séparer vos correctifs en plusieurs fichiers
5600 Les gros paquets peuvent avoir plusieurs bogues que vous devez
5601 gérer. Si vous corrigez sans faire attention les bogues dans les
5602 sources, vous ne pourrez pas différencier facilement les nombreux
5603 correctifs que vous aurez appliqués. Cela peut devenir très compliqué
5604 de mettre à jour le paquet avec une nouvelle version amont qui intègre
5605 certains correctifs (mais pas tous). Vous ne pouvez pas prendre
5606 l'ensemble des correctifs (par exemple, dans les fichiers
5607 <file>.diff.gz</file>) et décider quels correctifs il vous faut
5608 enlever parce que les bogues ont été corrigés en amont.
5611 Malheureusement, le système de création des paquets tel qu'il est
5612 actuellement ne fournit pas de moyen de séparer les correctifs en
5613 plusieurs fichiers. Cependant, il existe des moyens de séparer les
5614 correctifs : les fichiers correctifs sont livrés dans le fichier
5615 correctif Debian (<file>.diff.gz</file>), habituellement dans le
5616 répertoire <file>debian/</file>. La seule différence est qu'ils ne
5617 sont pas appliqués immédiatement par dpkg-source, mais par la règle
5618 <tt>build</tt> du fichier <file>debian/rules</file>. Inversement, ils
5619 sont annulés par la règle <tt>clean</tt>.
5622 <prgn>dbs</prgn> est l'une des approches les plus populaires pour
5623 cela. Il fait ce qui est décrit ci-dessus et fournit la possibilité de
5624 créer de nouveaux correctifs et de mettre à jour d'anciens
5625 correctifs. Veuillez vous reporter au paquet <package>dbs</package>
5626 pour plus d'informations et au paquet <package>hello-dbs</package>
5630 <prgn>Dpatch</prgn> fournit également ces fonctions, mais il est prévu
5631 pour être encore plus facile d'utilisation. Veuillez voir le paquet
5632 <package>dpatch</package> pour la documentation et des exemples (dans
5633 <file>/usr/share/doc/dpatch</file>).
5636 <sect1 id="multiple-binary">
5638 Paquets binaires multiples
5641 Un simple paquet source va souvent permettre de construire plusieurs
5642 paquets binaires différents, que ce soit pour fournir plusieurs
5643 saveurs du même paquet (par exemple, le paquet source
5644 <package>vim</package>) ou pour créer plusieurs petits paquets au lieu
5645 d'un seul gros (par exemple, si l'utilisateur peut n'installer que la
5646 partie nécessaire et ainsi économiser de l'espace disque).
5649 Le second cas peut facilement être géré dans le fichier
5650 <file>debian/rules</file>. Vous avez simplement besoin de déplacer les
5651 fichiers appropriés du répertoire de construction dans les
5652 arborescence temporaires du paquet. Vous pouvez le faire en utilisant
5653 <prgn>install</prgn> ou <prgn>dh_install</prgn> du paquet
5654 <package>debhelper</package>. Assurez-vous de vérifier les différentes
5655 permutations de paquets, en garantissant que vous avez bien défini les
5656 dépendances entre les paquets dans le fichier
5657 <file>debian/control</file>.
5660 Le premier cas est un peu plus difficile car il implique de multiples
5661 recompilations du même logiciel, mais avec différentes options de
5662 configuration. Le paquet source <package>vim</package> est un exemple
5663 de la façon de gérer cela avec un fichier <file>rules</file> écrit à
5668 <sect id="bpp-debian-control">
5670 Les meilleures pratiques pour le fichier <file>debian/control</file>
5673 Les pratiques suivantes sont relatives au fichier
5674 <file>debian/control</file>. Elles viennent en complément des <url
5675 id="&url-debian-policy;ch-binary.html#s-descriptions" name="règles pour
5676 les descriptions des paquets">.
5679 La description du paquet, telle qu'elle est définie par le champ
5680 correspondant dans le fichier <file>control</file>, contient à la fois
5681 le résumé du paquet et la description longue pour le paquet. <ref
5682 id="bpp-desc-basics"> décrit des lignes générales pour les deux parties
5683 de la description. Ensuite, <ref id="bpp-pkg-synopsis"> fournit des
5684 principes spécifiques pour le résumé et <ref id="bpp-pkg-desc">
5685 contient des principes spécifiques pour la description longue.
5687 <sect1 id="bpp-desc-basics">
5689 Les règles générales pour les descriptions des paquets
5692 La description du paquet devrait être écrite pour l'utilisateur moyen,
5693 l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple,
5694 les paquets de développement sont pour les développeurs et leur
5695 description peut utiliser un langage technique. Pour les applications
5696 à but plus général comme un éditeur, la description devrait être
5697 écrite pour un non-spécialiste.
5700 Notre critique des descriptions des paquets nous amène à conclure que
5701 la plupart des descriptions des paquets sont techniques, c'est-à-dire,
5702 qu'elles ne sont pas écrites pour être comprises par les
5703 non-spécialistes. À moins que votre paquet ne soit que pour les
5704 techniciens, c'est un problème.
5707 Comment écrire pour les non-spécialistes ? Évitez le
5708 jargon. Évitez de vous référer à d'autres applications et cadres de
5709 travail avec lesquels l'utilisateur n'est pas forcément familier
5710 — « GNOME » ou « KDE » sont corrects
5711 car les utilisateurs sont probablement familiers avec ces termes, mais
5712 « GTK+ » ne l'est probablement pas. Ne supposez aucune
5713 connaissance. Si vous devez utiliser des termes techniques,
5717 Soyez objectif. Les descriptions de paquet ne sont pas un endroit pour
5718 promouvoir votre paquet, quel que soit l'amour que vous lui
5719 portez. Rappelez-vous que le lecteur n'a pas forcément les mêmes
5723 Des références aux noms de tout autre paquet de logiciels, noms de
5724 protocoles, standards ou spécifications devraient utiliser leurs
5725 formes canoniques si elles existent. Par exemple, utilisez « X
5726 Window System », « X11 » ou « X » et non
5727 « X Windows », « X-Windows » ou « X
5728 Window ». Utilisez « GTK+ » et non « GTK » ou
5729 « gtk ». Utilisez « GNOME » et non
5730 « Gnome ». Utilisez « PostScript » et non
5731 « Postscript » ou « postscript ».
5734 Si vous avez des problèmes pour écrire votre description, vous pouvez
5735 l'envoyer à &email-debian-l10n-english; et demander un retour
5739 <sect1 id="bpp-pkg-synopsis">
5741 Le résumé du paquet ou description courte
5744 La ligne de résumé (la description courte) devrait être concise. Elle
5745 ne doit pas répéter le nom du paquet (c'est une règle).
5748 C'est une bonne idée de penser au résumé comme à une clause apposée et
5749 non une phrase complète. Une clause apposée est définie dans WordNet
5750 comme une relation grammaticale entre un mot et une phrase pronominale
5751 qui la suit, par exemple « Rudolph, le renne au nez
5752 rouge ». La clause apposée ici est « le renne au nez
5753 rouge ». Comme le résumé est une clause et non une phrase
5754 complète, nous recommandons de ne pas la commencer par une majuscule
5755 et de ne pas la finir par un point. Il ne doit pas non plus commencer
5756 avec un article, défini (« le ») ou indéfini
5760 Cela peut vous aider d'imaginer le résumé combiné avec le nom du
5761 paquet de la façon suivante :
5762 <example><var>nom-paquet</var> est un <var>résumé</var>.</example>
5763 Sinon, il peut être plus compréhensible de le voir comme
5764 <example><var>nom-paquet</var> est <var>résumé</var>.</example>
5765 ou, si le nom du paquet est lui-même un pluriel (comme
5766 « developer-tools »)
5767 <example><var>nom-paquet</var> sont <var>résumé</var>.</example>
5768 Cette façon de former une phrase à partir du nom du paquet et du
5769 résumé devrait être considérée comme une heuristique et non comme une
5770 règle stricte. Il y a certains cas où cela n'a aucun sens de former
5774 <sect1 id="bpp-pkg-desc">
5776 La description longue
5779 La description longue du paquet est la première information dont
5780 dispose l'utilisateur avant d'installer un paquet. Aussi, elle devrait
5781 fournir toutes les informations nécessaires pour le laisser décider de
5782 l'installation du paquet. Vous pouvez supposer que l'utilisateur a
5783 déjà lu le résumé du paquet.
5786 La description longue devrait toujours être constituée de phrases
5790 Le premier paragraphe de la description longue devrait répondre aux
5791 questions suivantes : qu'est-ce que fait le paquet ? Quelle
5792 tâche aide-t-il l'utilisateur à accomplir ? Il est important de
5793 décrire ceci d'une manière non technique, à moins que le paquet ne
5794 s'adresse qu'à un auditoire de techniciens.
5797 Les paragraphes suivants devraient répondre aux questions
5798 suivantes : Pourquoi, en tant qu'utilisateur, ai-je besoin de ce
5799 paquet ? Quelles sont les autres fonctionnalités dont dispose le
5800 paquet ? Quelles sont les fonctionnalités marquantes et les
5801 déficiences de ce paquet comparé à d'autres paquets (par exemple,
5802 « si vous avez besoin de X, utilisez Y à la place ») ?
5803 Est-ce que le paquet est lié à d'autres paquets d'une certaine façon
5804 qui n'est pas gérée par le gestionnaire de paquet (par exemple,
5805 « il s'agit d'un client pour le serveur foo ») ?
5808 Soyez attentif à éviter les fautes d'orthographe et de
5809 grammaire. N'oubliez pas votre vérificateur orthographique. Les deux
5810 programmes <prgn>ispell</prgn> et <prgn>aspell</prgn> possèdent des
5811 modes spéciaux pour vérifier les fichiers
5812 <file>debian/control</file> :
5813 <example>ispell -d american -g debian/control</example>
5814 <example>aspell -d en -D -c debian/control</example>
5817 Les utilisateurs s'attendent habituellement à ce que les réponses aux
5818 questions suivantes soient présentes dans la description du
5823 Qu'est-ce que fait le paquet ? Si c'est un ajout d'un autre
5824 paquet, la description courte du paquet dont c'est un ajout devrait
5830 Pourquoi est-ce qu'il voudrait installer ce paquet ? Ceci est
5831 lié à ce qui est ci-dessus, mais pas tout à fait (c'est un client
5832 de messagerie ; il est cool, rapide, s'interface avec PGP,
5833 LDAP et IMAP, a les fonctionnalités X, Y et Z).
5838 Si ce paquet ne devrait pas être installé directement, mais être
5839 tiré par un autre paquet, cela devrait être mentionné.
5844 Si le paquet est expérimental, ou s'il y a d'autres raisons pour
5845 lesquelles il ne devrait pas être utilisé, si un autre paquet
5846 devrait être utilisé à la place, cela devrait également être
5852 En quoi le paquet est différent des paquets concurrents ?
5853 Est-ce que c'est une meilleure implémentation ? A-t-il plus de
5854 fonctionnalités, des fonctionnalités différentes ? Pourquoi
5855 devrait-il choisir ce paquet ?
5861 <sect1 id="bpp-upstream-info">
5863 Page d'accueil amont
5866 Nous vous recommandons d'ajouter l'adresse de la page d'accueil du
5867 paquet à la description du paquet dans le fichier
5868 <file>debian/control</file>. Cette information devrait être ajoutée à
5869 la fin de la description en utilisant le format suivant :
5871 Homepage: http://some-project.some-place.org/</example>
5872 Veuillez noter les espaces au début de la ligne, ils servent à séparer
5873 les lignes correctement. Pour voir un exemple de ce que cela affiche,
5874 veuillez vous reporter à <url id="&url-eg-desc-upstream-info;">.
5877 Ne mettez rien s'il n'existe pas de page pour le logiciel.
5880 Veuillez noter que nous espérons que ce champ sera remplacé par un
5881 vrai champ de <file>debian/control</file> qui serait compris par
5882 <prgn>dpkg</prgn> et <tt>&packages-host;</tt>. Si vous ne voulez pas
5883 vous embêter à déplacer la page d'accueil depuis la description vers
5884 ce nouveau champ, vous devriez probablement attendre qu'il soit
5885 disponible. Veuillez vous assurer que cette ligne correspond à
5886 l'expression rationnelle <tt>/^ Homepage: [^ ]*$/</tt> car cela permet
5887 à <file>packages.debian.org</file> de l'analyser correctement.
5891 <sect id="bpp-debian-changelog">
5893 Les meilleures pratiques pour le fichier <file>debian/changelog</file>
5896 Les pratiques suivantes viennent en complément de la <url
5897 id="&url-debian-policy;ch-docs.html#s-changelogs" name="directive sur
5898 les fichiers changelog">.
5900 <sect1 id="bpp-changelog-do">
5902 Écrire des entrées de changelog utiles
5905 L'entrée de changelog pour une révision de paquet documente les
5906 changements dans cette révision et seulement ceux-ci. Concentrez-vous
5907 sur la description des changements significatifs et visibles de
5908 l'utilisateur qui ont été effectués depuis la dernière version.
5911 Ciblez <em>ce</em> qui a été changé — qui, comment et quand
5912 cela a été fait est généralement de moindre importance. Ceci dit,
5913 rappelez-vous de nommer poliment les personnes qui ont fourni une aide
5914 notable pour réaliser le paquet (par exemple, ceux qui ont envoyé des
5918 Vous n'avez pas besoin de détailler les changements triviaux et
5919 évidents. Vous pouvez également regrouper plusieurs de ces changements
5920 dans une seule entrée. D'un autre côté, ne soyez pas trop concis si
5921 vous avez entrepris un changement majeur. Soyez tout spécialement
5922 clair s'il y a des changements qui modifient le comportement du
5923 programme. Pour plus d'explications, utilisez le fichier
5924 <file>README.Debian</file>.
5927 Utilisez un langage anglais commun pour que la majorité des lecteur
5928 puissent le comprendre. Évitez les abréviations, le parler technique
5929 et le jargon quand vous expliquez des changements fermant un bogue,
5930 spécialement pour les rapports de bogue créés par des utilisateurs qui
5931 ne vous paraissent pas particulièrement à l'aise techniquement. Vous
5932 devez être poli et ne pas jurer.
5935 Il est parfois désirable de préfixer les entrées de changelog avec le
5936 nom des fichiers qui ont été modifiés. Cependant, il n'est pas besoin
5937 de lister explicitement tous les fichiers modifiés, particulièrement
5938 si la modification est petite ou répétitive. Vous pouvez utiliser les
5939 caractères génériques.
5942 Quand vous faites référence aux bogues, ne supposez rien a
5943 priori. Dites ce qu'était le problème, comment il a été résolu et
5944 ajoutez la chaîne de caractères « closes: #nnnnn ». Veuillez
5945 voir <ref id="upload-bugfix"> pour plus d'informations.
5948 <sect1 id="bpp-changelog-misconceptions">
5950 idées fausses communes sur les entrées de changelog
5953 Les entrées de changelog <strong>ne devraient pas</strong> documenter
5954 des problèmes génériques d'empaquetage (« Hé, si vous cherchez
5955 foo.conf, il est dans /etc/blah/. ») car les administrateurs et
5956 utilisateurs sont supposés être au moins vaguement rompus à la façon
5957 dont les choses sont arrangées sur un système Debian. Mentionnez
5958 cependant tout changement d'emplacement d'un fichier de configuration.
5961 Les seuls bogues fermés par une entrée de changelog devraient être
5962 ceux qui sont vraiment corrigés dans la même révision du
5963 paquet. Fermer des bogues non liés par le fichier changelog est
5964 considéré comme une très mauvaise pratique. Veuillez voir <ref
5965 id="upload-bugfix">.
5968 Les entrées de changelog <strong>ne devraient pas</strong> être le
5969 lieu de discussions avec les émetteurs de bogues (« Je ne vois
5970 pas de segfaults lors du lancement de foo avec l'option bar ;
5971 envoyez-moi plus d'informations. »), ni celui de phrases
5972 génériques sur la vie, l'univers et tout le reste (« Désolé, cet
5973 envoi m'a pris du temps, mais j'avais attrapé la grippe ») ou
5974 celui de demandes d'aide (« La liste des bogues sur ce paquet est
5975 énorme, donnez-moi un coup de main »). Ceci ne sera généralement
5976 pas remarqué par les personnes ciblées, mais peut ennuyer les
5977 personnes qui désirent lire des informations sur les changements réels
5978 du paquet. Veuillez vous reporter à <ref id="bug-answering"> pour plus
5979 d'informations sur la façon d'utiliser le système de suivi des bogues.
5982 C'est une vieille tradition de valider les bogues fixés par une mise à
5983 jour indépendante dans la première entrée du changelog de l'envoi du
5984 vrai responsable. Veuillez utiliser l'option <tt>-v</tt> de
5985 <prgn>dpkg-buildpackage</prgn> pour fermer les rapports de bogue
5989 <sect1 id="bpp-changelog-errors">
5991 Erreurs communes dans les entrées de changelogs
5994 Les exemples suivants montrent des erreurs communes ou des exemples de
5995 mauvais style dans les entrées de changelog<footnote><p>NdT : Les
5996 entrées de changelog sont ici affichées en français pour faciliter la
5997 compréhension, mais vos entrées devront naturellement être rédigées en
5998 anglais.</p></footnote>.
6002 * Corrige tous les bogues restants.
6004 Ceci n'indique visiblement rien d'utile au lecteur.
6008 * Correctif de Jane Random appliqué.
6010 Sur quoi portait le correctif ?
6014 * Révision de cible d'installation la nuit dernière.
6016 Qu'a accompli la révision ? Est-ce que la mention de la nuit
6017 dernière est supposée nous rappeler que nous ne devons pas faire
6018 confiance à ce code ?
6022 * Corrige MRD vsync av. anciens CRTs.
6024 Trop d'acronymes et il n'est pas très clair de ce qu'était vraiment
6025 cette... euh... merde (oups, un mot interdit !) ou comment cela a
6030 * Ceci n'est pas un bogue. Closes: #nnnnnn.
6032 Premièrement, il n'y a absolument pas besoin d'envoyer un paquet pour
6033 communiquer cette information ; à la place, utilisez le système
6034 de suivi des bogues. Deuxièmement, il n'y a aucune explication
6035 concernant la raison pour laquelle le rapport n'était pas un bogue.
6039 * A été fixé il y a longtemps, mais j'ai oublié de le fermer. Closes: #54321.
6041 Si, pour toute raison, vous n'aviez pas indiqué le numéro du bogue
6042 dans une précédente entrée de changelog, ceci n'est pas un problème,
6043 fermez simplement le bogue normalement dans le BTS. Il n'y a pas
6044 besoin de modifier le fichier changelog, en supposant que la
6045 description de la correction est déjà intégrée (ceci s'applique aux
6046 correctifs par les auteurs/responsables amont également, vous n'avez
6047 pas à suivre les bogues qui ont été corrigés il y a longtemps dans
6052 * Closes: #12345, #12346, #15432.
6054 Où est la description ?! Si vous n'arrivez pas à trouver un
6055 message descriptif, commencez par insérer le titre de chacun des
6059 <sect1 id="bpp-news-debian">
6061 Compléter les changelogs avec les fichiers NEWS.Debian
6064 Les nouvelles importantes à propos des changements dans un paquet
6065 peuvent également être placées dans les fichiers NEWS.Debian. Ces
6066 nouvelles seront affichées par des outils comme apt-listchanges, avant
6067 le reste des changelogs. Ceci est le moyen préféré pour informer les
6068 utilisateurs des changements significatifs dans un paquet. Il est
6069 préférable d'utiliser ce fichier plutôt que d'utiliser des notes
6070 debconf car c'est moins ennuyeux et l'utilisateur peut y revenir et se
6071 référer au fichier NEWS.Debian après l'installation. Et c'est mieux
6072 que de lister les changements principaux dans README.Debian car
6073 l'utilisateur peut facilement rater de telles notes.
6076 Le format du fichier est le même que pour un fichier de changelog
6077 Debian, mais il n'utilise pas d'astérisques et décrit chaque élément
6078 de nouvelle dans un paragraphe complet si nécessaire plutôt que les
6079 résumés concis qui iraient dans un changelog. C'est une bonne idée de
6080 passer votre fichier par dpkg-parsechangelog pour vérifier son
6081 formatage car il n'est pas vérifié automatiquement pendant la
6082 construction comme le changelog. Voici un exemple d'un vrai fichier
6085 cron (3.0pl1-74) unstable; urgency=low
6087 The checksecurity script is no longer included with the cron package:
6088 it now has its own package, "checksecurity". If you liked the
6089 functionality provided with that script, please install the new
6092 -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
6096 Le fichier NEWS.Debian est installé comme
6097 /usr/share/doc/<package>/NEWS.Debian.gz. Il est compressé et a
6098 toujours ce nom même dans les paquets natifs Debian. Si vous utilisez
6099 debhelper, dh_installchangelogs installera les fichiers debian/NEWS
6103 À la différence des fichiers changelog, vous n'avez pas besoin de
6104 mettre à jour les fichiers NEWS.Debian à chaque nouvelle version. Ne
6105 les mettez à jour que si vous avez quelque chose de particulièrement
6106 important que l'utilisateur a besoin de savoir. Si vous n'avez pas de
6107 nouvelles du tout, il n'est pas nécessaire de fournir de fichier
6108 NEWS.Debian dans votre paquet. Pas de nouvelles, bonne nouvelle !
6112 <sect id="bpp-debian-maint-scripts">
6114 Les meilleures pratiques pour les scripts de maintenance
6117 Les scripts de maintenance incluent les fichiers
6118 <file>debian/postinst</file>, <file>debian/preinst</file>,
6119 <file>debian/prerm</file> et <file>debian/postrm</file>. Ces scripts
6120 prennent en charge la configuration d'installation ou de
6121 désinstallation des paquets, ce qui n'est pas simplement créer ou
6122 supprimer des fichiers et des répertoires. Les instructions suivantes
6123 complètent la <url id="&url-debian-policy;" name="charte Debian">.
6126 Les scripts de maintenance doivent être idempotents. Cela veut dire que
6127 vous devez vous assurer que rien de grave ne se produit si un script
6128 est appelé deux fois là où il ne devrait habituellement être appelé
6132 Les entrée et sortie standard peuvent être redirigées (par exemple,
6133 dans des tubes<footnote><p>pipes</p></footnote>) pour des besoins
6134 d'enregistrement d'activité, donc vous ne devez pas supposer que ce
6138 Tous les affichages et les configurations interactives devraient être
6139 minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet
6140 <package>debconf</package> pour l'interface. Rappelez-vous que, dans
6141 tous les cas, l'affichage ne doit se faire que dans l'étape de
6142 configuration, <tt>configure</tt> du script de post-installation,
6143 <file>postinst</file>.
6146 Gardez les scripts de maintenance aussi simples que possible. Nous vous
6147 suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que
6148 si vous avez besoin d'une fonctionnalité de Bash, le script de
6149 maintenance doit préciser bash dans sa première ligne. Un shell POSIX
6150 ou Bash sont préférés à Perl car ils permettent à
6151 <package>debhelper</package> d'ajouter facilement des parties aux
6155 Si vous modifiez les scripts de maintenance, assurez-vous de tester la
6156 suppression du paquet, la double installation et la purge
6157 complète. Assurez-vous qu'il ne reste rien d'un paquet purgé,
6158 c'est-à-dire, que la purge doit enlever tout fichier créé, directement
6159 ou indirectement, par les scripts de maintenance.
6162 Si vous avez besoin de vérifier l'existence d'une commande, vous
6163 devriez utiliser quelque chose comme :
6164 <example>if [ -x /usr/sbin/install-docs ]; then ...</example>
6165 Si vous ne désirez pas mettre en dur le chemin d'une commande dans le
6166 script de maintenance, la fonction de shell suivante conforme à POSIX
6167 peut vous aider : &example-pathfind; Vous pouvez utiliser cette
6168 fonction pour rechercher le <tt>$PATH</tt> pour un nom de commande
6169 passé en argument. Il renvoie vrai (zéro) si la commande a été trouvée
6170 et faux sinon. Il s'agit réellement de la façon la plus portable de
6171 faire car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn>
6175 Bien que <prgn>which</prgn> soit une alternative acceptable car il est
6176 présent dans le paquet classé <em>required</em>
6177 <package>debianutils</package>, il n'est pas présent dans la partition
6178 racine. Autrement dit, il est placé dans <file>/usr/bin</file> au lieu
6179 de <file>/bin</file>, il n'est donc pas possible de l'utiliser dans les
6180 scripts qui sont exécutés avant que la partition <file>/usr</file> soit
6181 montée. Cependant, la plupart des scripts n'auront pas ce problème.
6184 <sect id="bpp-config-mgmt">
6186 Gestion de la configuration avec <package>debconf</package>
6189 <package>Debconf</package> est un système de gestion de configuration
6190 qui peut être utilisé par les divers scripts de maintenance
6191 (principalement en post-installation dans le fichier
6192 <file>postinst</file>) pour demander à l'utilisateur des informations
6193 concernant la configuration du paquet. Il faut maintenant éviter les
6194 interactions directes avec l'utilisateur et préférer les interactions
6195 utilisant <package>debconf</package>. Ceci permettra à l'avenir des
6196 installations non interactives.
6199 Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs
6200 erreurs communes sont référencées dans la page de manuel <manref
6201 section="7" name="debconf-devel">. Vous devriez vraiment lire cette
6202 page si vous décidez d'utiliser debconf. Nous documentons également
6203 plusieurs des meilleures pratiques ici.
6206 Ces lignes directives incluent plusieurs recommandations de style
6207 d'écriture et de typographie, des considérations générales à propos de
6208 l'utilisation de debconf ainsi que des recommandations plus spécifiques
6209 pour certaines parties de la distribution (par exemple, le système
6214 N'abusez pas de debconf
6217 Depuis que debconf est apparu dans Debian, il a été largement abusé et
6218 plusieurs critiques reçues par la distribution Debian proviennent
6219 d'utilisation abusive de debconf avec la nécessité de répondre à un
6220 grand nombre de questions avant d'avoir n'importe quel petit logiciel
6224 Garder les notes d'utilisation à leur place : le fichier
6225 NEWS.Debian ou le fichier README.Debian. N'utilisez des notes que pour
6226 des notes importantes qui peuvent directement concerner l'utilisation
6227 du paquet. Rappelez-vous que les notes bloqueront toujours
6228 l'installation avant leur confirmation ou qu'elles embêtent
6229 l'utilisateur par un courriel.
6232 Choisissez avec soin les priorités des questions dans les scripts de
6233 responsable. Reportez-vous à <manref section="7" name="debconf-devel">
6234 pour plus de détails sur les priorités. La plupart des questions
6235 devraient utiliser un priorité moyenne ou basse.
6240 Recommandations générales pour les auteurs et traducteurs
6246 Écrivez un anglais correct
6249 La plupart des responsables de paquets Debian n'ont pas l'anglais
6250 comme langue maternelle. Écrire des modèles correctement rédigés peut
6251 donc ne pas être facile pour eux.
6254 Veuillez utiliser (et abuser de) la liste de discussions
6255 &email-debian-l10n-english;. Faites relire vos questionnaires.
6258 Des questionnaires écrits incorrectement donnent une pauvre image de
6259 votre paquet, de votre travail... ou même de Debian elle-même.
6262 Évitez le jargon technique autant que possible. Si certains termes
6263 vous semblent courants, ils peuvent être impossibles à expliquer à
6264 d'autres personnes. Si vous ne pouvez pas les éviter, essayez de les
6265 expliquer (en utilisant la description étendue). Quand vous faites
6266 cela, essayez d'équilibrer la verbosité et la simplicité.
6271 Être courtois avec les traducteurs
6274 Les questionnaires debconf peuvent être traduits. Debconf, avec son
6275 paquet-frêre <package>po-debconf</package>, offre un cadre de travail
6276 simple pour obtenir des questionnaires traduits par les équipes de
6277 traduction ou même par des individus isolés.
6280 Veuillez utiliser les questionnaires basés sur gettext. Installez
6281 <package>po-debconf</package> sur votre système de développement et
6282 lisez sa documentation (« man po-debconf » est un bon
6286 Évitez de changer vos questionnaires trop souvent. Modifier le texte
6287 des questionnaires entraîne plus de travail pour les traducteurs dont
6288 les traductions seront rendues « floues »
6289 (« fuzzy »). Si vous prévoyez des modifications dans vos
6290 questionnaires d'origine, veuillez contacter les traducteurs. La
6291 plupart des traducteurs actifs sont très réactifs et obtenir leur
6292 travail inclus avec vos questionnaires modifiés vous économisera des
6293 envois supplémentaires. Si vous utilisez des modèles basés sur
6294 gettext, le nom et l'adresse électronique du traducteur sont
6295 mentionnés dans les en-têtes des fichiers PO.
6298 L'utilisation de <prgn>podebconf-report-po</prgn> du paquet
6299 <package>po-debconf</package> est hautement recommandée pour avertir
6300 les traducteurs qui ont des traductions incomplètes et pour leur
6301 demander des mises à jour.
6304 En cas de doutes, vous pouvez également contacter l'équipe de
6305 traduction pour une langue donnée
6306 (debian-l10n-xxxxx@lists.debian.org) ou la liste de discussions
6307 &email-debian-i18n;.
6310 Les appels à traductions postés sur &email-debian-i18n; avec le
6311 fichier <file>debian/po/templates.pot</file> attaché ou référencé
6312 dans une URL sont encouragés. Assurez-vous de mentionner dans ces
6313 appels pour de nouvelles traductions quelles sont les langues pour
6314 lesquelles vous avez déjà des traductions existantes, pour éviter
6315 toute duplication de travail.
6320 « Dé-fuzzy-fiez » les traductions complètes lors des
6321 corrections de typos et d'orthographe
6324 Quand le texte d'un questionnaire debconf est corrigé et que vous
6325 êtes <strong>certain</strong> que les changements <strong>n'ont
6326 aucun</strong> effet sur les traductions, soyez courtois avec les
6327 traducteurs et dé-fuzzy-fiez leurs traductions.
6330 Si vous ne le faites pas, le questionnaire entier ne sera pas traduit
6331 jusqu'à ce qu'un traducteur vous envoie une mise à jour.
6334 Pour <strong>dé-fuzzy-fier</strong> les traductions, vous pouvez
6335 procéder ainsi :
6336 <enumlist numeration="arabic">
6339 enlevez tous les fichiers PO incomplets. Vous pouvez vérifier si
6340 les fichiers sont complets en utilisant (il faut que le paquet
6341 <package>gettext</package> soit installé) :
6342 <example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
6343 --statistics $i; done</example>
6348 déplacez tous les fichiers ayant des chaînes floues
6349 (« fuzzy ») dans un emplacement temporaire. Les fichiers
6350 n'ayant aucune chaîne floue (seulement des chaînes traduites et
6351 non traduites) seront conservées où ils sont placés,
6356 maintenant <strong>et seulement maintenant</strong>, corrigez les
6357 typos dans le questionnaire et vérifiez que les traductions ne
6358 sont pas impactées (les typos, les fautes d'orthographe et parfois
6359 les corrections de typographie sont généralement acceptables),
6364 exécutez <prgn>debconf-updatepo</prgn>. Cela va fuzzifier toutes
6365 les chaînes que vous avez modifiées dans les traductions. Vous
6366 pouvez constater cela en exécutant à nouveau la commande
6372 utilisez la commande suivante :
6373 <example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
6378 déplacez dans debian/po les fichiers qui avaient des chaînes
6379 floues dans la première étape,
6384 exécutez à nouveau <prgn>debconf-updatepo</prgn>.
6392 Ne faites pas de suppositions à propos des interfaces
6395 Le texte des modèles ne doit pas faire référence aux composants
6396 appartenant à l'une des interfaces debconf. Des phrases comme
6397 « If you answer Yes... » n'a aucun sens pour les
6398 utilisateurs d'interfaces graphiques qui utilisent des cases à cocher
6399 pour les questions booléennes.
6402 Les modèles de chaînes de caractères devraient éviter de mentionner
6403 les valeurs par défaut dans leur description. Tout d'abord, parce que
6404 cela est redondant avec les valeurs lues par les
6405 utilisateurs. Ensuite, parce ces valeurs par défaut peuvent être
6406 différentes selon les choix du responsable (par exemple, quand la
6407 base de données debconf a été préremplie).
6410 Plus généralement, essayez d'éviter de vous référer à toute action de
6411 l'utilisation. Donnez simplement des faits.
6416 N'utilisez pas la première personne
6419 Vous devriez éviter d'utiliser la première personne (« I will do
6420 this... » ou « We recommend... »). L'ordinateur n'est
6421 pas une personne et les questionnaires debconf ne parlent pas pour
6422 les développeurs Debian. Vous devriez utiliser une construction
6423 neutre et souvent une forme passive. Pour ceux d'entre vous qui
6424 écrivent déjà des publications scientifiques, écrivez simplement vos
6425 questionnaires comme vous écririez un papier scientifique.
6430 Soyez neutre dans le genre
6433 Le monde est fait d'hommes et de femmes. Veuillez utiliser des
6434 constructions neutres dans le genre dans votre texte. Ce n'est pas du
6435 politiquement correct, c'est simplement montrer du respect pour toute
6442 Définition des champs de questionnaires
6445 Cette partie donne plusieurs informations qui sont principalement
6446 extraites de la page de manuel <manref section="7"
6447 name="debconf-devel">.
6457 string: (chaîne de caractères)
6460 Résulte en un champ d'entrée libre dans lequel l'utilisateur peut
6461 écrire toute chaîne.
6466 password: (mot de passe)
6469 Demande un mot de passe à l'utilisateur. Veuillez utiliser ce champ
6470 avec précaution ; soyez conscient que le mot de passe que
6471 l'utilisateur entre sera écrit dans la base de données debconf. Vous
6472 devriez probablement enlever cette valeur de la base de données dès
6481 Un choix vrai/faux. Rappelez-vous : vrai/faux, PAS OUI/NON...
6489 Un choix parmi un certain nombre de valeurs. Les choix doivent être
6490 spécifiés dans un champ nommé « Choices ». Séparez les
6491 valeurs possibles par des virgules et des espaces ainsi :
6492 Choices: yes, no, maybe
6497 multiselect: (sélection multiple)
6500 Comme le type de données select, excepté que l'utilisateur peut
6501 choisir un nombre quelconque d'éléments dans la liste de choix (ou
6510 Plutôt que d'être une question en tant que telle, ce type de donnée
6511 indiqué une note qui peut être affichée à l'utilisateur. Il ne
6512 devrait être utilisé que pour des données importantes que
6513 l'utilisateur doit réellement voir, car debconf fera tout ce qu'il
6514 peut pour s'assurer que l'utilisateur le voit ; il stoppera
6515 l'installation en attendant que l'utilisateur appuie sur une touche
6516 ou il leur enverra même la note par courrier dans certains cas.
6524 Ce type est maintenant considéré comme obsolète : ne l'utilisez
6533 <strong>CE TYPE DE MODÈLE N'EST PAS ENCORE GÉRÉ PAR
6537 Il a été ajouté à cdebconf, la version C de debconf, utilisé en
6538 premier dans l'installateur Debian.
6541 Veuillez ne pas l'utiliser à moins que debconf ne le prenne en
6545 Ce type est conçu pour gérer des messages d'erreur. Il est presque
6546 semblable au type « note ». Des interfaces peuvent le
6547 présenter différemment (par exemple, l'interface dialog de cdebconf
6548 affiche un écran rouge au lieu de l'écran bleu habituel).
6554 Description: description courte et étendue
6557 Les descriptions des modèles sont composées de deux parties :
6558 une courte et une étendue. La description courte est dans la ligne
6559 « Description: » du questionnaire.
6562 La description courte devrait être gardée courte (50 caractères
6563 ou moins) pour qu'elle puisse être ajustée par la plupart des
6564 interfaces debconf. La garder courte aide également les traducteurs,
6565 car les traductions ont tendance à être plus longues que l'original.
6568 La description courte devrait se suffire à elle-même. Certaines
6569 interfaces n'affichent pas la description longue par défaut ou
6570 seulement si l'utilisateur la demande explicitement ou même ne
6571 l'affichent pas du tout. Évitez des choses comme « What do you
6572 want to do ? ».
6575 Il n'est pas nécessaire que la description courte soit une phrase
6576 complète. Cela fait partie de la recommandation « gardez-la
6577 courte et efficace ».
6580 La description étendue ne devrait pas répéter la description courte
6581 mot pour mot. Si vous ne trouvez pas de description longue, commencez
6582 par à y réfléchir plus. Envoyez un message sur debian-devel. Demandez
6583 de l'aide. Suivez un cours d'écriture ! La description étendue
6584 est importante. Si, après tout cela, vous ne trouvez toujours rien,
6588 La description étendue devrait utiliser des phrases complètes. Des
6589 paragraphes devraient être gardés court pour améliorer la
6590 lisibilité. Ne mélangez pas deux idées dans le même paragraphe, mais
6591 utilisez plutôt un autre paragraphe.
6594 Ne soyez pas trop verbeux. Certaines interfaces debconf ne gèrent pas
6595 très bien les descriptions de plus de 20 lignes, essayez donc de
6596 les conserver sous cette limite.
6599 Pour des règles spécifiques selon le type de questionnaire (chaîne de
6600 caractères, booléen, etc.), veuillez lire ci-dessous.
6608 Ce champ devrait utilisé pour des types Select et Multiselect. Il
6609 contient les choix possibles qui seront présentés aux
6610 utilisateurs. Ces choix devraient être séparés par des virgules.
6615 Default (valeur par défaut)
6618 Ce champ est facultatif. Il contient la réponse par défaut pour les
6619 modèles chaîne de caractères, sélection et multi-sélection. Pour des
6620 questionnaires multi-sélection, il peut contenir une liste de choix
6621 séparés par des virgules.
6627 Guide de style spécifique par champ de questionnaires
6636 Aucune indication spécifique excepté : utilisez le type
6637 approprié en vous référant à la section précédente.
6645 Voici ci-dessous des instructions spécifiques pour écrire
6646 correctement la description (courte et étendue) selon le type de
6651 questionnaire chaîne de caractères/mot de passe
6657 La description courte est une invite et NON un titre. Évitez des
6658 invites de style question (« IP Address? ») en faveur
6659 d'invites « ouvertes »à (« IP
6660 address: »). L'utilisation des deux-points est recommandée.
6665 La description étendue est un complément à la description
6666 courte. Dans la partie étendue, expliquez ce qui est demandé,
6667 plutôt que de poser la même question à nouveau en utilisant des
6668 mots plus longs. Utilisez des phrases complètes. Un style
6669 d'écriture trop concis est fortement découragé.
6683 La description courte devrait être rédigée sous la forme d'une
6684 question qui devrait être gardée courte et devrait généralement
6685 se terminer par un point d'interrogation. Un style d'écriture
6686 concis est permis et même encouragé si la question est plutôt
6687 longue (rappelez-vous que les traductions sont souvent plus
6688 longue que les versions d'origine)
6693 La description étendue ne devrait PAS inclure de question.
6698 À nouveau, veuillez éviter de vous référer à des composants
6699 d'interface spécifiques. Une erreur courante pour de telles
6700 questionnaires est les constructions du type « if you answer
6709 sélection/multi-sélection
6715 La description courte est une invite et NON un titre. N'utilisez
6716 PAS des constructions inutiles du type « Please
6717 choose... ». Les utilisateurs sont assez intelligents pour
6718 réaliser qu'ils doivent choisir quelque chose...:)
6723 La description étendue devra compléter la description
6724 courte. Elle peut se référer aux choix disponibles. Elle peut
6725 également mentionner que l'utilisateur peut choisir plus d'un des
6726 choix disponibles si le questionnaire est du type sélection
6727 multiple (bien que l'interface rende souvent cela clair).
6741 La description courte devrait être considéré comme un *titre*.
6746 La description étendue est ce qui sera affiché comme une
6747 description plus détaillée de la note. Faites des phrases,
6748 n'utilisez pas un style d'écriture trop concis.
6753 N'ABUSEZ PAS DE DEBCONF. Les notes sont le moyen le plus courant
6754 d'abus de debconf. Comme il est écrit dans la page de manuel de
6755 debconf-devel : il est préférable de ne les utiliser que
6756 pour des avertissements à propos de problèmes très sérieux. Les
6757 fichiers NEWS.Debian ou README.Debian sont les endroits
6758 appropriés pour un grand nombre de notes. Si, en lisant ceci,
6759 vous envisagez de convertir vos modèles de type note en entrées
6760 dans NEWS/Debian ou README.Debian, veuillez considérer de
6761 conserver les traductions existantes pour une utilisation future.
6773 S'il est probable que les choix changent souvent, veuillez considérer
6774 l'utilisation de l'astuce « __Choices ». Cela séparera
6775 chaque choix individuel en une chaîne de caractères seule, ce qui
6776 aidera considérablement les traducteurs à faire leur travail.
6784 S'il est probable que la valeur par défaut d'un modèle
6785 « select » change selon la langue de l'utilisateur (par
6786 exemple, s'il s'agit d'un choix de langue), veuillez utiliser
6787 l'astuce « _DefaultChoice ».
6790 Ce champ spécial permet aux traducteurs de positionner le choix le
6791 plus approprié selon leur propre langue. Cela deviendra le choix par
6792 défaut quand leur langue sera sélectionnée alors votre choix par
6793 défaut sera utilisé pour l'anglais.
6796 Un exemple tiré des modèles du paquet geneweb :
6798 Template: geneweb/lang
6800 __Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
6801 # This is the default choice. Translators may put their own language here
6802 # instead of the default.
6803 # WARNING : you MUST use the ENGLISH FORM of your language
6804 # For instance, the french translator will need to put "French (fr)" here.
6805 _DefaultChoice: English (en)[ translators, please see comment in PO files]
6806 _Description: Geneweb default language:
6810 Notez l'utilisation de crochets qui permettent des commentaires
6811 internes dans les champs debconf. Notez également l'utilisation de
6812 commentaires qui apparaîtront dans les fichiers sur lesquels
6813 travailleront les traducteurs.
6816 Les commentaires sont nécessaires car l'astuce DefaultChoice est un
6817 peu déroutante : les traducteurs peuvent y placer leur propre
6826 N'utilisez PAS de champ par défaut vide. Si vous ne voulez pas
6827 utiliser de valeurs par défaut, n'utilisez simplement pas du tout
6831 Si vous utilisez po-debconf (et vous DEVRIEZ le faire, voir 2.2),
6832 veuillez considérer de rendre ce champ traduisible, si vous pensez
6833 qu'il peut être traduit.
6836 Si la valeur par défaut peut varier selon la langue ou le pays (par
6837 exemple, la valeur par défaut pour un choix de langue), veuillez
6838 considérer l'utilisation du type spécial « _DefaultChoice »
6839 documenté dans <manref section="7" name="po-debconf">).
6844 <sect id="bpp-i18n">
6846 Internationalisation
6848 <sect1 id="bpp-i18n-debconf">
6850 Gestion des traductions de debconf
6853 Comme les porteurs, les traducteurs ont une tâche difficile. Ils
6854 travaillent sur un grand nombre de paquets et doivent donc collaborer
6855 avec plusieurs responsables différents. De plus, la plupart du temps,
6856 l'anglais n'est pas leur langue maternelle, il se peut que vous deviez
6857 être particulièrement patient avec eux.
6860 Le but de <package>debconf</package> était de faciliter la
6861 configuration des paquets aux responsables et aux utilisateurs. À
6862 l'origine, les traductions des questionnaires debconf étaient gérées
6863 avec <prgn>debconf-mergetemplate</prgn>. Cependant, cette technique
6864 est maintenant déconseillée ; la meilleure façon pour
6865 l'internationalisation de <package>debconf</package> est d'utiliser le
6866 paquet <package>po-debconf</package>. Cette méthode est plus facile
6867 pour le responsable et pour les traducteurs ; des scripts de
6868 transition sont fournis.
6871 Lors de l'utilisation de <package>po-debconf</package>, la traduction
6872 est stockée dans des fichiers <file>po</file> (à l'instar des
6873 techniques de traduction de <prgn>gettext</prgn>). Des fichiers
6874 modèles contiennent les messages d'origine et indiquent quels sont les
6875 champs traduisibles. Quand vous modifiez l'état d'un champ traduisible
6876 en appelant <prgn>debconf-updatepo</prgn>, la traduction est marquée
6877 comme ayant besoin de l'attention des traducteurs. Puis, lors de la
6878 construction du paquet, le programme <prgn>dh_installdebconf</prgn>
6879 prendra soin de toute la magie nécessaire à l'ajout du modèle avec les
6880 traductions à jour dans les paquets binaires. Veuillez vous reporter à
6881 la page de manuel <manref section="7" name="po-debconf"> pour les
6885 <sect1 id="bpp-i18n-docs">
6887 Documentation traduite
6890 La traduction de la documentation est cruciale pour les utilisateurs,
6891 mais elle représente un important travail. Il n'existe aucun moyen
6892 d'éliminer ce travail, mais vous pouvez faciliter les choses pour les
6896 Si vous êtes responsable d'une documentation quelle que soit sa
6897 taille, il est plus facile pour les traducteurs d'avoir accès à un
6898 système de contrôle de source. Ceci permet aux traducteurs de voir les
6899 différences entre deux versions de la documentation, pour, par
6900 exemple, qu'ils puissent voir ce qui a besoin d'être retraduit. Il est
6901 recommandé que le document traduit inclue une note à propos de la
6902 révision de contrôle du source sur laquelle la traduction est
6903 basée. Un système intéressant est fourni par <url
6904 id="&url-i18n-doc-check;" name="doc-check"> dans le paquet
6905 <package>boot-floppies</package> qui donne un aperçu de l'état de la
6906 traduction pour une langue donnée, en utilisant les commentaires
6907 structurés pour une révision donnée du fichier à traduire et, pour un
6908 fichier traduit, la révision du fichier d'origine sur laquelle la
6909 traduction est basée. Vous pouvez vouloir adapter et fournir ceci dans
6910 votre référentiel CVS.
6913 Si vous maintenez de la documentation au format XML ou SGML, nous vous
6914 suggérons d'isoler les informations indépendantes de la langue et de
6915 les définir comme des entités dans un fichier séparé qui sera inclus
6916 par les différentes traductions. Ceci aide, par exemple, à garder à
6917 jour les adresses pour plusieurs fichiers.
6921 <sect id="bpp-common-situations">
6923 Pratiques communes d'empaquetage
6925 <sect1 id="bpp-autotools">
6927 Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
6930 Conserver à jour les fichiers d'<prgn>autoconf</prgn>,
6931 <file>config.sub</file> et <file>config.guess</file>, est critique
6932 pour les porteurs, spécialement pour les architectures plus
6933 changeantes. De très bonnes pratiques d'empaquetage utilisant
6934 <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été regroupées
6935 dans &file-bpp-autotools; du paquet
6936 <package>autotools-dev</package>. Vous êtes vivement encouragé à lire
6937 ce fichier et à suivre les recommandations indiquées.
6940 <sect1 id="bpp-libraries">
6945 Pour diverses raisons, il a toujours été difficile d'empaqueter les
6946 bibliothèques. La charte impose plusieurs contraintes pour faciliter
6947 la maintenance et pour garantir que les mises à jour sont aussi
6948 simples que possible quand une nouvelle version amont est
6949 disponible. Une erreur dans une bibliothèque peut rendre défectueux
6950 une douzaine de paquets qui en dépendent.
6953 Les bonnes pratiques d'empaquetage des bibliothèques ont été
6954 regroupées dans <url id="&url-libpkg-guide;" name="le guide
6955 d'empaquetage des bibliothèques">.
6958 <sect1 id="bpp-docs">
6963 Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html"
6964 name="règles sur la documentation">.
6967 Si votre paquet contient de la documentation construite à partir de
6968 XML ou SGML, nous vous recommandons de ne pas fournir le source XML ou
6969 SGML dans le(s) paquet(s) binaire(s). Si les utilisateurs désirent
6970 avoir le source de la documentation, ils peuvent récupérer le paquet
6974 La Charte spécifie que la documentation doit être fournie au format
6975 HTML. Nous vous recommandons également de la fournir au format PDF et
6976 texte simple si c'est adapté et qu'une sortie de qualité raisonnable
6977 est possible. Cependant, il n'est généralement pas approprié de
6978 fournir des versions en texte simple pour la documentation dont le
6979 format source est du HTML.
6982 Les principaux manuels fournis devraient être enregistrés par le
6983 paquet <package>doc-base</package> à l'installation. Reportez-vous à
6984 la documentation du paquet <package>doc-base</package> pour plus
6988 <sect1 id="bpp-other">
6990 Types spécifiques de paquets
6993 Plusieurs types spécifiques de paquets ont des sous-chartes spéciales
6994 et des règles et pratiques d'empaquetage correspondantes :
6998 Les paquets liés à Perl ont leur <url id="&url-perl-policy;"
6999 name="charte Perl">, quelques exemples de paquets qui suivent cette
7000 charte sont <package>libdbd-pg-perl</package> (module perl binaire)
7001 ou <package>libmldbm-perl</package> (module perl indépendant de
7007 Les paquets liés à Python ont leur charte Python ; voir
7008 &file-python-policy; dans le paquet <package>python</package>.
7013 Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;"
7014 name="charte Emacs">.
7019 Les paquets liés à Java ont leur <url id="&url-java-policy;"
7020 name="charte Java">.
7025 Les paquets liés à Ocaml ont leur propre charte que l'on trouve
7026 dans &file-ocaml-policy; du paquet <package>ocaml</package>. Un bon
7027 exemple est le paquet source <package>camlzip</package>.
7032 Les paquets fournissant des DTD XML ou SGML devraient se conformer
7033 aux recommandations que l'on peut trouver dans le paquet
7034 <package>sgml-base-doc</package>
7039 Les paquets Lisp devraient s'enregistrer avec le paquet
7040 <package>common-lisp-controller</package> pour lequel vous pouvez
7041 vous reporter au fichier &file-lisp-controller;.
7047 <sect1 id="bpp-archindepdata">
7049 Données indépendantes de l'architecture
7052 Il n'est pas rare d'avoir une grande quantité de données indépendantes
7053 de l'architecture fournie avec un programme. Par exemple, des fichiers
7054 audio, une collection d'icônes, des motifs de papiers peints ou autres
7055 fichiers graphiques. Si la taille des données est négligeable par
7056 rapport à la taille du reste du paquet, il est probablement mieux de
7057 tout garder dans le même paquet.
7060 Cependant, si la taille des données est considérable, vous devez
7061 envisager de les partager dans un paquet séparé et indépendant de
7062 l'architecture (« _all.deb »). Ainsi, en faisant cela, vous
7063 évitez une duplication inutile des mêmes données dans onze fichiers
7064 .debs pour chaque architecture. Bien que ceci ajoute une surcharge
7065 supplémentaire aux fichiers <file>Packages</file>, ceci sauve beaucoup
7066 d'espace disque sur les miroirs Debian. Séparer les données
7067 indépendantes de l'architecture réduit également le temps de
7068 traitement de <prgn>lintian</prgn> ou de <prgn>linda</prgn> (voir <ref
7069 id="tools-lint">) quand ils sont exécutés sur l'ensemble de l'archive
7073 <sect1 id="bpp-locale">
7075 Avoir besoin d'une certaine locale pendant la construction
7078 Si vous avez besoin d'une certaine locale pendant la construction,
7079 vous pouvez créer un fichier temporaire par cette astuce :
7082 Si vous positionnez LOCPATH à l'équivalent de /usr/lib/locale, et
7083 LC_ALL au nom de la locale que vous générez, vous devriez obtenir ce
7084 que vous voulez sans être root. Quelque chose comme ceci :
7086 LOCALE_PATH=debian/tmpdir/usr/lib/locale
7088 LOCALE_CHARSET=UTF-8
7090 mkdir -p $LOCALE_PATH
7091 localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
7094 LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
7098 <sect1 id="bpp-transition">
7100 Rendre les paquets de transition conformes avec deborphan
7103 Deborphan est un programme pour aider les utilisateurs à détecter
7104 quels paquets peuvent être enlevés sans problème du système, i.e. ceux
7105 dont aucun paquet ne dépend. L'opération par défaut est de chercher
7106 seulement parmi les sections libs et oldlibs pour débusquer les
7107 bibliothèques inutilisées. Mais si l'on passe le bon argument, il
7108 tente d'attraper d'autres paquets inutiles.
7111 Par exemple, avec --guess-dummy, deborphan cherche tous les paquets de
7112 transition qui étaient nécessaires pour une mise à jour, mais qui
7113 peuvent sans problème être supprimés. Pour cela, il recherche la
7114 chaîne de caractères « dummy » ou « transitional »
7115 dans la description courte.
7118 Ainsi, quand vous créez un tel paquet, assurez-vous d'ajouter ce texte
7119 dans la description courte. Si vous cherchez des exemples, exécutez
7121 <example>apt-cache search .|grep dummy</example>
7123 <example>apt-cache search .|grep transitional</example>
7127 <sect1 id="bpp-origtargz">
7129 Les meilleures pratiques pour les fichiers <file>orig.tar.gz</file>
7132 Il existe deux types d'archives tar (« tarball ») source
7133 d'origine : les sources vierges et les sources amont
7136 <sect2 id="pristinesource">
7141 La caractéristique définissant une archive source vierge est que le
7142 fichier .orig.tar.gz est identique octet-pour-octet à l'archive tar
7143 officielle distribuée par l'auteur amont. <footnote><p>Nous ne
7144 pouvons pas empêcher les auteurs amont de changer l'archive tar
7145 qu'ils distribuent sans également incrémenter le numéro de version,
7146 il ne peut donc pas y avoir de garantie qu'une archive vierge est
7147 identique à ce que l'auteur amont distribue <em>actuellement</em> à
7148 tout moment. La seule chose à laquelle on peut s'attendre est que
7149 c'est identique à quelque chose que l'amont <em>a</em> un jour
7150 distribuée. Si une différence se produit plus tard (par exemple, si
7151 l'amont remarque qu'il n'a pas utilisé la compression maximale pour
7152 sa distribution d'origine et qu'il la recompresse), c'est vraiment
7153 trop dommage. Comme il n'y a pas de bonne façon d'envoyer un nouveau
7154 .orig.tar.gz pour la même version, il n'y a même pas de raison de
7155 traiter cette situation comme un bogue.</p></footnote> Cela rend
7156 possible d'utiliser des vérifications de somme pour vérifier
7157 facilement que tous les changements entre la version Debian et celle
7158 de l'amont sont contenus dans le fichier diff Debian. Également, si
7159 le source amont est énorme, les auteurs amont et d'autres qui ont
7160 déjà l'archive tar amont peuvent économiser du temps de
7161 téléchargement s'ils veulent inspecter votre empaquetage en détail.
7164 Il n'y a pas de règles universellement acceptées suivies par les
7165 auteurs amont concernant la structure des répertoires dans leur
7166 archive tar, mais <prgn>dpkg-source</prgn> est cependant capable de
7167 traiter la plupart des archives tar comme source vierge. Sa stratégie
7168 est équivalente à la suivante :
7171 <enumlist numeration="arabic">
7174 Il décompacte l'archive tar dans un répertoire temporaire vide par
7176 zcat chemin/vers/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf -</example>
7181 Si, après cela, le répertoire temporaire ne contient qu'un
7182 répertoire et pas d'autres fichiers, <prgn>dpkg-source</prgn>
7183 renomme ce répertoire en
7184 <tt><packagename>-<version-amont>(.orig)</tt>. Le nom
7185 du répertoire de premier niveau dans l'archive tar n'a pas
7186 d'importance et est oublié.
7191 Sinon, l'archive tar a dû être empaqueté sans répertoire de
7192 premier niveau commun (honte à l'auteur amont !). Dans ce
7193 cas, <prgn>dpkg-source</prgn> renomme le répertoire temporaire
7194 <em>lui-même</em> en
7195 <tt><packagename>-<version-amont>(.orig)</tt>.
7201 <sect2 id="repackagedorigtargz">
7203 Réempaquetage des sources amont
7206 Vous <strong>devriez</strong> envoyer des paquets sources avec une
7207 archive tar vierge si possible, mais il peut y avoir diverses raisons
7208 pour lesquelles cela n'est pas possible. C'est le cas si l'amont ne
7209 distribue pas le source comme un tar gzipé du tout ou si l'archive
7210 tar amont contient du matériel non libre au sens des DFSG que vous
7211 devez supprimer avant l'envoi.
7214 Dans tous ces cas, le développeur doit construire un fichier
7215 .orig.tar.gz convenable lui-même. Nous nous référerons à une telle
7216 archive tar comme un « source amont réempaqueté ». Notez
7217 qu'un « source amont réempaqueté » est différent d'un
7218 paquet natif Debian. Un source réempaqueté est toujours fourni avec
7219 des changements spécifiques Debian dans un fichier <tt>.diff.gz</tt>
7220 séparé et il a toujours un numéro de version composé de
7221 <tt><source-amont></tt> et de <tt><debian-revision></tt>.
7224 Il peut y avoir des cas où il est souhaitable de réempaqueter le
7225 source même si l'amont distribue un fichier <tt>.tar.gz</tt> qui
7226 pourrait en principe être utilisé dans sa forme vierge. Le plus
7227 évident est si des économies d'espaces <em>significatives</em>
7228 peuvent être réalisées en recompressant l'archive tar ou en
7229 supprimant des parties fondamentalement inutiles de l'archive
7230 source. Agissez à votre guise à cet endroit, mais soyez prêt à
7231 défendre votre décision si vous réempaquetez un source qui aurait pu
7235 Un .orig.tar.gz réempaqueté :
7238 <enumlist numeration="arabic">
7241 <strong>doit</strong> contenir des informations détaillées sur la
7242 façon dont a été obtenu le source réempaqueté et comment cela peut
7243 être reproduit dans le fichier <file>README.Debian-source</file>
7244 ou un fichier similaire. Ce fichier devrait être dans la partie
7245 <file>diff.gz</file> du paquet source Debian, habituellement dans
7246 le répertoire <file>debian</file>, <em>pas</em> dans le
7247 <file>orig.tar.gz</file> réempaqueté. C'est également une bonne
7248 idée de fournir une cible <tt>get-orig-source</tt> dans votre
7249 fichier <file>debian/rules</file> qui répète le processus, comme
7250 décrit dans la Charte, <url
7251 id="&url-debian-policy;ch-source.html#s-debianrules"
7252 name="debian/rules, le principal script de construction">.
7257 <strong>ne devrait pas</strong> contenir de fichiers qui ne
7258 viennent pas de l'auteur amont ou dont vous avez changé le
7259 contenu. <footnote><p>Comme exception spéciale, si l'omission d'un
7260 fichier non libre devait entraîner l'échec de la compilation du
7261 source sans assistance du diff Debian, il peut être approprié au
7262 lieu de cela d'éditer les fichiers, en omettant seulement les
7263 parties non libres de ceux-ci et/ou d'expliquer la situation dans
7264 un fichier README.Debian-source à la racine de l'arborescence du
7265 source. Mais dans ce cas, veuillez également demander instamment à
7266 l'auteur amont de faciliter la séparation des composants non
7267 libres du reste du source.</p></footnote>
7272 <strong>devrait</strong>, sauf cas impossible pour des raisons
7273 légales, préserver l'infrastructure de construction entière et de
7274 portabilité fournie par l'auteur amont. Par exemple, ce n'est pas
7275 une raison suffisante pour omettre un fichier qui n'est utilisé
7276 que pour la construction sur MS-DOS. De manière similaire, un
7277 Makefile fourni par l'amont ne devrait pas être réécrit en
7278 exécutant un script configure.
7281 (<em>Explication :</em> il est courant que les utilisateurs
7282 Debian qui ont besoin de reconstruire un logiciel pour des
7283 plates-formes non-Debian récupèrent le source d'un miroir Debian
7284 plutôt que de chercher à localiser un point de distribution
7290 <strong>devrait</strong> utiliser
7291 <tt><nom-du-paquet>-<version-amont>.orig</tt> comme
7292 nom du répertoire de premier niveau dans son archive tar. Cela
7293 rend possible la distinction entre des archives tar vierges
7294 d'archives réempaquetées.
7299 <strong>devrait</strong> être gzipé avec une compression maximale.
7305 La façon canonique de réaliser les deux derniers points est de
7306 laisser <tt>dpkg-source -b</tt> construire l'archive tar réempaquetée
7307 à partir du répertoire décompacté.
7310 <sect2 id="changed-binfiles">
7312 Changer des fichiers binaires dans le <tt>diff.gz</tt>
7315 Il est parfois nécessaire de changer des fichiers binaires contenus
7316 dans l'archive tar d'origine ou d'ajouter des fichiers binaires qui
7317 ne sont pas dans celle-ci. Si cela est fait en copiant simplement les
7318 fichiers dans l'arborescence de l'archive debianisée,
7319 <prgn>dpkg-source</prgn> ne pourra pas gérer cela. D'un autre côté,
7320 selon les règles détaillées ci-dessus, vous ne pouvez pas inclure un
7321 tel fichier binaire modifié dans un fichier <file>orig.tar.gz</file>
7322 réempaqueté. Au lieu de cela, incluez le fichier dans le répertoire
7323 <file>debian</file> dans un format <prgn>uuencode</prgn> (ou
7324 semblable) <footnote><p>Le fichier devrait avoir un nom qui indique
7325 clairement quel fichier binaire il encode. Habituellement, un
7326 postfixe indiquant le codage devrait être ajouté au nom du fichier
7327 d'origine.</p></footnote>. Le fichier sera ensuite décodé et copié à
7328 son emplacement pendant l'étape de construction. Le changement sera
7329 donc visible assez facilement.
7332 Certains paquets utilisent <prgn>dbs</prgn> pour gérer les correctifs
7333 à leur source amont et créent toujours un nouveau fichier
7334 <tt>orig.tar.gz</tt> contenant le vrai <tt>orig.tar.gz</tt> dans son
7335 répertoire de premier niveau. Cela est discutable concernant la
7336 préférence pour un source vierge. D'un autre côté, il est facile de
7337 modifier ou d'ajouter des fichiers binaires dans ce cas : placez
7338 les simplement dans le fichier <tt>orig.tar.gz</tt> nouvellement créé
7339 à côté du vrai et copiez les au bon endroit pendant l'étape de
7346 <chapt id="beyond-pkging">
7348 Au-delà de l'empaquetage
7351 Debian, c'est beaucoup plus que de l'empaquetage de logiciels et de la
7352 maintenance de paquets. Ce chapitre contient des informations sur les
7353 façons, souvent vraiment importantes, de contribuer à Debian au-delà de
7354 la simple création et maintenance de paquets.
7357 En tant qu'organisation de volontaires, Debian repose sur la liberté de
7358 choisir ce sur quoi l'on désire travailler et de choisir la partie la
7359 plus importante à laquelle on veut consacrer son temps.
7361 <sect id="submit-bug">
7363 Rapporter des bogues
7366 Nous vous encourageons à remplir des rapports de bogue quand vous
7367 trouvez des bogues dans les paquets Debian. En fait, les développeurs
7368 Debian sont souvent les testeurs de première ligne. Trouver et
7369 rapporter les bogues dans les paquets d'autres développeurs améliore la
7373 Lisez les <url id="&url-bts-report;" name="instructions pour créer un
7374 rapport de bogue"> dans le <url id="&url-bts;" name="système de suivi
7375 des bogues"> Debian.
7378 Essayez de soumettre le bogue à partir d'un compte utilisateur normal
7379 sur lequel vous pouvez recevoir des courriers, pour que les personnes
7380 puissent vous joindre s'ils ont besoin de plus d'informations à propos
7381 du bogue. Ne soumettez pas de bogues en tant que root.
7384 Vous pouvez utiliser un outil comme <manref section="1"
7385 name="reportbug"> pour soumettre des bogues. Il peut automatiser et
7386 dans l'ensemble faciliter le processus.
7389 Assurez-vous que le bogue n'a pas déjà été rapporté. Chaque paquet
7390 dispose d'une liste de bogues facilement accessible à
7391 <tt>http://&bugs-host;/<var>nom_paquet</var></tt>. Des outils comme
7392 <manref section="1" name="querybts"> peuvent également vous fournir ces
7393 informations (et <prgn>reportbug</prgn> invoquera également
7394 habituellement <prgn>querybts</prgn> avant l'envoi).
7397 Essayez d'envoyer vos bogues au bon emplacement. Quand, par exemple,
7398 votre bogue concerne un paquet qui réécrit des fichiers d'un autre
7399 paquet, vérifiez les listes des bogues pour les <em>deux</em> paquets
7400 pour éviter de créer des rapports de bogues dupliqués.
7403 Vous pouvez également parcourir les bogues d'autres paquets, en les
7404 regroupant s'ils sont indiqués plus d'une fois, ou en les marquant avec
7405 « fixed » quand ils ont déjà été corrigés. Notez cependant
7406 que si vous n'êtes ni le rapporteur du bogue, ni le responsable du
7407 paquet, vous ne devriez pas fermer réellement le bogue (à moins que
7408 vous n'ayez obtenu la permission du responsable).
7411 De temps en temps, vous pourrez vouloir vérifier ce qui s'est passé à
7412 propos des bogues que vous avez rapportés. Saisissez cette occasion
7413 pour fermer les bogues que vous ne pouvez plus reproduire. Pour trouver
7414 tous les bogues que vous avez rapportés, vous avez simplement besoin
7416 <tt>http://&bugs-host;/from:<var><votre-adresse-de-courrier></var></tt>.
7418 <sect1 id="submit-many-bugs">
7420 Ouvrir un grand nombre de rapports en une seule fois (« mass bug
7424 Ouvrir un grand nombre de rapports pour le même problème sur un grand
7425 nombre de paquets — plus de dix — est une
7426 pratique que nous déconseillons. Prenez toutes les mesures possibles
7427 pour éviter cette situation. Si le problème peut être détecté
7428 automatiquement par exemple, ajoutez un nouveau test dans le paquet
7429 <package>lintian</package> pour générer une erreur ou un
7433 Si vous ouvrez plus de dix rapports sur le même sujet, il est
7434 préférable d'indiquer votre intention sur la liste
7435 &email-debian-devel; et de mentionner le fait dans le sujet de votre
7436 message. Cela donnera à d'autres développeurs la possibilité de
7437 vérifier que le problème existe vraiment. De plus, cela permet
7438 d'éviter que plusieurs responsables ne rédigent les mêmes rapports de
7439 bogue simultanément.
7442 Quand vous envoyez un grand nombre de rapports sur le même sujet, vous
7443 devriez les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils
7444 ne soient pas redirigés vers les listes de diffusion.
7448 <sect id="qa-effort">
7450 Effort d'assurance qualité
7452 <sect1 id="qa-daily-work">
7457 Bien qu'il y ait un groupe de personnes dédié à l'assurance qualité,
7458 les devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez
7459 participer à cet effort en conservant vos paquets aussi exempts de
7460 bogues que possible et aussi corrects que possible selon
7461 <prgn>lintian</prgn> (reportez-vous à <ref id="lintian">). Si cela
7462 vous paraît impossible, vous devriez alors envisager d'abandonner
7463 certains de vos paquets (reportez-vous à <ref id="orphaning">). Sinon,
7464 vous pouvez demander de l'aide à d'autres personnes pour qu'elles
7465 puissent rattraper votre retard dans la correction des bogues (vous
7466 pouvez demander de l'aide sur &email-debian-qa; ou
7467 &email-debian-devel;). En même temps, vous pouvez rechercher des
7468 co-responsables (reportez-vous à <ref id="collaborative-maint">).
7473 Les chasses aux bogues
7476 De temps en temps, le groupe d'assurance qualité organise des chasses
7477 aux bogues<footnote><p><em>Bug Squashing Party</em></p></footnote>
7478 pour essayer de supprimer le plus de problèmes possible. Elles sont
7479 annoncées sur &email-debian-devel-announce; et l'annonce explique quel
7480 domaine sera visé pendant la chasse : habituellement, il s'agit
7481 des bogues empêchant l'intégration du paquet dans la distribution
7482 (« Release Critical »), mais il peut arriver qu'ils décident
7483 d'aider à finir une transition majeure (comme une nouvelle version de
7484 Perl qui demande la recompilation de tous les modules binaires).
7487 Les règles pour les mises à jour indépendantes sont différentes au
7488 cours de la chasse parce que l'annonce de la chasse est considérée
7489 comme une annonce préalable pour les mises à jour indépendantes. Si
7490 vous avez des paquets qui peuvent être affectées par la chasse (parce
7491 qu'ils ont des bogues critiques par exemple), vous devriez envoyer une
7492 mise à jour pour chaque bogue correspondant pour expliquer leur état
7493 actuel et ce que vous attendez de la chasse. Si vous ne voulez pas
7494 d'une mise à jour indépendante ou si vous n'êtes intéressé que par un
7495 correctif ou si vous voulez gérer vous-même le bogue, veuillez
7496 l'expliquer dans le BTS.
7499 Les personnes qui participent à la chasse ont des règles spécifiques
7500 pour les mises à jour indépendantes, ils peuvent en faire une sans
7501 avertissement préalable s'ils envoient leur paquet avec un délai d'au
7502 moins 3 jours dans DELAYED/3-day. Toutes les autres règles de mise à
7503 jour indépendante s'appliquent comme d'habitude ; ils devraient
7504 envoyer le correctif de la mise à jour dans le BTS (pour l'un des
7505 bogues ouverts corrigé par la mise à jour ou pour un nouveau bogue
7506 marqué comme fixé). Ils devraient également respecter tout souhait du
7507 responsable s'il en a exprimé.
7510 Si vous ne vous sentez pas à l'aise avec une mise à jour indépendante,
7511 envoyez simplement un correctif au BTS. C'est de loin meilleur qu'une
7512 mise à jour défectueuse.
7516 <sect id="contacting-maintainers">
7518 Contacter d'autres responsables
7521 Pendant vos activités dans Debian, vous aurez à contacter d'autres
7522 responsables pour différentes raisons. Vous pourrez vouloir discuter
7523 d'une nouvelle façon de coopérer au sein d'un ensemble de paquets liés,
7524 ou vous pouvez simplement rappeler à quelqu'un qu'une nouvelle version
7525 est disponible et que vous en avez besoin.
7528 Chercher l'adresse d'un responsable d'un paquet peut être
7529 fastidieux. Heureusement, il existe un alias de courrier simple,
7530 <tt><paquet>@&packages-host;</tt>, qui fournit un moyen d'envoyer
7531 un courrier à un responsable, quelle que soit son adresse (ou ses
7532 adresses). Remplacez <tt><paquet></tt> par le nom du paquet
7536 Vous pouvez également vouloir contacter les personnes qui sont
7537 inscrites à un paquet de source donné par le <ref
7538 id="pkg-tracking-system">. Vous pouvez le faire en utilisant l'adresse
7539 <tt><paquet>@&pts-host;</tt>.
7544 Gérer les responsables non joignables
7547 Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous
7548 assurer que le responsable est toujours actif et qu'il continue à
7549 travailler sur ses paquets. Il est possible qu'il ne soit plus actif,
7550 mais qu'il ne se soit pas désenregistré du système. D'un autre côté, il
7551 est possible qu'il ait simplement besoin d'un rappel.
7554 Il y a un système simple (la base de données MIA) dans laquelle les
7555 informations sur les responsables supposés Absents En Exercice
7556 (« Missing In Action) sont enregistrées. Quand un membre du groupe
7557 QA contacte un responsable inactif ou trouve plus d'informations sur
7558 celui-ci, c'est enregistré dans la base de données MIA. Ce système est
7559 disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut
7560 être interrogé avec un outil de nom <prgn>mia-history</prgn>. Par
7561 défaut, <prgn>mia-history</prgn> affiche des informations sur toutes
7562 les personnes qu'il connaît, mais il accepte des expressions
7563 rationnelles comme paramètre qu'il utilise comme correspondance de noms
7565 <example>mia-history --help</example>
7566 affiche quels paramètres sont acceptés. Si vous déterminez qu'aucune
7567 information n'a encore été enregistrée pour un responsable inactif ou
7568 si vous voulez ajouter plus d'informations, vous deviez utiliser la
7572 La première étape est de contacter poliment le responsable et
7573 d'attendre une réponse pendant un temps raisonnable. Il est assez
7574 difficile de définir le « temps raisonnable », mais il est
7575 important de prendre en compte que la vraie vie est parfois assez
7576 mouvementée. Une façon de gérer cela pourrait être d'envoyer un rappel
7577 après deux semaines.
7580 Si le responsable ne répond pas après quatre semaines (un mois), on
7581 peut supposer qu'il n'y aura probablement pas de réponse. Si ceci se
7582 produit, vous devriez poursuivre vos investigations et essayer de
7583 réunir toutes les informations utiles sur ce responsable. Ceci
7590 Les informations « echelon » disponibles dans la <url
7591 id="&url-debian-db;" name="base de données LDAP des développeurs">,
7592 qui indiquent quand le développeur a envoyé un message pour la
7593 dernière fois sur une liste de diffusion Debian (cela inclut les
7594 envois via les listes debian-*-changes). Rappelez-vous également de
7595 vérifier si le responsable est indiqué comme en vacances dans la
7601 Le nombre de paquets de ce responsable et les conditions de ces
7602 paquets. En particulier, reste-t-il des bogues empêchant
7603 l'intégration du paquet dans la distribution qui sont ouverts depuis
7604 des lustres ? De plus, combien de bogues y a-t-il en
7605 général ? Un autre point d'information important est si les
7606 paquets ont subi des mises à jour indépendantes et si oui, par qui.
7611 Est-ce que le responsable est actif en dehors de Debian ? Par
7612 exemple, il peut avoir envoyé des messages récemment à des listes de
7613 diffusion non-Debian ou des groupes de discussion.
7619 Un gros problème est représenté par les paquets parrainés
7620 — le responsable n'est pas un développeur Debian
7621 officiel. Les informations « echelon » ne sont pas
7622 disponibles pour les personnes parrainées, par exemple, vous devez donc
7623 trouver et contacter le responsable Debian qui a réellement envoyé le
7624 paquet. Étant donné qu'il a signé le paquet, il est responsable de
7625 l'envoi de toute façon et il devrait savoir ce qui s'est passé avec la
7626 personne qu'il parraine.
7629 Il est également permis d'envoyer une demande à &email-debian-devel;
7630 demandant si quelqu'un est au courant d'information sur le responsable
7634 Une fois que vous avez réuni toutes ces informations, vous pouvez
7635 contacter &email-mia;. Les personnes de cet alias utiliseront les
7636 informations que vous aurez fournies pour décider comment procéder. Par
7637 exemple, ils peuvent abandonner un ou tous les paquets du
7638 responsable. Si un paquet a subi une mise à jour indépendante, ils
7639 peuvent préférer contacter le responsable ayant fait cette mise à jour
7640 — il est peut-être intéressé par le paquet.
7643 Un dernier mot : veuillez vous souvenir d'être poli. Nous sommes
7644 tous des volontaires et nous ne pouvons dédier l'intégralité de notre
7645 temps à Debian. Vous n'êtes pas non plus au courant des circonstances
7646 de la personne impliquée. Elle est peut-être sérieusement malade ou
7647 pourrait même nous avoir quitté — vous ne savez pas qui
7648 recevra vos courriers. Imaginez comme un proche se sentira s'il lit un
7649 courrier pour la personne décédée et trouve un message très impoli, en
7650 colère et accusateur !
7653 D'un autre côté, bien que nous soyons tous volontaires, nous avons une
7654 responsabilité. Vous pouvez donc insister sur l'importance du plus
7655 grand intérêt — si un responsable n'a plus le temps ou
7656 l'envie, il devrait « laisser filer » et donner le paquet à
7657 quelqu'un ayant plus de temps.
7660 <sect id="newmaint">
7662 Interagir avec de futurs développeurs Debian
7665 Le succès de Debian dépend de sa capacité à attirer et retenir de
7666 nouveaux et talentueux volontaires. Si vous êtes un développeur
7667 expérimenté, nous vous recommandons de vous impliquer dans le processus
7668 d'apport des nouveaux responsables. Cette section décrit comment aider
7669 les futurs développeurs.
7671 <sect1 id="sponsoring">
7673 Parrainer des paquets
7676 Parrainer un paquet veut dire envoyer un paquet pour un responsable
7677 qui n'est pas encore autorisé à le faire lui-même, un candidat nouveau
7678 responsable. Parrainer un paquet veut aussi dire que vous en acceptez
7682 Les nouveaux responsables ont habituellement certaines difficultés à
7683 créer des paquets Debian — ceci est bien
7684 compréhensible. C'est pourquoi le parrain est là pour vérifier que le
7685 paquet parrainé est assez bon pour être inclus dans Debian. (Notez que
7686 si le paquet parrainé est nouveau, les ftpmasters devront également
7687 l'inspecter avant de l'intégrer)
7690 Effectuer un parrainage en signant simplement l'envoi ou en
7691 recompilant le paquet <strong>n'est définitivement pas
7692 recommandé</strong>. Vous devez construire le paquet source comme si
7693 vous vouliez construire l'un de vos paquets. Rappelez-vous que cela ne
7694 change rien si vous avez laissé le nom du candidat développeur dans le
7695 changelog et dans le fichier de contrôle, il est toujours possible de
7696 savoir que c'est vous qui avez fait l'envoi.
7699 Si vous êtes un gestionnaire de candidature pour un futur développeur,
7700 vous pouvez également être son parrain. Ainsi, vous pourrez vérifier
7701 comment le candidat gère la partie « Tâches et
7702 Capacités »<footnote><p>Tasks and Skills</p></footnote> de sa
7708 Gérer les paquets parrainés
7711 En envoyant un paquet sponsorisé vers Debian, vous certifiez que le
7712 paquet atteint les standards minimum de Debian. Ceci implique que vous
7713 devez construire et tester le paquet sur votre propre système avant
7717 Vous ne pouvez pas simplement envoyer un fichier <file>.deb</file>
7718 binaire d'un filleul. En théorie, vous devriez seulement demander le
7719 fichier diff et l'emplacement de l'archive source d'origine et ensuite
7720 vous devriez récupérer le source et appliquer le diff vous-même. En
7721 pratique, vous pouvez vouloir utiliser le paquet source construit par
7722 votre filleul. Dans ce cas, vous devez vérifier qu'il n'a pas modifié
7723 les fichiers sources du fichier <file>.orig.tar.gz</file> qu'il
7727 N'ayez pas peur de répondre au filleul et de lui indiquer les
7728 changements qu'il doit faire. Cela prend souvent plusieurs échanges de
7729 courriers avant que le paquet ne soit dans un état acceptable. Être un
7730 parrain veut dire être un mentor.
7733 Une fois que le paquet a atteint les standards Debian, construisez et
7734 signez le paquet avec
7735 <example>dpkg-buildpackage -k<var>KEY-ID</var></example>
7736 avant de l'envoyer dans le répertoire incoming. Bien sûr, vous pouvez
7737 également utiliser toute partie de votre <var>KEY-ID</var>, tant
7738 qu'elle est unique dans votre porte-clés secret.
7741 Le champ Maintainer du fichier <file>control</file> et le fichier
7742 <file>changelog</file> devraient afficher la personne qui a fait
7743 l'empaquetage, c'est-à-dire, le filleul. Celui-ci recevra donc tous
7744 les courriers du système de suivi des bogues (BTS) à propos de son
7748 Si vous préférez laisser une trace plus visible de votre travail de
7749 parrainage, vous pouvez ajouter une ligne l'indiquant dans la plus
7750 récente entrée du changelog.
7753 Vous êtes encouragé à garder un œil sur le suivi des paquets que
7754 vous parrainez en utilisant le <ref id="pkg-tracking-system">.
7759 Recommander un nouveau développeur
7762 Reportez-vous à la page sur les <url id="&url-newmaint-advocate;"
7763 name="recommandations pour un développeur prospectif"> sur le site web
7769 Gérer les candidatures des nouveaux candidats
7772 Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;"
7773 name="liste à vérifier pour les responsables de candidatures"> sur le
7781 Internationalisation, traduction, être internationalisé et être traduit
7784 Debian prend en charge un nombre toujours croissant de langues
7785 naturelles. Même si l'anglais est votre langue maternelle et que vous ne
7786 parlez pas d'autre langue, il est de votre devoir de responsable d'être
7787 conscient des problèmes d'internationalisation (abrégé en i18n à cause
7788 des 18 lettres entre le i et le n dans internationalisation). C'est
7789 pourquoi, même si des programmes seulement en anglais vous suffisent,
7790 vous devriez lire la plupart de ce chapitre.
7793 Selon l'<url id="http://www.debian.org/doc/manuals/intro-i18n/"
7794 name="introduction à l'i18n"> de Tomohiro KUBOTA, « I18N
7795 (internationalisation) veut dire la modification d'un logiciel ou de
7796 technologies liées pour qu'un logiciel puisse potentiellement gérer des
7797 langues multiples, des conventions multiples et ainsi de suite dans le
7798 monde entier » alors que « L10N (localisation) veut dire
7799 l'implémentation dans une langue spécifique pour un logiciel déjà
7800 internationalisé ».
7803 La l10n et l'i18n sont interconnectées, mais les difficultés liées à
7804 chacune sont très différentes. Il n'est pas vraiment difficile de
7805 permettre à un programme de changer la langue dans laquelle sont
7806 affichés les textes selon les paramètres de l'utilisateur, mais il est
7807 très coûteux en temps de traduire réellement ces messages. D'un autre
7808 côté, définir le codage des caractères est trivial, mais adapter le code
7809 pour utiliser des codages de caractères différents est un problème
7813 En laissant de côté les problèmes d'i18n pour lesquels il n'existe pas
7814 de règle générale, il n'y a pas actuellement d'infrastructure
7815 centralisée pour la l10n dans Debian qui puisse être comparée au
7816 mécanisme dbuild pour le portage. Le plus gros du travail doit donc être
7817 réalisé manuellement.
7819 <sect id="l10n-handling">
7821 Comment sont gérées les traductions au sein de Debian
7824 La gestion des traductions des textes contenus dans un paquet est
7825 encore une tâche manuelle et le processus dépend du type de texte que
7826 vous désirez voir traduit.
7829 Pour les messages des programmes, l'infrastructure gettext est utilisée
7830 pour la plupart d'entre eux. La plupart du temps, la traduction est
7831 gérée en amont dans des projets comme le <url
7832 id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="projet de
7833 traduction libre">, le <url
7834 id="http://developer.gnome.org/projects/gtp/" name="projet de
7835 traduction de Gnome"> ou <url id="http://i18n.kde.org/" name="celui de
7836 KDE">. La seule ressource centralisée dans Debian est les <url
7837 id="http://www.debian.org/intl/l10n/" name="statistiques de traduction
7838 Debian centralisées"> où vous pouvez trouver des statistiques sur les
7839 fichiers de traduction trouvés dans les paquets, mais il n'y a aucune
7840 infrastructure pour faciliter le processus de traduction.
7843 Un effort pour traduire les descriptions de paquet a démarré il y a
7844 longtemps, même si les outils fournissent très peu de prise en charge
7845 pour les utiliser vraiment (i.e., seul APT peut les utiliser quand il
7846 est configuré convenablement). Les responsables n'ont rien à faire de
7847 particulier pour gérer les traductions des descriptions de
7848 paquets ; les traducteurs devraient utiliser le <url
7849 id="http://ddtp.debian.org/" name="DDTP">.
7852 Pour les questionnaires debconf, les responsable devraient utiliser le
7853 paquet po-debconf pour faciliter le travail des traducteurs, qui
7854 peuvent utiliser le DDTP pour faire leur travail (mais les équipes
7855 française et brésilienne ne le font pas). On peut trouver certaines
7856 statistiques à la fois sur le site du DDTP (à propos de ce qui est
7857 vraiment traduit) et sur le site des <url
7858 id="http://www.debian.org/intl/l10n/" name="statistiques de traduction
7859 Debian centralisées"> (à propos de ce qui est intégré dans les
7863 Pour les pages web, chaque équipe l10n a accès au CVS correspondant et
7864 les statistiques sont disponibles sur le site des statistiques de
7865 traduction Debian centralisées.
7868 Pour la documentation générale à propos de Debian, le processus est
7869 plus ou moins le même que pour les pages web (les traducteurs ont accès
7870 au CVS), mais il n'y a pas de page de statistiques.
7873 Pour la documentation spécifique aux paquets (pages de manuel,
7874 documents info, autres formats), presque tout est encore à faire.
7877 Le plus notablement, le projet KDE gère la traduction de ses
7878 documentations de la même façon que ses messages de programme.
7881 Il existe un effort pour gérer les pages de manuel spécifiques Debian
7883 id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="dépôt CVS
7887 <sect id="l10n-faqm">
7889 FAQ I18N & L10N pour les responsables
7892 Voici une liste des problèmes que les responsables peuvent rencontrer
7893 concernant l'i18n et la l10n. Lorsque vous lirez cela, gardez à
7894 l'esprit qu'il n'y a pas de consensus sur ces points au sein de Debian
7895 et que ce ne sont que des conseils. Si vous avez une meilleure idée
7896 pour un problème donné ou si vous êtes en désaccord avec certains
7897 points, vous êtes libre de fournir vos impressions pour que ce document
7898 puisse être amélioré.
7900 <sect1 id="l10n-faqm-tr">
7902 Comment faire en sorte qu'un texte soit traduit
7905 Pour traduire des descriptions de paquet ou des questionnaires
7906 debconf, vous n'avez rien à faire, l'infrastructure du DDTP répartira
7907 le matériel à traduire aux volontaires sans besoin d'interaction de
7911 Pour tous les autres matériels (fichiers gettext, pages de manuel ou
7912 autre documentation), la meilleure solution est de placer votre texte
7913 quelque part sur l'Internet et de demander sur debian-i18n la
7914 traduction dans différentes langues. Certains membres des équipes de
7915 traduction sont abonnés à cette liste et ils prendront soin de la
7916 traduction et du processus de relecture. Une fois qu'ils ont fini,
7917 vous recevrez de leur part votre document traduit dans votre boîte aux
7921 <sect1 id="l10n-faqm-rev">
7923 Comment faire en sorte qu'une traduction donnée soit relue
7926 De temps en temps, des personnes indépendantes traduiront certains
7927 textes inclus dans votre paquet et vous demanderont d'inclure la
7928 traduction dans le paquet. Cela peut devenir problématique si vous
7929 n'êtes pas familier avec la langue donnée. C'est une bonne idée
7930 d'envoyer le document à la liste de diffusion l10n correspondante en
7931 demandant une relecture. Une fois celle-ci faite, vous devriez avoir
7932 plus confiance dans la qualité de la traduction et l'inclure sans
7933 crainte dans votre paquet.
7936 <sect1 id="l10n-faqm-update">
7938 Comment faire en sorte qu'une traduction donnée soit mise à jour
7941 Si vous avez certaines traductions d'un texte donné qui traînent,
7942 chaque fois que vous mettez à jour l'original, vous devriez demander
7943 au précédent traducteur de mettre à jour sa traduction avec vos
7944 nouveaux changements. Gardez à l'esprit que cette tâche demande du
7945 temps ; au moins une semaine pour obtenir une mise à jour relue.
7948 Si votre traducteur ne répond pas, vous pouvez demander de l'aide sur
7949 la liste de diffusion correspondante. Si tout échoue, n'oubliez pas de
7950 mettre un avertissement dans le document traduit, indiquant que la
7951 traduction est un peu obsolète et que le lecteur devrait se référer au
7952 document d'origine si possible.
7955 Évitez de supprimer complètement une traduction à cause de son
7956 obsolescence. Un vieux document est souvent mieux que pas de
7957 documentation du tout pour les personnes non anglophones.
7960 <sect1 id="l10n-faqm-bug">
7962 Comment gérer un rapport de bogue concernant une traduction
7965 La meilleure solution peut être de marquer le bogue comme « suivi
7966 au développeur amont » (<em>forwarded to upstream</em>) et de
7967 faire suivre le bogue à la fois au précédent traducteur et à son
7968 équipe (en utilisant la liste de diffusion debian-l10n-XXX
7973 <sect id="l10n-faqtr">
7975 FAQ I18N & L10N pour les traducteurs
7978 Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de procédure
7979 générale dans Debian concernant ces points et que, dans tous les cas,
7980 vous devriez collaborer avec votre équipe et les responsables des
7983 <sect1 id="l10n-faqtr-help">
7985 Comment aider l'effort de traduction
7988 Choisissez ce que vous désirez traduire, assurez-vous que personne ne
7989 travaille déjà dessus (en utilisant votre liste de diffusion
7990 debian-l10n-XXX), traduisez-le, faites-le relire par d'autres
7991 personnes dont c'est également la langue maternelle sur votre liste de
7992 diffusion l10n et fournissez-le au responsable du paquet (voir le
7996 <sect1 id="l10n-faqtr-inc">
7998 Comment fournir une traduction pour inclusion dans un paquet
8001 Assurez-vous que votre traduction est correcte (en demandant une
8002 relecture sur votre liste de discussion l10n) avant de la fournir pour
8003 inclusion. Cela gagnera du temps à tout le monde et évitera le chaos
8004 qui résulterait d'avoir plusieurs versions du même document dans les
8008 La meilleure solution est de créer un rapport de bogue standard
8009 contenant la traduction sur le paquet. Assurez-vous d'utiliser
8010 l'étiquette « patch » et n'utilisez pas une gravité
8011 supérieure à « wishlist » car l'absence de traduction n'a
8012 jamais empêché un programme de fonctionner.
8016 <sect id="l10n-best">
8018 Meilleures pratiques actuelles concernant la l10n
8024 En tant que responsable, ne modifiez jamais les traductions en
8025 aucune façon (même pour reformater l'affichage) sans demander à la
8026 liste de diffusion l10n correspondante. Vous risquez, par exemple,
8027 de casser le codage du fichier en agissant ainsi. De plus, ce que
8028 vous considérez comme une erreur peut être correct (ou même
8029 nécessaire) pour une langue donnée.
8034 En tant que traducteur, si vous trouvez une erreur dans le texte
8035 d'origine, assurez-vous de l'indiquer. Les traducteurs sont souvent
8036 les lecteurs les plus attentifs d'un texte donné et s'ils ne rendent
8037 pas compte des erreurs qu'ils trouvent, personne ne le fera.
8042 Dans tous les cas, rappelez-vous que le problème principal avec la
8043 l10n est qu'elle demande la coopération de plusieurs personnes et
8044 qu'il est très facile de démarrer une guerre incendiaire à propos de
8045 petits problèmes dûs à des incompréhensions. Donc, si vous avez des
8046 problèmes avec votre interlocuteur, demandez de l'aide sur la liste
8047 de diffusion l10n correspondante, sur debian-i18n ou même sur
8048 debian-devel (attention, cependant, les discussions sur la l10n
8049 tournent très souvent à l'incendie sur cette liste :)
8054 Dans tous les cas, la coopération ne peut être atteinte qu'avec un
8055 <strong>respect mutuel</strong>.
8062 <appendix id="tools">
8064 Aperçu des outils du responsable Debian
8067 Cette section contient un aperçu rapide des outils dont dispose le
8068 responsable. Cette liste n'est ni complète, ni définitive, il s'agit
8069 juste d'un guide des outils les plus utilisés.
8072 Les outils du responsable Debian sont destinés à aider les responsables
8073 et libérer leur temps pour des tâches plus cruciales. Comme le dit Larry
8074 Wall, il y a plus d'une manière de le faire.
8077 Certaines personnes préfèrent utiliser des outils de haut niveau,
8078 d'autres pas. Debian n'a pas de position officielle sur la
8079 question ; tout outil conviendra du moment qu'il fait le
8080 boulot. C'est pourquoi cette section n'a pas été conçue pour indiquer à
8081 chacun quel outil il doit utiliser ou comment il devrait faire pour
8082 gérer sa charge de responsable Debian. Elle n'est pas non plus destinée
8083 à favoriser l'utilisation d'un outil aux dépens d'un autre.
8086 La plupart des descriptions de ces outils proviennent des descriptions
8087 de leurs paquets. Vous trouverez plus d'informations dans les
8088 documentations de ces paquets. Vous pouvez aussi obtenir plus
8089 d'informations avec la commande <tt>apt-cache show
8090 <nom_paquet></tt>.
8092 <sect id="tools-core">
8097 Les outils suivants sont pratiquement nécessaires à tout responsable.
8099 <sect1 id="dpkg-dev">
8101 <package>dpkg-dev</package>
8104 Le paquet <package>dpkg-dev</package> contient les outils (y compris
8105 <prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et
8106 livrer des paquets Debian source. Ces utilitaires fournissent les
8107 fonctionnalités de bas niveau indispensables pour créer et manipuler
8108 les paquets ; en tant que tels, ils sont essentiels à tout
8112 <sect1 id="debconf">
8114 <package>debconf</package>
8117 Le paquet <package>debconf</package> fournit une interface unifiée
8118 pour configurer les paquets interactivement. Il est indépendant de
8119 l'interface et permet une configuration en mode texte, par une
8120 interface HTML ou par boîtes de dialogue. D'autres types d'interface
8121 peuvent être ajoutés sous forme de modules.
8124 Vous trouverez la documentation de ce paquet dans le paquet
8125 <package>debconf-doc</package>.
8128 Beaucoup pensent que ce système devrait être utilisé pour tout paquet
8129 nécessitant une configuration interactive ; reportez-vous à la
8130 <ref id="bpp-config-mgmt">. <package>debconf</package> n'est pas
8131 requis par la <em>charte Debian</em> pour le moment ; cependant,
8132 cela pourra changer.
8135 <sect1 id="fakeroot">
8137 <package>fakeroot</package>
8140 <package>fakeroot</package> simule les privilèges <em>root</em>. Cela
8141 permet de fabriquer un paquet sans être root (en général, les paquets
8142 installent des fichiers appartenant à <em>root</em>). Si vous avez
8143 installé <package>fakeroot</package>, vous pouvez construire un paquet
8144 en tant que simple utilisateur avec : <tt>dpkg-buildpackage
8149 <sect id="tools-lint">
8151 Outils du paquet lint
8154 Selon le « Free On-line Dictionary of Computing » (FOLDOC),
8155 « lint » est « un outil de traitement de langage C qui
8156 contient beaucoup plus de tests complets sur le code que n'en font
8157 habituellement les compilateurs C. ». Les outils du paquet lint
8158 aide les responsables de paquet à trouver automatiquement des problèmes
8159 habituels et des violations de charte dans leurs paquets
8161 <sect1 id="lintian">
8163 <package>lintian</package>
8166 <package>lintian</package> dissèque les paquets pour y repérer des
8167 bogues et des manquements aux règles de développement. Il contient des
8168 tests automatisés pour vérifier de nombreuses règles et quelques
8172 Vous devriez récupérer la dernière version de
8173 <package>lintian</package> depuis <em>unstable</em> régulièrement et
8174 vérifier tous vos paquets. Notez que l'option <tt>-i</tt> donne des
8175 explications détaillées sur la signification de chaque erreur, la
8176 partie concernée dans la charte et le moyen habituel de régler le
8180 Veuillez vous reporter à <ref id="sanitycheck"> pour plus
8181 d'informations sur comment et quand utiliser Lintian.
8184 Vous pouvez aussi obtenir un résumé de tous les problèmes reportés par
8185 Lintian sur vos paquets à <url id="&url-lintian;">. Ces rapports
8186 contiennent la sortie de la dernière version de <prgn>lintian</prgn>
8187 pour l'ensemble de la distribution de développement
8188 (<em>unstable</em>).
8193 <package>linda</package>
8196 <package>linda</package> est un autre vérificateur de paquet. Il est
8197 semblable à <package>lintian</package>, mais il a un ensemble de tests
8198 différents. Il est écrit en Python plutôt qu'en Perl.
8201 <sect1 id="debdiff">
8203 <package>debdiff</package>
8206 <prgn>debdiff</prgn> (du paquet <package>devscripts</package>, <ref
8207 id="devscripts">) compare des listes de fichiers et des fichiers de
8208 contrôle de deux paquets. C'est un simple test de régression qui peut
8209 vous aider à remarquer si le nombre de paquets binaires a changé
8210 depuis le dernier envoi ou si autre chose a changé dans le fichier de
8211 contrôle. Bien sûr, certains des changements qu'il indique sont
8212 normaux, mais il peut aider à empêcher différents accidents.
8215 Vous pouvez l'exécuter sur un couple de paquets binaires :
8217 debdiff package_1-1_arch.deb package_2-1_arch.deb
8221 Ou même sur un couple de fichiers de changements :
8223 debdiff package_1-1_arch.changes package_2-1_arch.changes
8227 Pour plus d'informations, veuillez voir <manref section="1"
8232 <sect id="tools-helpers">
8234 Aides pour le fichier <file>debian/rules</file>
8237 Des outils de construction de paquets rendent le processus d'écriture
8238 du fichier <file>debian/rules</file> plus facile. Veuillez voir les
8239 <ref id="helper-scripts"> pour plus d'informations sur les raisons pour
8240 lesquelles ils peuvent être désirables ou non.
8242 <sect1 id="debhelper">
8244 <package>debhelper</package>
8247 Le paquet <package>debhelper</package> regroupe un ensemble de
8248 programmes qui peuvent être utilisés dans <file>debian/rules</file>
8249 pour automatiser les tâches courantes relatives à la fabrication des
8250 paquets Debian binaires. <package>debhelper</package> inclut des
8251 programmes pour installer différents fichiers, les compresser, ajuster
8252 leurs droits et intégrer votre paquet dans le système de menu Debian.
8255 À la différence d'autres approches, <package>debhelper</package> est
8256 divisé en plusieurs petits utilitaires simples qui agissent de manière
8257 cohérente. Ce découpage permet un contrôle des opérations plus fin que
8258 certains des autres « <em>outils debian/rules</em> ».
8261 Il existe aussi un certain nombre de petites extensions
8262 <package>debhelper</package> trop éphémères pour être
8263 documentées. Vous en listerez la plupart en faisant <tt>apt-cache
8267 <sect1 id="debmake">
8269 <package>debmake</package>
8272 <package>debmake</package> — un précurseur de
8273 <package>debhelper</package> — est un assistant moins modulaire
8274 pour manipuler le fichier <file>debian/rules</file>. Il inclut deux
8275 programmes principaux : <prgn>deb-make</prgn>, utile au
8276 développeur Debian pour convertir un paquet source normal (non-Debian)
8277 en paquet source Debian, et <prgn>debstd</prgn> qui regroupe le type
8278 de fonction que l'on trouve dans <package>debhelper</package>.
8281 Le consensus actuel est que l'utilisation de
8282 <package>debmake</package> est déconseillée au profit de
8283 <package>debhelper</package>. C'est un bogue d'utiliser
8284 <package>debmake</package> pour les nouveaux paquets. Les nouveaux
8285 paquets utilisant <package>debmake</package> seront rejetés de
8289 <sect1 id="dh-make">
8291 <package>dh-make</package>
8294 Le paquet <package>dh-make</package> contient <prgn>dh_make</prgn>, un
8295 programme qui crée un squelette de fichiers nécessaires à la
8296 construction d'un paquet Debian à partir d'une arborescence
8297 source. Comme le nom le suggère, <prgn>dh_make</prgn> est une
8298 réécriture de <package>debmake</package> et ses fichiers modèles
8299 utilisent les programmes dh_* de <package>debhelper</package>.
8302 Quoique les fichiers de règles fabriqués par <prgn>dh_make</prgn>
8303 constituent en général une base suffisante pour un paquet fonctionnel,
8304 ce ne sont que les fondations : la charge incombe toujours au
8305 responsable d'affiner les fichiers générés et de rendre le paquet
8306 complètement fonctionnel et en conformité avec la charte.
8311 <package>yada</package>
8314 Le paquet <package>yada</package> est un autre assistant pour la
8315 création de paquets. Il utilise un fichier
8316 <file>debian/packages</file> pour générer <file>debian/rules</file> et
8317 d'autres fichiers nécessaires dans le sous-répertoire
8318 <file>debian/</file>. Le fichier <file>debian/packages</file> contient
8319 des instructions pour construire les paquets et il n'y a pas besoin de
8320 créer de fichiers <file>Makefile</file>. Il existe la possibilité
8321 d'utiliser un moteur de macros semblable à celui utilisé dans les
8322 fichiers SPECS des paquets source RPM.
8325 Pour plus d'informations, voir le <tt><url
8326 id="http://yada.alioth.debian.org/" name="site de YADA"></tt>.
8331 <package>equivs</package>
8334 <package>equivs</package> est un autre paquet pour faire des
8335 paquets. Il est souvent conseillé pour un usage local, si vous avez
8336 besoin de faire un paquet pour satisfaire des dépendances. Il est
8337 aussi parfois utilisé pour faire des « méta-paquets » qui
8338 sont des paquets dont l'unique objet est de dépendre d'autres paquets.
8342 <sect id="tools-builders">
8344 Constructeurs de paquets
8347 Les paquets suivants aident le processus de construction des paquets,
8348 en général en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que la
8349 gestion du support de tâches.
8351 <sect1 id="cvs-buildpackage">
8353 <package>cvs-buildpackage</package>
8356 Le paquet <package>cvs-buildpackage</package> permet de mettre à jour
8357 ou de récupérer des paquets sources dans un référentiel CVS, il permet
8358 de fabriquer un paquet Debian depuis le référentiel CVS et il assiste
8359 le développeur lors de l'intégration de modifications amont dans le
8363 Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS
8364 pour le responsable Debian. Il permet de conserver des branches CVS
8365 distinctes pour les distributions <em>stable</em>, <em>unstable</em>
8366 et probablement <em>experimental</em> et de bénéficier des avantages
8367 d'un système de contrôle de version.
8370 <sect1 id="debootstrap">
8372 <package>debootstrap</package>
8375 Le paquet <package>debootstrap</package> vous permet d'amorcer un
8376 système Debian de base à n'importe quel endroit dans votre système de
8377 fichiers. Par « système de base », nous entendons le strict
8378 minimum nécessaire pour fonctionner et installer le reste du système.
8381 Avoir un système comme celui-ci peut vous servir de différentes
8382 manières. Vous pouvez, par exemple, déplacer votre racine dans ce
8383 système avec <prgn>chroot</prgn> pour tester vos dépendances de
8384 construction. Vous pouvez aussi l'utiliser pour voir comment se
8385 comporte votre paquet quand il est installé dans un environnement
8389 <sect1 id="pbuilder">
8391 <package>pbuilder</package>
8394 <package>pbuilder</package> construit un système « chrooté »
8395 et compile des paquets dans ce système. Ceci est très utile pour
8396 vérifier que les dépendances de compilation de votre paquet sont
8397 correctes et pour vous assurer qu'aucune dépendance de construction
8398 inutile ou incorrecte n'existe dans le paquet résultant.
8401 Un paquet lié est <package>pbuilder-uml</package>, qui va même plus
8402 loin en réalisant la construction au sein d'un environnement
8403 « User Mode Linux ».
8408 <package>sbuild</package>
8411 <package>sbuild</package> est un autre compilateur automatique. Il
8412 peut aussi être utilisé dans un environnement
8413 « chrooté ». Il peut être utilisé seul ou comme partie d'un
8414 environnement de compilation distribué en réseau. Comme le précédent,
8415 c'est une partie du système utilisé par les porteurs pour construire
8416 des paquets binaires pour toutes les architectures
8417 disponibles. Veuillez vous reporter à <ref id="buildd"> pour plus
8418 d'informations et à <url id="&url-buildd;"> pour voir le système en
8423 <sect id="uploaders">
8425 Téléchargeurs de paquets
8428 Les paquets suivants aident à automatiser ou à simplifier le processus
8429 d'envoi de paquets dans l'archive officielle.
8431 <sect1 id="dupload">
8433 <package>dupload</package>
8436 Le paquet <package>dupload</package> contient un script du même nom
8437 pour mettre à jour des paquets dans l'archive Debian, tracer les mises
8438 à jour et les annoncer par courrier électronique automatiquement. Vous
8439 pouvez le configurer pour faire des mises à jour à d'autres endroits
8440 et avec d'autres méthodes.
8445 <package>dput</package>
8448 Le script <package>dput</package> fait à peu près la même chose que
8449 <package>dupload</package>, mais il le fait différemment. Il a aussi
8450 quelques fonctions supplémentaires telles que la possibilité de
8451 vérifier la signature GnuPG et les sommes de contrôles avant le
8452 téléchargement et la possibilité de démarrer <prgn>dinstall</prgn> en
8453 mode simulation (<em>dry-run</em>) après le téléchargement.
8458 <package>dcut</package>
8461 Le script <package>dcut</package> (faisant partie du paquet <ref
8462 id="dput">) aide à la suppression de fichiers du répertoire d'envoi
8467 <sect id="tools-maint-automate">
8469 Automatisation de la maintenance
8472 Les outils suivants aident à automatiser les différentes tâches de
8473 maintenance par l'ajout des entrées de changelog ou de lignes de
8474 signatures, par la recherche de bogues à partir d'Emacs et par
8475 l'utilisation du fichier officiel <file>config.sub</file> le plus
8478 <sect1 id="devscripts">
8480 <package>devscripts</package>
8483 Le paquet <package>devscripts</package> contient des scripts et outils
8484 qui sont très utiles pour maintenir vos paquets Debian. Parmi ces
8485 scripts, vous trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui
8486 manipulent votre fichier <file>debian/changelog</file> depuis la ligne
8487 de commande et <prgn>debuild</prgn> qui est construit au-dessus de
8488 <prgn>dpkg-buildpackage</prgn>. L'outil <prgn>bts</prgn> est également
8489 très utile pour mettre à jour l'état des rapports de bogue depuis la
8490 ligne de commande. Le programme <prgn>uscan</prgn> peut être utilisé
8491 pour suivre les nouvelles versions amont de vos paquets. Le programme
8492 <prgn>debrsign</prgn> peut être utilisé pour signer à distance un
8493 paquet avant de l'envoyer, ce qui est agréable quand la machine sur
8494 laquelle vous construisez le paquet est différente de celle où
8495 résident vos clés GPG.
8498 Vérifiez la page de manuel <manref section="1" name="devscripts"> pour
8499 une liste complète des scripts disponibles.
8502 <sect1 id="autotools-dev">
8504 <package>autotools-dev</package>
8507 <package>autotools-dev</package> contient les meilleurs pratiques pour
8508 des personnes assurant la maintenance de paquets qui utilisent
8509 <prgn>autoconf</prgn> et/ou <prgn>automake</prgn>. Contient également
8510 des fichiers canoniques <file>config.sub</file> et
8511 <file>config.guess</file> qui sont connus pour fonctionner avec tous
8512 les portages Debian.
8515 <sect1 id="dpkg-repack">
8517 <package>dpkg-repack</package>
8520 <prgn>dpkg-repack</prgn> crée un paquet Debian à partir d'un paquet
8521 qui a déjà été installé. Si des changements ont été effectués sur le
8522 paquet quand il a été décompacté (par exemple, des fichiers dans
8523 <file>/etc</file> ont été modifiés), le nouveau paquet héritera de ces
8527 Cet utilitaire peut faciliter la copie de paquet d'un ordinateur vers
8528 un autre ou la re-création de paquets installés sur un système, mais
8529 qui ne sont plus disponibles ailleurs ou pour sauvegarder l'état
8530 actuel d'un paquet avant de le mettre à jour.
8535 <package>alien</package>
8538 <prgn>alien</prgn> convertit des paquets binaires entre différents
8539 formats de paquets, y compris des paquets Debian, RPM (RedHat), LSB
8540 (Linux Standard Base), Solaris et Slackware.
8543 <sect1 id="debsums">
8545 <package>debsums</package>
8548 <prgn>debsums</prgn> vérifie des paquets installés par rapport à leur
8549 somme de hachage MD5. Veuillez noter que tous les paquets n'ont pas de
8550 sommes MD5 car elles ne sont pas requises par la charte.
8553 <sect1 id="dpkg-dev-el">
8555 <package>dpkg-dev-el</package>
8558 <package>dpkg-dev-el</package> fournit des macros Emacs Lisp qui
8559 apportent une aide lors de l'édition des fichiers du répertoire
8560 <file>debian</file> de votre paquet. Par exemple, il y a des fonctions
8561 pratiques pour lister les bogues actuels d'un paquet et pour finaliser
8562 la dernière entrée d'un fichier <file>debian/changelog</file> file.
8565 <sect1 id="dpkg-depcheck">
8567 <package>dpkg-depcheck</package>
8570 <prgn>dpkg-depcheck</prgn> (du paquet <package>devscripts</package>,
8571 <ref id="devscripts">) exécute une commande sous <prgn>strace</prgn>
8572 pour déterminer tous les paquets utilisés par la commande.
8575 Pour les paquets Debian, c'est utile quand vous devez créer une ligne
8576 <tt>Build-Depends</tt> pour votre nouveau paquet : exécuter le
8577 processus de compilation avec <prgn>dpkg-depcheck</prgn> vous fournira
8578 une bonne première approximation des dépendances de compilation. Par
8581 dpkg-depcheck -b debian/rules build
8585 <prgn>dpkg-depcheck</prgn> peut aussi être utilisé pour vérifier les
8586 dépendances d'exécution, particulièrement si votre paquet utilise
8587 exec(2) pour exécuter d'autres programmes.
8590 Pour plus d'informations, veuillez voir <manref section="1"
8591 name="dpkg-depcheck">.
8595 <sect id="tools-porting">
8600 Les outils suivants facilitent le travail des porteurs et la
8601 compilation croisée.
8603 <sect1 id="quinn-diff">
8605 <package>quinn-diff</package>
8608 <package>quinn-diff</package> est utilisé pour localiser les
8609 différences d'une architecture à l'autre. Il pourrait vous dire, par
8610 exemple, quels paquets de l'architecture <var>X</var> doivent être
8611 portés sur l'architecture <var>Y</var>.
8614 <sect1 id="dpkg-cross">
8616 <package>dpkg-cross</package>
8619 <package>dpkg-cross</package> est un outil qui installe les
8620 bibliothèques et les en-têtes nécessaires à une compilation
8621 croisée<footnote><p><em>cross-compilation</em></p></footnote> d'une
8622 manière similaire à <package>dpkg</package>. De plus, les paquets
8623 <prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
8624 améliorés pour accepter les compilations croisées.
8628 <sect id="tools-doc">
8630 Documentation et information
8633 Les paquets suivants fournissent des informations pour les responsables
8634 ou de l'aide pour construire de la documentation
8636 <sect1 id="debiandoc-sgml">
8638 <package>debiandoc-sgml</package>
8641 <package>debiandoc-sgml</package> fournit la DTD DebianDoc SGML qui
8642 est habituellement utilisée pour la documentation Debian. Ce manuel,
8643 par exemple, est écrit en DebianDoc. Il fournit également des scripts
8644 pour construire et décliner le source en de multiples formats de
8648 La documentation sur la DTD peut être trouvée dans le paquet
8649 <package>debiandoc-sgml-doc</package>.
8652 <sect1 id="debian-keyring">
8654 <package>debian-keyring</package>
8657 Contient les clés publiques GPG et PGP des développeurs Debian. Voir
8658 <ref id="key-maint"> et la documentation du paquet pour plus
8662 <sect1 id="debview">
8664 <package>debview</package>
8667 <package>debview</package> fournit un mode Emacs pour voir les paquets
8668 binaires Debian. Il vous permet d'examiner un paquet sans le