X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.fr.sgml;h=50822285d5e7f61410436e8ecfb774aad55bcbdc;hb=a2c790cb659d425284a524ce8dfd748dbc84f511;hp=41268c6ebaa18dfb35b95aba986ee9a8a123b17e;hpb=a183b548f0c9cc3baea3f0ee774f4d879a33cbab;p=developers-reference.git diff --git a/developers-reference.fr.sgml b/developers-reference.fr.sgml index 41268c6..5082228 100644 --- a/developers-reference.fr.sgml +++ b/developers-reference.fr.sgml @@ -1,662 +1,3102 @@ - - + + %versiondata; + + %commondata; + + + + + +]> + + + +Référence du développeur Debian + +<author>Adam Di Carlo, responsable actuel <email>aph@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 les membres de la liste +<email>debian-l10n-french@lists.debian.org</email> +<version>Version &version;, &date-fr; (version française 20020506). + +<copyright> + +<copyrightsummary> + Copyright ©1998 – 2002 Adam Di Carlo</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). + +<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. + +<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 detail="sect2"> + + + + + <chapt id="scope">Introduction + + <sect>Portée de ce document + +<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. + +<p> +Les procédures décrites ci-après expliquent entre autre 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 bogues (<ref id="bug-handling">). + +<p> +Les ressources présentées dans ce manuel incluent les listes de diffusion et +les serveurs (<ref id="servers">), 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">). + +<p> +Ce manuel de référence ne présente pas les aspects techniques liés aux paquets +Debian. Il ne décrit pas non plus 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 le <url id="&url-debian-policy;" name="Debian +Policy Manual">. + +<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. + + + + + + <sect>Introduction à la version française + + <sect1>Avertissement + +<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... + +<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 quelque soit le média. + + + <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. + + + <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">). + + <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">). + + <item><em>NMU source</em> : mise à jour indépendante source. Il + s'agit d'une mise à jour indépendante pour un paquet source (<ref + id="nmu-terms">). + + <item><em>NMU binaire</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 remettant en cause 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>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 sensé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 documentation, + site web, création des cédéroms, administration des serveurs... + + <item><em>Upstream version</em> : version amont. Il s'agit du + logiciel tel qu'il est fournit 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 id="new-maintainer">Devenir responsable Debian + -<title>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> + <sect id="getting-started">Pour commencer -<copyright>Copyright ©1997 Christian Schwarz. <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 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 vous pouvez commencer par vous inscrire à la +liste &email-debian-devel;. + +<p> +Pour cela, envoyez un courrier à l'adresse +&email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne +<em>Objet</em><footnote><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'information dans la section <ref +id="mailing-lists">. + +<p> +Vous suivrez les discussions de cette liste (sans poster) pendant quelques +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> sur le réseau +<em>Linux People IRC</em> (c.-à-d. <tt>irc.debian.org</tt>) pourra aussi être +utile. + +<p> +Quand vous avez choisi la manière dont vous contriburez au projet +&debian-formal;, prenez contact avec les responsables Debian qui travaillent +sur des tâches similaires. Ainsi vous pouvez 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 +rustines et des améliorations. + + + <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. + +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 +attentifs pour éviter un acte malveillant. C'est pourquoi nous contrôlons les +nouveaux responsables avant de leur donner un compte sur nos serveurs et les +autoriser à ajouter des paquets dans l'archive. -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). <p> +Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail +et être un bon contributeur. Pour cela, vous pourrez proposer des +rustines 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 +propes paquets. Si vous pouvez aider d'autres responsables en fournissant des +informations sur un bogue ou même avec une rustine, faite-le ! -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> +Pour votre candidature, vous devrez être familiarisé avec la philosophie du +projet Debian et avec sa documentation technique. Il vous faudra aussi une +clé GPG signée par un responsable Debian. Si votre clé GPG n'est pas encore +signée, vous devriez essayer de recontrer un responsable Debian pour le faire. +La <url id="&url-gpg-coord;" name="page de coordination des signatures de clé +GPG"> 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é GPG. Privilégiez tout de même la clé GPG 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.) -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> +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'information sur la gestion de votre clé +publique. -<toc sect> +<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">. -<chapt>Devenir un mainteneur <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. -<sect>Avant de travailler sur un paquet <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à. -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 ? <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 cryptage (comme c'est le cas en +France). &debian-formal; ne nécessite en aucune manière de cryptographie en +tant que cryptage. Si vous vivez dans un pays où l'usage de la cryptographie +pour authentification est interdit, contactez-nous pour que nous prenions des +dispositions particulières. -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> +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. -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> +Quand vous avez trouvez un <em>avocat</em>, quand votre clé GPG est signée et +quand vous avez contribuez pendant un temps au projet vous êtes près pour +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>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. + -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> +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 vous porter +candidat. Vous gagnerez beaucoup de temps si vous êtes bien préparé. + -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</>. + <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). -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> +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. -<sect>S'enregistrer comme un développeur Debian <p> +De plus, si vous avez des paquets prêts à être intégrés mais attendez le +résultat de votre candidature, vous pouvez chercher un parrain qui +téléchargera les paquets pour vous. Les parrains sont des responsables Debian +officiels volontaires pour examiner vos paquets et les télécharger pour vous. +Vous pouvez demander un parrainage à l'adresse <url id="&url-sponsors;">. -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> +Si vous désirez être mentor ou parrain, reportez vous à <ref id="newmaint">. + + + <chapt id="developer-duties">Les charges du responsable Debian + + + <sect id="user-maint">Mise à jour de vos références Debian -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> +Une base de données LDAP contient de nombreuses 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;">. -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). <p> +Vous y tiendrez à jour les informations vous concernant. -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> -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> -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. + <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 +<tt>master.debian.org</tt>. 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">. -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> +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. -<chapt>Les Serveurs Internet <p> +Vous pouvez trouver une présentation approfondie de la gestion de clé Debian +dans la documentation du paquet <package>debian-keyring</package>. + + + + + <sect id="inform-vacation">Prendre des vacances courtoisement -<sect>Les listes de diffusion <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 bloquants pour la distribution, mise à jour de +sécurité...) durant vos vacances. -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> +Il y a deux choses à faire pour informer les autres développeurs. +Premièrement, envoyer 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 ; ajoutez '[VAC] ' à l'objet de votre courrier +pour qu'il soit facilement filtré. -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. <p> +Deuxièmement, il faut mettre +à jour la base de données Debian LDAP et vous signaler « en +vacances » (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 ! + + + + + <sect id="upstream-coordination">Coordination avec les développeurs + amonts -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. <p> +Une grosse 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 une rustine qui corrige ce bogue. +Les utilisateurs et responsables Debian proposent souvent des rustines +pour corriger des bogues amonts, il vous faudra alors évaluer cette +rustine puis la transmettre aux développeurs amonts. -<sect>Le serveur principal <p> +Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un +paquet conforme à la charte Debian, alors vous devriez proposer une +rustine aux développeurs amonts pour qu'elle soit incluse 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. + + + + + + <sect id="rc-bugs">Gestion des bogues bloquants pour la distribution -<sect>Le serveur Ftp et ses miroirs <p> +Les bogues bloquants pour la distribution<footnote>Traduction de l'anglais +<em>Release-critical bug (RCB)</em></footnote> sont les bogues 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>. +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. Vous devez être +conscient que certains 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. + + + + <sect id="qa-effort">L'effort d'assurance qualité -<sect>Les serveurs WWW <p> +Même s'il y a un groupe de personnes dédié à l'assurance qualité, cette +activité ne leur est pas réservée. Vous pouvez participer à cet effort en +éliminant, autant que faire se peut, tout bogue de vos paquets et en observant +les remarques émises par <prgn>lintian</prgn> (voir <ref id="lintian-reports">). Si cela +ne vous semble pas possible, il faudrait songer à abandonner certains +de vos paquets (voir <ref id="orphaning">). Vous pouvez aussi +demander l'aide d'autres personnes pour rattraper votre retard dans la liste +des bogues (vous pouvez demander de l'aide sur les listes &email-debian-qa; +et &email-debian-devel;). + -<chapt>Le travail quotidien du développeur de paquet + <sect id="mia-qa">Responsables injoignables <p> +Si vous remarqué qu'un paquet manque d'attention, assurez-vous que le +responsable est toujours actif et continuera à travailler sur son paquet. +Essayez de le contacter. -<sect>Annoncer les nouveaux paquets <p> +Si vous n'obtenez pas de réponse après quelques semaines, rassemblez toutes +les informations utiles sur ce responsable. Commencez par consulter la <url +id="http://db.debian.org" name="base de données des développeurs"> pour +déterminer si le responsable est en vacances et quand il a été vu pour la +dernère fois. Listez les paquets importants gérés par ce responsable et les +bogues bloquants pour la distribution qui concernent ces paquets. -<sect>Envoyer les nouveaux paquets +<p> Envoyez toutes ces informations à &email-debian-qa; pour que l'équipe +d'assurance qualité prenne les mesures nécessaires. + + <sect>Démissionner <p> +Si vous choisissez de quitter le projet Debian, procédez comme suit : + + <enumlist> + <item> + Abandonnez tous vos paquets comme décrit dans <ref id="orphaning">. + + <item> + Envoyez un courrier électronique à &email-debian-private; indiquant + comment vous quittez le projet. + + <item> + Signalez aux responsables du porte-clés Debian que vous quittez le + projet en écrivant à &email-debian-keyring;. + + </enumlist> + + + <chapt><heading>Au dela de la mise en paquet</heading> -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. <p> +Le projet Debian nécessite bien plus que la mise en paquet des logiciels et la +maintenance de ces paquets. Ce chapitre décrit d'autres types de contributions +— contributions souvent d'importance critique pour le projet Debian +— au dela de la création et de la maintenance de paquet. -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>. <p> +En tant qu'organisation basée sur le volontariat, Debian compte sur +l'appréciation de ces membres qui choisiront sur quoi ils veulent travailler +et sur quoi il est le plus important de passer son temps. + + <sect id="newmaint"><heading>Interaction avec les nouveaux + responsables</heading> -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. <p> +Le succès de Debian dépend de sa capacité à attirer et retenir des volontaires +de talent. Si vous êtes un responsable expérimenté, nous vous recommandons de +vous impliquer dans le recrutement de nouveaux responsables. Cette section +décrit comment aider les nouveaux responsables. + + <sect1 id="sponsoring">Parrainer un paquet -<sect>Mises à jour par Intérim <p> +Parrainer un paquet signifie télécharger un paquet pour un responsable qui +n'a pas la possibilité de le faire lui même : un nouveau responsable. +Parrainer un paquet signifie aussi en accepter la responsabilité. -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. <p> +Si vous êtes prêt à parrainer un paquet, vous pouvez vous inscrire à <url +id="&url-sponsors;">. -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. <p> +Les nouveaux responsables ont souvent quelques difficultés pour créer des +paquets Debian — ce qui est bien compréhensible. C'est là que le parrain +intervient. Il vérifie que le paquet est suffisamment bon pour intégrer +la distribution. Notez que si le paquet est nouveau les administrateurs de +l'archive l'inspecteront aussi avant de le laisser entrer. -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/. <p> +Parrainer un paquet en se contentant de signer la livraison ou de recompiler +le paquet n'est <strong>franchement pas recommandé</strong>. Vous devez +construire le paquet source comme vous le feriez avec vos propres paquets. +N'oubliez pas qu'il sera possible de voir que vous avez téléchargé un paquet +même si vous avez laissé le nom du futur responsable dans les fichiers +<em>control</em> et <em>changelog</em>. -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/. <p> +Si vous êtes responsable de candidature pour un nouveau responsable, vous +pouvez aussi être son parrain. Ainsi vous pouvez aussi vérifier comment le +candidat traite la partie « Tâches et compétences<footnote>'Tasks and +Skills'</footnote> » de leur candidature. + + <sect1>Aider un nouveau responsable -<sect>Changement de mainteneur <p> +Consultez la page <url id="&url-newmaint-advocate;" name="Aider un futur +responsable"> sur le site du projet Debian. + + + + <sect1>Suivre la candidature d'un nouveau responsable -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/. <p> +Consultez la page <url id="&url-newmaint-amchecklist;" name="Aide mémoire du +responsable de candidature"> sur le site du projet Debian. + + + + + + + <chapt id="servers">Listes de diffusion, serveurs et autres machines -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. <p> +Dans ce chapitre vous trouverez une très brève description des listes de +diffusion Debian, des principaux serveurs Debian et des autres machines +auxquelles vous aurez accès en tant que développeur. + + + + <sect id="mailing-lists">Les listes de diffusion -<chapt>Le système de suivi de bogues <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. +Le serveur de liste de diffusion est <tt>&lists-host;</tt>. 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><em>Subject</em> en +anglais</footnote> pour vous abonner à la liste ou <tt>unsubscribe</tt> pour +vous désabonner. Vous trouverez des instructions plus détaillées pour vous +abonner et vous désabonner aux adresses <url +id="&url-debian-lists-subscribe;">, <url id="&url-debian-lists-txt;"> ou +localement dans le fichier &file-mail-lists; si vous avez installé le paquet +<package>doc-debian</package>. + <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. +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> +Les principales listes de diffusion Debian sont : + <list compact> + <item> &email-debian-devel; ; + <item> &email-debian-policy; ; + <item> &email-debian-user; ; + <item> &email-debian-private; ; + <item> &email-debian-announce; et + <item> &email-debian-devel-announce;. + </list> + +Un développeur devrait, au minimum, être inscrit à la liste +&email-debian-devel-announce;. - <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>. <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. Nous déconseillons l'usage des correspondances +croisées (envoyer le même message à plusieurs listes). -<sect>Manipuler les rapports de bogues <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é, quelqu'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 disponible sur la toile. Vous pouvez les consulter en +visitant le répertoire <file>~debian/archive/debian-private</file> avec votre +compte sur <tt>master.debian.org</tt>. -<sect1>Clore un rapport de bogue <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. - 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>). <p> +Comme toujours sur internet, éliminez les lignes inutiles quand vous citez +le message auquel vous répondez. Plus généralement, respectez +les conventions habituelles lorsque vous envoyez des messages. - 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 ». <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. +Les archives des listes de diffusion sont disponibles en ligne à l'adresse +<url id="&url-lists-archives;">. + + + + + <sect id="server-machines">Les serveurs 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. +Les serveurs Debian sont bien connus et hébergent les fonctions +critiques du projet Debian. Tout développeur se doit de savoir ce qu'ils sont +et à quoi ils servent. + <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, vous trouverez +l'adresse d'un responsable pour cette machine à la page <url +id="&url-devel-machines;">. Si votre problème n'est pas lié au système +(paquet à supprimer 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. -<sect1>Messages suivis + + + <sect1 id="servers-master">Le serveur maître + <p> +<tt>master.debian.org</tt> est le serveur maître du système de suivi des +bogues (BTS<footnote>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 le gaspillage de temps machine. - 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. <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. +Tous les développeurs Debian ont un compte sur <tt>master.debian.org</tt>. +Prenez grand soin de votre mot de passe. Évitez les méthodes de connexion et +de téléchargement qui envoient votre mot de passe en clair sur internet. + +<p> +Si vous rencontrez un problème avec <tt>master.debian.org</tt> tel qu'un +disque plein, une activité suspecte ou autre, envoyez un courrier +électronique à &email-debian-admin;. + + + + + <sect1 id="servers-ftp-master">Le serveur ftp-master + +<p> +Le serveur ftp-master (<tt>ftp-master.debian.org</tt> ou <tt> +auric.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 contre 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 id="servers-www">Le serveur WWW + +<p> +Le serveur web principal, <tt>www.debian.org</tt>, est aussi connu sous le nom +<tt>klecker.debian.org</tt>. Tous les développeurs ont un compte sur cette +machine. + +<p> +Si vous désirez publier quelques informations spécifiques à Debian sur la +toile, +vous pouvez le faire en les déposant dans le sous-répertoire +<file>public_html</file> de votre répertoire personnel sur +<tt>klecker.debian.org</tt>. Toute information déposée à cet endroit est +accessible à l'adresse <tt>http://people.debian.org/~<var>user-id</var>/</tt>. +Vous devriez préférer ce serveur aux autres car les répertoires +<file>public_html</file> du serveur <tt>klecker.debian.org</tt> sont +sauvegardés. Ce n'est pas le cas sur les autres serveurs. N'utilisez pas ces +serveurs pour publier des informations sans rapport avec le projet Debian +avant d'en avoir obtenu la permission. Pour toute question supplémentaire, +adressez-vous à la liste &email-debian-devel;. + +<p> +Si vous rencontrez un problème avec un serveur web Debian, vous devez +généralement envoyer un rapport de bogue contre 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. + + + + + <sect1 id="servers-cvs">Le serveur CVS + +<p> +Le serveur <tt>cvs.debian.org</tt> est aussi connu sous le nom +<tt>klecker.debian.org</tt> (déjà présenté plus haut). 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 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 propriétaire du +répertoire racine et pourquoi vous en avez besoin. + + + + + <sect1 id="servers-mirrors">Les miroirs des serveurs Debian + +<p> +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 +ces 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 (et en général 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. + + + + + <sect id="other-machines">Les autres machines Debian + +<p> +Vous aurez peut-être accès à d'autres machines Debian. Vous pouvez utiliser +ces machines pour des tâches en rapport avec le projet Debian. Soyez gentils +avec les administrateurs et ne consommez pas des montagnes d'espace disque, de +bande passante ou de temps machine sans en avoir d'abord reçu l'autorisation. +En général, ces machines sont gérés par des volontaires et sont utilisées pour +des activités de portage. + +<p> +Vous trouverez une liste des autres machines mises à la disposition des +développeurs Debian à l'adresse <url id="&url-devel-machines;">. + + + + + + <chapt id="archive">L'archive Debian + + <sect>Aperçu + +<p> +La distribution &debian-formal; est composée d'un grand nombre de paquets Debian +(fichiers <tt>.deb</tt> : à peu près &number-of-pkgs;) et de quelques +autres fichiers (documentation, images des disquettes d'installation, +etc.). + +<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, +<tt>dists/</tt> et <tt>pool/</tt>. 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>. Le +découpage en sous-répertoires est identique d'un répertoire de distribution à +l'autre ; nous nous contenterons donc d'exposer ce découpage pour la +distribution <em>stable</em>. Les fichiers <tt>Packages</tt> et +<tt>Sources</tt> qui se trouvent dans les répertoires de distribution peuvent +faire référence à des fichiers du répertoire <tt>pool/</tt>. + + +<p> +Le répertoire <tt>dists/stable</tt> contient trois répertoires nommés +<tt>main</tt>, <tt>contrib</tt> et <tt>non-free</tt>. + +<p> +Dans chacune de ces sections se trouve un répertoire contenant les paquets +sources (<tt>source/</tt>), un répertoire pour chaque architecture supportée +(<tt>binary-i386/</tt>, <tt>binary-m68k/</tt>, etc) et un répertoire pour les +paquets indépendants de l'architecture (<tt>binary-all/</tt>). + +<p> +La section <em>main</em> contient d'autres répertoires destinés aux images de +disquettes et à quelques documentations essentielles pour installer la +distribution Debian sur une architecture particulière (<tt>disk-i386/</tt>, +<tt>disk-m68k/</tt>, etc). + +<p> +Les répertoires <tt>binary-*/</tt> et <tt>source/</tt> sont à nouveau +divisés en <em>sous-sections</em>. + + + + <sect>Les sections + +<p> +La section <em>main</em> constitue la <strong>distribution &debian-formal; +officielle</strong>. Elle est officielle parce qu'elle est conforme à toutes +nos recommandations. Les deux autres sections divergent de ces recommandations +à différents degrés, elles ne font donc pas officiellement partie de +&debian-formal;. + +<p> +Chaque paquet de la section <em>main</em> doit être conforme aux <url +id="&url-dfsg;" name="Debian Free Software Guidelines"> et à toutes les autres +recommandations décrites dans <url id="&url-debian-policy;" name="le Debian +Policy Manual">. Les DFSG<footnote><em>Debian Free Software +Guidelines</em></footnote> constituent notre définition de <em>logiciel +libre</em>. Reportez-vous au <em>Debian Policy Manual</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. - <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> +<p> +Le <em>Debian Policy Manual</em> donne des définitions plus précises pour ces trois sections. +Les paragraphes précédants 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. -<sect1>Enregistrer que vous avez fait suivre un rapport de bogue <p> +D'un autre coté, un distributeur de cédérom pourra facilement vérifier +individuellement les licences des paquets de la section <em>non-free</em> et +ajouter autant de paquets qu'il est autorisé à le faire sur ses cédéroms (dans +la mesure où cela varie énormément d'un distributeur à l'autre ce travail ne +peut être fait par les développeurs Debian). + + + + <sect>Les architectures - 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 : <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 supporte encore +plus d'architectures dont ARM et UltraSPARC. Puisque Linux supporte ces +architectures, Debian a décidé qu'il devait les supporter aussi. 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>, et <em>arm</em>. - 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 ». <p> +&debian-formal; 1.3 est disponible uniquement pour <em>i386</em>. Debian 2.0 +supporte les architectures <em>i386</em> et <em>m68k</em>. Debian 2.1 +supporte les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et +<em>sparc</em>. Debian 2.2 ajoute le support de l'architecture +<em>powerpc</em>. - 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. <p> +Vous trouverez des informations destinées aux développeurs à propos d'un +portage particulier sur la page <url id="&url-debian-ports;" name="Portage +Debian">. + + + + + <sect>Les sous-sections - 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. <p> - - Vous pouvez aussi manipuler l'information « forwarded to » en envoyant des - messages à <tt>control@bugs</tt>. +Les sections <em>main</em>, <em>contrib</em> et <em>non-free</em> sont +divisées en sous-sections pour simplifier le processus d'installation et la +maintenance de l'archive Debian. Ces sous-sections ne sont pas définies +formellement, à l'exception peut-être de la sous-section <em>base</em>. +Elles existent pour simplifier l'organisation des paquets et la navigation +dans la liste des paquets disponibles. Reportez-vous à la distribution +courante pour connaître la liste des sous-sections disponibles. + <p> - -<sect1>Messages de résumé à « debian-devel » +Notez qu'avec l'introduction de la nouvelle organisation de l'archive (voir le +répertoire racine <em>pool/</em>), les sous-sections matérialisées par des +répertoires pourraient disparaître à l'avenir. Elles seront cependant +conservées dans le champ <tt>Section</tt> de l'en-tête des paquets. + + + + + <sect>Les paquets + <p> +Il existe deux types de paquets Debian : les paquets sources et les +paquets binaires. - 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. <p> +Les paquets sources sont constitués de deux ou trois fichiers : - 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é. + <list compact> + <item> + un fichier <tt>.dsc</tt> et un fichier <tt>.tar.gz</tt> ou, + + <item> + un fichier <tt>.dsc</tt>, un fichier <tt>.orig.tar.gz</tt> et un + fichier <tt>.diff.gz</tt>. + + </list> + <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 <tt>.tar.gz</tt> qui +contient les sources du programme. Si un paquet est distribué ailleurs, le +fichier <tt>.orig.tar.gz</tt> 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 <tt>.diff.gz</tt> contient les modifications faites par le responsable +Debian. -<sect1>Rouvrir, réassigner et manipuler des bogues <p> +Le fichier <tt>.dsc</tt> 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). + + + + + <sect>Les répertoires des distributions - 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>. <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 <tt>pool</tt> à la racine de l'archive Debian. - Le format de ces messages est décrit dans les sections - suivantes. <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 <tt>/pub/debian</tt>. -<sect1>Fonctionnalités plus ou moins obsolètes -(étude des sujets) <p> +Une distribution est composée de paquets Debian sources et binaires et des +fichiers <tt>Sources</tt> et <tt>Packages</tt> correspondants. Ces derniers +contiennent la description de tous les paquets. Les premiers sont +conservés dans le répertoire <tt>pool/</tt> tandis que les seconds sont +conservés dans le répertoire <tt>dists/</tt> de l'archive (pour des questions +de compatibilité descendante) + + + + + <sect1 id="sec-dists"><em>Stable</em>, <em>testing</em> et + <em>unstable</em> - 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 »). <p> +Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire +<tt>dists/stable</tt>), une distribution appelée <em>testing</em> (dans le +répertoire <tt>dists/testing</tt>) et une distribution appelée +<em>unstable</em> (dans le répertoire <tt>dists/unstable</tt>). Ceci reflète +le processus de développement du projet Debian. + +<p> +Les développements se font sur la distribution <em>unstable</em><footnote> +<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 <em>instable</em>. - 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> +<p> +Les paquets sont copiés de <em>unstable</em> vers <em>testing</em> s'ils +satisfont certains critères. Pour entrer dans la distribution <em>testing</em> +un paquet doit faire partie de l'archive depuis deux semaines et ne doit pas +avoir de bogue bloquant pour la distribution (<em>RC bug</em>). Passé cette +période, le paquet sera installé dans <em>testing</em> dès que les paquets +dont il dépend y seront. Ce processus est automatique. Vous pouvez consulter +quelques notes sur ce système ainsi que les <tt>update_excuses</tt> (qui +indiquent quels paquets sont candidats, lesquels ne le sont pas et pourquoi) à +l'adresse <url id="&url-testing-maint;">. - 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. <p> +Après une période de développement, quand le responsable de +distribution<footnote><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 quelques 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> +est renommée <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>). -<sect1>Projets futurs <p> +Ce cycle de développement est basé sur l'idée que la distribution +<em>instable</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 ajoutées individuellement à 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 <tt>proposed-updates</tt>. 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é (« 1.3 » devient « 1.3r1 », +« 2.0r2 » devient « 2.0r3 » et ainsi de suite). - Le champ « Package: » de l'en-tête devrait devenir obligatoire ; - actuellement, en cas d'oubli, seul un avertissement est généré. <p> +Notez que pendant la période de gel les développements continuent sur la +distribution instable car cette distribution reste en place. + + + <sect1><em>Experimental</em> -<sect1>Fonctionnalité obsolète « X-Debian-PR: quiet » <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 ont de grandes chances 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 qui 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>. - 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> +<p> +Si un logiciel risque de causer des dégats importants, il sera +sûrement préférable de le mettre dans la distribution <em>experimental</em>. +Un système de fichier compressé, par exemple, devrait probablement aller dans +<em>experimental</em>. - 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>). <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. -<sect>L'interface de contrôle par courrier <p> +Quelques logiciels expérimentaux peuvent 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>. - 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. <p> +Un nouveau logiciel qui ne risque pas d'endommager le système ira +directement dans <em>unstable</em>. - 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> +Une alternative à <em>experimental</em> consiste à utiliser vos pages +personnelles sur le serveur <tt>people.debian.org</tt> +(<tt>klecker.debian.org</tt>). + + <sect id="codenames">Les noms de distribution - 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. <p> +Chaque distribution Debian diffusée a un nom : Debian 1.1 s'appelle +« buz » ; 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 +supportées ou pour lesquelles la distribution n'a pas encore été diffusée. Ces +architectures doivent rejoindre les architectures supportées à une date +future. - 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 ». <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. -Voici la liste des commandes disponibles : -<taglist> -<tag><tt> close bugnumber</tt> -<item> - Ferme le rapport de bogue « #bugnumber ». <p> +Si nous avions nommé le répertoire qui contient la prochaine version àc +diffuser « testing », il aurait fallu le renommer +« stable » au moment de la diffusion, ce qui aurait forcé les +miroirs FTP à re-télécharger la distribution complète (qui est plutôt +volumineuse). - 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. <p> +D'un autre coté, si une distribution s'appelle <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.) -<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). <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. -<tag><tt> reopen bugnumber [originator-address|=]</tt> -<item> - Rouvre « #bugnumber » si il a été fermé. <p> +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. + + + + + + <chapt id="upload">La mise à jour d'un paquet + + + <sect>Nouveaux paquets - 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. <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. - 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. <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 <tt>wnpp</tt>. 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. - 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. <p> +Le sujet de votre rapport de bogue devra être <ITP<footnote><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>whishlist</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. -<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. <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">). -<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. <p> +Il y a plusieurs raisons qui nous poussent à demander aux responsables d'annoncer +leurs intentions : + + <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> + Cela permet aux autres responsables d'en savoir plus sur le nouveau + paquet que ne le permettent la description d'une ligne et l'habituelle + entrée « <em>Initial release</em> » que l'on trouve dans les + fichiers <em>changelog</em> qui sont postés sur + <tt>debian-devel-changes</tt>. + + <p> + 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. + + <p> + 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 nouveautés du + projet. + + </list> + + + <sect id="changelog-entries"> + <heading>Ajouter une entrée à debian/changelog</heading> -<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). <p> +Les modifications que vous apportez au paquet doivent être tracées dans le +fichier <file>debian/changelog</file>. Ces traces doivent donner une +description concise des changements, expliquer pourquoi (si ce n'est pas +clair) et indiquer si des rapports de bogues sont 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. - 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é. <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'information sur la structure de ce +fichier dans le <em>Debian Policy Manual</em> section +« <file>debian/changelog</file> ». -<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. <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">. - 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. <p> +Par convention, l'entrée changelog d'un paquet qui contient une nouvelle +version amont ressemble à : +<example> + * new upstream version +</example> - 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. <p> +Quelques outils peuvent vous aider à créer des entrées et finaliser +<file>changelog</file> pour une livraison — voir les sections <ref +id="devscripts"> et <ref id="dpkg-dev-el">. + + <sect id="upload-checking">Vérifier le paquet avant la mise à jour - 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 -<p> - - 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. -<p> - -<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. <p> +Avant de mettre à jour votre paquet vous ferez quelques tests de base. Vous +devrez au moins faire les tests suivants (il vous faut une ancienne version +du paquet) : + <list compact> + <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 <tt>postrm</tt> et <tt>prerm</tt>. + + <item> + Désinstallez le paquet et réinstallez-le. + + </list> + + + + <sect>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 <tt>.changes</tt>. 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 <tt>changes</tt> 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 le +<url id="&url-debian-policy;" name="Debian Policy Manual"> 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">). + + + <sect1>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 <tt>tar</tt> de cette version amont doit être +téléchargé et mentionné dans le fichier <tt>.changes</tt>. Par la suite, ce +fichier <tt>tar</tt> sera utilisé pour générer les fichiers <tt>diff</tt> et +<tt>.dsc</tt> 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 <tt>tar</tt> 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 <tt>tar</tt> des sources +originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les +fichiers <tt>.dsc</tt> et <tt>diff</tt> de la mise à jour, utilisez un fichier +<tt>tar</tt> identique à l'octet près à celui sur le serveur. Si pour une +raison ou pour une autre il y a une différence, la nouvelle version de ce +fichier doit à nouveau être incluse dans la mise à jour (en utilisant l'option +<tt>-sa</tt> par exemple). + + + + + <sect1 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 y a trois valeurs possibles pour ce champ : <em>stable</em>, +<em>unstable</em> et <em>experimental</em> . En temps +normal, les paquets sont téléchargés dans <em>unstable</em>. + +<p> +Vous devriez éviter de combiner <em>stable</em> avec d'autres cibles à cause +des problèmes potentiels de dépendance de bibliothèque (pour votre paquet et +pour les paquets fabriqués par le démon de compilation pour les autres +architectures). Se reporter à <ref id="upload-stable"> pour savoir quand et +comment faire une mise à jour de <em>stable</em>. + +<p> +Notez bien que combiner <em>experimental</em> avec quelque distribution +que ce soit n'a pas de sens. + + + <sect2 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 <tt>proposed-updates</tt> 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> requière 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 probleme 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 causer un bogue plus +tard. 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 la rustine correspondante de la +nouvelle version amont et à l'appliquer à l'ancienne (faire un +portage (<em>backport</em>) de la rustine. + +<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>proposed-updates</em> et décidera si votre +paquet peut être inclus dans la distribution <em>stable</em>. Soyez précis +(et, si nécéssaire, généreux) quand vous décrivez, dans le fichier changelog, +vos changements pour une livraison vers <em>stable</em> sinon le paquet ne +sera pas considéré. + + + + <sect id="uploading">Mettre à jour un paquet + + + <sect1 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</ftpsite>, ce que vous devez 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 +<tt>&us-upload-dir;</tt>. Si vous utilisez un FTP anonyme, +placez-les dans <ftppath>/pub/UploadQueue/</ftppath>. Attention, il est +préférable de transférer le fichier <tt>changes</tt> en dernier. Dans le cas +constraire, 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 <tt>&us-upload-dir;</tt>. + +<p> +<em>Note :</em> ne téléchargez pas de paquet contenant un logiciel +protégé par des brevets américains sur <tt>ftp-master</tt>, de même n'y +téléchargez pas de paquet cryptographique qui appartiendrait a +<em>contrib</em> ou <em>non-free</em>. 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>. Les livraisons de ces logiciels doivent +aller sur <tt>non-us</tt> (voir <ref id="upload-non-us">). 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 <package>dupload</package> ou <package>dput</package> pourront +vous faciliter le travail lors du téléchargement. Ces programmes, bien +pratique, sont configurés par défaut pour +se connecter par FTP sur les serveurs <tt>ftp-master</tt>, +<tt>chiark</tt> et <tt>erlangen</tt>. Ils peuvent aussi être configurés pour +utiliser <prgn>ssh</prgn> ou <prgn>rsync</prgn>. Se reporter à <manref +name="dupload" section="1">, <manref name="dupload" section="5"> et <manref +name="dput" section="1"> pour en savoir plus. + +<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> + + + + + + <sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt> + (pandora) + +<p> +Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des +exportations américain 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 <tt>&non-us-upload-dir;</tt> (<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 <ftppath>/pub/UploadQueue/</ftppath>. + +<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à disponible 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 ftp-master ou l'une de ses files d'attente décrites +plus haut. + + +<p> +Le <em>Debian Policy Manual</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>. + + + <sect1>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 +<tt>Incoming</tt> 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. + + + + <sect1>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 : + +<p> + <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 <tt>Incoming</tt> 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 +<tt>.changes</tt> 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 <tt>.changes</tt> 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. + + + + + + <sect1>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;">. + + + + + <sect 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 <tt>.changes</tt> +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 : + +<p> +<tt> &email-debian-changes;.</tt> + +<p> +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;. + +<p> +Le programme <prgn>dupload</prgn> est suffisamment intelligent pour déterminer +où devra aller l'annonce et pour envoyer le courrier sur la bonne liste. Voir <ref +id="dupload">. + + + + + <sect 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>, en particulier, sont +installés 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 patients. + +<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 bogues 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 plus loin). + + + + + <sect1 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 aurez envie de 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 le fichier <em>override</em>, reportez-vous à <manref +name="dpkg-scanpackages" section="8">, &file-bts-mailing; et &file-bts-info;. + + + + + <chapt id="nmu">Mise à jour indépendante + +<p> +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 font partie du travail normal des porteurs qui +compilent les paquets pour d'autres architectures (voir <ref id="porting">). +Nous faisons aussi des mises à jour indépendantes quand un développeur Debian +corrige le paquet d'un autre développeur pour éliminer un trou de sécurité +ou un bogue paralysant. 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 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écie 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, un fichier <em>diff</em> +modifié ou, plus rarement, des nouveaux sources amonts. + +<p> +Une mise à jour indépendante binaire est 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>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 « mise à jour +indépendante » seul, il s'agit des deux types de livraisons. + + + + + + <sect 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 rustines qui le méritent au +système de suivi des bogues. Les responsables apprécient presque toujours les +rustines et les rapports de bogue soignés. + + + <sect 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. stable, instable ou +experimentale). 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 faille de sécurité est détectée, un +paquet corrigé doit être livré le plus tôt possible. Dans ce cas, un membre de +l'équipe de sécurité Debian<footnote>Debian Security officer</footnote> +entrera en contact +avec le responsable du paquet pour s'assurer qu'un paquet corrigé sera livré dans +un délai raisonnable (moins de 48 heures). Si le mainteneur ne peut +fournir une mise à jour suffisamment vite ou s'il ne peut être joint à temps, +l'équipe de sécurité pourra corriger le paquet (i.e. faire une mise à jour +indépendante source). + +<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 +devrez 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. + +<p> +Les mises à jour indépendantes sont aussi acceptable pour la distribution +instable mais seulement en dernier ressort +ou avec une autorisation. Essayez d'abord ce qui suit et si cela ne fonctionne +pas il est probablement correct de faire une mise à jour indépendante +<em>(NMU)</em> : + +<p> + <list compact> + <item> + Vérifiez que le bogue est bien référencé dans le système de suivi des + bogues. S'il n'y est pas, faites un rapport de bogue. + + <item> + Envoyez un courrier au responsable du paquet et proposez votre aide + pour corriger le bogue. Donnez-lui quelques jours. + + <item> + Lancez-vous. Corrigez le bogue et envoyez votre rustine au système de + suivi des bogues. Construisez le paquet et testez-le comme décrit dans + la section <ref id="upload-checking">. Utilisez le paquet chez vous. + + <item> + Attendez une réponse pendant quelques semaines. + + <item> + Envoyez un courrier au responsable lui demandant son accord pour faire + une mise à jour indépendante <em>(NMU)</em>. + + <item> + Vérifiez une nouvelle fois que votre modification n'a pas d'effet de + bord inattendu et qu'elle est aussi minimaliste et peu intrusive que + possible. + + <item> + Attendez une réponse une semaine encore. + + <item> + Faites votre mise à jour indépendante comme décrit dans la section + <ref id="nmu-guidelines">. + + </list> + + + + + + + <sect 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 une rustine aussi petite 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 faits lors d'une mise à jour indépendante. + + + + + + <sect1 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 ». Notez que pour +faire cela vous devrez utiliser <prgn>dpkg-buildpackage</prgn> avec l'option +<tt>-sa</tt> pour le forcer à utiliser le nouveau paquet source (par défaut il +reconnaît les numéros de révisions « 0 » ou « 1 » — il +n'est pas suffisamment intelligent pour reconnaître « 0.1 »). + +<p> +Attention, les porteurs qui ne font que recompiler les paquets pour d'autres +architectures n'ont pas besoin de renuméroter les paquets. Les porteurs ne +doivent utiliser de nouveaux numéros de version que s'ils modifient les +paquets sources qu'ils recompilent, c'est-à-dire s'ils font une mise à jour +indépendante source et non une mise à jour indépendante binaire. + + + + + + <sect1 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> + + + + + + <sect1 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> +En cas de simple recompilation du paquet, le processus diffère +suivant que vous agissez en tant que porteur ou pas. Si vous faites une mise +à jour indépendante qui ne nécessite rien de plus qu'une recompilation et +n'agissez pas en temps que porteur (i.e. une nouvelle bibliothèque partagée +est disponible, un bogue a été corrigé dans <package>debhelper</package>), +vous devez tout de même ajouter une entrée dans le fichier <em>changelog</em>; +il y aura donc une modification. Si vous êtes porteur, vous êtes probablement +en train de faire une mise à jour indépendante binaire. (Note : ce système ne +tient pas compte des porteurs qui font des recompilations — tenez cela pour +une faiblesse de notre système de gestion des paquets.) + +<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 reconnait 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 changelog). 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 une rustine contenant toutes les +modifications que vous avez faites. +Le responsable officiel pourra choisir d'appliquer la rustine, 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 rustines 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>. + + + + + + + <sect1 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">. + +<p> +En fait, toutes les prescriptions de la section <ref id="upload"> sont +applicables ici, y compris l'obligation d'annoncer la mise à jour sur la liste +idoine. + +<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 <tt>.changes</tt>. + + + + + <chapt id="porting">Le portage + +<p> +Debian supporte 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 paquet 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. + + + + + <sect 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 bogues 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 une +<em>checklist</em> de 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 pour vérifier cela 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 cette + environnement. + <p> + Consultez le <url id="&url-debian-policy;" name="Debian Policy + Manual"> pour en savoir plus sur les dépendances de fabrication. + <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 du + <url id="&url-debian-policy;" name="Debian Policy Manual">. Choisir + la valeur « i386 » est la plupart du temps incorrect. + + <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ésarchive correctement. En utilisant le résultat de ce test, + construisez votre paquet binaire à l'aide de la commande + <tt>dpkg-buildpackage</tt>. + + <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> + 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> + Ne vous appuyez pas sur une installation préexistante de votre paquet + (un sous-cas de la remarque précédente). + + <item> + Si possible, ne vous appuyez pas sur une particularité présente dans + un compilateur précis ou dans 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> + 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>. + + </enumlist> + + + + + <sect 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 mise à +jour indépendante 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 une mise à jour indépendante binaire, ne faites pas de changement +dans les sources. Vous n'avez pas besoin de modifier les fichiers du paquet +source (cela inclut <file>debian/changelog</file>). + +<p> +La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante : +<tt>dpkg-buildpackage -B -e<var>adresse-porteur</var></tt>. Bien sûr, +remplacez <var>adresse-porteur</var> par votre adresse électronique. Cette +commande construira les portions du paquet qui dépendent de l'architecture, en +utilisant la cible <em>binary-arch</em> de <file>debian/rules</file>. + + + <sect1 id="recompile-nmu-versioning"> + <heading>Numéro de version des mises à jour indépendantes + binaires</heading> + +<p> +Parfois il est nécessaire de recompiler des paquets quand d'autres paquets, +tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez +changer le numéro de version pour que le système de comparaison des numéros de +version fonctionne correctement. 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 ». + + + + + <sect1 id="source-nmu-when-porter"> <heading>Quand faire une mise à + jour indépendante source pour un portage ?</heading> + +<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. + +<!-- +FIXME: commented out until I can work out how to upload to testing directly + +Une correction +cruciale (i.e. rendre un paquet compilable sur une architecture supportée par +la prochaine distribution) peut être installée <em>sans</em> délai pour la +distribution gelé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. + + + + + <sect>Outils pour les porteurs + +<p> +Il y a plusieurs outils pour le travail de portage. Cette section contient +une courte description de ces outils ; reportez-vous à la documentation de +leurs paquets ou aux références citées ci-après pour une description complète. + + + + + <sect1 id="quinn-diff"> + <heading><package>quinn-diff</package> + +<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="buildd"> + <heading><package>buildd</package> + +<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. Il regroupe un ensemble de composants très utiles, +continuellement utilisés mais non encore mis en paquet, tels que +<prgn>andrea</prgn>, <prgn>sbuild</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 +enthousiasmés par 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 la Debian — qui peuvent être ou ne pas être +intéressantes pour tous (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. + + + + + <sect1 id="dpkg-cross"> + <heading><package>dpkg-cross</package> + +<p> +<package>dpkg-cross</package> est un outil qui installe les bibliothèques et +les entêtes nécessaires à une compilation croisée<footnote><em>cross-compilation</em> +</footnote> d'une manière similaire à <package>dpkg</package>. De plus +<prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été +améliorés pour supporter les compilations croisées. + + + + + + <chapt id="archive-manip"> + <heading>Déplacer, effacer, renommer, adopter et abandonner des + paquets</heading> + +<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. + + + + + <sect>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 LGP GNU ; dans ce cas le paquet doit être déplacé dans la section +<tt>main</tt> ou <tt>contrib</tt><footnote> Reportez-vous au <url +id="&url-debian-policy;" name="Debian Policy Manual"> 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 au +<url id="&url-debian-policy;" name="Debian Policy Manual"> pour en savoir +plus. Lisez attentivement le rapport d'installation qui vous sera envoyé lors +de l'archivage de votre paquet. Si pour une raison ou une autre le paquet +est toujours à son ancien emplacement, envoyez un rapport de bogue sur le +pseudo-paquet <tt>ftp.debian.org</tt> demandant la suppression dudit paquet. +Décrivez précisément vos manipulations car il pourrait s'agir d'un bogue dans +le logiciel de gestion de l'archive. + +<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">. + + + + + <sect 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 demandant sa suppression. N'oubliez pas de +préciser de quelle distribution le paquet doit être supprimé. + +<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>package</var> </tt> vous +indiquera, entre autres, les paquets qui dépendent de <var>package </var>. + + <sect1>Supprimer des paquets dans <tt>Incoming</tt> +<p> +Par le passé, il était possible de supprimer un paquet de <tt>Incomming</tt>. +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 +replacée par la nouvelle. Toutefois, si vous testez correctement vos paquets, +le besoin d'en remplacer un ne devrait pas être trop fréquent. + + + + <sect>Remplacer ou renommer un paquet + +<p> +Il peut vous arriver de vous tromper en nommant un paquet et avoir besoin de le +renommer. Dans ce cas, vous devrez intervenir en deux étapes. D'abord, +modifiez votre fichier <file>debian/control</file> pour que votre paquet +renommé remplace et entre en conflit avec le nom de paquet que vous voulez +remplacer. Reportez-vous au <url id="&url-debian-policy;" name="Debian Policy +Manual"> 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é. +l'archive, faites un rapport de bogue concernant le pseudo-paquet +<tt>ftp.debian.org</tt> et demandant la suppression du paquet mal nommé. + + + + + + <sect 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 <tt>wnpp</tt>. Le titre de votre rapport de bogue devra être +« <tt>O<footnote><em>Orphaned</em> : abandonné.</footnote>: +<var>paquet</var> — <var>courte description</var></tt> » pour indiquer +que le paquet est orphelin. 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 <tt>wnpp</tt>, titrer +« <tt>RFA<footnote><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 précédemment. + +<p> +Reportez-vous à la page WNPP<footnote><em>Work-needing and prospective +packages</em> : paquets en souffrance et paquets souhaités.</footnote> <url +id="&url-wnpp;"> pour en savoir plus. + + + + + + <sect id="adopting">Adopter un paquet + +<p> +Une liste des paquets en attente de nouveau responsable est disponible à la +page <url id="&url-wnpp;" name="Work-Needing and Prospective Packages">. Si +vous voulez prendre en charge un paquet de cette liste reportez-vous à la page +susmentionnée 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 une prise d'otage. 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;. + +<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, envoyez un courrier électronique à +&email-override; pour pouvoir recevoir les rapports de bogue. + + + + + + <chapt id="bug-handling">Gérer les bogues + + + + <sect>Superviser les rapports de bogues + +<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. + +<p> +Les responsables interagissent avec le système de suivi des bogues en +utilisant l'adresse électronique <tt>bugs.debian.org</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 : + +<p> +<example> +# Synthèse hebdomadaire des rapports de bogue qui me concernent +&cron-bug-report; +</example> + +<p> +Remplacez <var>address</var> par votre adresse officielle de responsable +Debian. + + + + + <sect id="submit-bug">Ouvrir un rapport de bogue + +<p> +En tant que responsable Debian, vous trouvez des bogues dans d'autres paquets +En tant que responsable Debian, vous trouvez des bogues dans d'autres paquets, +ou bien vous voulez réassigner à d'autres paquets des rapports de bogue +concernant vos paquets. La page d'aide du <url id="&url-bts-control;" +name="système de suivi des bogues"> vous explique comment procéder. + +<p> +Nous vous encourageons à ouvrir des rapports de bogue s'il y a des problèmes. +Essayez de soumettre ces rapports depuis un compte utilisateur où vous pouvez +recevoir du courrier. Ne les envoyez pas en tant que <em>root</em>. + +<p> +Vérifiez que le bogue n'a pas encore été déclaré. Essayez de faire un travail +propre en déclarant le bogue et en l'envoyant à la bonne adresse. + +<p> +Pour faire encore mieux, vous pouvez consulter d'autres paquets, grouper les +bogues qui ont été rapportés plusieurs fois ou affecter la gravité +<em>corrigé</em> (i.e. <em>fixed</em>) à un rapport dont le bogue a été +corrigé. Attention, quand vous n'êtes ni le rapporteur d'un bogue ni le +responsable du paquet vous ne devez pas clore le rapport (à moins que vous +n'ayez l'autorisation du responsable). + + + + + <sect>Répondre à des rapports de bogues + +<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). + +<p> +Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la +commande <em>close</em> à l'adresse : + +<p> +<tt> &email-bts-control;</tt> + +<p> +Si vous le faites, le rapporteur n'aura aucun retour sur la clôture de son +rapport. + + + + + <sect id="upload-bugfix">Quand les rapports sont 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é. Pourtant 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> +Si vous utilisez une version récente de <package>dpkg-dev</package> et que +vous remplissez convenablement le fichier <file>changelog</file>, le logiciel de +maintenance de l'archive fermera les rapports de bogue automatiquement. Tout ce +que vous avez à faire est de respecter la syntaxe suivante dans votre fichier +<file>debian/changelog</file> : +<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 manpage. Closes: #98725. +</example> + +Techniquement parlant, l'expression régulière suivante est utilisée : +<example> + /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig +</example> + +L'auteur préfère la syntaxe <tt>(closes: Bug#<var>XXX</var>)</tt>, car elle +est facilement repérable dans le fichier <file>changelog</file>. + +<p> +Si vous voulez fermer un rapport de bogue manuellement — à l'ancienne — il +suffit d'envoyer le fichier <tt>.changes</tt> à l'adresse +<email>XXX-done@bugs.debian.org</email> où <var>XXX</var> est le numéro du +bogue. + + + + + <sect id="lintian-reports">Les rapports Lintian + +<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. Vous +pouvez aussi chercher votre adresse électronique dans la page de <url +id="&url-lintian;" name="rapport lintian">. Cette page, mise à jour +automatiquement, contient les rapports lintian concernant la +dernière version de la distribution (en général <em>unstable</em>) générés +avec la dernière version de <package>lintian</package>. + + + + + + <sect>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 +paquet — 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. + + + + + + + + <chapt 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 devrait utiliser ou comment il devrait faire pour gérer sa +charge de responsable Debian. Elle n'est pas non plus destinée à +favoriser l'usage 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'information dans les +documentations de ces paquets. +Vous pouvez aussi obtenir plus d'information avec la commande <tt>apt-cache +show <var>package_name</var></tt>. + + + + <sect id="dpkg-dev"> + <heading><package>dpkg-dev</package> + +<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. + + + + + <sect id="lintian"> + <heading><package>lintian</package> + +<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. L'utilisation de +<package>lintian</package> a déjà été discutée dans <ref id="upload-checking"> +et <ref id="lintian-reports">. + + <sect id="debconf"> + <heading><package>debconf</package></heading> + +<p> +Le paquet <package>debconf</package> fournit une interface consistante 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. <package>debconf</package> n'est +pas requis par le <em>Debian Policy Manual</em> pour le moment ; cela +pourra changer dans le futur. + + + <sect id="debhelper"> + <heading><package>debhelper</package> + +<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 outils « <em>debian/rules</em> ». + +<p> +Il existe aussi un certain nombre de petites extensions +<package>debhelper</package> trop éphémères pour être documentées. Vous en +listerez la plupart en faisant <tt>apt-cache search ^dh-</tt>. + + + + <sect id="debmake"> + <heading><package>debmake</package> + +<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>. + + + + <sect id="yada"> + <heading><package>yada</package> + +<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é. + + + + <sect id="equivs"> + <heading><package>equivs</package> + +<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. + + + + <sect id="cvs-buildpackage"> + <heading><package>cvs-buildpackage</package> + +<p> +Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou +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 amont dans le référentiel. + +<p> +Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS +pour le responsable. Il permet de conserver des branches CVS distinctes +pour les distributions <em>stable</em>, <em>unstable</em> et probablement +<em>experimental</em>. + + + <sect id="dupload"> + <heading><package>dupload</package> + +<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. + + + <sect id="dput"> + <heading><package>dput</package> +<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 <tt>dinstall</tt> en mode simulation (<em>dry-run</em>) après le +téléchargement. + + <sect id="fakeroot"> + <heading><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 +utilisateur : <tt>dpkg-buildpackage -rfakeroot</tt>. + + + <sect id="debootstrap"> + <heading><package>debootstrap</package> + +<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écéssaire 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. + + + <sect id="devscripts"> + <heading><package>devscripts</package> + +<p> +Le paquet <package>devscripts</package> contient quelques scripts et outils +que vous trouverez peut-être 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>. + + + + <sect id="dpkg-dev-el"> + <heading><package>dpkg-dev-el</package> + +<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. + + + <sect id="debget"> + <heading><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 +<var>package</var></tt> fasse à peu près la même chose). + + + +<!-- FIXME: add the following + dpkg-awk + alien + dpkg-repack + grep-dctrl + pbuilder --> + + + + - 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. -<p> - - 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. -<p> -</taglist> -<p> - -<sect>Résumé des commandes disponibles -<p> - -<sect1>Synopsis des commandes disponibles à « request@bugs.debian.org » -<p> - -<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 -<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> -</list> -<p> </book> +</debiandoc> + +<!-- 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: +--> +<!-- vim:set tw=78:ts=8: -->