X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=developers-reference.fr.sgml;h=6d3165ff67dd8db83d959320c6c8d07d1f2f4128;hp=41268c6ebaa18dfb35b95aba986ee9a8a123b17e;hb=d03c6635e55f988ef2a7b6264da28d0d93e635b9;hpb=a183b548f0c9cc3baea3f0ee774f4d879a33cbab diff --git a/developers-reference.fr.sgml b/developers-reference.fr.sgml index 41268c6..6d3165f 100644 --- a/developers-reference.fr.sgml +++ b/developers-reference.fr.sgml @@ -1,662 +1,4343 @@ - + + %versiondata; + + %commondata; + + + + + + + FIXME: "> + +]> + - -Guide de Référence du Développeur Debian -<author>Christian Schwarz <email/schwarz@debian.org/ -<author>basé sur des documents précédemment écrits par Ian Jackson -<email/ijackson@gnu.ai.mit.edu/ -<author>version française par Hervé Floch -<email/Herve.Floch@Linux.EU.Org/ -<version>version 0.1, <date> + <book> -<copyright>Copyright ©1997 Christian Schwarz. -<p> + <title>Référence du développeur Debian + <author>Adam Di Carlo, responsable actuel<email>aph@debian.org</email> + <author>Raphaël Hertzog, co-responsable <email>hertzog@debian.org</email> + <author>Christian Schwarz <email>schwarz@debian.org</email> + <author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email> + <author>  + <author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.org</email> + <author>et Frédéric Bothamy (traducteur actuel) <email>fbothamy@mail.dotcom.fr</email> + <author>et les membres de la liste <email>debian-l10n-french@lists.debian.org</email> + <version>Version &version;, &date-fr; (version française 20021231).</version> -Ce manuel relève du logiciel libre ; vous pouvez le redistribuer et/ou le -modifier conformément à la GNU GPL (General Public License) publiée par la FSF -(Free Software Foundation) dans la version 2 (ou supérieure si vous le -préférez). + <copyright> + <copyrightsummary>Copyright © 1998—2002 Adam Di Carlo</copyrightsummary> + <copyrightsummary>Copyright © 2002 Raphaël Hertzog</copyrightsummary> + <copyrightsummary>Copyright © 1997, 1998 Christian Schwarz.</copyrightsummary> <p> +Ce manuel est un logiciel libre ; il peut être redistribué et/ou modifié +selon les termes de la licence publique générale du projet GNU (GNU GPL), telle +que publiée par la « Free Software Foundation » (version 2 ou toute +version postérieure). -Il est distribué dans l'espoir qu'il sera utile, <em>sans aucune garantie</em> ; -sans même une garantie implicite de qualité marchande ou d'adéquation à un -quelconque usage. Voyez la GNU GPL pour plus de détails. <p> +Il est distribué dans l'espoir qu'il sera utile, mais <em>sans aucune +garantie</em>, sans même la garantie implicite d'une possible valeur marchande +ou d'une adéquation à un besoin particulier. Consultez la licence publique +générale du projet GNU pour plus de détails. -Une copie de la licence GNU GPL est disponible dans le fichier -<tt>/usr/doc/copyright/GPL</tt> de la distribution Debian GNU/Linux ou sur le -World Wide Web à l'URL <tt>http://www.gnu.org/copyleft/gpl.html</tt>. Vous -pouvez aussi l'obtenir en écrivant à la Free Software Foundation, Inc., 675 Mass -Ave, Cambridge, MA 02139, USA. -<p> +<p>Une copie de la licence publique générale du projet GNU est disponible dans +le fichier &file-GPL; de la distribution &debian-formal; ou sur la toile : +<url id="&url-gpl" name="la licence publique générale du projet GNU">. Vous +pouvez également l'obtenir en écrivant à la &fsf-addr;. -<toc sect> + <toc detail="sect1"> -<chapt>Devenir un mainteneur -<p> + <chapt id="scope">Portée de ce document -<sect>Avant de travailler sur un paquet <p> +Le but de ce document est de donner une vue d'ensemble des procédures à suivre +et des ressources mises à la disposition des développeurs Debian. -Vous avez lu toute la documentation, vous avez compris l'utilité de chaque -élément du paquet d'exemple <prgn/hello/ et vous voulez « debianiser » votre -paquet favori. Alors, comment devient-on un développeur Debian dont le travail -peut être incorporé dans le projet ? +<!-- FIXME: rewrites --> <p> +Les procédures décrites ci-après expliquent comment devenir +responsable Debian (<ref id="new-maintainer">), comment installer des nouveaux +paquets dans l'archive (<ref id="upload">), quand et comment faire un portage ou +une mise à jour du paquet d'un autre responsable (<ref id="nmu">), comment +déplacer, effacer ou abandonner un paquet (<ref id="archive-manip">) et comment +gérer les rapports de bogues (<ref id="bug-handling">). -Tout d'abord, abonnez-vous à <prgn/debian-devel/ si vous ne l'avez pas déjà -fait. Envoyez juste le mot <tt/subscribe/ dans le champ <em/Subject/ d'un -courrier électronique à <email/debian-devel-REQUEST@lists.debian.org/. En cas de -problème, contactez l'administrateur de la liste de diffusion à l'adresse -<email/listmaster@lists.debian.org/. <p> +Les ressources présentées dans ce manuel incluent les listes de diffusion (<ref +id="mailing-lists">) et les serveurs (<ref id="server-machines">), une +présentation de la structure de l'archive Debian (<ref id="archive">), des +explications sur les serveurs qui acceptent les mises à jour de paquets (<ref +id="upload-ftp-master">) et une présentation des outils qui peuvent aider un +responsable à améliorer la qualité de ses paquets (<ref id="tools">). -Vous devriez vous abonner et observer un peu avant d'écrire le moindre code, -vous devriez aussi poster un message annonçant vos intentions avant d'attaquer -un travail, afin d'épargner des efforts dupliqués. <p> +Ce manuel de référence ne présente pas les aspects techniques liés aux paquets +Debian, ni comment les créer. Il ne décrit pas non plus les règles que doivent +respecter les paquets Debian. Cette information est disponible dans la <url +id="&url-debian-policy;" name="charte Debian">. -Si vous n'avez pas déjà de clef PGP, générez-en une. Vous devriez probablement -lire le manuel de PGP. En effet, il contient de nombreuses informations -importantes qui sont primordiales pour sa sécurité. Bien plus de failles de -sécurité sont dues à des erreurs humaines qu'à des bogues logiciels ou des -techniques d'espionnage perfectionnées. <p> +De plus ce document <em>n'est pas l'expression d'une politique officielle</em>. +Il contient de la documentation sur le système Debian et des conseils pratiques +largement suivis. C'est une sorte de guide pratique. -En raison des restrictions à l'exportation décidées par le gouvernement des -États Unis, quelques paquets Debian dont PGP ont été déplacés vers un serveur -FTP en dehors des U.S.A. . Vous pouvez obtenir les localisations de ces paquets -à <ftpsite/ftp.debian.org/ dans le fichier -<ftppath>/pub/debian/README.non-US</>. -<p> + <sect>Introduction à la version française -Si vous vivez dans un pays où l'usage de la cryptographie est interdit, même -pour l'authentification, veuillez nous contacter pour que nous trouvions des -arrangements particuliers. Ceci ne s'applique pas pour la France où je pense -que seul le chiffrement est interdit et pas l'authentification. -<p> + <sect1>Avertissement -<sect>S'enregistrer comme un développeur Debian <p> +Bien que ce document soit en français, l'activité de responsable Debian implique +une maîtrise de la langue anglaise. Le projet Debian est un projet international +auquel participent des japonais, néo-zélandais, américains, allemands, +finlandais, français, espagnols, danois... -Quand votre nouveau paquet sera prêt à être envoyé, vous devrez poster un -message à <email/new-maintainer@debian.org/ pour vous enregistrer comme un -développeur Debian « officiel » afin d'être autorisé à envoyer des paquets. <p> +En conséquence, la langue utilisée dans toutes les listes de diffusion destinées +aux développeurs est l'anglais et les rapports de bogue doivent être rédigés en +anglais. En fait, sauf exception rare, tout dialogue avec les autres +responsables Debian se fera en anglais quel que soit le média. -Le message devra annoncer ce que vous avez fait et qui vous êtes. Aussi, vous -devriez demander à avoir un compte sur le serveur principal et à être inscrit -sur la liste debian-private (la liste de diffusion réservée aux développeurs). -Il devra contenir votre clé publique PGP ou RSA (extraite avec la commande -<tt>pgp -kxa</tt>, dans le cas de PGP) pour la base de données des clés fournie -avec dpkg. Vérifiez que vous avez signé votre message avec la clé PGP ou RSA que -vous avez choisie. -<p> -Incluez votre nom d'usager préféré pour le serveur principal (sept caractères ou -moins), ainsi que l'adresse électronique à laquelle vous souhaitez recevoir les -messages de debian-private (typiquement, ce sera ou votre adresse principale ou -votre nouvelle adresse debian.org). + <sect1>Glossaire + <p> +Cette section liste les termes techniques qui ont un sens spécifique dans le +projet Debian. Pour chacune de ces expressions, vous trouverez la traduction +française utilisée dans ce manuel, une définition et une référence à la section +du manuel qui traite de ce sujet. -Vous devrez aussi indiquer un moyen par lequel nous pourrons vérifier votre -identité réelle. Par exemple, un des moyens suivants conviendrait : -<list compact> -<item>Une clé PGP ou RSA signée par une signature bien connue, comme : -<list compact> -<item>un des développeurs Debian -<item>un service de certification (comme Verisign, Thawte, etc.) -</list> -<item>une copie numérisée ou physiquement postée de documents officiels -certifiant de votre identité (comme un extrait de naissance, une carte nationale -d'identité, un permis de conduire, etc.). Incluez votre empreinte PGP or RSA sur -l'image numérisée et signez l'image avec votre clé PGP ou RSA. -</list> +<list> + <item><em>Upload</em> : mise à jour, téléchargement (parfois + livraison). Opération qui consiste à télécharger un nouveau paquet ou + une nouvelle version de paquet dans l'archive Debian (<ref + id="upload">). -Les mécanismes suivants sont déconseillés, mais acceptables si aucun des moyens -précédents n'est utilisable : -<list compact> -<item>Une liste de numéros de téléphone auxquels vous pouvez être joint (à nos -frais). Cette liste doit pouvoir être vérifiée indépendamment, par des moyens -tel qu'un annuaire national ou toute autre source faisant autorité. -</list> + <item><em>Non-maintainer upload (NMU)</em> : mise à jour + indépendante. Téléchargement d'une nouvelle version de paquet dans + l'archive Debian par une personne qui n'est pas officiellement + responsable de ce paquet (<ref id="nmu">). -Nous sommes désolés pour les contraintes découlant de cette vérification -d'identité, mais pour le moment, de telles mesures sont indispensables pour -assurer la sécurité et la fiabilité de notre distribution. -<p> + <item><em>Source NMU</em> : mise à jour indépendante source. Il + s'agit d'une mise à jour indépendante pour un paquet source (<ref + id="nmu-terms">). -Une fois que cette information est reçue et traitée, vous devriez recevoir les -informations concernant votre nouveau compte de mainteneur Debian. Si vous ne -recevez rien sous 7-10 jours, veuillez renvoyer votre message original car les -bénévoles gérant les nouveaux volontaires sont généralement débordés et des -erreurs surviennent parfois. -<p> + <item><em>Binary NMU</em> : mise à jour indépendante binaire. Mise + à jour indépendante pour un paquet binaire (<ref id="nmu-terms">). + + <item><em>Bug Tracking System (BTS)</em> : système de suivi des + bogues. Il s'agit du système utilisé par le projet Debian pour suivre + les bogues et leur correction (<ref id="bug-handling">). + + <item><em>Bug submitter</em> : rapporteur du bogue. Personne qui + envoie un rapport de bogue au système de suivi des bogues (<ref + id="submit-bug">). + + <item><em>Release critical bug</em> : bogue empêchant l'intégration + du paquet dans la distribution. Bogues de gravité <em>critique</em>, + <em>grave</em> et <em>sérieuse</em>. Ces bogues ne doivent pas + apparaître dans une distribution <em>stable</em>. Ils doivent être + corrigés ou bien les paquets en cause doivent être supprimés (<ref + id="rc-bugs">). + + <item><em>Package Tracking System (PTS)</em> : système de suivi des + paquets. Il s'agit du système utilisé par le projet Debian pour suivre + les paquets sources des différentes distributions (<ref + id="pkg-tracking-system">). + + <item><em>Unstable</em> : Nom de la distribution en cours de + développement. Cette distribution contient les paquets envoyés par les + développeurs. Ceux-ci étant humains, elle est parfois cassée (<ref + id="sec-dists">). + + <item><em>Testing</em> : Nom de la distribution en test. Cette + distribution reçoit les paquets des développeurs qui ont passé une + période de deux semaines dans <em>unstable</em> et pour lesquels aucun + bogue remettant en cause la distribution (cf. <em>Release critical + bug</em>) n'a été découvert. Cette distribution n'a pas été testée en + profondeur. Elle est cependant censée être plus stable que + <em>unstable</em> (<ref id="sec-dists">). + + <item><em>Stable</em> : Nom de la distribution dite stable. Cette + distribution a été testée, validée et diffusée (<ref id="sec-dists">). + + <item><em>Debian maintainer</em> : responsable Debian, développeur + Debian (parfois mainteneur). Personne qui fait officiellement partie du + projet Debian. Elle a accès aux serveurs Debian et participe au + développement — au sens large — de la distribution (<ref + id="developer-duties">). La plupart des responsables font de la mise en + paquet, mais il existe d'autres activités telles que la documentation, + la gestion du site web, la création des cédéroms, l'administration des + serveurs, etc. + + <item><em>Upstream version</em> : version amont. Il s'agit du + logiciel tel qu'il est fourni par le responsable amont — par + opposition à la version fournie par la distribution Debian. (Voir <ref + id="upstream-coordination">.) + + <item><em>Upstream maintainer</em> : responsable amont ou + développeur amont. Personne(s) responsable(s) du développement ou de la + maintenance d'un logiciel. En général, le responsable amont n'a rien à + voir avec le projet Debian (<ref id="upstream-coordination">). + + <item><em>Debian keyring</em> : porte-clés Debian. Le porte-clés + Debian contient les clés publiques de tous les responsables Debian (<ref + id="key-maint">). + + <item><em>Work-needing and prospective packages (WNPP)</em> : + paquets en souffrance et paquets souhaités. La liste des paquets en + souffrance indique les paquets qui n'ont plus de responsable. La liste + des paquets souhaités indique les logiciels que des utilisateurs + aimeraient bien voir dans la distribution (<ref id="upload">). + + </list> -<chapt>Les Serveurs Internet -<p> -<sect>Les listes de diffusion + <chapt id="new-maintainer">Devenir responsable Debian + + <sect id="getting-started">Pour commencer <p> +Vous avez lu toute la documentation, vous avez examiné le <url + id="&url-newmaint-guide;" name="guide du nouveau responsable">, vous comprenez + l'intérêt de tout ce qui se trouve dans le paquet d'exemple + <package>hello</package> et vous vous apprêtez à mettre en paquet votre + logiciel préféré. Comment devenir responsable Debian et intégrer votre travail + au projet ? +<p> +Si vous ne l'avez pas encore fait, commencez par vous inscrire à la + liste &email-debian-devel;. Pour cela, envoyez un courrier à l'adresse + &email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne + <em>Objet</em><footnote><p><em>Subject</em> en anglais</footnote> de votre + message. En cas de problème, contactez l'administrateur de la liste + &email-listmaster;. Vous trouverez plus d'informations dans la section <ref + id="mailing-lists">. &email-debian-devel-announce; est une autre liste + incontournable pour qui veut suivre les développements de Debian. +<p> +Vous suivrez les discussions de cette liste (sans poster) pendant quelque temps + avant de coder quoi que ce soit et vous informerez la liste de votre intention + de travailler sur quelque chose pour éviter de dupliquer le travail d'un autre. +<p> +Une autre liste intéressante est &email-debian-mentors;. Voir la section <ref + id="mentors"> pour les détails. Le canal IRC <tt>#debian</tt> pourra aussi être + utile. -Le serveur des listes de diffusion est hébergé sur <tt/lists.debian.org/. -Envoyez un courrier électronique à -<tt/debian-<var/foo/-REQUEST@lists.debian.org/, <tt/debian-<var/foo// étant le -nom de la liste, avec le mot <tt/subscribe/ dans le sujet pour vous abonner ou -<tt/unsubscribe/ pour vous désabonner. <p> +Quand vous avez choisi la manière dont vous contribuerez au projet + &debian-formal;, prenez contact avec les responsables Debian qui travaillent + sur des tâches similaires. Ainsi vous pourrez apprendre auprès de personnes + expérimentées. Si, par exemple, vous voulez mettre en paquet des logiciels + existants, trouvez-vous un parrain. Un parrain est une personne qui travaillera + sur vos paquets avec vous et les téléchargera dans l'archive Debian une fois + qu'il sera satisfait de votre mise en paquet. Pour trouver un parrain, envoyez + une demande de parrainage à la liste &email-debian-mentors; en vous présentant + et en décrivant votre paquet (voir <ref id="sponsoring"> pour en savoir plus + sur le sujet). Si vous préférez porter Debian sur une architecture ou un noyau + alternatif, abonnez-vous aux listes dédiées au portage et demandez-y comment + démarrer. Finalement, si vous êtes intéressé par la documentation ou + l'assurance qualité (QA), vous pouvez contacter les responsables qui + travaillent déjà sur ces tâches et proposer des correctifs et des + améliorations. + -Quand vous répondez à un message sur la liste, n'envoyez pas de copie en <tt/CC/ -à l'auteur. Toute personne écrivant à une liste de diffusion devrait la lire -pour prendre connaissance des réponses. + <sect id="registering">Devenir responsable Debian <p> +Avant de décider de devenir responsable Debian, il vous faudra lire toute la + documentation disponible dans le <url id="&url-newmaint;" name="coin du nouveau + responsable">. Elle décrit toutes les étapes préparatoires qu'il vous faudra + franchir avant de déposer votre candidature. -Comme toujours dans vos courriers, essayez de réduire les citations des articles -auxquels vous répondez. Appliquez vous aussi à respecter la Nétiquette lorsque -vous postez. +Par exemple, avant d'être candidat, il vous faudra lire le <url + id="&url-social-contract;" name="contrat social Debian">. Devenir responsable + Debian implique que vous adhériez à ce contrat social et que vous vous engagiez + à le soutenir ; il est très important que les responsables soient en + accord avec les principes fondamentaux qui animent le projet &debian-formal;. + Lire le <url id="&url-gnu-manifesto;" name="Manifeste GNU"> est aussi une bonne + idée. <p> +Le processus d'enregistrement a pour but de vérifier votre identité, vos + intentions et vos compétences. Le nombre de personnes travaillant pour + &debian-formal; a atteint &number-of-maintainers; et notre système est utilisé + dans plusieurs endroits très importants : nous devons rester vigilants + pour éviter un acte malveillant. C'est pourquoi nous contrôlons les nouveaux + responsables avant de leur donner un compte sur nos serveurs et de les autoriser à + ajouter des paquets dans l'archive. +<p> +Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail + et que vous serez un bon contributeur. Pour cela, vous pourrez proposer des correctifs + par le système de suivi des bogues (BTS) ou maintenir un paquet parrainé + pendant un temps. Nous attendons aussi des contributeurs qu'ils soient + intéressés par le projet dans son ensemble et pas uniquement par leurs propres + paquets. Si vous pouvez aider d'autres responsables en fournissant des + informations sur un bogue ou même avec un correctif, faites-le ! +<p> +Pour votre candidature, vous devrez être familiarisé avec la philosophie du + projet Debian et avec sa documentation technique. Il vous faudra aussi une clé + GnuPG signée par un responsable Debian. Si votre clé GnuPG n'est pas encore + signée, vous devriez essayer de rencontrer un responsable Debian pour le faire. + La <url id="&url-gpg-coord;" name="page de coordination des signatures de clé + GnuPG"> devrait vous aider à trouver un responsable Debian près de chez vous. + (Si vous ne trouvez pas de responsable près de chez vous, il existe un second + moyen pour valider votre identité. Vous pouvez envoyer une photo d'identité + signée avec votre clé GnuPG. Privilégiez tout de même la clé GnuPG signée pour + valider une identité. Reportez-vous à la <url id="&url-newmaint-id;" name="page + d'identification"> pour en savoir plus sur ces deux options.) -<sect>Le serveur principal <p> +Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin d'une clé + OpenPGP pour signer et vérifier les mises à jour de paquets. Vous lirez la + documentation du logiciel de cryptographie que vous utiliserez car elle + contient des informations indispensables pour la sécurité de votre clé. Les + défaillances de sécurité sont bien plus souvent dues à des erreurs humaines + qu'à des problèmes logiciels ou à des techniques d'espionnage avancées. Voir + <ref id="key-maint"> pour plus d'informations sur la gestion de votre clé + publique. +<p> +Debian utilise <prgn>GNU Privacy Guard</prgn> (paquet <package>gnupg</package> + version 1 ou supérieure) comme standard de base. Vous pouvez aussi utiliser une + autre implémentation d'OpenPGP. OpenPGP est un standard ouvert basé sur la <url + id="&url-rfc2440;" name="RFC 2440">. +<p> +L'algorithme à clé publique recommandé pour les développements Debian est DSA + (parfois appelé « DSS » ou « DH\ElGamal »). Vous pouvez + aussi utiliser d'autres types de clés. La longueur de votre clé doit être au + minimum de 1024 bits ; il n'y a pas de raison d'utiliser une clé plus + courte et le faire serait beaucoup moins sûr. Votre clé doit être signée avec + votre propre identifiant ; cela évite les falsifications. <prgn>GNU + Privacy Guard</prgn> le fait automatiquement. +<p> +Si votre clé publique n'est pas sur un serveur public tel que &pgp-keyserv;, + reportez-vous à la documentation disponible localement dans &file-keyservs;. + Cette documentation explique comment mettre votre clé publique sur un serveur. + L'équipe <em>New maintainer</em> mettra votre clé publique sur les serveurs de + clés si elle n'y est pas déjà. +<p> +Certains pays limitent l'usage des logiciels de cryptographie. Cela ne devrait + cependant pas avoir d'impact sur l'activité d'un responsable de paquet car il + peut être tout à fait légal d'utiliser des logiciels de cryptographie pour + l'authentification plutôt que pour le chiffrement. &debian-formal; ne nécessite + en aucun chiffrement. Si vous vivez dans un pays où l'utilisation de la + cryptographie pour authentification est interdite, contactez-nous pour que nous + prenions des dispositions particulières. +<p> +Pour faire acte de candidature, il vous faut un responsable Debian qui vérifiera + votre candidature (un <em>avocat</em>). Après avoir contribué au projet Debian + pendant un temps, quand vous choisissez de devenir un responsable Debian + officiel, un responsable déjà enregistré avec qui vous aurez travaillé dans les + derniers mois devra exprimer que, d'après lui, vous pouvez contribuer avec + succès au projet Debian. +<p> +Quand vous avez trouvez un <em>avocat</em>, quand votre clé GnuPG est signée et + quand vous avez déjà contribué au projet, vous êtes prêt à faire + acte de candidature. Il vous suffit pour cela de vous enregistrer sur notre + <url id="&url-newmaint-apply;" name="page de candidature">. Ensuite, votre + avocat devra confirmer votre candidature. Quand il aura accompli cette tâche, + un responsable de candidature<footnote><p>Application manager</footnote> sera + désigné pour vous accompagner dans le processus d'enregistrement. Vous pouvez + toujours consulter le <url id="&url-newmaint-db;" name="tableau de bord des + candidatures"> pour connaître l'état de votre candidature. +<p> +Pour en savoir plus, consultez le <url id="&url-newmaint;" name="coin des + nouveaux responsables"> sur le site Debian. Assurez-vous de bien connaître les + étapes nécessaires au processus d'enregistrement avant de vous porter candidat. + Vous gagnerez beaucoup de temps si vous êtes bien préparé. + -<sect>Le serveur Ftp et ses miroirs + <sect id="mentors">Mentors et parrains Debian +<p> +La liste de diffusion &email-debian-mentors; a été créée pour les responsables + débutants qui cherchent de l'aide pour leur première création de paquet ainsi + que pour des problèmes spécifiques aux développeurs. Tout responsable débutant + est invité à s'y inscrire (voir <ref id="mailing-lists"> pour plus de détails). +<p> +Ceux qui préfèrent une aide personnalisée (via une correspondance privée) + doivent aussi poster dans cette liste, un développeur expérimenté se portera + volontaire pour les aider. <p> +Si vos paquets sont prêts à être intégrés mais que vous attendiez le + résultat de votre candidature, vous pouvez chercher un parrain qui téléchargera + les paquets à votre place. Les parrains sont des responsables Debian officiels + volontaires pour examiner et télécharger vos paquets. Vous pouvez + demander un parrainage à l'adresse <url id="&url-sponsors;">. +<p> +Si vous désirez être mentor ou parrain, reportez-vous à <ref id="newmaint">. + -<sect>Les serveurs WWW + <chapt id="developer-duties">Les charges du responsable Debian + + <sect id="user-maint">Mise à jour de vos références Debian +<p> +Il existe une base de données LDAP qui contient des informations concernant +les développeurs ; + vous pouvez y accéder à l'adresse <url id="&url-debian-db;">. Vous pouvez + modifier votre mot de passe (ce mot de passe est diffusé sur la plupart des + machines auxquelles vous avez accès), votre adresse, votre pays, la latitude et + la longitude de l'endroit où vous résidez, vos numéros de téléphone et de fax, + votre interpréteur de commande préféré, votre surnom IRC, votre page web, votre + adresse de courrier électronique ainsi que l'alias que vous utilisez pour votre + courrier électronique chez debian.org. La plupart de ces informations ne sont + pas accessibles au public. Pour plus de détails au sujet de cette base de + données, reportez-vous à sa documentation en ligne disponible à l'adresse <url + id="&url-debian-db-doc;">. <p> +Vous y tiendrez à jour les informations vous concernant. -<chapt>Le travail quotidien du développeur de paquet + <sect id="key-maint">Gérer votre clé publique <p> +Soyez très vigilant en utilisant votre clé privée. Ne la placez pas sur un + serveur public ou sur des machines multi-utilisateurs telles que les serveurs + Debian (voir <ref id="server-machines">). Sauvegardez vos clés et gardez-en une + copie hors connexion. Lisez la documentation fournie avec votre logiciel et la + <url id="&url-pgp-faq;" name="FAQ PGP">. +<p> +Si vous ajoutez des signatures ou des identifiants à votre clé publique, vous + pouvez mettre à jour le porte-clés Debian en envoyant votre clé publique à + <tt>&keyserver-host;</tt>. Si vous voulez ajouter ou supprimer une clé, envoyez + un courrier à &email-debian-keyring;. Les procédures d'extraction de clé + décrites dans <ref id="registering"> s'appliquent ici. +<p> +Vous pouvez trouver une présentation approfondie de la gestion de clé Debian + dans la documentation du paquet <package>debian-keyring</package>. -<sect>Annoncer les nouveaux paquets + + <sect id="voting">Voter +<p> +Debian, sans être une vraie démocratie, dispose d'outils à + caractère démocratique et utilise un procédé démocratique pour élire son chef + ou pour approuver une résolution. Ces procédures sont décrites dans la <url + id="&url-constitution;" name="Constitution Debian">. <p> +Un processus démocratique ne fonctionne bien que si tout le monde participe au + vote, c'est pourquoi vous devez voter. Pour cela, vous devez vous inscrire à la + liste &email-debian-devel-announce; car les annonces de votes sont publiées sur + cette liste. Si vous voulez suivre les débats qui précèdent un vote, + inscrivez-vous à liste &email-debian-vote;. +<p> +La liste de toutes les propositions (passées et présentes) est disponible à la + page <url id="&url-vote;" name="Informations sur les votes Debian">. Vous y + trouverez aussi des informations complémentaires sur la procédure à suivre pour + proposer un vote. + -<sect>Envoyer les nouveaux paquets + <sect id="inform-vacation">Prendre des vacances courtoisement +<p> +La plupart des développeurs prennent des vacances ; généralement, cela + signifie qu'ils ne peuvent ni travailler pour Debian, ni être joints par + courrier électronique si un problème se présentait. Les autres développeurs ont + besoin de savoir que vous êtes en vacances ; ainsi ils sauront comment + réagir en cas de problème. En général, cela signifie que les autres + développeurs sont autorisés à modifier votre paquet (voir <ref id="nmu">) en + cas de gros problème (bogues empêchant l'intégration dans la distribution, mise à jour de + sécurité, etc.) durant vos vacances. +<p> +Il y a deux choses à faire pour en informer les autres développeurs. + Premièrement, envoyez un courrier électronique indiquant vos dates de vacances + à &email-debian-private;, vous pouvez aussi donner quelques instructions pour + indiquer comment agir si un problème survenait. Notez bien que certaines + personnes ne sont pas intéressées par les annonces de vacances et ne veulent + pas les lire ; veuillez ajouter '[VAC] ' à l'objet de votre courrier pour + qu'il soit facilement filtré. <p> +Deuxièmement, il faut mettre à jour la base de données Debian LDAP et vous + signaler « en vacances »<footnote><p><em>on vacation</em> en + anglais</footnote>(l'accès à cette information est réservé aux développeurs). + N'oubliez pas de retirer votre indicateur « en vacances » lorsque + celles-ci sont terminées ! -Quand vous avez un compte personnel sur le serveur principal, vous pouvez vous -connecter par ftp et transférer les fichiers dans -<tt>/home/Debian/ftp/private/project/Incoming</tt>. Vous ne pouvez pas -envoyer dans « Incoming » sur le serveur principal par FTP anonyme, vous devez -utiliser votre nom et votre mot de passe. + <sect id="upstream-coordination">Coordination avec les développeurs amonts <p> +Une grande part de votre travail de responsable Debian sera de rester en contact + avec les développeurs amonts. Parfois, les utilisateurs établissent des + rapports de bogue qui ne sont pas spécifiques à Debian. Vous devez transmettre + ces rapports de bogue aux développeurs amonts pour qu'ils soient corrigés dans + les prochaines versions. Il n'est pas de votre responsabilité de corriger les + bogues qui ne sont pas spécifiques à Debian. Toutefois, si vous êtes capable de + le faire, nous vous encourageons à contribuer au développement amont en + proposant un correctif qui corrige le bogue. Les utilisateurs et responsables + Debian proposent souvent des correctifs pour corriger des bogues amonts, il + vous faudra alors évaluer ce correctif puis le transmettre aux développeurs + amonts. +<p> +Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un + paquet conforme à la charte Debian, alors vous devriez proposer un correctif + aux développeurs amonts pour qu'il soit inclus dans leur version. Ainsi, vous + n'aurez plus besoin de modifier les sources lors des mises à jour amonts + suivantes. Quels que soient les changements dont vous avez besoin, il faut + toujours essayer de rester dans la lignée des sources amonts. -Vous pouvez aussi envoyer vos fichiers dans « Incoming » avec une queue de -chargement gérée par un cron en Europe sur ftp.chiark.greenend.org.uk. Pour plus -de détails, connectez vous sur chiark via FTP anonyme et lisez -<tt>/pub/debian/private/project/README.how-to-upload</tt>. + <sect id="rc-bugs">Comment gérer les bogues empêchant l'intégration du paquet dans la distribution ? +<p> +Habituellement, vous devriez traiter les rapports de bogue sur vos paquets tel + que cela est décrit dans <ref id="bug-handling">. Cependant, il y a une + catégorie spéciale de bogues qui nécessite particulièrement votre + attention : les bogues empêchant l'intégration du paquet dans la + distribution<footnote>Traduction de l'anglais <em>Release-critical bug (RC + Bugs)</em></footnote>. Tous les rapports de bogue de gravité <em>critique</em>, + <em>grave</em> et <em>sérieuse</em><footnote>Respectivement <em>critical</em>, + <em>grave</em> et <em>serious</em> en anglais</footnote> sont considérés comme + ayant un impact sur la présence du paquet dans la prochaine version stable de + Debian. Ces bogues peuvent retarder la diffusion d'une distribution Debian + et/ou peuvent justifier la suppression d'un paquet d'une distribution gelée. + C'est pourquoi ces bogues ont besoin d'être corrigés au plus vite. <p> +Les développeurs faisant partie de l'équipe d'<url id="&url-debian-qa;" + name="assurance qualité Debian"> surveillent ces bogues et essaient de vous + aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas corriger un bogue de + ce type dans les deux semaines, vous devriez soit demander de l'aide en + envoyant un courrier à l'équipe d'assurance qualité (<em>QA group</em>) à + &email-debian-qa;, soit expliquer vos difficultés et présenter un plan pour + corriger le problème en répondant au rapport de bogue concerné. Si rien n'est + fait, des personnes de l'équipe d'assurance qualité pourraient chercher à + corriger votre paquet (voir <ref id="nmu">) après avoir tenté de vous contacter + (ils pourraient attendre moins longtemps que d'habitude pour faire leur mise à + jour s'il n'y a pas trace d'activité récente de votre part dans le système de + suivi des bogues). -Vous pouvez aussi trouver le paquet Debian <tt>dupload</tt> utile pour envoyer -les nouveaux paquets au serveur principal. Regardez la documentation de -<tt>dupload</tt> pour plus d'informations. + + <sect>Démissionner <p> +Si vous choisissez de quitter le projet Debian, procédez comme suit : +<enumlist compact="compact"> + <item><p>abandonnez tous vos paquets comme décrit dans <ref + id="orphaning"> ;</item> + <item><p>envoyez un courrier électronique à &email-debian-private; indiquant + pourquoi vous quittez le projet ;</item> + <item><p>signalez aux responsables du porte-clés Debian que vous quittez le + projet en écrivant à &email-debian-keyring;.</item> +</enumlist> + -<sect>Mises à jour par Intérim + + <chapt id="resources">Ressources pour le responsable Debian <p> +Dans ce chapitre, vous trouverez une brève description des listes de diffusions, + des machines Debian qui seront à votre disposition en tant que responsable + Debian ainsi que toutes les autres ressources à votre disposition pour vous + aider dans votre travail de responsable. -Dans certaines circonstances, il est nécessaire que quelqu'un d'autre que le -mainteneur courant réalise une nouvelle version d'un paquet. Par exemple, un -porteur vers une autre architecture peut avoir à faire quelques petits -changements au paquet source et ne pas vouloir attendre que le mainteneur -principal ait incorporé la pièce (patch) pour envoyer sa version, ou un problème -de sécurité peut être apparu, nécessitant des changements immédiats. + <sect id="mailing-lists">Les listes de diffusion +<p> +Le serveur de liste de diffusion est <tt>&lists-host;</tt>. <p> +Les archives des listes de diffusion sont consultables à <url + id="&url-lists-archives;">. -Les mainteneurs autres que les mainteneurs courants devraient faire le moins de -changements possible sur le paquet, et ils devraient toujours envoyer un -« unified context diff » (<tt/diff -u/) détaillant leurs changements au système -de suivi de bogues pour que le mainteneur soit tenu au courant de la situation. + <sect1 id="core-devel-mailing-lists">Principales listes pour les responsables +<p> +Les principales listes de diffusion de Debian que les développeurs + devraient suivre sont : +<list> +<item>&email-debian-devel-announce;, utilisée pour les annonces importantes + faites aux responsables. Tous les responsables Debian sont censés être + inscrits à cette liste,</item> +<item>&email-debian-devel;, utilisée pour discuter de diverses questions + techniques relatives au développement,</item> +<item>&email-debian-policy; où l'on discute et vote les modifications de la + Charte Debian,</item> +<item>&email-debian-project;, utilisée pour discuter de questions non + techniques.</item> +</list> <p> +Il existe d'autres listes de diffusion spécialisées dans différents thèmes. + Reportez-vous à la page <url id="&url-debian-lists-subscribe;"> pour en obtenir + la liste complète. -Quand quelqu'un d'autre que le mainteneur courant sort un nouveau paquet, il -devrait ajouter un nouveau morceau à la partie <var/debian-revision/ du numéro -de version -- c'est à dire la partie après le dernier trait d'union. Ce morceau -supplémentaire commencera à <tt/1/ afin d'éviter de priver un des mainteneurs -actuels d'un de ses numéros de version, ce qui pourrait le gêner. Si il n'y a -pas de partie <var/debian-revision/ dans le numéro de version, alors, il devrait -en être créée une dans le numéro de version, en commençant à <tt/1/. + <sect1 id="mailing-lists-subunsub">S'abonner et se désabonner +<p> +Pour vous abonner ou vous désabonner de n'importe quelle liste, + envoyez un courrier électronique à + <tt>debian-<var>foo</var>-REQUEST@&lists-host;</tt>, où + <tt>debian-<var>foo</var></tt> est le nom de la liste, avec le mot + <tt>subscribe</tt> dans le champ <em>Objet</em><footnote><p><em>Subject</em> + en anglais</footnote> pour vous abonner à la liste ou <tt>unsubscribe</tt> + pour vous désabonner. <p> +Si vous préférez utiliser une page web pour vous inscrire à plusieurs listes, + celle-ci se trouve à l'adresse <url id="&url-debian-lists-subscribe;">. +<p> +Vous pouvez télécharger la liste des listes de diffusion et quelques + instructions à <url id="&url-debian-lists-txt;"> ou installer le paquet + <package>doc-debian</package> et en disposer localement dans le fichier + &file-mail-lists;. -S'il est absolument nécessaire pour quelqu'un d'autre que le mainteneur courant -de faire une nouvelle version basée sur une nouvelle souche, alors la personne -faisant cette version devrait commencer avec le numéro <var/debian-revision/ -<tt/0.1/. Le mainteneur courant aurait commencé avec le numéro de -<var/debian-revision/ à <tt/1/. + <sect1 id="mailing-lists-rules">Règles d'usage simple +<p> +Lorsque vous répondez aux messages d'une liste de diffusion, n'envoyez pas de + copie (<tt>CC</tt>) à l'auteur du courrier à moins qu'il ne l'ait demandé + explicitement. Quelqu'un qui envoie un message à une liste de diffusion se doit + d'y lire les réponses. <p> +La multi-diffusion (envoyer le même message à plusieurs listes) est déconseillé. + Comme toujours sur Internet, veuillez réduire le texte cité des messages + auxquels vous répondez. En général, veuillez adhérer aux conventions usuelles + d'envoi de messages. Veuillez lire le <url id="&url-debian-lists;" name="code + de conduite"> pour plus d'information. -<sect>Changement de mainteneur + <sect1 id="mailing-lists-special">Listes spéciales <p> +&email-debian-private; est une liste de diffusion destinée aux discussions + privées entre développeurs Debian. Elle doit être utilisée pour tout message + qui ne doit pas être publié, quelle qu'en soit la raison. C'est une liste à + faible trafic et les utilisateurs sont priés de ne l'utiliser qu'en cas de + réelle nécessité. De plus, il ne faut <em>jamais</em> faire suivre un courrier + de cette liste à qui que ce soit. Pour des raisons évidentes, les archives de + cette liste ne sont pas disponibles sur la toile. Vous pouvez les consulter en + visitant le répertoire <file>~debian/archive/debian-private</file> avec votre + compte sur <tt>lists.debian.org</tt>. +<p> +&email-debian-email; est une liste de diffusion fourre-tout. Elle est utilisée + pour les correspondances relatives à Debian qu'il serait utile d'archiver, + telles que des échanges avec les auteurs amonts à propos de licences, de bogues + ou encore des discussions sur le projet avec d'autres personnes. -Régulièrement, une liste des paquets nécessitant un nouveau mainteneur est -postée vers la liste <tt>debian-devel</tt>. Cette liste peut aussi être -consultée sur <ftpsite>ftp.debian.org</> dans le fichier -<ftppath>/debian/doc/package-developers/prospective-packages.txt</>. -Si vous voulez reprendre la maintenance d'un de ces paquets, ou si vous ne -pouvez plus maintenir les paquets que vous avez, ou si vous voulez simplement -savoir si quelqu'un est en train de travailler sur un nouveau paquet, envoyez un -message à <email/override-change@debian.org/. + <sect id="irc-channels">Canaux IRC +<p> +Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont + principalement hébergés sur le réseau <url id="&url-openprojects;" + name="freenode"> (anciennement connu sous le nom de Open Projects Network). + L'entrée DNS <tt>irc.debian.org</tt> est simplement un alias vers + <tt>irc.openprojects.net</tt>. +<p> +Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un +canal important, généraliste, où les utilisateurs peuvent trouver des nouvelles + récentes dans le sujet et qui est administré par des robots. <em>#debian</em> + est destiné aux anglophones ; il existe également <em>#debian.de</em>, + <em>#debian-fr</em>, <em>#debian-br</em> et d'autres canaux avec des noms + semblables pour les personnes parlant d'autres langues. +<p> +Le canal principal pour le développement Debian est <em>#debian-devel</em>. + C'est un canal très actif avec habituellement plus de 150 personnes connectées + en permanence. C'est un canal pour les personnes qui travaillent sur Debian, ce + n'est pas un canal d'aide (il existe <em>#debian</em> pour cela). Il est + cependant ouvert à tous ceux qui veulent écouter (et apprendre). Le sujet est + toujours rempli d'informations intéressantes. <p> +Comme <em>#debian-devel</em> est un canal ouvert, vous ne devriez pas y parler + de problèmes discutés sur &email-debian-private;. Il existe un canal protégé + par clé <em>#debian-private</em> dans ce but. La clé est disponible dans les + archives de debian-private à + <file>master.debian.org:&file-debian-private-archive;</file>, effectuez + simplement un <prgn>zgrep</prgn> avec <em>#debian-private</em> dans tous les + fichiers. +<p> +Il existe d'autres canaux dédiés à des sujets spécifiques. <em>#debian-bugs</em> + est utilisé pour la coordination des <em>chasses aux bogues</em>. + <em>#debian-boot</em> est utilisé pour la coordination du travail sur les + disquettes de démarrage (i.e. l'installeur). <em>#debian-doc</em> est utilisé + occasionnellement pour travailler sur la documentation comme celle que vous + lisez actuellement. D'autres canaux sont dédiés à une architecture ou un + ensemble de paquets : <em>#debian-bsd</em>, <em>#debian-kde</em>, + <em>#debian-jr</em>, <em>#debian-edu</em>, <em>#debian-sf</em> (paquet + SourceForge), <em>#debian-oo</em> (paquet OpenOffice), etc. +<p> +Certains canaux pour développeurs non anglophones existent, par exemple, + <em>#debian-devel-fr</em> pour les francophones intéressés dans le + développement de Debian. -Si vous reprenez un ancien paquet, vous voudrez probablement être désigné comme -le mainteneur officiel du paquet dans le système de suivi de bogues. Ceci sera -fait automatiquement une fois que vous aurez envoyé une nouvelle version avec un -champ <tt/Maintainer:/ mis à jour. Si vous ne comptez pas envoyer de nouvelle -version avant un certain temps, envoyez un courrier électronique à -<email/override-change@debian.org/ pour que les rapports de bogue vous soient -envoyés. + + <sect id="doc-rsrcs">Documentation <p> +Ce document contient beaucoup d'informations très utiles aux développeurs + Debian, mais il ne peut pas tout contenir. La plupart des autres documents + intéressants sont référencés dans <url id="&url-devel-docs;" name="le coin du + développeur">. Prenez le temps de parcourir tous les liens, vous apprendrez + encore beaucoup de choses. + -<chapt>Le système de suivi de bogues + <sect id="server-machines">Les serveurs Debian <p> -Ce chapitre explique le système de traitement des bogues de Debian aux -mainteneurs Debian. Si vous voulez savoir comment signaler un bogue ou comment -accéder aux informations sur les bogues signalés lisez plutôt Le Manuel de -l'utilisateur Debian. +Debian possède plusieurs ordinateurs employés comme serveurs, dont la plupart hébergent + les fonctions critiques du projet Debian. La plupart des machines sont + utilisées pour des activités de portage et elles ont toutes un accès permanent + à Internet. <p> - Initialement, un rapport de bogue est soumis par un utilisateur par un simple - courrier électronique à <tt>submit@bugs.debian.org</tt>. Il lui sera alors - attribué un numéro, un accusé de réception sera envoyé à l'utilisateur et le - message sera envoyé vers la liste de diffusion <tt>debian-devel</tt>. Si - l'utilisateur a inclus une ligne « Package » indiquant un paquet avec un - mainteneur connu, ce mainteneur recevra une copie lui aussi. +La plupart des machines peuvent être utilisées par les développeurs + tant qu'ils respectent les règles définies dans la <url + id="&url-dmup;" name="charte d'utilisation des machines Debian">. <p> +Dans l'ensemble, vous pouvez faire usage de ces machines pour des buts relatifs + à Debian comme vous l'entendez. Veuillez cependant être gentil avec les + administrateurs système et ne pas utiliser de grandes quantités d'espace + disque, de ressource réseau ou CPU sans obtenir auparavant l'accord des + administrateurs. Habituellement, ces machines sont administrées par des + volontaires. +<p> +Veuillez prendre soin de votre mot de passe Debian ainsi que des clés SSH + installées sur les machines Debian. Évitez les méthodes de connexion ou d'envoi + de données qui envoient les mots de passe en clair par l'Internet comme telnet, + FTP, POP, etc. +<p> +Veuillez ne pas déposer de données non relatives à Debian sur les serveurs +Debian à moins que vous n'ayez préalablement obtenu la permission de le faire. +<p> +La liste actuelle des machines Debian est disponible à <url + id="&url-devel-machines;">. Cette page web contient les noms des machines, les + informations de contact, les informations sur qui peut s'y connecter, les clés + SSH, etc. +<p> +Si vous avez un problème en utilisant un serveur Debian et si vous estimez que + les administrateurs système devraient en être avertis, l'équipe des + administrateurs système peut être jointe à + <email>debian-admin@lists.debian.org</email>. +<p> +Si votre problème est lié à un certain service ou n'est pas lié au système + (paquet à supprimer de l'archive ou suggestion pour le site web par exemple), + il vous faudra en général ouvrir un rapport de bogue sur un + « pseudo-paquet ». Reportez-vous à la section <ref id="submit-bug"> + pour connaître la procédure à suivre. - <tt>Bug#nnn:</tt> sera ajouté à la ligne « Subject », et le champ - « Reply-To » inclura l'auteur du rapport de bogue, et - <tt>nnn@bugs.debian.org</tt>. + <sect1 id="servers-bugs">Le serveur pour les rapports de bogues +<p> +<tt>bugs.debian.org</tt> est le serveur maître du système de suivi des bogues + (BTS<footnote><p>Système de suivi des bogues se dit <em>Bug Tracking + System</em> en anglais</footnote>). Si vous envisagez de manipuler les rapports + de bogue ou d'en faire une analyse statistique, ce sera le bon endroit pour le + faire. Informez la liste &email-debian-devel; de votre intention avant + d'implémenter quoi que ce soit afin d'éviter un travail en double ou un + gaspillage de temps machine. <p> +Tous les développeurs Debian ont un compte sur + <tt>bugs.debian.org</tt>. -<sect>Manipuler les rapports de bogues + <sect1 id="servers-ftp-master">Le serveur ftp-master <p> +Le serveur <tt>ftp-master.debian.org</tt> est le serveur maître de l'archive + Debian (exception faite des paquets non-US). En général, les mises à jour de + paquets se font sur ce serveur. Reportez-vous à la section <ref id="upload"> + pour en savoir plus. +<p> +Les problèmes avec l'archive Debian FTP doivent généralement être rapportés + comme bogue sur le pseudo-paquet <package>ftp.debian.org</package> ou par + courrier électronique à &email-ftpmaster; ; reportez-vous à la section + <ref id="archive-manip"> pour connaître la procédure à suivre. -<sect1>Clore un rapport de bogue + <sect1 id="servers-non-us">Le serveur non-US +<p> +Le serveur non-US <tt>non-us.debian.org</tt> est le serveur maître de la partie + non-US de l'archive Debian. Si vous avez besoin d'envoyer un paquet dans l'une + des sections non-US, envoyez-le vers ce serveur. Reportez-vous à la section + <ref id="upload-non-us"> pour en savoir plus. <p> +Les problèmes avec l'archive de paquets non-US doivent généralement être + rapportés comme bogue sur le pseudo-paquet <package>nonus.debian.org</package> + pseudo-package (remarquez l'absence de trait d'union entre "non" et "us" dans + le nom du pseudo-paquet — c'est dû à la compatibilité descendante). + Rappelez-vous de vérifier si quelqu'un n'aurait pas déjà rempli un rapport de + bogue concernant le problème sur le <url + id="http://bugs.debian.org/nonus.debian.org" name="système de suivi des + bogues">. - Un développeur qui voit un bogue sur <tt>debian-devel</tt> et qui en prend la - responsabilité devrait envoyer une réponse, en utilisant la fonction - « Répondre » de son logiciel favori et en éditant le champ « À » pour envoyer - à <tt>nnn-done@bugs.debian.org</tt> au lieu de <tt>nnn@bugs</tt> - (<tt>nnn-close</tt> est un alias pour <tt>nnn-done</tt>). + <sect1 id="servers-www">Le serveur www-master <p> +Le serveur web principal est <tt>www-master.debian.org</tt>. Il héberge les + pages web officielles, la facade de Debian pour la plupart des débutants. +<p> +Si vous rencontrez un problème avec un serveur web Debian, vous devez + généralement envoyer un rapport de bogue sur le pseudo-paquet + <package>www.debian.org</package>. Vérifiez d'abord sur le <url + id="http://bugs.debian.org/www.debian.org" name="système de suivi des bogues"> + que personne ne l'a déjà rapporté avant vous. - L'adresse de l'auteur originel du rapport de bogue sera incluse dans le champ - « To » parce que le système de gestion des bogues l'avait inclus dans le champ - « Reply-To ». + <sect1 id="servers-people">Le serveur web people <p> - - Les messages « Done » ne sont pas automatiquement envoyés dans la liste de - diffusion, il pourrait donc parfois valoir la peine d'inclure la liste de - diffusion <tt>debian-devel</tt> si les autres développeurs peuvent être - intéressés. +<tt>people.debian.org</tt> est le serveur utilisé pour les pages personnelles + des développeurs concernant ce qui est lié à Debian. <p> - - La personne qui clôt le rapport de bogue et la personne qui l'a soumis - recevront chacune une notification du changement de statut du rapport. +Si vous avez des informations spécifiques Debian que vous voulez rendre + disponibles sur le web, vous pouvez le faire en les plaçant dans le répertoire + <file>public_html</file> de votre répertoire personnel sur + <tt>people.debian.org</tt>. Elles seront accessibles à l'adresse + <tt>http://people.debian.org/~<var>votre-user-id</var>/</tt>. <p> - - -<sect1>Messages suivis +Vous ne devriez utiliser que cet emplacement particulier car il sera sauvegardé + alors que sur les autres serveurs, ce ne sera pas le cas. +<p> +Habituellement, la seule raison pour utiliser un serveur différent est que vous + avez besoin de publier des informations soumises aux restrictions d'export + américaines, dans ce cas, vous pouvez utiliser l'un des autres serveurs situés + en dehors des États-Unis, comme le serveur mentionné ci-dessus + <tt>non-us.debian.org</tt>. <p> +Veuillez envoyer un courrier à &email-debian-devel; si vous avez une question. - Si un développeur veut répondre à un rapport de bogue sans marquer le bogue - comme résolu, il peut simplement répondre au message. Sa réponse ira (par - défaut) à <tt>nnn@bugs</tt> et à l'auteur du rapport de bogue. Le système de - suivi de bogues archivera la réponse avec le reste des traces pour ce rapport - de bogue et le fera suivre à <tt>debian-devel</tt>. Le bogue ne sera pas - marqué comme résolu. + <sect1 id="servers-cvs">Le serveur CVS <p> - - Si vous voulez envoyer une réponse à un message qui n'est pas appropriée pour - <tt>debian-devel</tt>, vous pouvez le faire en envoyant votre réponse à - <tt>nnn-quiet@bugs</tt> ou <tt>nnn-maintonly@bugs</tt>, qui l'archivera - simplement (sans le faire suivre aucunement) et l'enverra seulement au - mainteneur du paquet en question. +Notre serveur CVS est situé sur <tt>cvs.debian.org</tt>. +<p> +Si vous avez besoin d'un serveur CVS accessible par tous pour, par exemple, + coordonner le travail de plusieurs développeurs sur un paquet, vous pouvez + demander un espace CVS sur ce serveur. <p> +Le serveur <tt>cvs.debian.org</tt> autorise les accès CVS locaux, les accès en + lecture seule pour les connexions client-serveur anonymes et les accès + client-serveur complets pour les connexions <prgn>ssh</prgn>. L'espace CVS peut + aussi être consulté par la toile à l'adresse <url id="&url-cvsweb;">. +<p> +Pour obtenir un espace CVS, envoyez une demande à l'adresse &email-debian-admin; + en précisant le nom de l'espace, le compte Debian propriétaire du répertoire + racine et pourquoi vous en avez besoin. - <em>N'utilisez pas</em> les fonctionnalités « reply to all recipients » ou - « follow-up » de votre outil de courrier, à moins d'avoir l'intention de - modifier ensuite les destinataires. En particulier, n'envoyez pas un message - de « follow-up » à <tt>nnn@bugs.debian.org</tt> et à - <tt>submit@bugs.debian.org</tt> simultanément parce que le système de suivi - de bogues recevrait alors deux copies de chaque et chacune serait renvoyée à - <tt>debian-devel</tt> séparément. -<p> -<sect1>Enregistrer que vous avez fait suivre un rapport de bogue + <sect id="devel-db">La base de données des développeurs <p> - - Quand un développeur fait suivre un rapport de bogue au développeur d'un - paquet plus général dont est dérivé le paquet Debian, il doit le noter dans - le système de suivi de bogue comme suit : +La base de données des développeurs à <url id="&url-debian-db;"> est un annuaire + LDAP de gestion des informations des développeurs Debian. Vous pouvez utiliser + cette ressource pour rechercher la liste des développeurs Debian. Pour plus + d'informations sur la façon de garder à jour vos informations dans la base des + développeurs, reportez-vous à <ref id="user-maint">. Une partie de ces + informations est également disponible à travers le service finger sur les + serveurs Debian, essayez <prgn>finger yourlogin@debian.org</prgn> pour voir ce + qu'il indique. <p> +La base de données vous permet d'enregistrer d'autres informations ; par +exemple, des + clés publiques SSH qui seront installées automatiquement sur les machines + Debian officielles, ou des entrées DNS de type *debian.net. Ces fonctionnalités + sont documentées à <url id="&url-debian-db-mail-gw;">. - Vérifiez que le champ « To » de votre message à l'auteur contient uniquement - l'adresse de l'auteur ; mettez ensuite la personne qui a signalé le bogue et - <tt>nnn-forwarded@bugs.debian.org</tt> dans le champ « CC ». +<!-- <sect id="servers-mirrors">Les miroirs des serveurs Debian <p> - - Demandez à l'auteur de respecter le « CC » à <tt>nnn-forwarded@bugs</tt> - quand il répond, pour que le système de suivi de bogue archive sa réponse - avec le rapport original. +Les serveurs web et FTP Debian sont dupliqués sur d'autres serveurs. + Évitez de charger les serveurs originaux. Idéalement, les serveurs originaux + se contentent de copier leur contenu sur les miroirs de premier niveau et tous + les utilisateurs consultent les miroirs. Ainsi le projet Debian étale ses + besoins en bande passante sur plusieurs serveurs et plusieurs réseaux. Notez + que la duplication des données sur les miroirs est déclenchée par le serveur + maître. Ceci nous garantit que les miroirs sont aussi à jour que possible. +<p> +La liste des miroirs FTP/HTTP se trouve à l'adresse <url + id="&url-debian-mirrors;">. Vous trouverez plus d'information sur les miroirs + Debian à l'adresse <url id="&url-debian-mirroring;">. Cette page contient des + informations et des outils qui pourront vous aider si vous avez l'intention de + mettre en place votre propre miroir, que ce soit pour un usage interne ou pour + un accès public. <p> +Les miroirs sont en général mis en oeuvre par des tiers qui veulent aider + Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces + machines. +--> - Quand le système de suivi de bogues reçoit un message à - <tt>nnn-forwarded</tt>, il marque le bogue correspondant comme ayant été - transmis à (aux) adresse(s) figurant dans le champ « To » du message qu'il - reçoit. + <sect id="archive">L'archive Debian +<p> +La distribution &debian-formal; est composée d'un grand nombre de paquets + (fichiers <tt>.deb</tt> : actuellement, à peu près &number-of-pkgs;) et de + quelques autres fichiers (comme la documentation et des images des disquettes + d'installation). +<p> +Voici un exemple d'arborescence pour une archive Debian complète : +<p> +&sample-dist-dirtree; +<p> +Comme vous pouvez le voir, le répertoire racine contient deux répertoires, + <file>dists/</file> et <file>pool/</file>. Le second est un ensemble de + répertoires où sont stockés les paquets. Ceux-ci sont manipulés grâce à la base + de données de l'archive et aux logiciels qui l'accompagnent. Le premier + répertoire contient les distributions <em>stable</em>, <em>testing</em> et + <em>unstable</em>. Les fichiers <file>Packages</file> et <file>Sources</file> + qui se trouvent dans les répertoires de distribution peuvent faire référence à + des fichiers du répertoire <file>pool/</file>. Le découpage en sous-répertoires + est identique d'un répertoire de distribution à l'autre . Ce que nous + exposerons ci-dessous pour la distribution <em>stable</em> est également + applicable aux distributions <em>unstable</em> et <em>testing</em>. <p> - - Vous pouvez aussi manipuler l'information « forwarded to » en envoyant des - messages à <tt>control@bugs</tt>. +Le répertoire <file>dists/stable</file> contient trois répertoires nommés + <file>main</file>, <file>contrib</file> et <file>non-free</file>. <p> - -<sect1>Messages de résumé à « debian-devel » +Dans chacune de ces sections, se trouve un répertoire contenant les paquets + sources (<file>source/</file>) et un répertoire pour chaque architecture + acceptée (<file>binary-i386/</file>, <file>binary-m68k/</file>, etc.). <p> +La section <em>main</em> contient d'autres répertoires destinés aux images de + disquettes et à plusieurs documents essentiels pour installer la distribution + Debian sur une architecture particulière (<file>disk-i386/</file>, + <file>disk-m68k/</file>, etc). - Chaque vendredi, une liste des bogues non résolus est postée sur - <tt>debian-devel</tt>, triée suivant l'âge du rapport ; chaque mardi, une - liste des rapports de bogue non résolus depuis trop longtemps est postée, - triée suivant le mainteneur du paquet. + <sect1>Les sections <p> +La section <em>main</em> constitue la <strong>distribution &debian-formal; + officielle</strong>. Elle est officielle parce qu'elle est entièrement conforme + à toutes nos recommandations. Les deux autres sections divergent de ces + recommandations à différents degrés, elles <strong>ne</strong> font donc <strong>pas</strong> + officiellement partie de &debian-formal;. +<p> +Chaque paquet de la section <em>main</em> doit être conforme aux <url + id="&url-dfsg;" name="directives Debian pour le logiciel + libre"><footnote>Debian Free Software Guidelines</footnote> et à toutes les + autres recommandations décrites dans <url id="&url-debian-policy;" name="la + charte Debian"><footnote>Debian Policy Manual</footnote>. Les + DFSG<footnote><em>Debian Free Software Guidelines</em></footnote> constituent + notre définition de « logiciel libre ». Reportez-vous à la <em>charte + Debian</em> pour en savoir plus. +<p> +Les paquets de la section <em>contrib</em> doivent être conformes aux DFSG, mais + ne respectent pas d'autres contraintes. Ils peuvent, par exemple, dépendre de + paquets de la section <em>non-free</em>. +<p> +Les paquets qui ne sont pas conformes aux DFSG sont rangés dans la section + <em>non-free</em>. Bien que nous supportions l'usage de ces paquets et qu'ils + bénéficient de nos infrastructures (système de suivi des bogues, listes de + diffusion, etc), ces paquets <em>non-free</em> ne font pas partie de la + distribution Debian. +<p> +La <em>charte Debian</em> donne des définitions plus précises pour ces trois + sections. Les paragraphes précédents ne constituent qu'une introduction. +<p> +La séparation de l'archive en trois sections est importante pour toute personne + qui désire distribuer Debian, que ce soit par serveur FTP ou sur cédérom. Il + suffit de distribuer les sections <em>main</em> et <em>contrib</em> pour éviter + tout problème légal. Certains paquets de la section <em>non-free</em> + interdisent leur distribution à titre commercial par exemple. +<p> +D'un autre coté, un distributeur de cédérom pourra facilement vérifier + la licence de chacun des paquets de la section <em>non-free</em> et + ajouter tous les paquets qu'il pourra ajouter (dans + la mesure où cela varie énormément d'un distributeur à l'autre, ce travail ne + peut être fait par les développeurs Debian). - Si le mainteneur d'un paquet est listé incorrectement, c'est généralement - parce qu'il y a eu un changement de mainteneur récemment, et le nouveau - mainteneur n'a pas encore envoyé de nouvelle version du paquet avec un champ - de contrôle « Maintainer » modifié. Ceci sera réglé quand le paquet sera - envoyé. Une autre solution, il y a un fichier que les mainteneurs de la - distribution peuvent éditer pour enregistrer les changements de mainteneur. - Par exemple, si un nouveau paquet n'est pas prévu pour une période - suffisamment longue, vous pouvez contacter - <tt>iwj-mastercron@master.debian.org</tt> pour que le changement soit forcé. + + <sect1>Les architectures +<p> +À ses débuts, le noyau Linux existait uniquement pour les architectures Intel + x86 ; il en était de même pour Debian. Linux devenant de plus en plus + populaire, il a été porté vers d'autres architectures. <p> +Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC, + Motorola, 680x0 (Atari, Amiga, et Macintosh), MIPS et PowerPC. Le noyau 2.2 + reconnaît de nouvelles architectures, comme ARM et UltraSPARC. Puisque Linux + reconnaît ces architectures, Debian a décidé qu'elle devait également les + accepter. C'est pourquoi plusieurs portages sont en cours ; en fait, il y + a aussi des portages vers d'autres noyaux. À coté d'<em>i386</em> (notre nom + pour Intel x86), nous avons, au moment où j'écris <em>m68k</em>, + <em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>, + <em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>, <em>mips</em>, + <em>mipsel</em> et <em>sh</em>. +<p> +&debian-formal; 1.3 est disponible uniquement pour <em>i386</em>. Debian 2.0 + reconnaît les architectures <em>i386</em> et <em>m68k</em>. Debian 2.1 reconnaît + les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et + <em>sparc</em>. Debian 2.2 accepte en plus les architectures + <em>powerpc</em> et <em>arm</em>. Debian 3.0 accepte cinq + nouvelles architectures : <em>ia64</em>, <em>hppa</em>, <em>s390</em>, + <em>mips</em> et <em>mipsel</em>. +<p> +Pour chaque portage, vous trouverez des informations destinées aux développeurs + et utilisateurs sur la page <url id="&url-debian-ports;" name="Portage + Debian">. -<sect1>Rouvrir, réassigner et manipuler des bogues + <sect1>Les paquets +<p> +Il existe deux types de paquets Debian : les paquets sources et les paquets + binaires. +<p> +Les paquets sources sont constitués de deux ou trois fichiers : un fichier + <file>.dsc</file> et soit un fichier <file>.tar.gz</file>, soit un fichier + <file>.orig.tar.gz</file> et un fichier <file>.diff.gz</file>. <p> +Si un paquet est développé spécifiquement pour le projet Debian et n'est pas + distribué en dehors de Debian, il n'y a qu'un fichier <file>.tar.gz</file> qui + contient les sources du programme. Si un paquet est distribué ailleurs, le + fichier <file>.orig.tar.gz</file> contient ce que l'on appelle <em>code source + amont</em>, c'est-à-dire, le code source distribué par le <em>mainteneur + amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le fichier + <file>.diff.gz</file> contient les modifications faites par le responsable + Debian. +<p> +Le fichier <file>.dsc</file> liste tous les fichiers sources avec leurs sommes + de contrôle (<prgn>md5sums</prgn>) et quelques informations supplémentaires + concernant le paquet (responsable, version, etc). + - Il est possible de réassigner des rapports de bogue à d'autres paquets, d'en - rouvrir certains clos par erreur, de modifier l'information disant où - l'information a été transmise (forwarded), si elle l'a été, de changer les - titres des rapports, de fusionner et séparer des rapports de bogue. Ceci est - fait en envoyant des courriers électroniques à - <tt>control@bugs.debian.org</tt>. + <sect1>Les répertoires des distributions +<p> +L'organisation des répertoires présentée précédemment est elle-même englobée par + les <em>répertoires des distributions</em>. Chaque distribution est incluse + dans le répertoire <file>pool</file> à la racine de l'archive Debian. +<p> +En résumant, une archive Debian a un répertoire racine sur un serveur FTP. Par + exemple, sur le site miroir <ftpsite>ftp.us.debian.org</ftpsite>, l'archive + Debian se trouve dans <ftppath>/debian</ftppath> ce qui est un emplacement + courant. Un autre emplacement courant est <file>/pub/debian</file>. <p> +Une distribution est composée de paquets sources et binaires et des + fichiers <file>Sources</file> et <file>Packages</file> correspondants qui + contiennent toutes les meta-informations sur les paquets. Les premiers sont + conservés dans le répertoire <file>pool/</file> tandis que les seconds sont + conservés dans le répertoire <file>dists/</file> de l'archive (pour + compatibilité descendante). - Le format de ces messages est décrit dans les sections - suivantes. + + <sect2 id="sec-dists"><em>Stable</em>, <em>testing</em> et + <em>unstable</em> +<p> +Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire + <file>dists/stable</file>), une distribution appelée <em>testing</em> (dans le + répertoire <file>dists/testing</file>) et une distribution appelée + <em>unstable</em> (dans le répertoire <file>dists/unstable</file>). Ceci + reflète le processus de développement du projet Debian. +<p> +Les développements se font sur la distribution + <em>unstable</em><footnote><p><em>unstable</em> signifie + « instable »</footnote> (c'est pourquoi elle est aussi appelée + <em>distribution de développement</em>). Chaque développeur Debian peut + modifier ses paquets à tout moment dans cette distribution. Ainsi son contenu + change tous les jours. Comme aucun effort particulier n'est fait pour s'assurer + que tout fonctionne correctement dans cette distribution, elle est parfois + littéralement « instable ». +<p> +<ref id="testing"> est générée automatiquement en prenant les paquets de + <em>unstable</em> s'ils satisfont à certains critères. Ces critères + garantissent que les paquets de <em>testing</em> sont de bonne qualité. La mise + à jour de <em>testing</em> est lancée chaque jour après que les nouveaux + paquets ont été installés. <p> +Après une période de développement, quand le responsable de + distribution<footnote><p><em>Release manager</em></footnote> le juge opportun, + la distribution <em>testing</em> est gelée, ce qui signifie que les conditions + à remplir pour qu'un paquet passe de <em>unstable</em> à <em>testing</em> sont + durcies. Les paquets trop bogués sont supprimés et les seules mises à jours + autorisées concernent les corrections de bogues. Après quelque temps, selon + l'avancement, la distribution entre dans une phase de « gel complet » + où les seules modifications acceptées concernent la procédure d'installation. + Cette phase s'appelle un « cycle de test » et cela peut durer jusqu'à + deux semaines. Il peut y avoir plusieurs cycles de tests avant que le + responsable de distribution ne la déclare prête pour la diffusion. À la fin du + dernier cycle de test, la distribution <em>frozen</em> devient <em>stable</em>, + remplaçant l'ancienne distribution <em>stable</em> qui est enlevée à cette + occasion (elle peut être retrouvée à l'adresse <tt>&archive-host;</tt>). +<p> +Ce cycle de développement est basé sur l'idée que la distribution + <em>unstable</em> devient <em>stable</em> après une période de test + (<em>testing</em>). Une distribution contient inévitablement des bogues, même + si elle est classée stable. C'est pourquoi les distributions stables sont mises + à jour de temps en temps. Les corrections introduites sont testées avec une + grande attention et sont ajoutées une à une à l'archive pour diminuer les + risques d'introduire de nouveaux bogues. Vous pouvez trouver des paquets + proposés pour les mises à jour de <em>stable</em> dans le répertoire + <file>proposed-updates</file>. De temps en temps, les paquets de ce répertoire + qui ne présentent pas de problème sont installés dans la distribution + <em>stable</em> et le numéro de révision de cette distribution est incrémenté + (« 3.0 » devient « 3.0r1 », « 2.0r4 » devient + « 2.0r5 » et ainsi de suite). +<p> +Notez que, pendant la période de gel, les développements continuent sur la + distribution <em>unstable</em> car cette distribution reste en place. -<sect1>Fonctionnalités plus ou moins obsolètes -(étude des sujets) + <sect2><em>Experimental</em> +<p> +La distribution <em>experimental</em> est une distribution particulière. Ce n'est + pas une distribution à part entière comme le sont <em>stable</em> et + <em>unstable</em>. Elle est prévue pour servir de plate-forme de + développement pour les projets expérimentaux qui risquent vraiment de + détruire le système ou bien pour des logiciels qui sont vraiment trop + instables pour être inclus dans la distribution <em>unstable</em> (mais pour + lesquels une mise en paquet est justifiée). Les utilisateurs qui téléchargent + et installent des paquets depuis <em>experimental</em> sont prévenus : + on ne peut pas faire confiance à la distribution <em>experimental</em>. +<p> +Si un logiciel peut causer des dégats importants, il sera sûrement + préférable de le mettre dans la distribution <em>experimental</em>. Un + système expérimental de fichier compressé, par exemple, devrait probablement + aller dans <em>experimental</em>. <p> +Une nouvelle version amont qui ajoute de nouvelles fonctions tout en supprimant + de nombreuses autres ne devra pas être téléchargée dans l'archive Debian, + elle pourra cependant être téléchargée dans <em>experimental</em>. Une + nouvelle version non finalisée d'un logiciel qui utilise une méthode de + configuration complètement différente pourrait aller dans + <em>experimental</em> au gré du responsable. Si vous travaillez sur un cas de + mise à jour complexe ou incompatible, vous pouvez aussi utiliser + <em>experimental</em> comme plate-forme d'intégration et ainsi fournir un + accès aux testeurs. +<p> +Quelques logiciels expérimentaux peuvent cependant aller dans <em>unstable</em>, + avec un avertissement dans la description mais ce n'est pas recommandé car + les paquets de <em>unstable</em> se propagent dans <em>testing</em> et + aboutissent dans <em>stable</em>. Vous ne devriez pas avoir peur d'utiliser + <em>experimental</em> car ceci ne cause aucun souci aux ftpmasters, les + paquets expérimentaux sont automatiquement enlevés quand vous envoyez le + paquet dans <em>unstable</em> avec un numéro de version supérieur. +<p> +Un nouveau logiciel qui ne risque pas d'endommager le système ira directement + dans <em>unstable</em>. +<p> +Une alternative à <em>experimental</em> consiste à utiliser vos pages + personnelles sur le serveur <tt>people.debian.org</tt>. + - Les messages qui arrivent pour soumission ou les bogues dont le sujet - commence par <tt>Bug#nnn</tt> sont traités comme ayant déjà été envoyés à - <tt>nnn@bugs</tt>. Ceci pour des raisons de compatibilité ascendante avec les - courriers envoyés depuis les anciennes adresses et pour éviter les messages - de suivi (followup) envoyés par erreur à <tt>submit@bugs.debian.org</tt> pour - soumission (par exemple, en utilisant « reply to all recipients »). + <sect1 id="codenames">Les noms de distribution <p> +Chaque distribution Debian diffusée a un <em>nom de code</em> : Debian 1.1 + s'appelle « buzz » ; Debian 1.2, « rex » ; Debian + 1.3 « bo » ; Debian 2.0, « hamm » ; Debian 2.1, + « slink »; Debian 2.2 « potato » et Debian 3.0 + « woody ». Il y a aussi une pseudo-distribution nommée + « sid », il s'agit de la distribution <em>unstable</em> ; comme + les paquets vont de <em>unstable</em> à <em>testing</em> quand ils approchent + de la stabilité, la distribution « sid » n'est jamais diffusée. En + plus du contenu habituel d'une distribution Debian, « sid » contient + des paquets pour des architectures qui ne sont pas encore officiellement + reconnues ou pour lesquelles la distribution n'a pas encore été diffusée. Ces + architectures seront intégrées ulterieurement à la distribution principale. +<p> +Comme Debian est un projet de développement ouvert (i.e. tout le monde peut + participer et suivre les développements), même les distributions + <em>unstable</em> et <em>testing</em> sont disponibles sur les serveurs HTTP et + FTP de Debian. Si nous avions nommé le répertoire qui contient la prochaine + distribution à diffuser « testing », il aurait fallu changer son nom en + « stable » au moment de la diffusion, ce qui aurait forcé les miroirs + FTP à télécharger à nouveau la distribution complète (qui est plutôt volumineuse). +<p> +D'un autre coté, si une distribution s'appelait <em>Debian-x.y</em> dès le + départ, des personnes pourraient s'imaginer que la distribution Debian + <em>x.y</em> est disponible. (Cela s'est produit par le passé, un distributeur + avait gravé des cédéroms Debian 1.0 en utilisant une version de développement + pré-1.0. C'est pour cette raison que la première version officielle était la + version 1.1 et non la 1.0.) +<p> +En conséquence, les noms de répertoire des distributions dans l'archive sont + déterminés par leurs noms de code et non par leur statut (exemple : + slink). Ces noms sont identiques pendant la période de développement et une + fois la distribution diffusée ; des liens symboliques, qui peuvent être + modifiés facilement, indiquent la distribution stable actuelle. Tout ceci + explique pourquoi les répertoires des distributions sont nommés à partir des + noms de code des distributions alors que <em>stable</em>, <em>testing</em> et + <em>unstable</em> sont des liens symboliques qui pointent vers les répertoires + appropriés. - Un schéma similaire est utilisé pour « maintonly », « done », « quiet » et - « forwarded », qui traitent les courriers arrivant avec un champ « Subject » - modifié comme ayant été envoyés à l'adresse <tt>nnn-whatever@bugs</tt> - correspondante. -<p> + <sect id="mirrors">Les miroirs Debian + <p> +Les différentes archives de téléchargement et le site web disposent de plusieurs +miroirs pour soulager les serveurs principaux d'une lourde charge. En fait, +certains de ces serveurs ne sont pas publics et la charge est +répartie sur une première série de serveurs. De cette façon, les +utilisateurs ont toujours accès aux miroirs et s'y habituent, ce qui permet à +Debian de mieux répartir les besoins en bande passante sur plusieurs serveurs et +plusieurs réseaux différents et évitent aux utilisateurs de surcharger +l'emplacement primaire. Notez que dans cette première série, les serveurs sont aussi à jour +que possible car la mise à jour est déclenchée par les sites maîtres internes. + <p> +Toutes les informations sur les miroirs Debian peuvent être trouvées à <url +id="&url-debian-mirrors;">, y compris une liste des miroirs publics disponibles +FTP/HTTP. Cette page utile inclut également des informations et des outils pour +créer son propre miroir, soit en interne soit pour un accès public. + <p> +Les miroirs sont en général mis en oeuvre par des tiers qui veulent aider + Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces + machines. - Les messages arrivant sans numéro de rapport de bogue dans leur adresse, ni - dans leur champ Subject seront archivés comme « junk » et gardés pendant - quelques semaines, mais autrement ignorés. + <sect id="incoming-system"> + <heading>Le système Incoming +<p> +Le système Incoming est responsable de la collecte des paquets mis à jour et de + leur installation dans l'archive Debian. Il est constitué d'un ensemble de + répertoires et de scripts qui sont installés à la fois sur + <tt>&ftp-master-host;</tt> et sur <tt>&non-us-host;</tt>. <p> +Les paquets sont envoyés par tous les responsables Debian dans un répertoire + nommé <file>unchecked</file>. Ce répertoire est parcouru toutes les 15 minutes + par le script <prgn>katie</prgn> qui vérifie l'intégrité des paquets envoyés et + les signatures de chiffrage. Si le paquet est considéré comme prêt à être + installé, il est déplacé dans le répertoire <file>accepted</file>. S'il s'agit + du premier envoi du paquet, il est déplacé dans le répertoire <file>new</file> + où il attend l'approbation des ftpmasters. Si le paquet contient des fichiers + devant être installés <em>à la main</em>, il est déplacé dans le répertoire + <file>byhand</file> où il attend une installation manuelle par les ftpmasters. + Sinon, si une erreur a été détectée, le paquet est refusé et il est déplacé + dans le répertoire <file>reject</file>. +<p> +Une fois que le paquet est accepté, le système envoie une confirmation par + courrier au responsable et ferme les bogues corrigés par l'envoi, puis + les compilateurs automatiques peuvent commencer la recompilation. Le paquet est + maintenant accessible publiquement à <url id="&url-incoming;"> (une telle + adresse n'existe pas pour les paquets de l'archive non-US) jusqu'à ce qu'il + soit vraiment installé dans l'archive Debian. Ceci se produit seulement une + fois par jour, le paquet est alors supprimé de <file>Incoming</file> et + installé dans le pool avec les autres paquets. Une fois que toutes les autres + mises à jour (générant des nouveaux fichiers d'index <file>Packages</file> et + <file>Sources</file> par exemple) ont été effectuées, un script spécial est + appelé pour demander aux miroirs primaires de se mettre à jour. +<p> +Tous les développeurs Debian ont un droit d'écriture dans le répertoire + <file>unchecked</file> pour pouvoir y envoyer leurs paquets, ils ont également + accès au répertoire <file>reject</file> pour supprimer les mauvais envois ou + déplacer certains fichiers dans le répertoire <file>unchecked</file>. Mais + seuls les ftpmasters ont droit d'écriture dans les autres répertoires. + C'est pourquoi vous ne pouvez pas supprimer un envoi une fois qu'il a été + accepté. -<sect1>Projets futurs + <sect1 id="delayed-incoming">Incoming différé <p> +Le répertoire <file>unchecked</file> comprend un sous-répertoire spécial, + <file>DELAYED</file>. Celui-ci est lui-même subdivisé en neuf répertoires + nommés <file>1-day</file> à <file>9-day</file>. Les paquets qui sont envoyés + dans l'un de ces répertoires seront déplacés dans le vrai répertoire + <file>unchecked</file> après le nombre correspondant de jours. Ceci est fait + par un script qui est exécuté chaque jour et qui déplace les paquets entre les + répertoires. Ceux qui sont dans « 1-day » sont installés dans + <file>unchecked</file> alors que les autres sont déplacés dans le répertoire + adjacent (par exemple, un paquet dans <file>5-day</file> sera déplacé dans + <file>4-day</file>). Cette fonctionnalité est particulièrement utile pour les + personnes qui effectuent des mises à jour indépendantes (NMU, + « non-maintainer uploads »). Au lieu d'attendre avant d'envoyer la + NMU, elle est envoyée dès qu'elle est prête dans l'un de ces répertoires + <file>DELAYED/<var>x</var>-day</file>. Ceci laisse le nombre correspondant de + jours au responsable pour réagir et envoyer lui-même une autre correction s'il + n'est pas complètement satisfait par la NMU. Il peut également enlever + complètement la NMU. +<p> +L'utilisation de cette fonctionnalité de délai peut être simplifiée en + l'intégrant à votre outil d'envoi. Par exemple, si vous utilisez + <prgn>dupload</prgn> (voir <ref id="dupload">), vous pouvez ajouter cette + partie à votre fichier de configuration : +<example> +$delay = ($ENV{DELAY} || 7); +$cfg{'delayed'} = { + fqdn => "&ftp-master-host;", + login => "yourdebianlogin", + incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/", + dinstall_runs => 1, + method => "scpb" +};</example> +Une fois que vous avez fait ce changement, <prgn>dupload</prgn> peut être +utilisé pour envoyer facilement dans l'un des répertoires de délai ainsi : +<example>DELAY=5 dupload --to delayed <changes-file></example> - Le champ « Package: » de l'en-tête devrait devenir obligatoire ; - actuellement, en cas d'oubli, seul un avertissement est généré. + <sect id="testing"> + <heading>La distribution « testing » +<p> +Les scripts qui mettent à jour la distribution <em>testing</em> sont exécutés + chaque jour après l'installation des paquets mis à jour. Ils génèrent les + fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils + le font d'une manière intelligente pour éviter toute incohérence et essayer de + n'utiliser que des paquets sans bogues. +<p> +L'inclusion d'un paquet de <em>unstable</em> est soumise aux + conditions suivantes : +<list compact="compact"> +<item><p>Le paquet doit avoir été disponible dans <em>unstable</em> depuis + plusieurs jours ; le nombre précis dépend du champ d'urgence de + l'envoi. Il s'agit de 10 jours pour une urgence faible, 5 jours pour une + urgence moyenne et 2 jours pour une urgence élevée. Ces délais peuvent + être doublés lors d'un gel de distribution ;</item> +<item><p>Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la + version disponible dans <em>testing</em> ;</item> +<item><p>Il doit être disponible pour toutes les architectures pour lesquelles + il a été auparavant construit. <ref id="madison"> peut être + intéressant pour vérifier cette information ;</item> +<item><p>Il ne doit pas casser les dépendances d'un paquet qui est déjà + disponible dans <em>testing</em> ;</item> +<item><p>Les paquets dont il dépend doivent soit être déjà disponibles dans + <em>testing</em> soit être acceptés dans <em>testing</em> au + même moment (et ils doivent eux-mêmes respecter tous ces + critères).</item> +</list> +<p> +Les scripts génèrent certains fichiers pour expliquer + pourquoi certains paquets sont maintenus hors de <em>testing</em>. Ils sont + disponibles à <url id="&url-testing-maint;">. Sinon, il est possible + d'utiliser le programme <prgn>grep-excuses</prgn> inclus dans le paquet + <package>devscripts</package>. Il peut facilement être mis dans la <manref + section="5" name="crontab"> pour rester informé de la progression de ses + paquets dans <em>testing</em>. +<p> +Le fichier <file>update_excuses</file> ne donne pas toujours la raison précise + pour laquelle un paquet est refusé, on peut avoir à la chercher soi-même en + regardant ce qui serait cassé avec l'inclusion du paquet. La <url + id="&url-testing-maint;" name="vue d'ensemble de testing"> donne plus + d'informations à propos des problèmes courants qui peuvent occasionner cela. <p> +Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce que le + jeu des inter-relations est trop compliqué et ne peut être résolu par le + script. Dans ce cas, le responsable de version doit être contacté et il forcera + l'inclusion du paquet. -<sect1>Fonctionnalité obsolète « X-Debian-PR: quiet » + <sect id="pkg-info">Informations sur un paquet <p> - Ceci est utilisé pour empêcher le système de suivi de bogues de transmettre - n'importe où des messages qu'il reçoit à <tt>debian-bugs</tt>, en rajoutant - une ligne <tt>X-Debian-PR: quiet</tt> dans l'en-tête du courrier. -<p> - Cette en-tête est maintenant ignorée. A la place, envoyez vos messages à - <tt>quiet</tt> ou <tt>nnn-quiet</tt> (ou <tt>maintonly</tt> ou - <tt>nnn-maintonly</tt>). + <sect1 id="pkg-info-web">Sur le web <p> +Chaque paquet a plusieurs pages web dédiées. + <tt>http://&packages-host;/<var>package-name</var></tt> affiche chaque version + du paquet disponible dans les différentes distributions. Les informations + détaillées par version incluent la description du paquet, les dépendances et + des liens pour récupérer le paquet. +<p> +Le système de suivi des bogues trie les bogues par paquet. Vous pouvez regarder + les bogues de chaque paquet à + <tt>http://&bugs-host;/<var>package-name</var></tt>. -<sect>L'interface de contrôle par courrier + <sect1 id="madison">L'outil <prgn>madison</prgn> +<p> +<prgn>madison</prgn> est un outil en ligne de commande qui est disponible sur + <tt>&ftp-master-host;</tt> et sur <tt>&non-us-host;</tt>. Il utilise un seul + argument qui correspond au nom du paquet. Il affiche comme résultat quelle + version du paquet est disponible pour chaque combinaison d'architecture et de + distribution. Un exemple l'expliquera mieux. <p> +<example> +$ madison libdbd-mysql-perl +libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc +libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc +libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha +libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc</example> +<p> +Dans cet exemple, vous pouvez voir que la version dans <em>unstable</em> diffère + de celle de <em>testing</em> et qu'il y a eu une NMU binaire seulement pour + l'architecture alpha. À chaque fois, le paquet a été recompilé sur la plupart + des architectures. - En plus du serveur de courrier sur <tt>request@bugs.debian.org</tt> qui - permet la recherche de données sur les bogues et de documentation par - courrier électronique, il y a un autre serveur à - <tt>control@bugs.debian.org</tt> qui permet de manipuler les rapports de - bogues de plusieurs façons. + <sect id="pkg-tracking-system">Le système de suivi des paquets +<p> +Le système de suivi des paquets (PTS)<footnote>« Package Tracking + System »</footnote> est un outil pour suivre par courrier l'activité + concernant un paquet source. Il suffit simplement de s'inscrire à un + paquet source pour recevoir les courriers liés à celui-ci. Vous + recevez les mêmes courriers que le responsable. Chaque courrier envoyé par le + PTS est classé et associé à l'un des mots-clés listés ci-dessous. Ceci vous + permettra de sélectionner les courriers que vous voulez recevoir. <p> +Par défaut, vous recevrez : +<taglist> + <tag><tt>bts</tt> + <item>Tous les rapports de bogue et les discussions qui + suivent. + + <tag><tt>bts-control</tt> + <item>Les courriers de contrôle notifiant le changement d'état de l'un des + bogues. + + <tag><tt>upload-source</tt> + <item>Le courrier de confirmation de <prgn>katie</prgn> quand un paquet + source envoyé a été accepté. + + <tag><tt>katie-other</tt> + <item>Les autres courriers d'avertissement et d'erreur de + <prgn>katie</prgn> (comme une incohérence de forçage pour les champs + section ou priorité). + + <tag><tt>default</tt> + <item>Tout courrier non automatique envoyé au PTS par les personnes qui + veulent contacter les inscrits au paquet. + + <tag><tt>summary</tt> + <item>À l'avenir, vous pourriez recevoir des courriers de résumé pour vous + tenir informé de l'état du paquet (statistiques sur les bogues, vue + générale du portage, progression dans <em>testing</em>, + etc.). +</taglist> - Le serveur de contrôle fonctionne de la même façon que le serveur de - requêtes, excepté qu'il a quelques commandes supplémentaires ; en fait, c'est - le même programme. Les deux adresses sont seulement séparées pour éviter que - les utilisateurs ne fassent des erreurs et causent des problèmes en essayant - juste d'obtenir des informations. <p> +Vous pouvez également décider de recevoir plus d'informations : +<taglist> + <tag><tt>upload-binary</tt> + <item>Le courrier d'information de <prgn>katie</prgn> quand un paquet + binaire envoyé est accepté (pour vérifier que votre paquet est + recompilé pour toutes les architectures). + + <tag><tt>cvs</tt> + <item>Les modifications CVS<footnote><p><em>CVS commits</em></footnote> si le + responsable a mis en place un système pour faire suivre les + notifications de modifications vers le PTS. + +</taglist> - Regardez « introduction au serveur de requêtes » disponible sur le World Wide - Web, dans le fichier bug-maint-mailcontrol.txt ou en demandant de l'aide à - chaque serveur de courrier pour les bases d'utilisation des serveurs et les - différentes commandes disponibles quand on écrit à une adresse. + <sect1 id="pts-commands">L'interface de courrier du PTS <p> +Vous pouvez contrôler votre (vos) inscription(s) au PTS en envoyant différents + commandes à <email>pts@qa.debian.org</email>. + +<taglist> + <tag><tt>subscribe <srcpackage> [<email>]</tt> + <item>Inscrit <var>email</var> aux communications liées au paquet source + <var>srcpackage</var>. L'adresse de l'expéditeur est utilisé si le + second argument n'est pas présent. Si <var>srcpackage</var> n'est pas + un paquet source valide, vous obtiendrez un avertissement. Cependant, + s'il s'agit d'un paquet binaire valide, le PTS vous inscrira pour le + paquet source correspondant. + + <tag><tt>unsubscribe <srcpackage> [<email>]</tt> + <item>Supprime une inscription précédente au paquet source + <var>srcpackage</var> en utilisant l'adresse spécifiée ou l'adresse de + l'expéditeur si le second argument n'est pas rempli. + + <tag><tt>which [<email>]</tt> + <item>Liste les inscriptions pour l'expéditeur ou pour l'adresse indiquée + si elle est spécifiée. - La carte de référence pour les serveurs de courrier est disponible via le - WWW, dans le fichier bug-mailserver-refcard.txt ou par courrier électronique - en utilisant la commande « refcard ». + <tag><tt>keyword [<email>]</tt> + <item>Donne les mots-clés que vous acceptez. Chaque courrier envoyé par le + PTS est associé à un mot-clé et vous ne recevez que les courriers associés + aux mots-clés que vous avez acceptés. Voici la liste des mots-clés + disponibles : + <list> + <item><tt>bts</tt> : courriers venant du système de gestion de bogues (BTS) Debian + <item><tt>bts-control</tt> : réponses aux courriers envoyés à + <email>control@bugs.debian.org</email> + <item><tt>summary</tt> : courriers de résumé automatique sur l'état + d'un paquet + <item><tt>cvs</tt> : notifications de modifications CVS + <item><tt>upload-source</tt> : annonce d'un nouvel envoi de paquet + source qui a été accepté + <item><tt>upload-binary</tt> : annonce d'un nouvel envoi de binaire + seulement (portage) + <item><tt>katie-other</tt> : autres courriers des ftpmasters + (incohérence de forçage, etc.) + <item><tt>default</tt> : tous les autres courriers (ceux qui ne sont + pas "automatiques") + </list> + + <tag><tt>keyword <srcpackage> [<email>]</tt> + <item>Identique à l'élément précédent, mais pour un paquet source donné + car vous pouvez sélectionner un ensemble de mots-clés différent pour + chaque paquet source. + + <tag><tt>keyword [<email>] {+|-|=} <list of keywords></tt> + <item>Accepte (+) ou refuse (-) les courriers associés au(x) mot(s)-clé(s). + Définit la liste (=) des mots-clés acceptés. + + <tag><tt>keyword <srcpackage> [<email>] {+|-|=} <list of keywords></tt> + <item>Identique à l'élément précédent, mais remplace la liste des mots-clés + pour le paquet source indiqué. + + <tag><tt>quit | thanks | --</tt> + <item>Arrête le traitement des commandes. Toutes les lignes suivantes sont + ignorées par le robot. +</taglist> + + <sect1 id="pts-mail-filtering">Filtrer les courriers du PTS <p> +Une fois que vous vous êtes inscrit à un paquet, vous recevrez les courriers + envoyés à <tt><var>srcpackage</var>@packages.qa.debian.org</tt>. Ces courriers + ont des en-têtes spéciaux ajoutés pour vous permettre de les filtrer dans des + boîtes aux lettres avec <prgn>procmail</prgn>. Les en-têtes ajoutés sont + <tt>X-Loop</tt>, <tt>X-PTS-Package</tt>, <tt>X-PTS-Keyword</tt> et + <tt>X-Unsubscribe</tt>. +<p> +Voici un exemple d'en-têtes ajoutés pour une notification d'envoi de +source sur le paquet <package>dpkg</package> : +<example> +X-Loop: dpkg@&pts-host; +X-PTS-Package: dpkg +X-PTS-Keyword: upload-source +X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org +</example> -Voici la liste des commandes disponibles : -<taglist> -<tag><tt> close bugnumber</tt> -<item> - Ferme le rapport de bogue « #bugnumber ». + <sect1 id="pts-cvs-commit">Faire suivre les modifications de CVS vers le PTS <p> +Si vous utilisez un référentiel CVS accessible publiquement pour maintenir votre + paquet Debian, vous pouvez vouloir faire suivre les notifications de + modifications vers le PTS pour que les inscrits (par exemple, des + co-responsables) puissent suivre de près l'évolution du paquet. +<p> +C'est très facile à mettre en place. Une fois que votre référentiel génère des + notifications de modifications, vous devez simplement vous assurer qu'il envoie une + copie de tous ces courriers à <tt><var>srcpackage</var>_cvs@&pts-host;</tt>. + Seules les personnes qui ont accepté le mot-clé <em>cvs</em> recevront les + notifications. - Une notification est envoyée à l'utilisateur qui a soumis le bogue, - mais (contrairement au courrier envoyé à <tt>bugnumber-done@bugs</tt>) - le texte du courrier qui a clos le bogue <em>n'est pas</em> inclus - dans cette notification. Le mainteneur qui a fermé un rapport devrait - s'assurer, probablement en envoyant un message séparé, que - l'utilisateur qui a soumis le bogue sait pourquoi il a été clos. + <sect id="ddpo">Vue d'ensemble des paquets d'un développeur +<p> +Un portail web pour l'Assurance Qualité (QA) est disponible à <url + id="&url-ddpo;"> qui affiche un tableau de tous les paquets d'un + développeur (y compris ceux pour lequel il est co-responsable). Le tableau donne + un bon résumé sur les paquets d'un développeur : nombre de bogues par + gravité, liste des versions disponibles, état des tests et des liens vers + d'autres informations utiles. <p> +C'est une bonne idée de vérifier régulièrement vos données pour ne pas oublier + de bogues ouverts et pour ne pas oublier quels paquets sont sous votre + responsabilité. -<tag><tt> reassign bugnumber package</tt> -<item> - Enregistre que le rapport de bogue « #bugnumber » est un bogue dans un - paquet. Ce peut être utilisé pour fixer le paquet si l'utilisateur a - oublié la pseudo en-tête, ou pour modifier une assignation précédente. - Aucune notification n'est envoyée à qui que ce soit (en dehors des - informations usuelles transcrites lors des traitements). + + <chapt id="pkgs">Gestion des paquets <p> +Ce chapitre contient des informations relatives à la création, l'envoi, la + maintenance et le portage des paquets. -<tag><tt> reopen bugnumber [originator-address|=]</tt> -<item> - Rouvre « #bugnumber » si il a été fermé. + <sect id="upload">La mise à jour d'un paquet + <sect1>Nouveaux paquets +<p> +Si vous voulez créer un nouveau paquet pour la distribution Debian, vous devriez + commencer par consulter la liste des <url id="&url-wnpp;" name="paquets en + souffrance et paquets souhaités">. Vous pourrez ainsi vérifier que personne ne + travaille déjà sur ce paquet et éviter un double travail. Consultez aussi cette + page si vous voulez en savoir plus. +<p> +Supposons que personne ne travaille sur le paquet que vous visez, vous devez + alors envoyer un rapport de bogue (voir <ref id="submit-bug">) concernant le + pseudo-paquet <package>wnpp</package>. Ce courrier devra décrire le paquet que + vous projetez de créer, la licence de ce paquet et l'URL à laquelle le source + peut être téléchargé. Cette liste n'est pas limitative. +<p> +Le sujet de votre rapport de bogue devra être <ITP<footnote><p><em>Intent To + Package</em> : intention de mise en paquet</footnote> : + <var>NomDuPaquet</var> — <var>courte description</var>>, en remplaçant + <var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera + <em>wishlist</em>. Si vous le jugez nécessaire, envoyez une copie à + &email-debian-devel; en mettant cette adresse dans le champ + <tt>X-Debbugs-CC:</tt> de l'en-tête du message. N'utilisez pas le champ + <tt>CC:</tt> car de cette manière le sujet du message ne contiendrait pas le + numéro du bogue. <p> +Il faudra aussi ajouter une entrée <tt>Closes: bug#<var>nnnnn</var></tt> dans le + fichier <file>changelog</file> du nouveau paquet. Cette indication fermera + automatiquement le rapport de bogue à l'installation du nouveau paquet sur les + serveurs d'archivage (voir <ref id="upload-bugfix">). +<p> +Plusieurs raisons nous poussent à demander aux responsables + d'annoncer leur intention : +<list compact> +<item>Les responsables ont ainsi la possibilité de puiser dans l'expérience + des autres responsables et cela leur permet de savoir si une autre + personne travaille déjà dessus. +<item>D'autres personnes qui envisagent de travailler sur le même paquet + apprendront ainsi qu'il existe déjà un volontaire, l'effort peut alors + être partagé.</item> +<item>Cela permet aux autres responsables de connaître le nouveau + paquet mieux que ne le permettent la description d'une ligne et l'habituelle + entrée de type changelog <em>Initial release</em> postée sur + <tt>debian-devel-changes</tt>. +<item>C'est une information utile pour + les gens qui utilisent la distribution <em>unstable</em> et qui sont nos + premiers testeurs. Nous devons faciliter la tâche de ces gens. +<item>Avec ces annonces, les développeurs Debian et toutes les autres personnes + intéressées peuvent se faire une meilleure idée des évolutions et des + nouveautés du projet. +</list> - Par défaut, vous êtes enregistré comme étant à l'origine du rapport, - donc vous recevrez l'accusé de réception quand il sera fermé une - nouvelle fois. Ceci pour éviter d'inonder un innocent utilisateur avec - plusieurs notifications sur un même rapport de bogue. + <sect1 id="changelog-entries"> + <heading>Ajouter une entrée à <file>debian/changelog</file></heading> +<p> +Les modifications que vous apportez au paquet doivent être notifiées dans le + fichier <file>debian/changelog</file>. Ces notes doivent donner une + description concise des changements, expliquer pourquoi (si ce n'est pas + clair) et indiquer si des rapports de bogue ont été clos. Il faut aussi indiquer + quand le paquet a été terminé. Ce fichier sera installé dans + <file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou + <file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un paquet + natif. <p> +Le fichier <file>debian/changelog</file> a une structure précise comportant + différents champs. Le champ <em>distribution</em> est décrit dans <ref + id="upload-dist">. Vous trouverez plus d'informations sur la structure de ce + fichier dans la section « <file>debian/changelog</file> » de la + <em>charte Debian</em>. +<p> +Les entrées du fichier <file>changelog</file> peuvent être + utilisées pour fermer des rapports de bogue au moment où le paquet est + installé dans l'archive. Voir la section <ref id="upload-bugfix">. +<p> +Par convention, l'entrée changelog d'un paquet qui contient une nouvelle version + amont ressemble à : +<example> + * new upstream version +</example> +<p> +Quelques outils peuvent vous aider à créer des entrées et à finaliser le fichier + <file>changelog</file> pour une livraison — voir les sections <ref + id="devscripts"> et <ref id="dpkg-dev-el">. + - Si vous rajoutez une adresse d'origine, l'auteur du rapport de bogue - sera enregistré à l'adresse que vous avez rajouté. Vous pouvez - utiliser <tt>=</tt> pour conserver l'auteur original des traitements - précédents. C'est habituellement une bonne idée d'annoncer à la - personne qui est enregistrée comme auteur du rapport de bogue que vous - rouvrez le rapport, pour qu'elle s'attende à recevoir l'accusé de - clôture du bogue. + + <sect1 id="upload-checking">Vérifier le paquet avant de l'envoyer <p> +Avant d'envoyer votre paquet, vous devriez faire quelques tests de base. Vous + devriez au moins faire les tests suivants (il vous faut une ancienne version + du paquet) : +<list> +<item>Installez le paquet et vérifiez que le logiciel fonctionne. Si le + paquet existait déjà dans une version plus ancienne, faites une mise à + jour. +<item>Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter + <prgn>lintian</prgn> comme suit : <tt>lintian -v + <var>package-version</var>.changes</tt>. Ce programme fera une + vérification sur les paquets source et binaire. Si vous ne comprenez pas + les messages générés par <prgn>lintian</prgn>, essayez l'option + <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus + bavard dans sa description du problème. + <p> + En principe, un paquet pour lequel <prgn>lintian</prgn> génère des erreurs + (elles commencent par <tt>E</tt>) <em>ne doit pas</em> être installé dans + l'archive. + <p> + Pour en savoir plus sur <prgn>lintian</prgn>, reportez-vous à la section + lintian <ref id="lintian">. +<item>Faites régresser le paquet vers sa version précédente si elle existe + — cela permet de tester les scripts <file>postrm</file> et + <file>prerm</file>. +<item>Désinstallez le paquet et réinstallez-le. +</list> + - Si le bogue n'est pas fermé, alors le rouvrir ne fera rien, même pas - de changer l'auteur original. Il n'y a aucune manière de changer - l'auteur original d'un rapport de bogue ouvert (ceci est délibéré pour - qu'il ne puisse pas y avoir de rapport de bogue fermé et détruit 28 - jours plus tard sans que personne ne soit au courant. + <sect1>Générer le fichier « changes » <p> +Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit + être accompagnée d'un fichier <file>.changes</file>. Ce fichier explique à + l'administrateur de l'archive Debian ce qu'il doit faire du paquet. Il est en + général créé par <prgn>dpkg-genchanges</prgn> au cours du processus de + fabrication du paquet. +<p> +Le fichier <file>changes</file> est un fichier de contrôle qui contient les + champs suivants : +<p> +&control-file-fields; +<p> +Tous ces champs sont obligatoires pour une installation sur les serveurs Debian. + Vous pouvez consulter la liste des champs de contrôle dans la <url + id="&url-debian-policy;" name="charte Debian"> pour connaître les valeurs que + prennent ces champs. Vous pouvez fermer un rapport de bogue automatiquement + avec le champ <tt>Description</tt> (voir <ref id="upload-bugfix">). -<tag><tt> forwarded bugnumber address</tt> -<item> - Enregistre que le rapport de bogue a été passé à un mainteneur à - l'adresse <tt>address</tt>. Ceci n'envoie pas le message à la personne - concernée. Ceci peut être utilisé pour modifier une adresse de - « forwarded-to » erronée, ou pour en enregistrer un nouveau pour un - bogue n'ayant pas été noté comme ayant précédemment été transmis. + + <sect2>L'archive des sources amonts +<p> +La première fois qu'un paquet est installé dans l'archive pour une version amont + donnée, le fichier <file>tar</file> de cette version amont doit être + téléchargé et mentionné dans le fichier <file>.changes</file>. Par la suite, + ce fichier <file>tar</file> sera utilisé pour générer les fichiers + <file>diff</file> et <file>.dsc</file> et il ne sera pas nécessaire de le + télécharger à nouveau. <p> +Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn> + incluront le fichier <file>tar</file> amont si et seulement si le numéro de + révision du paquet source est 0 ou 1, ce qui indique une nouvelle version + amont. Ce comportement peut être modifié en utilisant <tt>-sa</tt> pour + l'inclure systématiquement ou <tt>-sd</tt> pour ne jamais l'inclure. +<p> +Si la mise à jour ne contient pas le fichier <file>tar</file> des sources + originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les + fichiers <file>.dsc</file> et <file>diff</file> de la mise à jour, utiliser + un fichier <tt>tar</tt> identique à l'octet près à celui déjà présent dans + l'archive. -<tag><tt> notforwarded bugnumber</tt> -<item> - Efface toute trace que le rapport de bogue a été transmis à un - quelconque mainteneur. Si le bogue n'a pas été enregistré comme ayant - été transmis, alors ceci ne fera rien. + + <sect2 id="upload-dist">Choisir une distribution +<p> +Le champ <tt>Distribution</tt>, qui provient de la première ligne du fichier + <file>debian/changelog</file>, indique à quelle distribution le paquet est + destiné. <p> +Il existe plusieurs valeurs possibles pour ce champ : « stable », + « unstable », « testing-proposed-updates » et + « experimental ». En fait, il y a deux autres possibilités : + « stable-security » et « testing-security ». Cependant, + ces dernières sont utilisées par l'équipe de sécurité ; n'envoyez pas + de paquets dedans sans l'accord de celle-ci. +<p> +Il est techniquement possible d'envoyer un paquet dans plusieurs distributions + en même temps, mais ceci n'a habituellement aucun sens d'utiliser cette + fonctionnalité car les dépendances d'un paquet peuvent varier selon les + distributions. En particulier, il est absurde de combiner la distribution + <em>experimental</em> avec tout autre chose. -<tag><tt> retitle bugnumber new-title</tt> -<item> - Change le titre d'un rapport de bogue pour celui spécifié (par défaut, - il s'agit du champ Subject de l'en-tête du courrier du rapport - original). + + <sect3 id="upload-stable">Mettre à jour un paquet de la distribution + <em>stable</em> +<p> +Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet + sera dirigé vers le répertoire <file>stable-proposed-updates</file> des + archives Debian pour y être testé avant d'être effectivement inclus dans + <em>stable</em>. +<p> +Une livraison pour la distribution <em>stable</em> requiert des soins + supplémentaires. Un paquet de cette distribution ne devrait être mis à jour + que dans les cas suivants : +<list> +<item>un problème de sécurité (un avis de sécurité Debian<footnote>Debian + security advisory</footnote>), +<item>un problème fonctionnel vraiment critique, +<item>un paquet devenu ininstallable, +<item>un paquet indisponible pour une architecture. +</list> +<p> +Il est fortement déconseillé de changer quoi que ce soit si ce + n'est pas important car même une modification triviale peut provoquer un + bogue. Livrer une nouvelle version amont d'un logiciel pour + corriger un problème de sécurité est désapprouvé ; dans la plupart + des cas, la bonne solution consiste à prendre le correctif correspondant de + la nouvelle version amont et à l'appliquer à l'ancienne (faire un + rétro-portage<footnote><em>backport</em></footnote> du correctif). +<p> +Les paquets livrés pour <em>stable</em> doivent être compilés avec la + distribution <em>stable</em> pour que leurs dépendances se limitent aux + bibliothèques (et autres paquets) disponibles dans <em>stable</em> ; + un paquet livré pour la distribution <em>stable</em> qui dépend d'une + bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté. + Modifier les dépendances d'autres paquets (en manipulant le champ + <tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets + ininstallables, est fortement déconseillé. +<p> +L'équipe responsable de la distribution<footnote><em>the Release + team</em></footnote> (joignable à l'adresse &email-debian-release;) + évaluera régulièrement le contenu de <em>stable-proposed-updates</em> et + décidera si votre paquet peut être inclus dans la distribution + <em>stable</em>. Soyez précis (et, si nécessaire, prolixe) quand vous + décrivez, dans le fichier changelog, vos changements pour une livraison + vers <em>stable</em>, sinon le paquet ne sera pas pris en considération. + + <sect3 id="upload-t-p-u">Mettre à jour un paquet de la distribution + <em>testing-proposed-updates</em> +<p> +La distribution <em>testing</em> est peuplée avec des paquets en provenance + d'<em>unstable</em> selon des règles expliquées dans <ref id="testing">. + Cependant, le responsable de distribution peut stopper les scripts de + <em>testing</em> quand il veut geler la distribution. Dans ce cas, vous + pouvez envoyer vos paquets vers <em>testing-proposed-updates</em> pour + fournir des paquets corrigés durant le gel. <p> +Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement, + ils doivent passer entre les mains du responsable de version. Vous devez + donc avoir une bonne raison pour les y envoyer. Pour savoir ce que + représente une bonne raison aux yeux du responsable de version, vous + devriez lire les instructions données qu'il envoie régulièrement sur + &email-debian-devel-announce;. +<p> +Vous ne devriez pas envoyer un paquet à <em>testing-proposed-updates</em> quand + vous pouvez le mettre à jour par <em>unstable</em>. Si vous ne pouvez faire + autrement (par exemple, parce que vous avez une nouvelle version dans + <em>unstable</em>), vous pouvez l'utiliser, mais il est recommandé de + demander l'autorisation du responsable de distribution auparavant. + + <sect1 id="uploading">Mettre à jour un paquet - Contrairement à beaucoup des commandes de manipulation de bogue - utilisées sur un rapport parmi quelques-uns fusionnés, celle-ci - changera uniquement le titre du bogue concerné et pas ceux des - rapports avec lesquels il est fusionné. + <sect2 id="upload-ftp-master">Installer un paquet sur + <tt>ftp-master</tt> <p> +Pour installer un paquet, vous avez besoin d'un compte sur + <ftpsite>&ftp-master-host;</ftpsite>, ce que vous devriez déjà avoir en tant + que développeur Debian. Si vous utilisez <prgn>scp</prgn> ou + <prgn>rsync</prgn> pour télécharger vos paquets, placez-les dans + &us-upload-dir;. Si vous utilisez un FTP anonyme, placez-les dans + &upload-queue;. Attention, il est préférable de transférer le fichier + <tt>changes</tt> en dernier. Dans le cas contraire, votre livraison pourrait + être rejetée car l'outil de maintenance de l'archive pourrait lire le fichier + <tt>changes</tt> et constater que les fichiers ne sont pas tous présents. Si + vous ne voulez pas vous embêter avec l'ordre de transfert des fichiers, vous + pouvez tout simplement copier vos fichiers dans un répertoire temporaire de + <tt>ftp-master</tt> et les déplacer ensuite vers &us-upload-dir;. +<p> +<em>Note :</em> ne téléchargez pas sur <tt>ftp-master</tt> de paquet + concernant la cryptographie qui appartiendrait à <em>contrib</em> ou <em>non-free</em>. + Ces logiciels doivent aller sur <tt>non-us</tt> (voir <ref + id="upload-non-us">). De plus, les paquets contenant un logiciel protégé par + des brevets américains ne peuvent pas être envoyés sur + <tt>ftp-master</tt> ; selon le cas, ils peuvent peut-être pourtant être + envoyés vers <file>non-US/non-free</file> (le paquet est dans + <em>non-free</em> à cause de problèmes de distribution et non pas à cause de + la licence du logiciel). Quand vous ne pouvez télécharger sur + <tt>ftp-master</tt>, vous ne pouvez pas non plus télécharger sur + <tt>chiark</tt> ou <tt>erlangen</tt>. Si vous ne savez pas si votre paquet + est protégé par un brevet ou s'il est soumis aux lois de contrôle des + exportations américaines, posez la question sur la liste + &email-debian-devel;. +<p> +Les paquets <ref id="dupload"> ou <ref id="dput"> pourront vous faciliter le + travail lors du téléchargement. Ces programmes, bien pratiques, aident à + automatiser le processus d'envoi de paquet vers Debian +<p> +Après avoir téléchargé votre paquet, vous pouvez vérifier ce qu'en + fera le logiciel de maintenance de l'archive en exécutant + <prgn>dinstall</prgn> sur votre fichier <file>.changes</file> : +<example>dinstall -n foo.changes</example>. +Notez que <prgn>dput</prgn> peut le faire automatiquement pour vous. -<tag><tt> merge bugnumber bugnumber ...</tt> -<item> - Fusionne deux ou plusieurs rapports de bogue. Quand des rapports sont - fusionnés, l'action d'ouvrir, fermer, marquer comme transmis ou - supprimer cette marque et réassigner un des bogues à un nouveau - paquet, aura un effet identique sur tous les autres rapports - fusionnés. + <sect2 id="upload-non-us">Installer un paquet sur <tt>non-US</tt> <p> +Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des + exportations américaines ne doivent pas être installés sur + <tt>ftp-master</tt>. Installez le paquet sur + <ftpsite>non-us.debian.org</ftpsite> dans le répertoire &non-us-upload-dir; + (<ref id="dupload"> et <ref id="dput"> avec les options adéquates peuvent + tous deux être utilisés pour cela). Par défaut, vous pouvez utiliser le même + <em>login/mot de passe</em> que pour <tt>ftp-master</tt>. Si vous utilisez + une connexion FTP anonyme pour le téléchargement, placez vos fichiers dans le + répertoire &upload-queue;. +<p> +Tout comme sur <tt>ftp-master</tt>, vous pouvez vérifier votre téléchargement + avec : <example>dinstall -n foo.changes</example> +<p> +Attention, les personnes résidant aux États-Unis et les citoyens américains sont + soumis à des restrictions sur l'exportation des logiciels de cryptographie. + Au moment où j'écris, les citoyens américains peuvent exporter quelques + logiciels de cryptographie soumis à une obligation de déclaration auprès du + département du commerce américain. Toutefois, cette restriction a été + abandonnée pour des logiciels qui sont déjà disponibles en dehors des + États-Unis. En conséquence, tout logiciel de cryptographie de la section + <em>main</em> de l'archive Debian qui ne dépend d'aucun paquet d'une autre + section — il ne doit pas dépendre de <em>non-US/main</em> — peut + être téléchargé sur <tt>ftp-master</tt> ou l'une de ses files d'attente + décrites plus haut. +<p> +La <em>charte Debian</em> n'empêche pas les résidents et citoyens américains de + livrer des paquets sur <tt>non-US</tt> mais ils devront être vigilants en le + faisant. Nous recommandons aux responsables concernés de prendre toutes les + précautions nécessaires, <em>y compris la consultation d'un juriste</em>, + pour s'assurer qu'ils n'enfreignent pas une loi américaine en livrant un + paquet sur <tt>non-US</tt>. +<p> +Pour les paquets des sections <em>non-US/main</em> et <em>non-US/contrib</em>, + les responsables devraient au moins suivre la <url id="&url-u.s.-export;" + name="procédure décrite par le gouvernement américain">. Les responsables de + paquets <em>non-US/non-free</em> devront en plus consulter les <url + id="&url-notification-of-export;" name="règles de déclaration d'exportation + pour les logiciels commerciaux">. +<p> +Cette section a pour seul but d'informer, elle n'a pas valeur de conseil + juridique. Une fois encore, nous recommandons aux résidents et citoyens + américains de consulter un juriste avant de livrer un paquet sur + <tt>non-US</tt>. + - Avant que les bogues puissent être fusionnés, ils doivent être - exactement dans le même état : soit tous ouverts, soit tous fermés, - avec la même adresse de mainteneur « forwarded-to », s'ils ont été - transmis ou aucun marqué comme transmis, et tous assignés au(x) - même(s) paquet(s) (une comparaison exacte des chaînes de caractères - est faite sur le paquet auquel le bogue est assigné). Si ils ne sont - pas dans le même état au départ, vous devrez utiliser réassigne - (reassign), rouvrir (reopen) et les autres pour vous assurer qu'ils se - trouvent dans le même état avant de les fusionner. + <sect2>Installer un paquet via <tt>chiark</tt> +<p> +Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs + possibilités. L'une d'elles consiste à télécharger vos fichiers dans + <file>Incoming</file> en passant par le serveur <tt>chiark</tt> en Europe. + Pour les détails, consultez <url id="&url-chiark-readme;">. +<p> +Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux lois de + contrôle des exportations américaines sur <tt>chiark</tt>. Les paquets + téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>, les + indications de la section <ref id="upload-ftp-master"> sont applicables ici + aussi. <p> +Le programme <prgn>dupload</prgn> est capable de télécharger sur + <tt>chiark</tt> ; consultez la documentation de ce programme pour en + savoir plus. - Si un des bogues listés dans la commande de fusion est déjà fusionné - avec un autre bogue, alors tous les rapports fusionnés avec un de ceux - listés seront fusionnés également. La fusion est comme l'égalité : - c'est réflexif, transitif et symétrique. + + <sect2>Installer un paquet via <tt>erlangen</tt> +<p> +Vous pouvez aussi accéder à un serveur situé en Allemagne : il vous suffit + d'ouvrir une connexion anonyme sur <url id="&url-upload-erlangen;">. +<p> +Le téléchargement fait sur ce serveur doit être aussi complet que s'il était + fait dans le répertoire <file>Incoming</file> sur <tt>ftp-master</tt> : il + doit comporter le fichier <file>.changes</file> et tous les fichiers + mentionnés dans ce dernier. Le serveur vérifie que le fichier + <file>.changes</file> est bien signé avec la clé PGP d'un développeur Debian + pour éviter que des faux paquets n'atteignent <tt>ftp-master</tt>. Vérifiez + bien que le champ <tt>Maintainer</tt> du fichier <file>.changes</file> + contient <em>votre</em> adresse électronique. De même que sur + <tt>ftp-master</tt>, cette adresse est ensuite utilisée pour toutes les + réponses. +<p> +Il n'est pas nécessaire de déplacer votre fichier dans un autre répertoire après + le téléchargement, contrairement au serveur <tt>chiark</tt>. Vous devriez + ensuite recevoir un courrier du serveur expliquant ce qu'il a fait de votre + paquet. Normalement, il devrait avoir été déplacé vers + <tt>ftp-master</tt> ; vous serez informé par le même biais si une erreur + s'est produite au cours du processus. <p> +Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux lois de + contrôle des exportations américaines sur <tt>erlangen</tt>. Les paquets + téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>, les + indications de la section <ref id="upload-ftp-master"> sont applicables ici + aussi. +<p> +Le programme <prgn>dupload</prgn> est capable de télécharger sur + <tt>erlangen</tt> ; consultez la documentation de ce programme pour en + savoir plus. + - Fusionner des rapports de bogue provoque l'apparition d'une note dans - les traces de chacun des rapports ; sur les pages WWW, des liens sur - les autres bogues sont rajoutés + <sect2>Les autres serveurs <p> +Un autre serveur est disponible aux États-Unis ; c'est un bon point de + repli quand il est difficile de joindre <tt>ftp-master</tt>. Livrez vos + paquets à l'adresse <url id="&url-upload-samosa;"> comme vous le feriez sur + <tt>erlangen</tt>. +<p> +Il existe aussi un serveur au Japon : téléchargez vos paquet par FTP + anonyme sur <url id="&url-upload-jp;">. + - L'expiration des rapports fusionnés se produit pour tous - simultanément, et uniquement quand chacun des paquets pris séparément - répond aux critères d'expiration. + + <sect1 id="upload-announce">Annoncer une mise à jour +<p> +Quand un paquet est mis à jour, une annonce doit être envoyée sur l'une des + listes « debian-changes ». Ceci est maintenant géré automatiquement + par le logiciel de gestion de l'archive quand il est exécuté (en principe, une + fois par jour). Vous devez juste utiliser une version récente de + <package>dpkg-dev</package> (>= 1.4.1.2). Le courrier généré par le logiciel + de maintenance de l'archive contiendra le fichier <file>.changes</file> signé + que vous avez livré avec votre paquet. Précédemment, cette charge revenait à + <prgn>dupload</prgn> ; vérifiez que vous avez bien configuré + <prgn>dupload</prgn> pour qu'il n'envoie pas ces annonces (cherchez + <tt>dinstall_runs</tt> dans la documentation de <prgn>dupload</prgn>). <p> +Si un paquet est mis à jour avec un champ <tt>Distribution:</tt> à + <em>stable</em>, l'annonce est envoyée sur la liste &email-debian-changes;. + S'il est mis à jour avec un champ <tt>Distribution:</tt> à <em>unstable</em> ou + <em>experimental</em>, l'annonce est envoyée sur la liste + &email-debian-devel-changes;. -<tag><tt> unmerge bugnumber</tt> -<item> - Sépare un rapport de bogue d'autres rapports de bogue avec lesquels il - a été fusionné. Si le rapport listé est fusionné avec plusieurs - autres, alors ils sont tous laissés fusionnés ensemble, et seules leur - association avec le bogue explicitement cité sont supprimées. + <sect1 id="upload-notification"> + <heading>Notification de l'installation d'un nouveau paquet</heading> +<p> +Les administrateurs de l'archive Debian sont responsables de l'installation des + mises à jour. La plupart des mises à jour sont gérées quotidiennement par le + logiciel de gestion de l'archive <prgn>katie</prgn>. Les mises à jour de + paquets sur la distribution <em>unstable</em> sont installées + ainsi. Dans les autres cas et notamment dans le cas d'un nouveau paquet, + celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois entre le + téléchargement d'un paquet vers un serveur et son installation effective. Soyez + patient. <p> +Dans tous les cas, vous recevrez un accusé de réception par courrier + électronique indiquant que votre paquet a été installé et quels rapports de + bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous les + rapports de bogue que vous vouliez clore sont bien dans cette liste. +<p> +L'accusé de réception indique aussi la section dans laquelle le paquet a été + installé. S'il ne s'agit pas de votre choix, vous recevrez un second courrier + qui vous informera de cette différence (voir ci-dessous). - Si plusieurs rapports de bogues sont fusionnés et que vous voulez les - séparer en deux groupes séparés de rapports fusionnés, vous devez - séparer chacun des rapports des nouveaux groupes séparément et alors - seulement les fusionner dans les nouveaux groupes désirés. + <sect2 id="override-file">Le fichier <em>override</em> +<p> +Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier + <file>debian/control</file> n'indiquent ni où le paquet sera installé dans + l'archive Debian, ni sa priorité. Afin de conserver la cohérence de + l'archive, ce sont les administrateurs qui contrôlent ces champs. Les valeurs + du fichier <file>debian/control</file> sont juste des indications. +<p> +Les administrateurs de l'archive indiquent les sections et priorités des paquets + dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le + fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez + informé par courrier électronique quand votre paquet sera installé dans + l'archive. Vous pourrez corriger votre fichier <em>debian/control</em> avant + votre prochain téléchargement ou alors vous pourrez vouloir modifier le + fichier <em>override</em>. +<p> +Pour modifier la section dans laquelle un paquet est archivé, vous devez d'abord + vérifier que fichier <file>debian/control</file> est correct. Ensuite, + envoyez un courrier à &email-override; ou un rapport de bogue sur le + pseudo-paquet <package>ftp.debian.org</package> demandant la modification de + la section ou de la priorité de votre paquet. Exposez bien les raisons qui + vous amènent à demander ces changements. <p> +Pour en savoir plus sur les <em>fichiers override</em>, reportez-vous à <manref + section="8" name="dpkg-scanpackages"> et + <url id="&url-bts-devel;#maintincorrect">. - Vous ne pouvez séparer uniquement qu'un rapport de bogue des autres - rapports de bogue fusionnés pour chaque commande « unmerge » ; si vous - voulez séparer plus d'un rapport de bogue, ajoutez simplement quelques - commandes « unmerge » à votre message. + + <sect id="nmu">Mise à jour indépendante <p> -</taglist> +Dans certaines circonstances, il est nécessaire qu'une personne autre que le + responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de + mise à jour est désigné en anglais par l'expression <em>non-maintainer + upload (NMU)</em>. Dans le présent document, nous traduisons librement + cette expression par « mise à jour indépendante ». <p> +Ces mises à jour indépendantes de binaires font de temps en temps partie du + travail normal des porteurs qui compilent les paquets pour d'autres + architectures (voir <ref id="porting">). Un développeur peut aussi faire + des mises à jour indépendantes quand il corrige le paquet d'un autre + développeur pour éliminer un problème de sécurité ou un bogue bloquant. Cela + se produit plus particulièrement en période de gel de la distribution de + développement ou quand le responsable officiel du paquet ne peut pas + fournir une correction dans un délai raisonnable. +<p> +Ce chapitre contient des informations qui vous expliqueront quand et comment + faire des mises à jour indépendantes. Une distinction fondamentale doit + être faite entre les mises à jour indépendantes sources et les mises à + jour indépendantes binaires. Elle est explicitée dans la section suivante. -<sect>Résumé des commandes disponibles + <sect1 id="nmu-terms">Terminologie +<p> +Deux nouvelles expressions sont introduites dans cette section : + « mise à jour indépendante source » et « mise à jour + indépendante binaire ». Ces expressions ont une définition précise dans le + monde Debian. Elles correspondent toutes deux au même type d'activité ; + elles impliquent toutes deux qu'une personne fait une mise à jour d'un paquet + alors qu'elle n'est pas officiellement responsable de ce paquet. C'est pourquoi + nous qualifions ces mises à jours + d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser + entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas + question d'agir sans prévenir le responsable au préalable (voir <ref + id="nmu-guidelines">).</footnote>. <p> +Une mise à jour indépendante source est une livraison de paquet faite par une + personne qui n'est pas le responsable officiel de ce paquet avec pour objectif + de corriger un bogue dans le paquet. Une mise à jour indépendante source + implique toujours une modification des sources du paquet, même s'il ne s'agit + que d'un changement dans le fichier <file>debian/changelog</file>. Ce + changement peut tout aussi bien concerner la partie amont du source que la + partie spécifique à Debian. Une mise à jour indépendante source peut aussi + inclure des paquets spécifiques à une architecture tout comme un fichier + <em>diff</em> modifié. +<p> +Une mise à jour indépendante binaire est constitué par la recompilation et + l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du + résultat d'un effort de portage. Une mise à jour indépendante binaire est la + livraison d'un paquet compilé (souvent pour une autre architecture) à condition + que cette compilation n'ait pas nécessité de modifications des sources. Dans de + nombreux cas, les porteurs sont obligés de modifier les sources pour les rendre + compilables sur leur architecture cible ; il s'agira alors d'une mise à + jour indépendante source et non d'une mise à jour indépendante binaire. Comme + vous pouvez le remarquer, nous ne faisons pas de distinction entre les mises à + jour indépendantes faites par des porteurs et les autres mises à jour + indépendantes. +<p> +Les mises à jour indépendantes sources et binaires sont toutes deux couvertes + par l'expression « mise à jour indépendante » + (NMU<footnote><p>Non-maintainer upload</footnote>). Pourtant, cela conduit + souvent à des confusions car beaucoup associent « mise à jour + indépendante » et « mise à jour indépendante source ». Il faut + donc rester vigilant. Dans ce chapitre, si nous utilisons l'expression + « mise à jour indépendante » seule, il s'agit des deux types de + livraisons. -<sect1>Synopsis des commandes disponibles à « request@bugs.debian.org » + + <sect1 id="nmu-who">Qui peut faire une mise à jour indépendante ? <p> +Seuls les responsables Debian officiels peuvent faire des mises à jour + indépendantes. Un responsable officiel est une personne dont la clé est dans le + porte-clés Debian. Toute personne est invitée à télécharger les paquets sources + pour corriger des bogues ; au lieu de faire des mises à jour + indépendantes, ils pourront soumettre les correctifs qui le méritent au système + de suivi des bogues. Les responsables apprécient presque toujours les + correctifs et les rapports de bogue soignés. -<list> -<item><tt>send bugnumber</tt> -<item><tt>send-detail bugnumber</tt> -<item><tt>index [full]</tt> -<item><tt>index-summary by-package</tt> -<item><tt>index-summary by-number</tt> -<item><tt>index-maint</tt> -<item><tt>index maint maintainer-substring</tt> -<item><tt>send-unmatched [this|0]</tt> -<item><tt>send-unmatched last|-1</tt> -<item><tt>send-unmatched old|-2</tt> -<item><tt>getinfo filename</tt> (voir plus bas) -<item><tt>help</tt> -<item><tt>refcard</tt> -<item><tt>quit|stop|thank...|--...</tt> -<item><tt>#...</tt> _(comment)_ -<item><tt>debug level</tt> -</list> -<p> -<sect1>Liste des fichiers d'informations pour « getinfo » -<p> -<list -<item><tt>maintainers</tt> -<item><tt>override.stable</tt> -<item><tt>override.development</tt> -<item><tt>override.contrib</tt> -<item><tt>override.non-free</tt> -<item><tt>override.experimental</tt> -<item><tt>override.codeword</tt> -<item><tt>pseudo-packages.description</tt> -<item><tt>pseudo-packages.maintainers</tt> -</list> -<p> -<sect1>Synopsis des commandes supplémentaires disponibles sur le serveur de -courriers de contrôle + + <sect1 id="nmu-when">Quand faire une mise à jour indépendante + source ? +<p> +Les recommandations pour déterminer quand faire une mise à jour indépendante + source dépendent de la distribution visée (i.e. <em>stable</em>, + <em>unstable</em> ou <em>experimental</em>). Les porteurs, ayant une activité + particulière, obéissent à des règles légèrement différentes (voir <ref + id="source-nmu-when-porter">). +<p> +Quand une bogue de sécurité est détecté, l'équipe de sécurité peut faire une + mise à jour indépendante. Veuillez vous reporter à <ref id="bug-security"> pour + plus d'informations. +<p> +Pendant le cycle de mise au point (<em>release cycle</em>, voir <ref + id="sec-dists">), les livraisons qui corrigent les bogues de gravité + <em>sérieuse</em> (i.e. <em>serious</em>) et supérieures sont encouragées et + acceptées. Même pendant cette période, vous devriez tenter d'entrer en contact + avec le responsable du paquet ; il pourrait bien être sur le point de + livrer un paquet corrigé lui aussi. Comme pour n'importe quelle mise à jour + indépendante source, les recommandations de la section <ref + id="nmu-guidelines"> doivent être respectées. Des exceptions spéciales sont + effectuées pour <ref id="qa-bsp">. +<p> +Envoyer des corrections de bogues vers <em>unstable</em> par une autre personne + que le responsable ne devrait être fait qu'en suivant ce protocole : <p> <list> -<item><tt>close bugnumber</tt> (vous devez expliquer séparément à l'auteur -pourquoi) -<item><tt>reassign bugnumber package</tt> -<item><tt>reopen bugnumber [originator-address|=]</tt> -<item><tt>forwarded bugnumber address</tt> -<item><tt>notforwarded bugnumber</tt> -<item><tt>retitle bugnumber new-title</tt> -<item><tt>merge bugnumber bugnumber ...</tt> -<item><tt>unmerge bugnumber</tt> +<item>Vérifiez que les bogues du paquet qui devraient être corrigés par la + mise à jour indépendante sont bien référencés dans le système de suivi des + bogues. S'ils n'y sont pas, faites des rapports de bogue + immédiatement. +<item>Attendez la réponse du responsable quelques jours. Si vous n'obtenez + aucune réponse, vous pouvez l'aider en lui envoyant le correctif qui + corrige le bogue. N'oubliez pas de marquer le bogue avec le mot-clé + « patch ». +<item>Patientez quelques jours. Si vous n'avez toujours aucune réponse du + responsable, envoyez-lui un courrier annonçant votre intention + d'effectuer une mise à jour indépendante du paquet. Préparez la NMU comme + décrit dans <ref id="nmu-guidelines">, testez-la soigneusement sur votre + machine (cf. <ref id="upload-checking">). Re-vérifiez que votre correctif + n'a aucun effet de bord inattendu. Assurez-vous que votre correctif est + aussi minimaliste et non intrusif que possible. +<item>Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file> (cf. + <ref id="delayed-incoming">), envoyez le correctif final au responsable + par le BTS et expliquez-lui qu'il a 7 jours pour réagir s'il veut annuler + la NMU. +<item>Suivez ce qui se passe, vous êtes responsable pour tout bogue que vous + auriez introduit avec votre NMU. Vous devriez probablement utiliser le + <ref id="pkg-tracking-system"> (PTS) pour vous tenir informé de l'état du + paquet après votre NMU. </list> -<p> +<p> +Parfois, le responsable de version ou un groupe organisé de + développeurs peut annoncer une certaine période de temps au cours de laquelle + les règles de mise à jour indépendante seront plus souples. Ceci implique + habituellement une période plus courte d'attente avant d'envoyer des + correctifs et une période de délai plus courte. Il est important de noter que + même au cours de ces « chasses aux bogues », la personne + désirant faire la mise à jour indépendante doit remplir des bogues et + contacter en premier le développeur, et ensuite seulement passer à + l'action. + + <sect1 id="nmu-guidelines">Comment faire une mise à jour indépendante + source ? +<p> +Les règles qui suivent s'appliquent aux porteurs tant qu'ils jouent le double + rôle de correcteur de bogue et de porteur. Si un porteur doit modifier le + paquet source, cette mise à jour est automatiquement une mise à jour + indépendante source et est soumise aux règles qui suivent. Si un porteur + construit un paquet binaire recompilé, les règles sont différentes (voir <ref + id="porter-guidelines">. +<p> +Tout d'abord, il est capital que ces mises à jour indépendantes soient aussi peu + intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des + modules ou des fichiers, ne déplacez pas les répertoires ; plus + généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi + petit que possible. Si certaines choses froissent votre sens de l'esthétique, + parlez-en au responsable du paquet, au responsable amont ou soumettez un + rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent + pas</em> être effectués lors d'une mise à jour indépendante. + + + <sect2 id="nmu-version">Numéro de version pour les mises à jour + indépendantes sources +<p> +Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit + changer, même pour la plus triviale des modifications. Notre système de + gestion de paquets s'appuie sur ces numéros de version. +<p> +Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter + un numéro de version mineur à la partie <var>debian-revision</var> du numéro + de version (la partie qui suit le dernier trait d'union). Ce numéro + supplémentaire débutera à « 1 ». Prenons pour exemple le paquet + « foo » qui porte le numéro de version 1.1-3. Dans l'archive, le + fichier de contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La + version amont est « 1.1 » et la révision Debian est + « 3 ». La mise à jour indépendante suivante ajouterait le numéro de + version mineur « .1 » au numéro de révision Debian; le nouveau + fichier de contrôle du paquet source serait alors + <file>foo_1.1-3.1.dsc</file>. +<p> +Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro de + version au responsable officiel du paquet, ce qui pourrait perturber son + travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas + été livré par le responsable officiel. +<p> +S'il n'y a pas de partie <var>debian-revision</var> dans le numéro de version du + paquet, il faut en créer une en démarrant à « 0.1 ». S'il est + absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet + fasse une livraison basée sur une nouvelle version amont, cette personne doit + choisir « 0.1 » comme numéro de révision Debian. Le mainteneur du + paquet doit, lui, démarrer sa numérotation à « 1 ». + + + <sect2 id="nmu-changelog"> + <heading>Les mises à jour indépendantes sources doivent être + mentionnées dans le fichier changelog</heading> +<p> +Une personne qui fait une mise à jour indépendante source doit ajouter une + entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés + et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée + comportera l'adresse de la personne ayant fait la mise à jour ainsi que la + version livrée. +<p> +Par convention, dans le cas d'une mise à jour indépendante source + <em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne + +<example> + * Non-maintainer upload +</example> + + + <sect2 id="nmu-patch">Mise à jour indépendante source et système de + suivi des bogues +<p> +Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de + modifications que possible et doit toujours envoyer ses modifications au + système de suivi des bogues au format diff unifié (<tt>diff -u</tt>). +<p> +Et si vous recompilez simplement le paquet ? Si vous avez simplement besoin + de recompiler le paquet pour une seule architecture, vous pouvez faire une + NMU binaire seulement comme décrit dans <ref id="binary-only-nmu"> qui ne + nécessite pas qu'un correctif soit envoyé. Si vous désirez que le paquet soit + recompilé pour toutes les architectures, vous devez alors faire une NMU + source et vous devrez envoyer un correctif. +<p> +Si la mise à jour indépendante source (<em>source NMU</em>) corrige des bogues, + ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système de + suivi des bogues plutôt que clos. Par convention, seul le responsable du + paquet et la personne qui a ouvert le rapport de bogue peuvent clore ce + rapport. Heureusement, le système d'archivage Debian reconnaît les mises à + jours indépendantes et positionne correctement le statut des bogues à + <em>fixed</em> si la personne qui fait la mise à jour a listé tous les bogues + dans le fichier changelog en utilisant la syntaxe <tt>Closes: + bug#<var>nnnnn</var></tt> (voir <ref id="upload-bugfix"> pour en savoir plus + sur la fermeture de bogue par le fichier <file>changelog</file>). Ce passage + au statut <em>fixed</em> assure que chacun sait que le bogue est corrigé par + une mise à jour indépendante tout en laissant le rapport de bogue ouvert + jusqu'à ce que le responsable du paquet incorpore les modifications de cette + mise à jour dans la version officielle du paquet. +<p> +Après avoir fait une mise à jour indépendante, il vous faudra aussi ouvrir un + nouveau rapport de bogue qui inclura un correctif contenant toutes les + modifications que vous avez faites. Sinon, vous pouvez envoyer cette + information aux bogues qui sont fixés par votre NMU. Le responsable officiel + pourra choisir d'appliquer le correctif, il pourra aussi employer une autre + méthode pour régler le problème. Certains bogues sont corrigés dans la + version amont, ce qui est une bonne raison pour annuler les modifications + d'une mise à jour indépendante. Si le responsable choisit de mettre à jour le + paquet plutôt que d'utiliser les correctifs de la mise à jour indépendante, + il devra s'assurer que cette nouvelle version corrige effectivement chacun + des bogues corrigés dans la mise à jour indépendante. +<p> +De plus, le responsable officiel devrait <em>toujours</em> conserver les entrées + documentant une mise à jour indépendante dans le fichier + <file>changelog</file>. + + + <sect2 id="nmu-build">Fabriquer une mise à jour indépendante source +<p> +Les paquets faisant l'objet d'une mise à jour indépendante source sont + construits comme les autres. Sélectionnez une distribution en utilisant les + règles décrites dans la section <ref id="upload-dist"> et construisez un + fichier <tt>.changes</tt> classique avec tout ce qui l'accompagne + conformément à la description <ref id="uploading">. En fait, toutes les + prescriptions de la section <ref id="upload"> sont applicables ici. +<p> +Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt> dans + le fichier <file>debian/control</file>. Votre nom, mentionné dans l'entrée du + fichier <file>debian/changelog</file> concernant la mise à jour, sera utilisé + pour signer le fichier <file>.changes</file>. + + <sect1 id="ack-nmu">Valider une mise à jour indépendante +<p> +Si l'un de vos paquets a subi une mise à jour indépendante, vous devez récupérer + les changements dans votre copie des sources. Ceci est aisé, vous avez + simplement à appliquer le correctif qui vous a été envoyé. Une fois ceci fait, + vous devez fermer les bogues qui ont été marqués comme fixés par la mise à + jour. Vous pouvez soit les fermer manuellement en envoyant les courriers + nécessaires au BTS soit ajouter les <tt>closes: #nnnn</tt> nécessaires dans + l'entrée du changelog de votre prochain envoi. +<p> +Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une NMU n'est + pas une attaque personnelle contre le responsable. C'est une preuve que le + paquet est important pour quelqu'un et qu'il est désireux de vous aider dans + votre travail, vous devriez donc lui être reconnaissant. Vous pouvez également + lui demander s'il serait intéressé pour vous aider sur une base plus régulière + comme co-responsable ou responsable de secours (cf. <ref + id="collaborative-maint">). + + + <sect id="porting">Le portage +<p> +Debian accepte un nombre croissant d'architectures. Même si vous n'êtes pas un + porteur et même si vous n'utilisez qu'une architecture, il est de votre + responsabilité de développeur d'être attentif aux questions de + portabilité. C'est pourquoi il est important que vous lisiez ce chapitre + même si vous n'êtes pas un porteur. +<p> +Porter un paquet consiste à faire un paquet binaire pour une architecture + différente de celle du paquet binaire fait par le responsable du paquet. + C'est une activité remarquable et essentielle. En fait, les porteurs sont + à l'origine de la plupart des compilations de paquets Debian. Pour un + paquet binaire <em>i386</em>, par exemple, il faut compter une + recompilation pour chaque autre architecture, soit un total de + &number-of-arches; recompilations. + + + <sect1 id="kind-to-porters">Être gentil avec les porteurs +<p> +Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un + grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans + modification. Malheureusement, c'est rarement le cas. Cette section contient + une liste d'erreurs commises régulièrement par les responsables Debian — + problèmes courants qui bloquent souvent les porteurs et compliquent inutilement + leur travail. +<p> +Ici, le mot d'ordre est de répondre rapidement aux rapports de bogues et + remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils + étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine manière). + Merci pour votre indulgence envers des rapports de bogue succincts ou peu + clairs ; faites de votre mieux pour éliminer le problème. +<p> +Les problèmes les plus couramment rencontrés par les porteurs sont causés par + des erreurs de mise en paquet dans le paquet source. Voici un + pense-bête pour les choses auxquelles vous devez être attentif : +<enumlist> + <item> + Vérifiez que les champs <tt>Build-Depends</tt> et + <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont + corrects. Le meilleur moyen de le vérifier est d'utiliser le paquet + <package>debootstrap</package> pour créer un environnement + <em>unstable</em> <em>chrooté</em>. Dans cet environnement + <em>chrooté</em> il faudra installer le paquet + <package>build-essential</package> et tous les paquets mentionnés dans + les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>. + Ensuite, vous essayerez de fabriquer votre paquet dans cet + environnement. Ces étapes peuvent être automatisées en utilisant le + programme <prgn>pbuilder</prgn> qui est fourni par le paquet de même + nom. + <p> + Consultez la <url id="&url-debian-policy;" name="charte Debian"> pour en + savoir plus sur les dépendances de fabrication. + </item> + <item> + Ne choisissez pas d'autre valeur que <em>all</em> ou <em>any</em> pour + le champ architecture sans avoir de bonnes raisons pour le faire. Trop + souvent, les développeurs ne respectent pas les instructions de la <url + id="&url-debian-policy;" name="charte Debian">. Choisir la valeur + « i386 » est la plupart du temps incorrect. + </item> + <item> + Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x + <var>package</var>.dsc</tt> pour vous assurer que le paquet se + décompresse correctement. En utilisant le résultat de ce test, + construisez votre paquet binaire à l'aide de la commande + <prgn>dpkg-buildpackage</prgn>. + </item> + <item> + Vérifiez que les fichiers <file>debian/files</file> et + <file>debian/substvars</file> ne sont pas dans votre paquet source. Ils + doivent être effacés par la cible <em>clean</em> de + <file>debian/rules</file>. + </item> + <item> + Assurez-vous que vous ne vous appuyez pas sur des éléments de + configuration ou des logiciels installés ou modifiés localement. Par + exemple, vous ne devriez jamais appeler des programmes du répertoire + <file>/usr/local/bin</file> ou de répertoires équivalents. Essayez de ne + pas vous appuyer sur des logiciels configurés de manière spéciale. + Essayez de construire votre paquet sur une autre machine, même s'il + s'agit de la même architecture. + </item> + <item> + Ne vous appuyez pas sur une installation préexistante de votre paquet + (un sous-cas de la remarque précédente). + </item> + <item> + Si possible, ne vous appuyez pas sur une particularité présente dans un + compilateur précis ou dans une certaine version d'un compilateur. Si + vous ne pouvez pas faire autrement, assurez-vous que les dépendances de + fabrication reflètent bien cette restriction. Dans ce cas, vous cherchez + sûrement les problèmes car quelques architectures pourraient choisir un + compilateur différent. + </item> + <item> + Vérifiez que votre <file>debian/rules</file> distingue les cibles + <em>binary-arch</em> et <em>binary-indep</em> comme l'exige la charte + Debian. Vérifiez que ces cibles sont indépendantes l'une de l'autre, + c'est-à-dire, qu'il n'est pas nécessaire d'invoquer l'une de ces cibles + avant d'invoquer l'autre. Pour vérifier cela, essayez d'exécuter + <tt>dpkg-buildpackage -b</tt>. + </item> +</enumlist> + + + <sect1 id="porter-guidelines">Instructions pour les mises à jour des + porteurs +<p> +Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez + de la chance et votre travail est facile. Cette section s'applique dans ce + cas ; elle décrit comment construire et installer correctement votre + paquet binaire dans l'archive Debian. Si vous devez modifier le paquet pour le + rendre compilable sur votre architecture cible vous devez faire une mise à jour + des sources, consultez la section <ref id="nmu-guidelines">. +<p> +Pour un envoi de portage, ne faites pas de changement dans les sources. Vous + n'avez pas besoin de modifier les fichiers du paquet source (cela inclut le + fichier <file>debian/changelog</file>). +<p> +La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante : + <tt>dpkg-buildpackage -B -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez + <var>adresse-porteur</var> par votre adresse électronique. Cette commande + construira les parties du paquet qui dépendent de l'architecture, en utilisant + la cible <em>binary-arch</em> de <file>debian/rules</file>. + + <sect2 id="binary-only-nmu"> + Mises à jour indépendantes binaires ou recompilations +<p> +Parfois l'envoi du portage initial pose problème car l'environnement dans lequel + le paquet a été construit n'était pas bon (bibliothèques plus à jour ou + obsolètes, mauvais compilateur, etc.). Il se peut que vous ayez à le recompiler + dans un environnement mis à jour. Cependant, dans ce cas, vous devez changer + le numéro de version pour que les mauvais anciens paquets soient remplacés dans + l'archive Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets + s'ils n'ont pas un numéro de version supérieur à celui actuellement + disponible). Malgré les modifications nécessaires du changelog, ce type de mise + à jour reste une mise à jour indépendante binaire — il n'est pas + nécessaire de reconsidérer le statut des paquets binaires des autres + architectures pour les marquer périmés ou à recompiler. +<p> +Ces recompilations nécessitent des numéros de version « magiques » + pour que le système de maintenance de l'archive comprennent que, bien qu'il y + ait une nouvelle version, il n'y a pas eu de modification des sources. Si vous + ne faites pas cela correctement, les administrateurs de l'archive rejetteront + votre mise à jour (car il n'y aura pas de code source associé). +<p> +Cette magie associée à une mise à jour par recompilation est déclenchée en + utilisant un troisième nombre dans la partie debian du numéro de version. Si, + par exemple, la dernière version du paquet que vous recompilez était + « 2.9-3 », votre mise à jour portera le numéro + « 2.9-3.0.1 ». Si cette version était « 3.4-2.1 » votre + mise à jour portera le numéro « 3.4-2.1.1 ». + + + <sect2 id="source-nmu-when-porter"> + Quand faire une mise à jour indépendante source pour un portage ? +<p> +Les porteurs qui font des mises à jour indépendantes sources suivent + généralement les instructions de la section <ref id="nmu"> tout comme les + non-porteurs. Les délais d'attente sont cependant plus courts car les + porteurs doivent manipuler un grand nombre de paquets. À nouveau, la + situation diffère selon la distribution visée. +<p> +Si vous êtes porteur et faites une mise à jour pour <em>unstable</em>, les + instructions précédentes sont applicables à deux différences près. Tout + d'abord, le temps d'attente raisonnable — délai entre le moment où vous + envoyez un rapport au système de suivi des bogues et le moment où vous pouvez + faire une mise à jour indépendante <em>(NMU)</em> — est de sept jours. + Ce délai peut être raccourci si le problème est crucial et met l'effort de + portage en difficulté : c'est à la discrétion de l'équipe de portage. + (Souvenez-vous, il ne s'agit pas d'un règlement, mais de recommandations + communément acceptées) +<p> +Deuxième différence, les porteurs qui font des mises à jour indépendantes + sources doivent choisir une gravité <em>sérieuse</em> (i.e. <em>serious</em>) + ou supérieure quand ils envoient leur rapport au système de suivi des bogues. + Ceci assure qu'un paquet source unique permet de produire un paquet binaire + pour chaque architecture supportée au moment de la sortie de la distribution. + Il est très important d'avoir un paquet source et un paquet binaire pour + toutes les architectures pour être conforme à plusieurs licences. +<p> +Les porteurs doivent éviter d'implémenter des contournements pour des bogues de + l'environnement de compilation, du noyau ou de la libc. Quelques fois, ces + contournements sont inévitables. Si vous devez faire quelque chose de ce + genre, marquez proprement vos modifications avec des <tt>#ifdef</tt> et + documentez votre contournement pour que l'on sache le retirer une fois que le + problème aura disparu. +<p> +Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de leur + travail pendant le délai d'attente. Ainsi, d'autres personnes peuvent + bénéficier du travail du porteur même pendant ce délai. Bien sûr, ces + adresses n'ont rien d'officiel, alors soyez sur vos gardes si vous les + utilisez. + + + <sect1 id="porter-automation"> + <heading>Infrastructure de portage et automatisation</heading> + <p> +Il existe une infrastructure et plusieurs outils pour faciliter l'automatisation +du portage des paquets. Cette section contient un bref aperçu de cette +automatisation et du portage de ces outils ; veuillez vous reporter à la +documentation des paquets ou les références pour une information complète.</p> + + <sect2> + <heading>Listes de diffusion et pages web</heading> + <p> +Les pages web contenant l'état de chaque portage peuvent être trouvées à <url +id="&url-debian-ports;">. + <p> +Chaque portage de Debian possède sa propre liste de diffusion. La liste des +listes de diffusion de portage peut être trouvée à <url +id="&url-debian-port-lists;">. Ces listes sont utilisées pour coordonner les +porteurs et pour mettre en relation les utilisateurs d'un portage donné avec les +porteurs.</p> + </sect2> + + <sect2> + <heading>Outils pour les porteurs</heading> +<p> +Les descriptions de plusieurs outils de portage peuvent être trouvés dans les +<ref id="tools-porting">.</p> + + + <sect2 id="buildd"> + <heading><package>buildd</package></heading> +<p> +Le système <package>buildd</package> est un système distribué pour la + compilation d'une distribution. Il est habituellement utilisé en conjonction + avec des automates de compilation ; ce sont des machines + « esclaves » qui récupèrent des paquets sources et tentent de les + compiler. Il est aussi possible d'interagir par courrier électronique avec ce + système. Cette interface est utilisée par les porteurs pour récupérer un + paquet source (en général, un paquet qui ne peut être compilé + automatiquement) et travailler dessus. +<p> +<package>buildd</package> n'est pas disponible sous forme de paquet ; + pourtant, la plupart des équipes de porteurs l'utilisent aujourd'hui ou ont + prévu de l'utiliser bientôt. L'outil de construction automatisé réel est dans + le paquet <package>sbuild</package>, voir la description dans <ref + id="sbuild">. Le système <package>buildd</package> regroupe également un + ensemble de composants très utiles, continuellement utilisés, mais non encore + mis en paquet, tels que <prgn>andrea</prgn> et <prgn>wanna-build</prgn>. +<p> +Une partie des informations produites par <package>buildd</package> — + utiles pour les porteurs — est disponible sur la toile à l'adresse <url + id="&url-buildd;">. Ces informations incluent les résultats produits toutes + les nuits par <prgn>andrea</prgn> (dépendances des sources) et + <prgn>quinn-diff</prgn> (paquets à recompiler). +<p> +Nous sommes très fiers de ce système car il a de nombreux usages potentiels. Des + groupes de développeurs indépendants peuvent utiliser ce système pour créer + différentes saveurs de Debian — qui peuvent être ou ne pas être + intéressantes pour tous (par exemple, une version de Debian compilée avec des + vérifications relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi + de recompiler rapidement toute une distribution. +</sect2> + + + <sect id="collaborative-maint"> + Maintenance collaborative +<p> +« Maintenance collaborative » est un terme décrivant le partage des + devoirs de la maintenance d'un paquet Debian par plusieurs personnes. Cette + collaboration est presque toujours une bonne idée car il en résulte + généralement une meilleure qualité et un temps de correction de bogues plus + petit. Il est fortement recommandé que les paquets de priorité + <tt>Standard</tt> ou qui font partie de la base aient des co-responsables. +<p> +Habituellement, il y a un responsable principal et un ou plusieurs + co-responsables. Le responsable principal est celui dont le nom est indiqué + dans le champ <tt>Maintainer</tt> du fichier <file>debian/control</file>. Les + co-responsables sont tous les autres responsables. +<p> +Dans sa forme la plus simple, ajouter un nouveau co-responsable est assez + simple : +<list> +<item><p> Donner au co-responsable un accès aux sources à partir desquelles vous + construisez le paquet. Habituellement, cela implique que vous utilisiez un + système de contrôle de version comme <prgn>CVS</prgn> ou + <prgn>Subversion</prgn>. +</item> +<item><p> Ajouter les nom et adresse correctes du co-responsable au champ + <tt>Uploaders</tt> dans la partie globale du fichier + <file>debian/control</file>. +<example> +Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org> +</example> +</item> +<item><p> + En utilisant le PTS (<ref id="pkg-tracking-system">), les + co-responsables devraient s'inscrire eux-mêmes aux paquets sources + appropriés. +</item> +</list> + + + <sect id="archive-manip"> + <heading>Déplacer, effacer, changer de nom, adopter et abandonner des paquets +<p> +Certaines manipulations de l'archive ne sont pas accessibles avec le processus + de mise à jour automatisé. Elles sont appliquées manuellement par les + développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations. + + <sect1 id="moving-pkgs">Déplacer des paquets +<p> +Parfois, un paquet pourra changer de section. Une nouvelle version d'un paquet + de la section <tt>non-free</tt> pourrait, par exemple, être distribuée sous + licence GNU GPL ; dans ce cas, le paquet doit être déplacé dans la section + <tt>main</tt> ou <tt>contrib</tt><footnote><p>Reportez-vous à la <url + id="&url-debian-policy;" name="charte Debian"> pour savoir dans quelle section + un paquet doit être classé.</footnote>. +<p> +Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez les + informations de contrôle du paquet pour le placer dans la section désirée et + téléchargez à nouveau votre paquet dans l'archive. Reportez-vous à la <url + id="&url-debian-policy;" name="charte Debian"> pour en savoir plus. Si votre + nouvelle section est valide, il sera déplacé automatiquement. Si ce n'est pas + le cas, contactez les ftpmasters pour comprendre ce qui s'est passé. +<p> +Si vous avez besoin de modifier la sous-section de l'un de vos paquets + (<tt>devel</tt> ou <tt>admin</tt> par exemple), la procédure est légèrement + différente. Modifiez la sous-section dans le fichier de contrôle de votre + paquet et téléchargez-le. Il vous faudra ensuite demander la modification du + fichier <em>override</em> comme décrit dans la section <ref + id="override-file">. + + + <sect1 id="removing-pkgs">Supprimer des paquets +<p> +Si, pour une raison ou une autre, vous avez besoin de supprimer un paquet de + l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile, que + l'on conservait pour des raisons de compatibilité), il vous faudra envoyer un + rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et + demander sa suppression. N'oubliez pas de préciser de quelle distribution le + paquet doit être supprimé. Normalement, vous ne devriez avoir à supprimer que + des paquets de <em>unstable</em> ou de <em>experimental</em>. Les paquets de + <em>testing</em> ne sont pas supprimés directement. Ils sont plutôt enlevés + automatiquement après que le paquet a été supprimé de <em>unstable</em> et + si aucun paquet de <em>testing</em> n'en dépend. +<p> +Vous devez également détailler les raisons justifiant cette demande. Ceci a pour + but d'éviter les suppressions non désirées et de garder une trace de la raison + pour laquelle un paquet a été supprimé. Par exemple, vous pouvez fournir le nom + du paquet qui remplace celui à supprimer. +<p> +Vous ne pouvez demander la suppression d'un paquet que si vous en + êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez + obtenir l'accord de son dernier responsable. +<p> +Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des + autres développeurs sur la liste &email-debian-devel;. Le programme + <prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être + utile. La commande <tt>apt-cache showpkg <var>paquet</var> </tt> vous + indiquera, entre autres, les paquets qui dépendent de <var>paquet</var>. +<p> +Une fois que le paquet a été supprimé, les bogues du paquet doivent être gérés. + Soit ils sont réattribués à un autre paquet dans le cas où le code actuel a + évolué en un autre paquet (par exemple, <tt>libfoo12</tt> a été supprimé parce + que <tt>libfoo13</tt> le remplace) ou ils sont fermés si le logiciel ne fait + simplement plus partie de Debian. + + <sect2>Supprimer des paquets dans <tt>Incoming</tt> +<p> +Par le passé, il était possible de supprimer un paquet de <file>Incoming</file>. + Cependant, ce n'est plus possible depuis la mise en place du nouveau système + de file d'attente. Il vous faudra télécharger une nouvelle version de votre + paquet avec un numéro de version postérieur à celui que vous voulez + remplacer. Les deux versions seront installées dans l'archive mais seule la + plus récente sera accessible dans <em>unstable</em> car la précédente sera + immédiatement remplacée par la nouvelle. Toutefois, si vous testez + correctement vos paquets, le besoin d'en remplacer un ne devrait pas être + trop fréquent. + + <sect1>Remplacer un paquet ou changer son nom +<p> +Il peut vous arriver de vous tromper en nommant un paquet et avoir besoin de + changer son nom. Dans ce cas, vous devrez intervenir en deux étapes. D'abord, modifiez + votre fichier <file>debian/control</file> pour que votre nouveau paquet + remplace et entre en conflit avec l'ancien paquet que vous voulez remplacer + (Reportez-vous à la <url id="&url-debian-policy;" name="charte Debian"> pour + les détails). Une fois que votre paquet est installé dans l'archive, faites un + rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et + demandant la suppression du paquet mal nommé. N'oubliez pas de réattribuer + correctement les bogues du paquet en même temps. +<p> +D'autres fois, vous pouvez commettre une erreur en construisant le paquet et + désirez le remplacer. La seule façon de faire est d'incrémenter le numéro + de version et d'envoyer une nouvelle version. L'ancienne version expirera de la + façon habituelle. Notez que ceci s'applique à chaque partie de votre paquet, y + compris les sources : si vous désirez remplacer l'archive source amont de + votre paquet, vous devez l'envoyer avec un numéro de version différent. Une + possibilité simple est de remplacer <file>foo_1.00.orig.tar.gz</file> par + <file>foo_1.00+0.orig.tar.gz</file>. Cette restriction donne à chaque fichier + du site ftp un nom unique ce qui garantit la consistance dans le réseau des + miroirs. + + <sect1 id="orphaning">Abandonner un paquet +<p> +Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres et + faire le nécessaire pour qu'il soit marqué <em>abandonné</em> (i.e. + <em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA + Group &orphan-address;</tt> dans le champ <tt>maintainer</tt> du paquet et + faire un rapport de bogue sur le pseudo-paquet <package>wnpp</package>. Le + titre de votre rapport de bogue devrait être + « <tt>O<footnote><p><em>Orphaned</em> : abandonné.</footnote>: + <var>paquet</var> — <var>courte description</var></tt> » pour + indiquer que le paquet est abandonné. La gravité du bogue sera + <em>normale</em>. Si vous le jugez nécessaire, envoyez une copie à + &email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de + l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le sujet + du message ne contiendra pas le numéro du bogue. +<p> +Si le paquet est particulièrement important pour la distribution, il vous faudra + faire un rapport de bogue sur le pseudo-paquet <package>wnpp</package>, + l'intituler « <tt>RFA<footnote><p><em>Request For Adoption</em> : + offre d'adoption.</footnote>: <var>paquet</var> — <var>courte + description</var></tt> » et lui affecter la gravité <em>importante</em>. + Envoyez une copie de votre rapport de bogue à la liste debian-devel comme + décrit ci-dessus. +<p> +Reportez-vous à la page WNPP<footnote><p><em>Work-needing and prospective + packages</em> : paquets en souffrance et paquets souhaités.</footnote> + <url id="&url-wnpp;"> pour en savoir plus. + + <sect1 id="adopting">Adopter un paquet +<p> +Une liste des paquets en attente de nouveau responsable est disponible à la page + <url id="&url-wnpp;" name="paquets en souffrance et paquets souhaités">. Si + vous voulez prendre en charge un paquet de cette liste, reportez-vous à la page + mentionnée ci-dessus pour connaître la procédure à suivre. +<p> +Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas + correct — ce serait un détournement de paquet. Vous pouvez prendre + contact avec le responsable actuel et lui demander si vous pouvez prendre en + charge ce paquet. Vous ne pouvez le faire sans son accord. Qu'il vous ignore + n'est pas une raison suffisante pour le faire. Si vous avez le sentiment qu'un + responsable est parti sans prévenir depuis un moment, demandez-le sur la liste + &email-debian-private;. Vous pouvez également informer le groupe QA (cf. <ref + id="mia-qa">). +<p> +Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de suivi + des bogues indique que vous êtes le responsable du paquet. Cela se produira + automatiquement une fois que vous aurez installé une nouvelle version du paquet + dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut prendre + quelques heures après le téléchargement. Si vous pensez ne pas avoir de mise à + jour à faire pour un moment, vous pouvez utiliser <ref + id="pkg-tracking-system"> pour recevoir les rapports de bogue. Cependant, + assurez-vous que cela ne pose aucun problème à l'ancien responsable de + continuer à recevoir les bogues durant ce temps. + + + <sect id="bug-handling">Gérer les bogues +<p> +Vous trouverez souvent, en tant que responsable de paquet, des bogues dans + d'autres paquets ou vous aurez des bogues rapportés sur vos paquets et qui + doivent être réattribués. Les <url id="&url-bts-control;" name="instructions du + BTS"> peuvent vous indiquer comment faire cela. Vous pouvez trouver plus + d'informations sur la façon de faire des rapports de bogue dans <ref + id="submit-bug">. + + <sect1>Superviser les rapports de bogue +<p> +Si vous voulez être un bon responsable, consultez régulièrement la page du <url + id="&url-bts;" name="système de suivi des bogues">. Cette page contient tous + les rapports de bogue qui concernent vos paquets. Vous pouvez les vérifier avec + cette page : <tt>http://&bugs-host;/<var>yourlogin</var>@debian.org</tt>. +<p> +Les responsables interagissent avec le système de suivi des bogues en utilisant + l'adresse électronique <tt>&bugs-host;</tt>. Vous trouverez une documentation + sur les commandes disponibles à l'adresse <url id="&url-bts;"> ou, si vous avez + installé le paquet <package>doc-debian</package>, dans les fichiers locaux + &file-bts-docs;. +<p> +Certains trouvent utile de recevoir régulièrement une synthèse des rapports de + bogues ouverts. Si vous voulez recevoir une synthèse hebdomadaire relevant tous + les rapports de bogue ouverts pour vos paquets, vous pouvez configurer + <prgn>cron</prgn> comme suit : +<example> +# Synthèse hebdomadaire des rapports de bogue qui me concernent &cron-bug-report; +</example> +Remplacez <var>address</var> par votre adresse officielle de responsable Debian. + + <sect1 id="bug-answering">Répondre à des rapports de bogue +<p> +Assurez-vous que toutes vos discussions concernant les bogues sont envoyées au + rapporteur du bogue et au bogue lui-même (<email>123@bugs.debian.org</email> + par exemple). Si vous rédigez un nouveau courrier et que vous ne vous souvenez + plus de l'adresse du rapporteur de bogue, vous pouvez utiliser l'adresse + <email>123-submitter@bugs.debian.org</email> pour contacter le rapporteur + <em>et</em> enregistrer votre courrier dans le journal du bogue (ce qui veut + dire que vous n'avez pas besoin d'envoyer une copie du courrier à + <email>123@bugs.debian.org</email>). +<p> +Une fois que vous avez traité un rapport de bogue (i.e. que vous l'avez + corrigé), marquez-le comme <em>done</em> (fermez-le) en envoyant un message + d'explication à <email>123-done@bugs.debian.org</email>. Si vous corrigez un + bogue en changeant et en envoyant une nouvelle versions du paquet, vous pouvez + fermer le bogue automatiquement comme décrit dans <ref id="upload-bugfix">. +<p> +Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la commande + <tt>close</tt> à l'adresse &email-bts-control;.Si vous le faites, le rapporteur + n'aura aucune information sur la clôture de son rapport. + + <sect1 id="bug-housekeeping">Gestion générale des bogues +<p> +En tant que responsable de paquet, vous trouverez fréquemment des bogues dans + d'autres paquets ou vous aurez des bogues sur vos paquets qui sont en fait des + bogues sur d'autres paquets. Les fonctions intéressantes du système de suivi + des bogues pour les développeurs sont décrites dans la <url + id="&url-bts-devel;" name="documentation du BTS pour les développeurs Debian">. + Les <url id="&url-bts-control;" name="instructions du BTS"> documentent les + opérations techniques du BTS, telles que comment remplir, réassigner, regrouper + et marquer des bogues. Cette section contient des lignes directrices pour gérer + vos propres bogues, définies à partir de l'expérience collective des + développeurs Debian. +<p> +Remplir des rapports de bogue pour des problèmes que vous trouvez dans d'autres + paquet est l'une des « obligations civiques » du responsable, + reportez-vous à <ref id="submit-bug"> pour les détails. Cependant, gérer les + bogues de vos propres paquets est encore plus important. +<p> +Voici une liste des étapes que vous pouvez suivre pour gérer un rapport de + bogue : +<enumlist> + <item> + Décider si le rapport correspond à un bogue réel ou non. Parfois, les + utilisateurs exécutent simplement un programme de la mauvaise façon car + ils n'ont pas lu la documentation. Si c'est votre diagnostic, fermez + simplement le bogue avec assez d'informations pour laisser l'utilisateur + corriger son problème (donnez des indications vers la bonne + documentation et ainsi de suite). Si le rapport de bogue revient + régulièrement, vous devriez vous demander si la documentation est assez + bonne ou si le programme ne devrait pas détecter une mauvaise + utilisation pour donner un message d'erreur informatif. Il s'agit d'un + problème qui peut être présenté à l'auteur amont. + <p> + Si le rapporteur de bogue n'est pas d'accord avec votre décision de + fermeture du bogue, il peut le ré-ouvrir jusqu'à ce que vous trouviez un + accord sur la façon de le gérer. Si vous n'en trouvez pas, vous pouvez + marquer le bogue avec <tt>wontfix</tt> pour indiquer aux personnes que + le bogue existe, mais ne sera pas corrigé. Si cette situation n'est pas + acceptable, vous (ou le rapporteur) pouvez vouloir demander une décision + par le comité technique en réattribuant le bogue à + <package>tech-ctte</package> (vous pouvez utiliser la commande + <tt>clone</tt> du BTS si vous désirez garder le bogue comme rapporté sur + votre paquet). Avant de faire cela, veuillez lire la <url + id="&url-tech-ctte;" name="procédure recommandée">. + </item> + <item> + Si le rapport de bogue est réel, mais est causé par un autre paquet, + réattribuez simplement le bogue à l'autre paquet. Si vous ne savez pas à + quel paquet il doit être réattribué, vous pouvez demander de l'aide sur + &email-debian-devel; ou vous pouvez le réattribuer à + <package>debian-policy</package> pour les laisser décider dans quel + paquet est située l'erreur. + <p> + Parfois, vous devez également ajuster la gravité du bogue pour qu'elle + corresponde à notre définition de gravité des bogues. C'est dû au + fait que les gens tendent à augmenter la gravité des bogues pour + s'assurer que leurs bogues seront corrigés rapidement. La gravité de + certains bogues peut même être rétrogradée en <em>wishlist</em> (souhait) + quand le changement demandé est seulement d'ordre cosmétique. + </item> + <item> + Le rapporteur de bogue peut avoir oublié de fournir certaines + informations. Dans ce cas, vous devez lui demander les informations + nécessaires. Vous pouvez utiliser la marque <tt>moreinfo</tt> (plus + d'info) sur le bogue. De plus, si vous ne pouvez pas reproduire le + bogue, vous pouvez le marquer comme <tt>unreproducible</tt> (non + reproductible). Une personne qui arriverait à reproduire le bogue est + alors invitée à fournir plus d'informations sur la façon de le + reproduire. Après quelques mois, si cette information n'a été envoyée + par personne, le bogue peut être fermé. + </item> + <item> + Si le bogue est lié à l'empaquètement, vous devez simplement le + corriger. Si vous ne pouvez pas le corriger vous-même, marquez alors le + bogue avec <tt>help</tt> (aide). Vous pouvez également demander de + l'aide sur &email-debian-devel; ou &email-debian-qa;. S'il s'agit d'un + problème amont, vous devez faire suivre le rapport à l'auteur amont. + Faire suivre un bogue n'est pas suffisant, vous devez vérifier à chaque + version si le bogue a été corrigé ou non. S'il a été corrigé, vous le + fermez simplement, sinon vous devez le rappeler à l'auteur. Si vous avez + les compétences nécessaires, vous pouvez préparer un correctif pour + corriger le bogue et l'envoyer en même temps à l'auteur. Assurez-vous + d'envoyer le correctif au BTS et marquez le bogue avec <tt>patch</tt> + (correctif). + </item> + <item> + Si vous avez corrigé un bogue sur votre copie locale ou si un correctif + a été inclus dans le référentiel CVS, vous pouvez marquer le bogue avec + <tt>pending</tt> (en attente) pour informer que le bogue est corrigé et + qu'il sera fermé lors du prochain envoi (ajoutez le <tt>closes:</tt> + dans le <file>changelog</file>). C'est particulièrement utile si + plusieurs développeurs travaillent sur le même paquet. + </item> + <item> + Une fois que le paquet corrigé est disponible dans la distribution + <em>unstable</em>, vous pouvez fermer le bogue. Ceci peut être fait + automatiquement, pour cela, reportez-vous à <ref id="upload-bugfix">. + </item> +</enumlist> + + <sect1 id="bug-security">Gérer les bogues de sécurité +<p> +À cause de leur nature sensible, les bogues liés à la sécurité doivent être + soigneusement traités. L'équipe de sécurité de Debian est là pour coordonner + cette activité, pour faire le suivi des problèmes de sécurité en cours, pour + aider les responsables ayant des problèmes de sécurité ou pour les corriger + elle-même, pour envoyer les annonces de sécurité et pour maintenir le site + security.debian.org. + + <sect2 id="bug-security-you">Que faire si vous apprenez l'existence d'un + problème de sécurité ? +<p> +Si vous prenez connaissance d'un bogue lié à un problème de sécurité sur un + paquet Debian, que vous soyez ou non le responsable, regroupez les + informations pertinentes sur le problème et contactez rapidement l'équipe de + sécurité à &email-security-team;. Les informations utiles incluent, par + exemple : + + <list compact> + <item> + les versions du paquet connues pour être affectées par le bogue. Vérifiez + chaque version présente dans les distributions maintenues par Debian ainsi + que dans <em>testing</em> et dans <em>unstable</em>, + </item> + <item> + la nature d'une solution si elle est disponible (Les correctifs sont + particulièrement utiles), + </item> + <item> + tout paquet corrigé que vous avez vous-même préparé (envoyez seulement les + fichiers <file>.diff.gz</file> et <file>.dsc</file>), + </item> + <item> + toute information nécessaire pour l'annonce de sécurité (voir <ref + id="bug-security-advisories">). + </item> + </list> + + <sect2 id="bug-security-confidentiality">Confidentialité +<p> +À la différence de la plupart des autres activités au sein de Debian, les + informations sur les problèmes de sécurité doivent parfois être gardées en + privé pour un certain temps. Cette décision dépend de la nature du problème + et de l'existence d'une solution correspondante et également s'il s'agit d'un + fait connu publiquement. +<p> +Il existe plusieurs façons pour un développeur de prendre connaissance d'un +problème de sécurité : + +<list compact> + <item> + il le remarque sur un forum publique (liste de diffusion, site web, etc.), + </item> + <item> + quelqu'un remplit un rapport de bogue, + </item> + <item> + quelqu'un l'informe par courrier privé. + </item> +</list> + +Dans les deux premiers cas, l'information est publique et il est important +d'avoir une solution le plus vite possible. Dans le dernier cas, cependant, ce +n'est peut-être pas une information publique. Dans ce cas, il existe quelques +options possibles pour traiter le problème : + +<list> +<item> + si le problème est trivial (comme des fichiers temporaires non sécurisés), + il n'y a pas besoin de garder le secret sur le problème et une correction + devrait être effectuée et diffusée, +</item> +<item> + si le problème est grave (exploitable à distance, possibilité d'accéder + aux privilèges d'administratation), il est préférable de partager cette + information avec d'autres vendeurs et de coordonner une diffusion. + L'équipe de sécurité garde des contacts avec les différentes organisations + et individus et peut prendre soin des actions à mener. +</item> +</list> + +<p> +Dans tous les cas, si la personne qui indique le problème demande à ne pas +diffuser l'information, cela devrait être respecté avec l'évidente exception +d'informer l'équipe de sécurité (assurez-vous d'informer l'équipe de sécurité +que l'information ne doit pas être révélée). + +<p>Veuillez noter que si le secret est nécessaire, vous ne pourrez pas envoyer +un correctif vers <em>unstable</em> (ou ailleurs) puisque les informations de +changelog et de diff sont publiques pour <em>unstable</em>. + +<p>Il existe deux raisons pour diffuser l'information même si le secret est +demandé : le problème est connu depuis un certain temps ou le problème ou +son exploitation est devenu public. + + <sect2 id="bug-security-advisories">Annonces de sécurité +<p> +Les annonces de sécurité ne sont émises que pour la distribution actuelle + diffusée <em>stable</em>, pas pour <em>testing</em> ou <em>unstable</em>. + Quand elle est diffusée, l'annonce est envoyée à la liste de diffusion + &email-debian-security-announce; et elle est postée sur <url + id="&url-debian-security-advisories;" name="la page de sécurité">. Les + annonces de sécurité sont écrites et postées par l'équipe de sécurité. + Cependant, ils ne verront aucun inconvénient à ce qu'un responsable leur + apporte des informations ou écrive une partie du texte. Les informations qui + devraient être présentes dans une annonce incluent : +<list compact> +<item> + une description du problème et de sa portée, y compris : + <list> + <item> + le type du problème (escalade de privilège, déni de service, + etc.), + </item> + <item> + comment il peut être exploité, + </item> + <item> + si le problème peut être exploité à distance ou localement, + </item> + <item> + comment le problème a été corrigé, + </item> + </list> +</item> +<item> + les numéros de version des paquets affectés, +</item> +<item> + les numéros de version des paquets corrigés, +</item> +<item> + une information sur la façon de récupérer les paquets mis à jour, +</item> +<item> + des références à des annonces amont, des identifiants <url + id="http://cve.mitre.org" name="CVE"> et toute autre information utile + pour recouper les références de la vulnérabilité. +</item> +</list> + + <sect2 id="bug-security-building"> + <heading>Préparer les paquets pour corriger des problèmes de sécurité +<p> +Une façon d'assister l'équipe de sécurité dans ses travaux est de fournir des + paquets corrigés convenables pour une annonce de sécurité pour la version + <em>stable</em> de Debian +<p> +Quand une mise à jour de la version <em>stable</em> est effectuée, un soin + particulier doit être apporté pour éviter de modifier le comportement du + système ou d'introduire de nouveaux bogues. Pour cela, faites le moins de + changements possibles pour corriger le bogue. Les utilisateurs et les + administrateurs s'attendent à un comportement identique dans une version + lorsque celle-ci est effectuée, donc tout changement qui est fait est + susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour + les bibliothèques : assurez-vous ne de jamais changer l'API ou l'ABI, + quelque minimal que soit le changement. +<p> +Cela veut dire que passer à une version amont supérieure n'est pas une bonne +solution. À la place, les changements pertinents devraient être rétro-portés +vers la version présente dans la distribution <em>stable</em> de Debian. +Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de +sécurité Debian peut le faire. +<p> +Dans certains cas, il n'est pas possible de rétro-porter un correctif de +sécurité, par exemple, quand de grandes quantités de code source doivent être +modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à +une nouvelle version amont. Cependant, vous devez toujours coordonner cela avec +l'équipe de sécurité au préalable. +<p> +Il existe une autre règle de conduite liée à cela : testez toujours vos +changements. Si une exploitation du problème existe, essayez-là et +vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet +corrigé. Testez aussi les autres actions normales car parfois un correctif de +sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas +liées. +<p> +Examinez et testez autant que possible vos changements. Vérifiez les différences +avec la version précédente de manière répétée (<prgn>interdiff</prgn> et +<prgn>debdiff</prgn> sont des outils utiles pour cela). Lors de la construction +de la correction, gardez les points suivants à l'esprit : + +<list> +<item> + Assurez-vous que vous avez pour cible la bonne distribution dans votre + fichier <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de + <tt>stable-security</tt> et pour <em>testing</em>, c'est + <tt>testing-security</tt> et pour l'ancienne distribution stable, c'est + <tt>oldstable-security</tt>. Ne ciblez pas + <var>distribution</var>-proposed-updates ! +</item> +<item> + Assurez-vous que le numéro de version est correct. Il doit être plus élevé + que celui du paquet actuel, mais moins que ceux des paquets des versions + des distributions suivantes. En cas de doute, testez-le avec <tt>dpkg + --compare-versions</tt>. Pour <em>testing</em>, il doit y avoir un numéro + de version supérieur dans <em>unstable</em>. S'il n'y en a pas encore (par + exemple, si <em>testing</em> et <em>unstable</em> ont la même version), + vous devez envoyer une nouvelle version vers <em>unstable</em> en premier. +</item> +<item> + Ne faites pas d'envoi de source seul si votre paquet possède un ou + plusieurs paquets binary-all (n'utilisez pas l'option <tt>-S</tt> de + <prgn>dpkg-buildpackage</prgn>). L'infrastructure <prgn>buildd</prgn> ne + construira pas ceux-ci. Ce point s'applique aux envois de paquets normaux + également. +</item> +<item> + Si la source amont a été envoyée auparavant à security.debian.org (par une + précédente mise à jour de sécurité), construisez le paquet sans la source + amont (<tt>dpkg-buildpackage -sd</tt>). Sinon, construisez-le avec le + source complet (<tt>dpkg-buildpackage -sa</tt>). +</item> +<item> + Assurez-vous d'utiliser exactement le même nom <file>*.orig.tar.gz</file> + que celui utilisé dans l'archive normale, sinon il ne sera pas possible de + déplacer plus tard le correctif de sécurité dans l'archive principale. +</item> +<item> + Assurez-vous, lors de la compilation du paquet, de compiler sur un système + propre, dont tous les paquets appartiennent à la distribution pour laquelle vous + construisez le paquet. Si vous n'avez pas un tel système, vous pouvez + utiliser l'une des machines de debian.org (voir <ref + id="server-machines">) ou mettez en place un chroot (voir <ref id= + "pbuilder"> et <ref id="debootstrap">). +</item> +</list> + + <sect2 id="bug-security-upload">Mettre à jour le paquet corrigé +<p> +Vous <em>NE DEVEZ PAS</em> envoyer un paquet dans la file d'attente des envois de sécurité +sans l'accord préalable de l'équipe de sécurité. Si le paquet ne remplit pas +exactement les impératifs de l'équipe, il causera beaucoup de problèmes, ainsi +que des délais dans la gestion de l'envoi indésirable. +<p> +Vous <em>NE DEVEZ PAS</em> envoyer votre correction dans +<em>proposed-updates</em> sans vous coordonner avec l'équipe de sécurité. Les +paquets seront copiés de security.debian.org dans le répertoire +<file>proposed-updates</file> automatiquement. Si un paquet avec le même numéro +de version ou un numéro plus grand est déjà installé dans l'archive, la mise à +jour de sécurité sera rejetée par le système d'archive. Ainsi, la distribution +<em>stable</em> se retrouvera à la place sans la mise à jour de sécurité de ce +paquet. +<p> +Une fois que vous avez créé et testé le nouveau paquet et qu'il a été approuvé +par l'équipe de sécurité, il doit être envoyé pour être installé dans les +archives. Pour les envois de sécurité, l'adresse d'envoi est +<tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt>. + +<p> +Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera +automatiquement recompilé pour toutes les architectures et stocké pour +vérification par l'équipe de sécurité. + +<p> +Les envois en attente d'acceptation ou de vérification ne sont accessibles que +par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des +correctifs pour des problèmes de sécurités qui ne peuvent pas encore être +diffusés. + +<p> +Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur +security.debian.org ainsi que dans le répertoire +<var>distribution</var>-proposed-updates qui convient sur ftp-master ou dans +l'archive non-US. + + <sect1 id="upload-bugfix">Quand les rapports de bogue sont-ils fermés par + une mise à jour ? +<p> +Si vous corrigez un bogue dans vos paquets, il est de votre responsabilité de + fermer le rapport de bogue associé. Cependant, vous ne devez pas le fermer + avant que le paquet n'ait été accepté dans l'archive Debian. C'est pourquoi, + vous pouvez et vous devez clore le rapport dans le système de suivi des bogues + une fois que vous avez reçu l'avis indiquant que votre nouveau paquet a été + installé dans l'archive. +<p> +Cependant, il est possible d'éviter d'avoir à fermer manuellement les bogues + après l'envoi — indiquez simplement les bogues corrigés dans le fichier + <file>changelog</file> en suivant une syntaxe précise. Par exemple : + +<example> +acme-cannon (3.1415) unstable; urgency=low + + * Frobbed with options (closes: Bug#98339) + * Added safety to prevent operator dismemberment, closes: bug#98765, + bug#98713, #98714. + * Added man page. Closes: #98725. +</example> + +Techniquement parlant, l'expression régulière suivante Perl est utilisée : + +<example> + /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig +</example> + +L'auteur préfère la syntaxe <tt>closes: #<var>XXX</var></tt>, car c'est l'une +des plus concises et des plus faciles à intégrer dans le texte du fichier +<file>changelog</file>. +<p> +Si vous entrez un numéro de bogue incorrect ou si vous en oubliez un dans le + fichier <file>changelog</file>, n'hésitez pas à annuler tout dommage que + l'erreur a entrainé. Pour réouvrir un bogue fermé par erreur, envoyez une + commande <tt>reopen <var>XXX</var></tt> au robot de contrôle du système de + suivi des bogues. Pour fermer tous les bogues restants qui ont été corrigés par + votre envoi, envoyez le fichier <file>.changes</file> à + <email>XXX-done@bugs.debian.org</email> où <var>XXX</var> est le numéro du + bogue. +<p> +Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en utilisant le + <file>changelog</file> tel que décrit ci-dessus — si vous désirez + simplement fermer les bogues qui n'ont rien à voir avec l'un de vos envois, + faites-le simplement en envoyant une explication à + <email>XXX-done@bugs.debian.org</email>. + + <chapt id="best-pkging-practices"> + <heading>Les meilleurs pratiques pour la construction des paquets +<p> +La qualité de Debian est principalement due à la <url id="&url-debian-policy;" +name="charte Debian"> qui définit explicitement les obligations que tous les +paquets doivent suivre. Mais c'est également grâce à une histoire partagée +d'expériences qui va au-delà de la charte Debian, une accumulation d'années +d'expérience pour la construction des paquets ; des développeurs de grand +talent ont créé de bons outils qui vous aideront, vous, responsable Debian, à +créer et maintenir d'excellents paquets. + +<p> +Ce chapitre fournit les meilleurs pratiques pour les développeurs Debian. Ce ne +sont que des recommandations, non pas des obligations ou des règles. Ce sont +seulement des astuces et conseils subjectifs et des liens collectés pour les +développeurs Debian. Prenez et choisissez ce qui vous convient le mieux. + + <sect id="bpp-debian-rules"> + <heading>Les meilleures pratiques pour le fichier <file>debian/rules</file></heading> + <p> +Les recommandations suivantes s'appliquent au fichier <file>debian/rules</file>. +Comme ce fichier contrôle le processus de compilation et qu'il sélectionne les +fichiers inclus dans le paquet (directement ou indirectement), il s'agit +habituellement du fichier sur lequel les responsables passent le plus de temps. + + + <sect1 id="helper-scripts">Scripts d'aide +<p> +La raison sous-jacente à l'utilisation des scripts d'aide dans le fichier +<file>debian/rules</file> est que cela permet aux responsables d'utiliser et de +partager une logique commune pour un grand nombre de paquets. Prenez, par +exemple, l'installation des entrées de menu : vous avez besoin de +placer un fichier dans <file>/usr/lib/menu</file> et d'ajouter des commandes aux +scripts de maintenance pour enregistrer et désenregistrer ces entrées de menu. +Comme il s'agit d'une chose très commune, pourquoi chaque +responsable devrait-il écrire sa propre version, parfois avec des bogues ? +Supposons également que le répertoire de menu soit modifié, chaque paquet +devrait être modifié. +<p> +Les scripts d'aide peuvent résoudre ces problèmes. En supposant que vous vous +conformiez aux conventions attendues par le script d'aide, celui-ci prend soin +de tous les détails. Les changements dans la charte peuvent alors être faits +dans le script d'aide, les paquets ont alors simplement besoin d'être +reconstruits avec la nouvelle version du script et sans aucun changement +supplémentaire. +<p> +L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus +courant et le meilleur (à notre avis) système est <package>debhelper</package>. +Les précédents systèmes d'aide comme <package>debmake</package> étaient +« monolithiques » : vous ne pouviez pas choisir quelles parties +intéressantes vous pouviez utiliser, mais vous êtiez obligé de choisir le +système pour tout faire. <package>debhelper</package>, à l'inverse, consiste en +un certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple, +<prgn>dh_installman</prgn> installe et compresse les pages de manuel, +<prgn>dh_installmenu</prgn> installe les fichiers de menu et ainsi de suite. +Ainsi, il offre une flexibilité suffisante pour pouvoir utiliser les scripts +d'aide quand ils sont utiles, en complément de commandes définies manuellement +dans le fichier <file>debian/rules</file>. +<p> +Vous pouvez débuter avec <package>debhelper</package> par lire <manref +name="debhelper" section="1"> et en regardant les exemples fournis avec le +paquet. <prgn>dh_make</prgn> du paquet <package>dh-make</package> (voir <ref +id="dh-make">) peut être utilisé pour convertir un paquet source +« vierge » en une version utilisant <package>debhelper</package>. Ce +raccourci ne devrait cependant pas vous faire croire que vous n'avez pas besoin +de comprendre les scripts individuels <prgn>dh_*</prgn>). Si vous comptez +utiliser un système d'aide, vous devez prendre le temps d'apprendre à utiliser +ce système pour savoir ce que vous pouvez en attendre ainsi que son +comportement. +<p> +Plusieurs personnes pensent que des fichiers <file>debian/rules</file> vierges +sont préférables car vous n'avez pas à apprendre les détails internes d'un +quelconque système d'aide. La décision vous appartient complètement. Utilisez ce +qui vous convient. Plusieurs exemples de fichiers <file>debian/rules</file> sont +disponibles à <url id="&url-rules-files;">. + +<!-- Pour vous aider dans votre effort d'empaquètement, vous pouvez + utiliser les scripts d'aide. Les meilleurs scripts disponibles sont fournis + par <package>debhelper</package>. Avec <prgn>dh_make</prgn> (paquet + <package>dh-make</package>), vous pouvez générer en quelques secondes un + paquet qui est presque prêt. Cependant, cette apparente simplicité cache un + grand nombre de choses faites par les scripts d'aide. Vous devez savoir ce + qu'ils font, c'est pourquoi vous êtes fortement encouragé à lire les pages de + manuel correspondantes, en commençant par <manref section="1" name="debhelper">. C'est + nécessaire parce que vous devez comprendre ce qui se passe pour être capable + de les utiliser sagement et pour pouvoir corriger des bogues de manière + élégante. +<p> +debhelper est très utile car il vous permet de suivre la plus récente + charte Debian sans faire beaucoup de modifications car les changements qui + peuvent être automatisés sont presque toujours faits automatiquement par un + script debhelper. De plus, il offre suffisamment de flexibilité pour que vous + soyez capable de l'utiliser en conjonction avec des invocations de shell + écrites à la main à l'intérieur du fichier <file>rules</file>. +<p> +Vous pouvez cependant décider de ne pas utiliser de script d'aide et + tout de même écrire d'excellents fichiers <file>rules</file>. Plusieurs + exemples sont disponibles à <url id="&url-rules-files;">. + + --> + <sect1 id="multiple-patches"> + <heading>Appliquer des correctifs sur les sources ou appliquer des + correctifs lors de la construction ?</heading> +<p> +Les gros paquets peuvent avoir plusieurs bogues que vous devez corriger. + Si vous corrigez sans faire attention les bogues dans les +sources, + vous ne pourrez pas différencier facilement les + nombreux correctifs que vous aurez appliqués. Cela peut devenir trés +compliqué de mettre à jour le paquet avec une nouvelle version amont qui + intègre certains correctifs (mais pas tous). Vous ne pouvez pas prendre + l'ensemble des correctifs (par exemple, dans les fichiers <file>.diff.gz</file>) et + décider quels correctifs il vous faut enlever parceque les bogues ont été + corrigés en amont. +<p> +Une bonne solution est de conserver des correctifs séparés sous le répertoire + <file>debian</file> et de les appliquer lors de la compilation. Le paquet + <package>dbs</package> fournit un moyen pratique pour appliquer ces correctifs + lors de la compilation (et de les enlever lors du nettoyage). Le paquet + <package>dbs</package> fournit également des facilités pour créer des + correctifs et garder une trace de leur utilité. Comme toujours lorsque vous + utilisez des outils des maintenance, vous devez lire la documentation + associée. Le paquet <package>hello-dbs</package> est un exemple simple qui + présente comment utiliser <package>dbs</package>. +<p> + + <sect1 id="multiple-binary">Paquets binaires multiples +<p> +Un simple paquet source va souvent permettre de construire plusieurs paquets + binaires différents, que ce soit pour fournir plusieurs saveurs du même + paquet (par exemple, les différents paquets <package>vim-*</package>) ou pour + créer plusieurs petits paquets au lieu d'un seul gros (par exemple, si + l'utilisateur peut installer que la partie dont il a besoin et ainsi + économiser de l'espace disque). +<p> +Le second cas peut facilement être géré dans le fichier + <file>debian/rules</file>. Vous avez simplement besoin de déplacer les fichiers + appropriés du répertoire de construction dans les arborescence temporaires du + paquet. Vous pouvez le faire en utilisant <prgn>install</prgn> (approche + vierge) ou <prgn>dh_install</prgn> (du <package>debhelper</package>). + Assurez-vous de vérifier les différentes permutations de paquets, en + garantissant que vous avez bien défini les dépendances entre les paquets dans + le fichier <file>debian/control</file>. +<p> +Le premier cas est un peu plus diffile car il implique de multiples + recompilations du même logiciel, mais avec différentes options de + configuration. Le paquet <package>vim</package> est un exemple de la façon de + gérer cela avec un fichier rules écrit à la main. + +<!-- &FIXME; Find a good debhelper example with multile configure/make cycles + --> +</sect1> + + <sect id="bpp-debian-maint-scripts"> + <heading>Les meilleures pratiques pour les scripts de + maintenance</heading> + <p> +Les scripts de maintenance incluent les fichiers <file>debian/postinst</file>, +<file>debian/preinst</file>, <file>debian/prerm</file> et +<file>debian/postrm</file>. Ces scripts prennent soin de la configuration +d'installation ou de désinstallation des paquets, ce qui n'est pas simplement créer ou ++supprimer des fichiers et des répertoires. Les instructions suivantes +complètent la <url id="&url-debian-policy;" name="charte Debian">. + <p> +Les scripts de maintenance doivent être idempotents. Cela veut dire que vous +devez vous assurer que rien de grave ne se produit si un script est appelé deux +fois là où il ne devrait habituellement être appelé qu'une fois. + <p> +Les entrée et sortie standard peuvent être redirigées (par exemple, dans des +tubes<footnote><p>pipes</p></footnote>) pour des besoins d'enregistrement +d'activité, donc vous ne devez pas supposer que ce sont des tty. + <p> +Tous les affichages et les configurations interactives devraient être +minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet +<package>debconf</package> pour l'interface. Rappelez-vous que, dans tous les +cas, l'affichage ne doit se faire que dans l'étape de configuration, +<tt>configure</tt> du script de post-installation, <file>postinst</file>. + <p> +Gardez les scripts de maintenance aussi simples que possible. Nous vous +suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que si vous +avez besoin d'une fonctionnalité de Bash, le script de maintenance doit +l'indiquer dans sa première ligne. Un shell POSIX ou Bash sont préférés à +Perl car ils permettent à <package>debhelper</package> d'ajouter facilement des +parties aux scripts. + <p> +Si vous modifiez les scripts de maintenance, assurez-vous de tester la +suppression du paquet, la double installation et la purge complète. Assurez-vous +qu'il ne reste rien d'un paquet purgé, c'est-à-dire, que la purge doit enlever +tout fichier créé, directement ou indirectement, par les scripts de +maintenance. + <p> +Si vous avez besoin de vérifier l'existence d'une commande, vous devriez +utiliser quelque chose comme : +<example>if [ -x /usr/sbin/install-docs ]; then ...</example> + +Si vous ne désirez pas mettre en dur le chemin de la commande dans le script de +maintenance, la fonction de shell suivante conforme à POSIX peut vous +aider : + +&example-pathfind; + +Vous pouvez utiliser cette fonction pour rechercher le <tt>$PATH</tt> pour un +nom de commande passé en argument. Il renvoie vrai (zéro) si la commande a été +trouvé et faux sinon. Il s'agit réellement de la façon la plus portable de faire +car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn> ne sont pas +POSIX. Bien que <prgn>which</prgn> soit une alternative acceptable car il est +présent dans le paquet classé <em>required</em><package>debianutils</package>, il n'est pas +présent dans la partition racine ; mais cela ne posera sans doute pas de +problème. + + + <sect id="bpp-debian-control"> + <heading>Les meilleures pratiques pour le fichier + <file>debian/control</file></heading> + <p> +Les pratiques suivantes viennent en complément de la <url + id="&url-debian-policy;ch-miscellaneous.html#s-descriptions" + name="règles pour les descriptions de paquet">.</p> + + <sect1 id="bpp-pkg-desc"> + <heading>Écrire des descriptions utiles</heading> +<p> +La description du paquet (telle qu'elle est définie dans le champ correspondant + du fichier <file>control</file>) est habituellement la première + information dont dispose l'utilisateur avant d'installer un paquet. Aussi, + elle devrait fournir toutes les informations nécessaires pour le laisser + décider de l'installation du paquet. +<p> +Pour des raisons de cohérence et d'esthétique, vous devriez mettre en + majuscule la première lettre du résumé de la description. Ne mettez pas +de point à la fin. La description elle-même devrait n'être constituée + que de phrases entières. +<p> +Enfin, comme la première impression de l'utilisateur est basée sur cette + description, vous devriez éviter les fautes d'orthographe et de grammaire. + N'oubliez pas votre vérificateur orthographique. + <prgn>ispell</prgn> possède une option spéciale (<tt>-g</tt>) pour + cela : <example>ispell -d american -g debian/control</example>. Si + vous voulez qu'une personne relise la description que vous avez l'intention + d'utiliser, vous pouvez le demander sur &email-debian-l10n-english;. + </sect1> + + <sect1 id="bpp-upstream-info"> + <heading>Page d'accueil amont</heading> + <p> +Nous vous recommandons d'ajouter l'adresse de la page d'accueil du paquet à la +description du paquet dans le fichier <file>debian/control</file>. Cette +information devrait être ajoutée à la fin de la description en utilisant le +format suivant : + +<example> . + Homepage: http://some-project.some-place.org/</example> + +Veuillez noter les espaces au début de la ligne, ils servent à séparer les +lignes correctement. Pour voir un exemple de ce que cela affiche, veuillez vous +reporter à <url id="&url-eg-desc-upstream-info;">. + <p> +Ne mettez rien s'il n'existe pas de page pour le logiciel. + + <p> +Veuillez noter que nous espérons que ce champ sera remplacé par un +vrai champ de <file>debian/control</file> que comprendraient <prgn>dpkg</prgn> +et <tt>&packages-host;</tt>. Si vous ne voulez pas vous embêter à mettre la +page d'accueil de la description dans ce nouveau champ, vous devriez +probablement attendre qu'il soit disponible.</p> + </sect1> + </sect> + +<!-- <sect1 id="pkg-mgmt-cvs">Managing a package with CVS + <p> + &FIXME; presentation of cvs-buildpackage, updating sources + via CVS (debian/rules refresh). +--> + + + <sect id="bpp-config-mgmt"> + <heading>Gestion de la configuration avec <package>debconf</package></heading> + + <p> +<p> +<package>Debconf</package> est un système de gestion de configuration qui + peut être utilisé par les divers scripts de maintenance (principalement + en post-installation dans le fichier <file>postinst</file>) pour demander à +l'utilisateur des informations concernant la configuration du paquet. Il +faut maintenant éviter les interactions directes avec l'utilisateur et +préférer les interactions utilisant <package>debconf</package>. Ceci permettra + à l'avenir des installations non interactives. <!-- pas de trait d'union +entre non et adjectif --> + <p> +Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs erreurs + communes sont référencées dans la page de manuel <manref section="8" + name="debconf-devel">. Vous devriez vraiment lire cette page si vous décidez + d'utiliser debconf. + </sect> + + + <sect id="bpp-i18n"> + <heading>Internationalisation</heading> + + + + <sect1 id="bpp-i18n-debconf">Gestion des traductions de + debconf +<p> +Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur + un grand nombre de paquets et doivent donc collaborer avec plusieurs + responsables différents. De plus, la plupart du temps, l'anglais n'est pas leur + langue maternelle, il se peut que vous deviez être particulièrement patient + avec eux. +<p> +Le but de <package>debconf</package> était de faciliter la configuration des +paquets aux responsables et aux utilisateurs. À l'origine, les +traductions des questionnaires debconf étaient gérées avec +<prgn>debconf-mergetemplate</prgn>. Cependant, cette technique est maintenant +déconseillée ; la meilleure façon pour l'internationalisation de +<package>debconf</package> est d'utiliser le paquet +<package>po-debconf</package>. Cette méthode est plus facile et pour le +responsable et pour les traducteurs ; des scripts de transition sont +fournis. +<p> +Lors de l'utilisation de <package>po-debconf</package>, la traduction est +stockée dans des fichiers <file>po</file> (à l'instar des techniques de +traduction de <prgn>gettext</prgn>). Des fichiers modèles contiennent les +messages d'origine et indiquent quels sont les champs traduisibles. Quand vous +modifiez l'état d'un champ traduisible en appelant +<prgn>debconf-updatepo</prgn>, la traduction est marquée comme ayant besoin de +l'attention des traducteurs. Puis, lors de la construction du paquet, le +programme <prgn>dh_installdebconf</prgn> prendra soin de toute la magie +nécessaire à l'ajout du modèle avec les traductions à jour dans les paquets +binaires. Veuillez vous reporter à la page de manuel <manref name="po-debconf" +section="7"> pour les détails. + </sect1> + + <sect1 id="bpp-i18n-docs"> + <heading>Documentation traduite</heading> + <p> +La traduction de la documentation est cruciale pour les utilisateurs, mais elle +représente un important travail. Il n'existe aucun moyen d'éliminer ce travail, +mais vous pouvez faciliter les choses pour les traducteurs. + <p> +Si vous êtes responsable d'une documentation quelle que soit sa taille, il est +plus facile pour les traducteurs d'avoir accès à un système de contrôle de +source. Ceci permet aux traducteurs de voir les différences entre deux versions +de la documentation, pour, par exemple, qu'ils puissent voir ce qui a besoin +d'être retraduit. Il est recommandé que le document traduit inclue une note à +propos de la révision de contrôle du source sur laquelle la traduction est +basée. Un système intéressant est fourni par <url id="&url-i18n-doc-check;" +name="doc-check"> dans le paquet <package>boot-floppies</package> qui donne un +aperçu de l'état de la traduction pour une langue donnée, en utilisant les +commentaires structurés pour une révision donnée du fichier à traduire et, pour +un fichier traduit, la révision du fichier d'origine sur laquelle la traduction +est basée. Vous pouvez vouloir adapter et fournir ceci dans votre référentiel CVS. + <p> +Si vous maintenez de la documentation au format XML ou SGML, nous vous suggérons +d'isoler les informations indépendantes de la langue et de les définir +comme des entités dans un fichier séparé qui sera inclus par les différentes +traductions. Ceci aide, par exemple, à garder à jour les adresses pour +plusieurs fichiers. + </sect1> + </sect> + +<!-- , ils ne peuvent pas garder la trace de chaque changement dans les paquets + pour être informé quand une chaîne de traduction n'est plus à jour. + Heureusement, <package>debconf</package> peut automatiquement indiquer les + traductions non à jour si les responsables de paquet suivent les quelques + lignes de conduites de base décrites ci-dessous. +<p> +Les traducteurs peuvent utiliser <prgn>debconf-getlang</prgn> + (paquet <package>debconf-utils</package>) pour écrire un fichier + <file>templates.xx</file> contenant à la fois les champs en anglais et + localisés (où <em>xx</em> est le code de langue, qui peut être suivi par un + code de pays). Ce fichier peut être placé dans le sous-répertoire + <file>debian</file> sans aucun changement. +<p> +Lors de la construction d'un paquet binaire, les fichiers + <file>debian/templates.xx</file> sont regroupés avec + <file>debian/templates</file> pour générer le fichier <file>templates</file> + qui contient le paquet binaire. Ceci est fait automatiquement par + <prgn>dh_installdebconf</prgn> (paquet <package>debhelper</package>). Si vous + n'utilisez pas debhelper, vous pouvez faire la même chose avec + <prgn>debconf-mergetemplate</prgn> (paquet + <package>debconf-utils</package>). +<p> +Quand le responsable du paquet a besoin de faire une mise à jour du + fichier de modèle, il n'a qu'à changer <file>debian/templates</file>. Quand + les chaînes en anglais de ce fichier et de <file>debian/templates.xx</file> + diffèrent, les traducteurs savent que leur traduction n'est plus à jour. +<p> +Veuillez vous reporter à la page sur les <url id="&url-debconf-l10n-help;" + name="fichiers templates debconf de localisation"> du site web Debian, elle + contient des instructions plus détaillées, y compris un exemple complet. + --> + + <sect id="bpp-common-situations"> + <heading>Pratiques d'empaquètement communes</heading> + +<!-- + <sect1 id="bpp-kernel">Kernel modules/patches +<p> + + &FIXME; Heavy use of kernel-package. provide files in + /etc/modutils/ for module configuration. +--> + + <sect1 id="bpp-autotools"> + <heading>Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn> +<p> +Conserver à jour les fichiers d'<prgn>autoconf</prgn>, <file>config.sub</file> +et <file>config.guess</file>, est critique pour les porteurs, spécialement pour +les architectures plus changeantes. De très bonnes pratiques d'empaquetage +utilisant <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été regroupées +dans &file-bpp-autotools; du paquet <package>autotools-dev</package>. Vous êtes +vivement encouragé à lire ce fichier et à suivre les recommandations indiquées. + + + <sect1 id="bpp-libraries">Bibliothèques +<p> +Les bibliothèques ont toujours été difficiles à empaqueter pour diverses + raisons. La charte impose plusieurs contraintes pour faciliter la maintenance + et pour garantir que les mises à jour sont aussi simples que possible quand une + nouvelle version amont est disponible. Une erreur dans une bibliothèque peut + rendre défectueux une douzaine de paquets qui en dépendent. +<p> +Les bonnes pratiques d'empaquètement des bibliothèques ont été regroupées dans + <url id="&url-libpkg-guide;" name="le guide d'empaquètement des + bibliothèques">. + + <sect1 id="bpp-docs">Documentation + <p> +Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html" +name="règles sur la documentation">.</p> + <p> +Si votre paquet contient de la documentation construite à partir de XML ou SGML, +nous vous recommandons de ne pas fournir le source XML ou SGML dans le(s) +paquet(s) binaire(s). Si les utilisateurs désirent avoir le source de la +documentation, ils peuvent récupérer le paquet source.</p> + <p> +La charte spécifie que la documentation doit être fournie au format HTML. +Nous vous recommandons également de la fournir au format PDF et texte simple si +c'est adapté et qu'une sortie de qualité est possible. Cependant, il n'est +généralement pas approprié de fournir des versions en texte simple pour la +documentation dont le format source est du HTML.</p> + <p> +Les principaux manuels fournis devraient être enregistrés par le paquet +<package>doc-base</package> à l'installation. Reportez-vous à la documentation +du paquet <package>doc-base</package> pour plus d'information.</p> + + + + <sect1 id="bpp-other">Types spécifiques de paquets +<p> +Plusieurs types spécifiques de paquets ont des sous-chartes spéciales et des + règles et pratiques d'empaquètement correspondantes : +<list> +<item> + Les paquets liés à Perl ont leur <url id="&url-perl-policy;" name="charte + Perl">, quelques exemples de paquets qui suivent cette charte sont + <package>libdbd-pg-perl</package> (module perl binaire) ou + <package>libmldbm-perl</package> (module perl indépendant de + l'architecture). +</item> +<item> + Les paquets liés à Python ont leur charte python ; voir + &file-python-policy; dans le paquet <package>python</package>. +</item> +<item> + Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;" + name="charte Emacs">. +</item> +<item> + Les paquets liés à Java ont leur <url id="&url-java-policy;" name="charte + Java">. +</item> +<item> + Les paquets liés à Ocaml ont leur propre charte que l'on trouve dans + &file-ocaml-policy; du paquet <package>ocaml</package>. Un bon exemple est + le paquet source <package>camlzip</package>. +</item> +<item> + Les paquets fournissant des DTDs XML ou SGML devraient se conformer aux + recommandations que l'on peut trouver dans le paquet + <package>sgml-base-doc</package> +<item> + Les paquets Lisp devraient s'enregistrer avec le paquet + <package>common-lisp-controller</package> pour lequel vous pouvez vous + reporter à &file-lisp-controller;. +</list> + + </sect1> +</sect> + + <chapt id="beyond-pkging"> + <heading>Au-delà de l'empaquètement +<p> +Debian, c'est beaucoup plus que de l'empaquètement de logiciels et de + la maintenance de paquets. Ce chapitre contient des informations sur les + façons, souvent vraiment importantes, de contribuer à Debian au-delà de la + simple création et maintenance de paquets. +<p> +En tant qu'organisation de volontaires, Debian repose sur la liberté de + choisir ce sur quoi l'on désire travailler et de choisir la + partie la plus importante à laquelle on veut consacrer son temps. + + <sect id="submit-bug"> + <heading>Rapporter des bogues +<p> +Nous vous encourageons à remplir des rapports de bogue quand vous trouvez des + bogues dans les paquets Debian. En fait, les développeurs Debian sont souvent + les testeurs de première ligne. Trouver et rapporter les bogues dans les + paquets d'autres développeurs améliore la qualité de Debian. +<p> +Essayez de soumettre le bogue à partir d'un compte utilisateur normal sur lequel vous + pouvez recevoir des courriers. Ne soumettez pas de bogues en tant + que root. +<p> +Assurez-vous que le bogue n'a pas déjà été rapporté. Essayez de + faire du bon boulot quand vous rapportez le bogue et indiquez l'emplacement + exact. Vous pouvez également parcourir les bogues d'autres paquets, en les + regroupant s'ils sont indiqués plus d'une fois, ou en modifiant la gravité d'un + bogue à « fixed » quand ils ont déjà été corrigés. Notez cependant + que si vous n'êtes ni le rapporteur du bogue, ni le responsable du paquet, vous + ne devriez pas fermer réellement le bogue (à moins que vous n'ayez la + permission sécurisée du responsable). +<p> +De temps en temps, vous pourrez vouloir vérifier ce qui s'est passé à propos des + bogues que vous avez rapportés. Saisissez cette occasion pour fermer les bogues + que vous ne pouvez plus reproduire. Pour trouver tous les bogues que vous avez + rapportés, vous avez simplement besoin d'aller à + <tt>http://&bugs-host;/from:<your-email-addr></tt>. + + <sect1 id="submit-many-bugs">Ouvrir un grand nombre de rapports d'un seul + coup +<p> +Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de + paquets — plus de dix — est une pratique que nous déconseillons. + Prenez toutes les mesures possibles pour éviter cette situation. Si le problème + peut être détecté automatiquement par exemple, ajoutez un nouveau test dans le + paquet <package>lintian</package> pour générer une erreur ou un avertissement. +<p> +Si vous ouvrez plus de dix rapports sur le même sujet, il est préférable + d'indiquer votre intention sur la liste &email-debian-devel;. Cela donnera à + d'autres développeurs la possibilité de vérifier que le problème existe + vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent + les mêmes rapports de bogue simultanément. +<p> +Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez + les envoyer à <email>maintonly@bugs.debian.org</email> pour qu'ils ne soient + pas redirigés vers les listes de diffusions. + + + <sect id="qa-effort">Effort d'assurance qualité + + <sect1 id="qa-daily-work">Travail journalier +<p> +Bien qu'il y ait un groupe de personnes dédiées à l'assurance qualité, les + devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez participer à + cet effort en conservant vos paquets aussi exempts de bogues que possible et + aussi corrects que possible selon <prgn>lintian</prgn> (reportez-vous à <ref + id="lintian">). Si cela vous paraît impossible, vous devriez alors envisager + d'abandonner certains de vos paquets (reportez-vous à <ref id="orphaning">). + Sinon, vous pouvez demander de l'aide à d'autres personnes pour qu'elles + puissent rattraper votre retard dans la correction des bogues (vous pouvez + demander de l'aide sur &email-debian-qa; ou &email-debian-devel;). En même + temps, vous pouvez rechercher des co-responsables (reportez-vous à <ref + id="collaborative-maint">). + + <sect1 id="qa-bsp">Les chasses aux bogues +<p> +De temps en temps, le groupe d'assurance qualité organise des chasses aux + bogues<footnote><em>Bug Squashing Party</em></footnote> pour essayer de + supprimer le plus de problèmes possible. Elles sont annoncées sur + &email-debian-devel-announce; et l'annonce explique quel domaine sera visé + pendant la chasse : habituellement, il s'agit des bogues empêchant + l'intégration du paquet dans la distribution (« Release Critical »), + mais il peut arriver qu'ils décident d'aider à finir une transition majeure + (comme une nouvelle version de Perl qui demande la recompilation de tous les + modules binaires). +<p> +Les règles pour les mises à jour indépendantes sont différentes au cours de la + chasse parce que l'annonce de la chasse est considérée comme une annonce + préalable pour les mises à jour indépendantes. Si vous avez des paquets qui + peuvent être affectées par la chasse (parce qu'ils ont des bogues critiques par + exemple), vous devriez envoyer une mise à jour pour chaque bogue correspondant + pour expliquer leur état actuel et ce que vous attendez de la chasse. Si vous + ne voulez pas d'une mise à jour indépendante ou si vous n'êtes intéressé que + par un correctif ou si vous gérerez votre bogue vous-même, veuillez l'expliquer + dans le BTS. +<p> +Les personnes qui participent à la chasse ont des règles spécifiques pour les + mises à jour indépendantes, ils peuvent en faire une sans avertissement + préalable s'ils envoient leur paquet avec un délai d'au moins 3 jours dans + DELAYED/3-day. Toutes les autres règles de mise à jour indépendante + s'appliquent comme habituellement, ils devraient envoyer le correctif de la + mise à jour dans le BTS (pour l'un des bogues ouverts corrigé par la mise à + jour ou pour un nouveau bogue marqué comme fixé). Ils devraient également + respecter les souhaits du responsable s'il en a exprimés. +<p> +Si une personne ne se sent pas à l'aise avec une mise à jour indépendante, elle + devrait simplement envoyer un correctif au BTS. C'est de loin meilleur qu'une + mise à jour défectueuse. + + <sect id="mia-qa">Gérer les responsables non joignables +<p> +Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer + que le responsable est toujours actif et qu'il continue à travailler sur + ses paquets. Essayez de le contacter vous-même. +<p> +Si vous n'obtenez aucune réponse après quelques semaines, vous devriez réunir + toutes les informations utiles sur ce responsable. Commencez par vous + connecter sur la <url id="&url-debian-db;" name="base de données des + développeurs Debian"> et faites une recherche complète pour vérifier si le + responsable est en vacances et quand il a été vu la dernière fois. + Réunissez les noms des paquets importants dont il est responsable et tous + les bogues critiques pour la distribution rapportés sur ceux-ci. +<p> +Envoyez toutes ces informations à &email-debian-qa; pour laisser les personnes + de la QA décider de ce qui est nécessaire. + + <sect id="contacting-maintainers">Contacter d'autres responsables +<p> +Pendant vos activités dans Debian, vous aurez à contacter d'autres responsables + pour différentes raisons. Vous pourrez vouloir discuter d'une nouvelle + façon de coopérer au sein d'un ensemble de paquets liés, ou vous pouvez + simplement rappeler à quelqu'un qu'une nouvelle version est disponible et + que vous en avez besoin. +<p> +Chercher l'adresse d'un responsable d'un paquet peut être fastidieux. + Heureusement, il existe un alias de courrier simple, + <tt><package>@&packages-host;</tt>, qui fournit un moyen d'envoyer + un courrier à un responsable, quelle que soit son adresse (ou ses + adresses). Remplacez <tt><package></tt> par le nom du paquet source + ou binaire. +<p> +Vous pouvez également vouloir contacter les personnes qui sont inscrites à un + paquet de source donné par <ref id="pkg-tracking-system">. Vous pouvez le + faire en utilisant l'adresse <tt><package-name>@&pts-host;</tt>. + + + <sect id="newmaint"> + <heading>Interagir avec de futurs développeurs Debian +<p> +Le succès de Debian dépend de sa capacité à attirer et retenir de nouveaux et + talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous + recommandons de vous impliquer dans le processus d'apport des nouveaux + responsables. Cette section décrit comment aider les futurs développeurs. + + + <sect1 id="sponsoring">Parrainer des paquets +<p> +Parrainer un paquet veut dire envoyer un paquet pour un responsable qui n'est + pas encore autorisé à le faire lui-même, un candidat nouveau responsable. + Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité. +<p> +Si vous désirez être volontaire pour être parrain, vous pouvez vous inscrire à + <url id="&url-sponsors;">. +<p> +Les nouveaux responsables ont habituellement certaines difficultés à créer des + paquets Debian — ceci est bien compréhensible. C'est pourquoi le parrain + est là, pour vérifier que le paquet parrainé est assez bon pour être inclus + dans Debian. (Notez que si le paquet parrainé est nouveau, les ftpmasters + devront également l'inspecter avant de l'intégrer) +<p> +Effectuer un parrainage en signant simplement l'envoi ou en recompilant le + paquet <strong>n'est définitivement pas recommandé</strong>. Vous devez + construire le paquet source comme si vous vouliez construire l'un de vos + paquets. Rappelez-vous que cela ne change rien si vous avez laissé le nom du + candidat développeur dans le changelog et dans le fichier de + contrôle, l'envoi peut toujours vous être attribué. +<p> +Si vous êtes un gestionnaire de candidature pour un futur développeur, vous + pouvez également être son parrain. Ainsi, vous pourrez vérifier comment le + candidat gère la partie « Tâches et Capacités »<footnote>Tasks and + Skills</footnote> de sa candidature. + + <sect1>Gérer les paquets parrainés +<p> +En envoyant un paquet sponsorisé vers Debian, vous certifiez que le paquet + atteint les standards minimum de Debian. Ceci implique que vous devez + construire et tester le paquet sur votre propre système avant l'envoi. +<p> +Vous ne pouvez pas simplement envoyer un fichier <file>.deb</file> binaire d'un + filleul. En théorie, vous devriez seulement demander le fichier diff et + l'emplacement de l'archive source d'origine et ensuite vous devriez récupérer + le source et appliquer le diff vous-même. En pratique, vous pouvez vouloir + utiliser le paquet source construit par votre filleul. Dans ce cas, vous devez + vérifier qu'il n'a pas modifié les fichiers sources du fichier + <file>.orig.tar.gz</file> qu'il fournit. +<p> +N'ayez pas peur de répondre au filleul et de lui indiquer les changements qu'il + doit faire. Cela prend souvent plusieurs échanges de courriers avant que le + paquet ne soit dans un état acceptable. Être un parrain veut dire être un + mentor. +<p> +Une fois que le paquet a atteint les standards Debian, construisez le paquet + avec +<example> + dpkg-buildpackage -us -uc +</example> + et signez-le avec +<example> + debsign -m <var>"Nom complet</var> <var>votre-adresse-courrier</var> <var>changes-file</var> +</example> + avant de l'envoyer dans le répertoire Incoming. +<p> +Le champ Maintainer du fichier <file>control</file> et le fichier + <file>changelog</file> devraient lister la personne qui a fait l'empaquètement, + c'est-à-dire, le filleul. Celui-ci recevra donc tous les courriers du système + de suivi des bogues (BTS) à propos de son paquet. +<p> +Si vous préférez laisser une trace plus visible de votre travail de parrainage, + vous pouvez ajouter une ligne l'indiquant dans la plus récente entrée du + changelog. +<p> +Vous êtes encouragé à garder un ½il sur le suivi des paquets que vous parrainer + en utilisant <ref id="pkg-tracking-system">. + + <sect1>Recommander un nouveau développeur +<p> +Reportez-vous à la page sur les <url id="&url-newmaint-advocate;" + name="recommandations pour un développeur prospectif"> sur le site web Debian. + + <sect1>Gérer les candidatures des nouveaux candidats +<p> +Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;" name="liste à + vérifier pour les responsables de candidatures"> sur le site web Debian. + + + + <appendix id="tools">Aperçu des outils du responsable Debian +<p> +Cette section contient un aperçu rapide des outils dont dispose le responsable. + Cette liste n'est ni complète, ni définitive, il s'agit juste d'un guide + des outils les plus utilisés. +<p> +Les outils du responsable Debian sont destinés à améliorer le confort des + responsables et libérer leur temps des tâches plus cruciales. Comme le dit + Larry Wall, il y a plus d'une manière de le faire. +<p> +Certaines personnes préfèrent utiliser des outils de haut niveau, d'autres pas. + Debian n'a pas de position officielle sur la question ; tout outil + conviendra du moment qu'il fait le boulot. C'est pourquoi cette section + n'a pas été conçue pour indiquer à chacun quel outil il doit utiliser ou + comment il devrait faire pour gérer sa charge de responsable Debian. Elle + n'est pas non plus destinée à favoriser l'utilisation d'un outil aux + dépens d'un autre. +<p> +La plupart des descriptions de ces outils proviennent des descriptions de leurs + paquets. Vous trouverez plus d'informations dans les documentations de ces + paquets. Vous pouvez aussi obtenir plus d'informations avec la commande + <tt>apt-cache show <package_name></tt>.</p> + + + <sect id="tools-core"> + <heading>Outils de base</heading> + <p> +Les outils suivants sont pratiquement nécessaires à tout responsable.</p> + + + <sect1 id="dpkg-dev"> + <heading><package>dpkg-dev</package></heading> +<p> +Le paquet <package>dpkg-dev</package> contient les outils (y compris + <prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des + paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas + niveau indispensables pour créer et manipuler les paquets ; en tant que + tels, ils sont indispensables à tout responsable Debian. + + <sect1 id="debconf"> + <heading><package>debconf</package></heading> +<p> +Le paquet <package>debconf</package> fournit une interface unifiée pour + configurer les paquets interactivement. Il est indépendant de l'interface et + permet une configuration en mode texte, par une interface HTML ou par boîtes de + dialogues. D'autres types d'interface peuvent être ajoutés sous forme de + modules. +<p> +Vous trouverez la documentation de ce paquet dans le paquet + <package>debconf-doc</package>. +<p> +Beaucoup pensent que ce système devrait être utilisé pour tout paquet + nécessitant une configuration interactive ; reportez-vous à <ref + id="bpp-config-mgmt">. <package>debconf</package> n'est pas requis par la + <em>charte Debian</em> pour le moment ; cependant, cela pourra changer. +</sect1> + + <sect1 id="fakeroot"> + <package>fakeroot</package> +<p> +<package>fakeroot</package> simule les privilèges <em>root</em>. Cela permet de + fabriquer un paquet sans être root (en général, les paquets installent des + fichiers appartenant à <em>root</em>). Si vous avez installé + <package>fakeroot</package>, vous pouvez construire un paquet en tant que + simple utilisateur avec : <tt>dpkg-buildpackage -rfakeroot</tt>. + + + <sect id="tools-lint"> + <heading>Outils du paquet lint</heading> + <p> +Selon le « Free On-line Dictionary of Computing » (FOLDOC), +« lint » est « un outil de traitement de langage C qui contient +beaucoup plus de tests complets sur le code que n'en font habituellement les +compilateurs C. ». Les outils du paquet lint aide les responsables de +paquet à trouver automatiquement des problèmes habituels et des violations de +charte dans leurs paquets</p> + + <sect1 id="lintian"> + <heading><package>lintian</package></heading> +<p> +<package>lintian</package> dissèque les paquets pour y repérer des bogues et des + manquements aux règles de développement. Il contient des tests automatisés pour + vérifier de nombreuses règles et quelques erreurs courantes. +<p> +Vous devriez récupérer la dernière version de <package>lintian</package> depuis + <em>unstable</em> régulièrement et vérifier tous vos paquets. Notez que + l'option <tt>-i</tt> donne des explications détaillées sur la signication de + chaque erreur, la partie concernée dans la charte et le moyen habituel de + régler le problème. +<p> +Veuillez vous reporter à <ref id="upload-checking"> pour plus d'informations sur +comment et quand utiliser Lintian. +<p> + Vous pouvez aussi obtenir un résumé de tous les problèmes reportés par Lintian + sur vos paquets à <url id="&url-lintian;">. Ces rapports contiennent la sortie + de la dernière version de <prgn>lintian</prgn> sur l'ensemble de la + distribution de développement (<em>unstable</em>). +</sect1> + + <sect1 id="linda"> + <heading><package>linda</package></heading> + <p> +<package>linda</package> est un autre vérificateur de paquet. Il est sembable à +<package>lintian</package>, mais il a un jeu de tests différents. Il est écrit +en Python plutôt qu'en Perl.</p> + </sect1> + </sect> + + <sect id="tools-helpers"> + <heading>Aides pour le fichier <file>debian/rules</file></heading> + <p> +Des outils de construction de paquets rendent le processus d'écriture du fichier +<file>debian/rules</file> plus facile. Veuillez voir les <ref +id="helper-scripts"> pour plus d'informations sur les raisons pour lesquelles +ils peuvent être désirables ou non. + + <sect1 id="debhelper"> + <heading><package>debhelper</package></heading> +<p> +Le paquet <package>debhelper</package> regroupe un ensemble de programmes qui + peuvent être utilisés dans <file>debian/rules</file> pour automatiser les + tâches courantes relatives à la fabrication des paquets Debian binaires. Ce + paquet contient des utilitaires pour installer différents fichiers, les + compresser, ajuster leurs droits et intégrer votre paquet dans le système de + menu Debian. +<p> +Au contraire d'autres approches, <package>debhelper</package> est divisé en + plusieurs petits utilitaires qui agissent de manière cohérente. Ce découpage + permet un contrôle des opérations plus fin que d'autres « <em>outils + debian/rules</em> ». +<p> +Il existe aussi un certain nombre de petites extensions + <package>debhelper</package> trop volatiles pour être documentées. Vous en + listerez la plupart en faisant <tt>apt-cache search ^dh-</tt>. +</sect1> + + + <sect1 id="debmake"> + <heading><package>debmake</package></heading> +<p> +<package>debmake</package> — un précurseur de <package>debhelper</package> + — est un assistant moins modulaire pour manipuler le fichier + <file>debian/rules</file>. Il inclut deux programmes principaux : + <prgn>deb-make</prgn>, utile au développeur Debian pour convertir un paquet + source normal (non-Debian) en paquet source Debian, et <prgn>debstd</prgn> qui + regroupe le type de fonction que l'on trouve dans <package>debhelper</package>. +<p> +Le consensus actuel est que l'usage de <package>debmake</package> est + déconseillé au profit de <package>debhelper</package>, mais ce n'est pas une + erreur d'utiliser <package>debmake</package>. +</sect1> + + <sect1 id="dh-make"> + <heading><package>dh-make</package> + <p> +Le paquet <package/dh-make/ contient <prgn/dh_make/, un programme qui crée un +squelette de fichiers nécessaires à la construction d'un paquet Debian à partir +d'une arborescence source. Comme le nom le suggère, <prgn/dh_make/ est une +ré-écriture de <package/debmake/ et ses fichiers modèles utilisent les +programmes dh_* de <package/debhelper/. + <p> +Quoique les fichiers de règles générés par <prgn/dh_make/ constituent en général +une base suffisante pour un paquet fonctionnel, ce ne sont que les +fondations : la charge incombe toujours au responsable d'affiner +les fichiers générés et de rendre le paquet complètement fonctionnel et +en conformité avec la charte. + </sect1> + + <sect1 id="yada"> + <heading><package>yada</package></heading> +<p> +Le paquet <package>yada</package> est un autre assistant pour la création de + paquets. Il utilise un fichier <file>debian/packages</file> pour générer + <file>debian/rules</file> et d'autres fichiers nécessaires dans le + sous-répertoire <file>debian/</file>. +<p> +Remarque : <package>yada</package> est qualifié de « quasiment non + maintenu » par son responsable, Charles Briscoe-Smith. Son usage est donc + déconseillé. +</sect1> + + + <sect1 id="equivs"> + <heading><package>equivs</package></heading> +<p> +<package>equivs</package> est un autre paquet pour faire des paquets. Il est + souvent conseillé pour un usage local, si vous avez besoin de faire un paquet + pour satisfaire des dépendances. Il est aussi parfois utilisé pour faire des + « méta-paquets » qui sont des paquets dont l'unique objet est de + dépendre d'autres paquets.</p> + </sect1> +</sect> + + + <sect id="tools-builders"> + <heading>Constructeurs de paquets</heading> + <p> +Les paquets suivants aident le processus de construction des paquets, en général +en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que gérant le support de +tâches. + + <sect1 id="cvs-buildpackage"> + <heading><package>cvs-buildpackage</package></heading> +<p> +Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou de + récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer + un paquet Debian depuis le référentiel CVS et il assiste le développeur lors de + l'intégration de modifications amonts dans le référentiel. +<p> +Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS pour le + responsable Debian. Il permet de conserver des branches CVS distinctes pour les + distributions <em>stable</em>, <em>unstable</em> et probablement + <em>experimental</em> et de bénéficier des avantages d'un système de contrôle + de version. + </sect1> + + <sect1 id="debootstrap"> + <heading><package>debootstrap</package></heading> +<p> +Le paquet <package>debootstrap</package> vous permet d'amorcer un système Debian + de base à n'importe quel endroit dans votre système de fichier. Par + « système de base », nous entendons le strict minimum nécessaire pour + fonctionner et installer le reste du système. +<p> +Avoir un système comme celui-ci peut vous servir de différentes manières. Vous + pouvez, par exemple, déplacer votre racine dans ce système avec + <prgn>chroot</prgn> pour tester vos dépendances de fabrication. Vous pouvez + aussi l'utiliser pour voir comment se comporte votre paquet quand il est + installé dans un environnement minimum. + </sect1> + + <sect1 id="pbuilder"> + <heading><package>pbuilder</package></heading> +<p> +<package>pbuilder</package> construit un système « chrooté » et + compile des paquets dans ce système. Ceci est très utile pour vérifier que les + dépendances de compilation de votre paquet sont correctes et pour vous assurer + qu'aucune dépendance de construction inutile ou incorrecte n'existe dans le + paquet résultant. </sect1> + + <sect1 id="sbuild"> + <heading><package>sbuild</package></heading> +<p> +<package>sbuild</package> est un autre compilateur automatique. Il peut être + aussi utilisé dans un environnement « chrooté ». Il peut être utilisé + seul ou comme partie d'un environnement de compilation distribué en réseau. + Comme le précédent, c'est une partie du système utilisé par les porteurs pour + construire des paquets binaires pour toutes les architectures disponibles. + Veuillez vous reporter à <ref id="buildd"> pour plus d'informations et à <url + id="&url-buildd;"> pour voir le système en fonctionnement.</p> + </sect1> + </sect> + + <sect id="uploaders"> + <heading>Téléchargeurs de paquets</heading> + <p> +Les paquets suivants aident à automatiser ou à simplifier le processus d'envoi +de paquets dans l'archive officielle.</p> + + <sect1 id="dupload"> + <heading><package>dupload</package></heading> +<p> +Le paquet <package>dupload</package> contient un script du même nom pour mettre + à jour des paquets dans l'archive Debian, tracer ces mises à jour et les + annoncer par courrier électronique automatiquement. Vous pouvez le configurer + pour faire des mises à jour à d'autres endroits et avec d'autres méthodes. + </sect1> + + <sect1 id="dput"> + <heading><package>dput</package></heading> +<p> +Le script <package>dput</package> fait à peu près la même chose que + <package>dupload</package>, mais il le fait différemment. Il a aussi quelques + fonctions supplémentaires telles que la possibilité de vérifier la signature + GnuPG et les sommes de contrôles avant le téléchargement et la possibilité de + démarrer <prgn>dinstall</prgn> en mode simulation (<em>dry-run</em>) après le + téléchargement. + </sect1> + </sect> + + + <sect id="tools-maint-automate"> + <heading>Automatisation de la maintenance</heading> + <p> +Les outils suivants aident à automatiser les différentes tâches de maintenance +par l'ajout des entrées de changelog ou de lignes de signatures, par la +recherche de bogues à partir d'Emacs ou par l'utilisation du plus récent fichier +officiel <file>config.sub</file>.</p> + + + <sect1 id="devscripts"> + <heading><package>devscripts</package></heading> +<p> +Le paquet <package>devscripts</package> contient des scripts et outils qui sont + très utiles pour maintenir vos paquets Debian. Parmi ces scripts, vous + trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui manipulent votre + fichier <file>debian/changelog</file> depuis la ligne de commande et + <prgn>debuild</prgn> qui est construit au-dessus de + <prgn>dpkg-buildpackage</prgn>. L'outil <prgn>bts</prgn> est également très + utile pour mettre à jour l'état des rapports de bogue depuis la ligne de + commande. Le programme <prgn>uscan</prgn> peut être utilisé pour suivre les + nouvelles versions amonts de vos paquets. Le programme <prgn>debrsign</prgn> + peut être utilisé pour signer à distance un paquet avant de l'envoyer, ce qui + est agréable quand la machine sur laquelle vous construisez le paquet est + différente de celle où résident vos clés GPG.</p> +<p> +Vérifiez la page de manuel <manref section="1" name="devscripts"> pour une liste + complète des scripts disponibles. + + <sect1 id="autotools-dev"> + <heading><package>autotools-dev</package></heading> + <p> +Contient les meilleurs pratiques pour des personnes assurant la maintenance de +paquets qui utilisent <prgn>autoconf</prgn> et/ou <prgn>automake</prgn>. +Contient également des fichiers canoniques <file>config.sub</file> et +<file>config.guess</file> qui sont connus pour fonctionner avec tous les +portages Debian.</p> + </sect1> + + <sect1 id="dpkg-repack"> + <heading><package>dpkg-repack</package></heading> + <p> +<prgn>dpkg-repack</prgn> crée un paquet Debian à partir d'un paquet qui +a déjà été installé. Si des changements ont été effectués sur le paquet quand il +a été décompressé (par exemple, des fichiers dans <file>/etc</file> ont été +modifés), le nouveau paquet héritera de ces changements.</p> + <p> +Cet utilitaire peut faciliter la copie de paquet d'un ordinateur vers un autre +ou la re-création de paquets installés sur un système, mais qui ne sont plus +disponibles ailleurs ou pour stocker l'état actuel d'un paquet avant de le +mettre à jour.</p> + </sect1> + + <sect1 id="alien"> + <heading><package>alien</package></heading> + <p> +<prgn>alien</prgn> convertit des paquets binaires entre différents formats de +paquets, y compris des paquets Debian, RPM (RedHat), LSB (Linux Standard Base), +Solaris et Slackware.</p> + </sect1> + + <sect1 id="debsums"> + <heading><package>debsums</package></heading> + <p> +<prgn>debsums</prgn> vérifie des paquets installés par rapport à leur somme de +hachage MD5. Veuillez noter que tous les paquets n'ont pas de sommes MD5 car +elles ne sont pas requises par la charte.</p> + </sect1> + + <sect1 id="dpkg-dev-el"> + <heading><package>dpkg-dev-el</package></heading> +<p> +<package>dpkg-dev-el</package> fournit des macros Emacs Lisp qui apportent une + aide lors de l'édition des fichiers du répertoire <file>debian</file> de votre + paquet. À l'édition de <file>debian/changelog</file>, par exemple, vous + disposez de fonctions pour finaliser une version et consulter la liste des + rapports de bogue ouverts.</p> +</sect1> + + + <sect id="tools-porting"> + <heading>Outils de portage</heading> + <p> +Les outils suivants facilitent le travaile des porteurs et la compilation +croisée.</p> + + <sect1 id="quinn-diff"> + <heading><package>quinn-diff</package></heading> +<p> +<package>quinn-diff</package> est utilisé pour localiser les différences d'une + architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de + l'architecture <var>X</var> doivent être portés sur l'architecture + <var>Y</var>. + + <sect1 id="dpkg-cross"> + <heading><package>dpkg-cross</package></heading> +<p> +<package>dpkg-cross</package> est un outil qui installe les bibliothèques et les + en-têtes nécessaires à une compilation + croisée<footnote><p><em>cross-compilation</em></footnote> d'une manière + similaire à <package>dpkg</package>. De plus, les paquets + <prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été + améliorés pour accepter les compilations croisées. + + <sect id="tools-doc"> + <heading>Documentation et information</heading> + <p> +Les paquets suivants fournissent des informations pour les responsables ou de +l'aide pour construire de la documentation + + <sect1 id="debiandoc-sgml"> + <heading><package>debiandoc-sgml</package></heading> + <p> +<package>debiandoc-sgml</package> fournit la DTD DebianDoc SGML qui est +habituellement utilisée pour la documentation Debian. Ce manuel, par exemple, +est écrit en DebianDoc. Il fournit également des scripts pour construire et +décliner le source en de multiples formats de sortie.</p> + <p> +La documentation sur la DTD peut être trouvée dans le paquet +<package>debiandoc-sgml-doc</package>.</p> + </sect1> + + <sect1 id="debian-keyring"> + <heading><package>debian-keyring</package></heading> + <p> +Contient les clés publiques GPG et PGP des développeurs Debian. Voir <ref +id="key-maint"> et la documentation du paquet pour plus d'informations.</p> + </sect1> + + <sect1 id="debview"> + <heading><package>debview</package></heading> + <p> +<package>debview</package> fournit un mode Emacs pour voir les paquets binaires +Debian. Ceci vous permet d'examiner un paquer sans le décompresser.</p> + </sect1> + </sect> + +<!-- FIXME : tag heading suspect --> +<!-- + <sect id="debget"> + <package>debget</package> +<p> +Le paquet <package>debget</package> contient un script qui peut être + utile pour télécharger des paquets depuis l'archive Debian. Vous pouvez, par + exemple, l'utiliser pour télécharger des paquets sources (bien que <tt>apt-get + source <package></tt> fasse à peu près la même chose). + --> + +<!-- FIXME: add the following + +questionable: + ucf + dpkg-awk + grep-dctrl + d-shlibs + wajig + magpie + apt-dpkg-ref + apt-show-source + apt-show-versions + pdbv + epm + +rejected: + debaux: too new, unmaintained? + dh-make-perl: too new, unmaintained? +--> + +</appendix> + </book> +</debiandoc> -</book> +<!-- Keep this comment at the end of the file +Local variables: +mode: sgml +sgml-omittag:t +sgml-shorttag:t +sgml-minimize-attributes:nil +sgml-always-quote-attributes:t +sgml-indent-step:2 +sgml-indent-data:nil +sgml-parent-document:nil +sgml-exposed-tags:nil +sgml-declaration:nil +sgml-local-catalogs:nil +sgml-local-ecat-files:nil +End: +-->