-<list>
-<item>
- Ciblez la bonne distribution dans votre
- fichier <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de
- <tt>stable-security</tt> et pour <em>testing</em>, c'est
- <tt>testing-security</tt> et pour l'ancienne distribution stable, c'est
- <tt>oldstable-security</tt>. Ne ciblez ni
- <var>distribution</var>-proposed-updates, ni <tt>stable</tt> !
-</item>
-<item>L'envoi devra avoir « urgency=high ».
-</item>
-<item>
- Fournissez des entrées de changelog descriptives et complètes. D'autres
- personnes se baseront dessus pour déterminer si un bogue particulier a été
- corrigé. Incluez toujours une référence externe, de préférence un
- identifiant CVE, pour qu'elle puisse être recoupée. Incluez la même
- information dans le changelog pour <em>unstable</em> pour qu'il soit clair
- que le même bogue a été corrigé car cela est très utile pour vérifier que
- le bogue a été corrigé pour la prochaine version stable. Si aucun
- identifiant CVE n'a encore été assigné, l'équipe de sécurité en demandera
- un pour qu'il puisse être inclus dans le paquet et dans le changelog.
-</item>
-<item>
- Fournissez des entrées de changelog descriptives et complètes. D'autres
- personnes se baseront dessus pour déterminer si un bogue particulier a été
- corrigé. Quand cela est possible, incluez une référence externe, de
- préférence, un identifiant CVE, pour qu'elle puisse être recoupée.
-</item>
-<item>
- Assurez-vous que le numéro de version est correct. Il doit être plus élevé
- que celui du paquet actuel, mais moins que ceux des paquets des versions
- des distributions suivantes. En cas de doute, testez-le avec <tt>dpkg
- --compare-versions</tt>. Soyez attentif à ne pas ré-utiliser un numéro de
- version que vous auriez déjà utilisé pour un précédent envoi.
- Pour <em>testing</em>, il doit y avoir un numéro
- de version supérieur dans <em>unstable</em>. S'il n'y en a pas encore (par
- exemple, si <em>testing</em> et <em>unstable</em> ont la même version),
- vous devez envoyer une nouvelle version vers <em>unstable</em> en premier.
-</item>
-<item>
- Ne faites pas d'envoi de source seul si votre paquet possède un ou
- plusieurs paquets binary-all (n'utilisez pas l'option <tt>-S</tt> de
- <prgn>dpkg-buildpackage</prgn>). L'infrastructure <prgn>buildd</prgn> ne
- construira pas ceux-ci. Ce point s'applique aux envois de paquets normaux
- également.
-</item>
-<item>
- Sauf si la source amont a été envoyée auparavant à security.debian.org (par une
- précédente mise à jour de sécurité), construisez le paquet avec la source
- amont complète (<tt>dpkg-buildpackage -sa</tt>). S'il y a déjà eu un
- précédent envoi à security.debian.org, vous pouvez faire un envoi sans le
- paquet source (<tt>dpkg-buildpackage -sd</tt>).
-</item>
-<item>
- Assurez-vous d'utiliser exactement le même nom <file>*.orig.tar.gz</file>
- que celui utilisé dans l'archive normale, sinon il ne sera pas possible de
- déplacer plus tard le correctif de sécurité dans l'archive principale.
-</item>
-<item>
- Compilez le paquet sur un système
- propre, dont tous les paquets appartiennent à la distribution pour laquelle vous
- construisez le paquet. Si vous n'avez pas un tel système, vous pouvez
- utiliser l'une des machines de debian.org (voir <ref
- id="server-machines">) ou mettez en place un chroot (voir <ref id=
- "pbuilder"> et <ref id="debootstrap">).
-</item>
-</list>
-
- <sect2 id="bug-security-upload">Mettre à jour le paquet corrigé
-<p>
-Vous <em>NE</em> devez <em>PAS</em> envoyer un paquet dans la file d'attente des envois de sécurité
-(oldstable-security, stable-security, etc.)
-sans l'accord préalable de l'équipe de sécurité. Si le paquet ne remplit pas
-exactement les exigences de l'équipe, il causera beaucoup de problèmes, ainsi
-que des délais dans la gestion de l'envoi indésirable.
-<p>
-Vous <em>NE</em> devez <em>PAS</em> envoyer votre correction dans
-<em>proposed-updates</em> sans vous coordonner avec l'équipe de sécurité. Les
-paquets seront copiés de security.debian.org dans le répertoire
-<file>proposed-updates</file> automatiquement. Si un paquet avec le même numéro
-de version ou un numéro plus grand est déjà installé dans l'archive, la mise à
-jour de sécurité sera rejetée par le système d'archive. Ainsi, la distribution
-<em>stable</em> se retrouvera à la place sans la mise à jour de sécurité de ce
-paquet.
-<p>
-Une fois que vous avez créé et testé le nouveau paquet et qu'il a été approuvé
-par l'équipe de sécurité, il doit être envoyé pour être installé dans les
-archives. Pour les envois de sécurité, l'adresse d'envoi est
-<tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt>.
-
-<p>
-Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera
-automatiquement recompilé pour toutes les architectures et stocké pour
-vérification par l'équipe de sécurité.
-
-<p>
-Les envois en attente d'acceptation ou de vérification ne sont accessibles que
-par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des
-correctifs pour des problèmes de sécurité qui ne peuvent pas encore être
-diffusés.
-
-<p>
-Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur
-security.debian.org ainsi que dans le répertoire
-<var>distribution</var>-proposed-updates qui convient sur ftp-master ou dans
-l'archive non-US.
-
- <sect id="archive-manip">
- <heading>Déplacer, effacer, changer le nom, adopter et abandonner des paquets
-<p>
-Certaines manipulations de l'archive ne sont pas possibles avec le processus
- de mise à jour automatisé. Elles sont appliquées manuellement par les
- développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.
-
- <sect1 id="moving-pkgs">Déplacer des paquets
-<p>
-Il se peut qu'un paquet puisse changer de section. Une nouvelle version d'un paquet
- de la section <tt>non-free</tt> pourrait, par exemple, être distribuée sous
- licence GNU GPL ; dans ce cas, le paquet doit être déplacé dans la section
- <tt>main</tt> ou <tt>contrib</tt><footnote><p>Reportez-vous à la <url
- id="&url-debian-policy;" name="charte Debian"> pour savoir dans quelle section
- un paquet doit être classé.</footnote>.
-<p>
-Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez les
- informations de contrôle du paquet pour le placer dans la section désirée et
- téléchargez à nouveau votre paquet dans l'archive. Reportez-vous à la <url
- id="&url-debian-policy;" name="charte Debian"> pour en savoir plus. Si votre
- nouvelle section est valide, il sera déplacé automatiquement. Si ce n'est pas
- le cas, contactez les responsables ftp pour comprendre ce qui s'est passé.
-<p>
-Si vous avez besoin de modifier la sous-section de l'un de vos paquets
- (<tt>devel</tt> ou <tt>admin</tt> par exemple), la procédure est légèrement
- différente. Modifiez la sous-section dans le fichier de contrôle de votre
- paquet et téléchargez-le. Il vous faudra ensuite demander la modification du
- fichier <em>override</em> comme décrit dans la section <ref
- id="override-file">.
-
-
- <sect1 id="removing-pkgs">Supprimer des paquets
-<p>
-Si, pour une raison ou une autre, vous avez besoin de supprimer un paquet de
- l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile, que
- l'on conservait pour des raisons de compatibilité), il vous faudra envoyer un
- rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
- demander sa suppression. N'oubliez pas de préciser de quelle distribution le
- paquet doit être supprimé. Normalement, vous ne devriez avoir à supprimer que
- des paquets d'<em>unstable</em> ou de <em>experimental</em>. Les paquets de
- <em>testing</em> ne sont pas supprimés directement. Ils sont plutôt enlevés
- automatiquement après que le paquet a été supprimé d'<em>unstable</em> et
- si aucun paquet de <em>testing</em> n'en dépend.
-<p>
-Vous devez également détailler les raisons justifiant cette demande. Ceci a pour
- but d'éviter les suppressions non désirées et de garder une trace de la raison
- pour laquelle un paquet a été supprimé. Par exemple, vous pouvez fournir le nom
- du paquet qui remplace celui à supprimer.
-<p>
-Vous ne pouvez demander la suppression d'un paquet que si vous en
- êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez
- obtenir l'accord de son responsable.
-<p>
-Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
- autres développeurs sur la liste &email-debian-devel;. Le programme
- <prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
- utile. La commande <tt>apt-cache showpkg <var>paquet</var> </tt> vous
- indiquera, entre autres, les paquets qui dépendent de <var>paquet</var>.
- Le retrait de paquets orphelins est discuté sur &email-debian-qa;.
-<p>
-Une fois que le paquet a été supprimé, les bogues du paquet doivent être gérés.
- Soit ils sont réattribués à un autre paquet dans le cas où le code actuel a
- évolué en un autre paquet (par exemple, <tt>libfoo12</tt> a été supprimé parce
- que <tt>libfoo13</tt> le remplace) ou ils sont fermés si le logiciel ne fait
- simplement plus partie de Debian.
-
- <sect2>Supprimer des paquets dans <tt>Incoming</tt>
-<p>
-Par le passé, il était possible de supprimer un paquet de <file>Incoming</file>.
- Cependant, ce n'est plus possible depuis la mise en place du nouveau système
- de file d'attente. Il vous faudra télécharger une nouvelle version de votre
- paquet avec un numéro de version plus élevé que celui que vous voulez
- remplacer. Les deux versions seront installées dans l'archive mais seule la
- plus récente sera accessible dans <em>unstable</em> car la précédente sera
- immédiatement remplacée par la nouvelle. Toutefois, si vous testez
- correctement vos paquets, le besoin d'en remplacer un ne devrait pas être
- trop fréquent.
-
- <sect1>Remplacer un paquet ou changer son nom
-<p>
-Si vous vous trompez en nommant un paquet, vous devrez intervenir en deux
- étapes pour changer son nom. D'abord, modifiez
- votre fichier <file>debian/control</file> pour que votre nouveau paquet
- remplace et entre en conflit avec l'ancien paquet que vous voulez remplacer
- (reportez-vous à la <url id="&url-debian-policy;" name="charte Debian"> pour
- les détails). Une fois que votre paquet est installé dans l'archive, faites un
- rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
- demandez la suppression du paquet mal nommé. N'oubliez pas de réattribuer
- correctement les bogues du paquet en même temps.
-<p>
-D'autres fois, vous pouvez commettre une erreur en construisant le paquet et
-vous désirez le remplacer. La seule façon de faire est d'incrémenter le numéro de
- version et d'envoyer une nouvelle version. L'ancienne version expirera de la
- façon habituelle. Notez que ceci s'applique à chaque partie de votre paquet, y
- compris les sources : si vous désirez remplacer l'archive source amont de
- votre paquet, vous devez l'envoyer avec un numéro de version différent. Une
- possibilité simple est de remplacer <file>foo_1.00.orig.tar.gz</file> par
- <file>foo_1.00+0.orig.tar.gz</file>. Cette restriction donne à chaque fichier
- du site ftp un nom unique, ce qui aide à garantir la consistance dans le réseau
- des miroirs.
-
- <sect1 id="orphaning">Abandonner un paquet
-<p>
-Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres et
- faire le nécessaire pour qu'il soit marqué <em>abandonné</em> (i.e.
- <em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
- Group &orphan-address;</tt> dans le champ <tt>maintainer</tt> du paquet et
- faire un rapport de bogue sur le pseudo-paquet <package>wnpp</package>. Le
- titre de votre rapport de bogue devrait être
- « <tt>O<footnote><p><em>Orphaned</em> : abandonné.</footnote>:
- <var>paquet</var> — <var>courte description</var></tt> » pour
- indiquer que le paquet est abandonné. La gravité du bogue sera
- <em>normale</em> ; si le paquet a une priorité standard ou supérieure,
- elle devrait être <em>importante</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 vous avez simplement l'intention de donner le paquet, mais que vous pouvez
-conserver sa maintenance pour le moment, vous devriez à la place soumettre un
-rapport de bogue sur <package>wnpp</package> et l'intituler <tt>RFA: <var>paquet</var> --
-<var>description courte</var></tt>.
-<tt>RFA</tt> veut dire <em>Request For Adoption</em> (demande d'adoption).
- <p>
-Vous pouvez trouver plus d'informations sur les <url id="&url-wnpp;" name="pages
- web WNPP"><footnote><p><em>Work-needing and prospective
- packages</em> : paquets en souffrance et paquets
- souhaités.</footnote>.
-
- <sect1 id="adopting">Adopter un paquet
-<p>
-Une liste des paquets en attente de nouveau responsable est disponible à la page
- <url id="&url-wnpp;" name="paquets en souffrance et paquets souhaités">. Si
- vous voulez prendre en charge un paquet de cette liste, reportez-vous à la page
- mentionnée ci-dessus pour connaître la procédure à suivre.
-<p>
-Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
- correct — ce serait un détournement de paquet. Vous pouvez prendre
- contact avec le responsable actuel et lui demander si vous pouvez prendre en
- charge ce paquet. Si vous avez le sentiment qu'un responsable est parti sans
- prévenir depuis un moment, veuillez vous reporter à <ref id="mia-qa">).
-<p>
-Généralement, vous ne pouvez pas adopter un paquet sans l'accord du responsable
-actuel. Même s'il vous ignore, ce n'est pas une raison pour le faire. Les
-plaintes à propos des responsables devraient être portées sur la liste de
-diffusion des développeurs. Si la discussion ne se termine pas par une
-conclusion positive et que le problème est de nature technique, considérez de
-porter le cas à l'attention du comité technique (voir la <url name="page web du
-comité technique" id="&url-tech-ctte;"> pour plus d'information).
-<p>
-Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de suivi
- des bogues indique que vous êtes le responsable du paquet. Cela se produira
- automatiquement une fois que vous aurez installé une nouvelle version du paquet
- dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut prendre
- quelques heures après le téléchargement. Si vous pensez ne pas avoir de mise à
- jour à faire pour un moment, vous pouvez utiliser le <ref
- id="pkg-tracking-system"> pour recevoir les rapports de bogue. Cependant,
- assurez-vous que cela ne pose aucun problème à l'ancien responsable de
- continuer à recevoir les bogues durant ce temps.
-
- <sect id="porting">Le portage
-<p>
-Debian accepte un nombre croissant d'architectures. Même si vous n'êtes pas un
- porteur et même si vous n'utilisez qu'une architecture, il est de votre
- responsabilité de développeur d'être attentif aux questions de
- portabilité. C'est pourquoi il est important que vous lisiez ce chapitre
- même si vous n'êtes pas un porteur.
-<p>
-Porter un paquet consiste à faire un paquet binaire pour des architectures
- différentes de celle du paquet binaire fait par le responsable du paquet.
- C'est une activité remarquable et essentielle. En fait, les porteurs sont
- à l'origine de la plupart des compilations de paquets Debian. Pour un
- paquet binaire <em>i386</em>, par exemple, il faut compter une
- recompilation pour chaque autre architecture, soit un total de
- &number-of-arches; recompilations.
-
-
- <sect1 id="kind-to-porters">Être courtois 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, la première et la plus importante chose est de répondre rapidement aux rapports de bogues et
- remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
- étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine manière).
- Merci pour votre indulgence envers des rapports de bogue succincts ou peu
- clairs ; faites de votre mieux pour éliminer le problème.
-<p>
-Les problèmes les plus couramment rencontrés par les porteurs sont causés par
- des erreurs de mise en paquet dans le paquet source. Voici un
- pense-bête pour les choses auxquelles vous devez être attentif :
-<enumlist>
- <item>
- Vérifiez que les champs <tt>Build-Depends</tt> et
- <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
- corrects. Le meilleur moyen de le vérifier est d'utiliser le paquet
- <package>debootstrap</package> pour créer un environnement
- <em>unstable</em> <em>chrooté</em> (voir <ref id="debootstrap">). Dans
- cet environnement <em>chrooté</em>, il faudra installer le paquet
- <package>build-essential</package> et tous les paquets mentionnés dans
- les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
- Ensuite, vous essayerez de fabriquer votre paquet dans cet
- environnement. Ces étapes peuvent être automatisées en utilisant le
- programme <prgn>pbuilder</prgn> qui est fourni par le paquet de même
- nom (voir <ref id="pbuilder">).
- <p>
- Si vous n'arrivez pas à installer un environnement <em>chrooté</em>,
- <prgn>dpkg-depcheck</prgn> pourra peut-être vous aider (voir <ref
- id="dpkg-depcheck">).
- <p>
- Consultez la <url id="&url-debian-policy;" name="charte Debian"> pour en
- savoir plus sur les dépendances de fabrication.
- </item>
- <item>
- Ne choisissez pas d'autres valeurs que <em>all</em> ou <em>any</em> pour
- le champ architecture sans avoir de bonnes raisons pour le faire. Trop
- souvent, les développeurs ne respectent pas les instructions de la <url
- id="&url-debian-policy;" name="charte Debian">. Choisir la valeur
- « i386 » est la plupart du temps incorrect.
- </item>
- <item>
- Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
- <var>paquet</var>.dsc</tt> pour vous assurer que le paquet se
- décompresse correctement. En utilisant le résultat de ce test,
- construisez votre paquet binaire à l'aide de la commande
- <prgn>dpkg-buildpackage</prgn>.
- </item>
- <item>
- Vérifiez que les fichiers <file>debian/files</file> et
- <file>debian/substvars</file> ne sont pas dans votre paquet source. Ils
- doivent être effacés par la cible <em>clean</em> de
- <file>debian/rules</file>.
- </item>
- <item>
- Assurez-vous que vous ne vous appuyez pas sur des éléments de
- configuration ou des logiciels installés ou modifiés localement. Par
- exemple, vous ne devriez jamais appeler des programmes du répertoire
- <file>/usr/local/bin</file> ou de répertoires équivalents. Essayez de ne
- pas vous appuyer sur des logiciels configurés de manière spéciale.
- Essayez de construire votre paquet sur une autre machine, même s'il
- s'agit de la même architecture.
- </item>
- <item>
- Ne vous appuyez pas sur une installation préexistante de votre paquet
- (un sous-cas de la remarque précédente).
- </item>
- <item>
- Si possible, ne vous appuyez pas sur une particularité présente dans un
- compilateur précis ou dans une certaine version d'un compilateur. Si
- vous ne pouvez pas faire autrement, assurez-vous que les dépendances de
- fabrication reflètent bien cette restriction. Dans ce cas, vous cherchez
- sûrement les problèmes car quelques architectures pourraient choisir un
- compilateur différent.
- </item>
- <item>
- Vérifiez que votre fichier <file>debian/rules</file> distingue les
- cibles <em>binary-arch</em> et <em>binary-indep</em> comme l'exige la
- charte Debian. Vérifiez que ces cibles sont indépendantes l'une de
- l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer l'une de
- ces cibles avant d'invoquer l'autre. Pour vérifier cela, essayez
- d'exécuter <tt>dpkg-buildpackage -B</tt>.
- </item>
-</enumlist>
-
-
- <sect1 id="porter-guidelines">Instructions pour les mises à jour des
- porteurs
-<p>
-Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez
- de la chance et votre travail est facile. Cette section s'applique dans ce
- cas ; elle décrit comment construire et installer correctement votre
- paquet binaire dans l'archive Debian. Si vous devez modifier le paquet pour le
- rendre compilable sur votre architecture cible vous devez faire une mise à jour
- des sources, consultez la section <ref id="nmu-guidelines">.
-<p>
-Pour un envoi de portage, ne faites pas de changement dans les sources. Vous
- n'avez pas besoin de modifier les fichiers du paquet source (cela inclut le
- fichier <file>debian/changelog</file>).
-<p>
-La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante :
- <tt>dpkg-buildpackage -B -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
- <var>adresse-porteur</var> par votre adresse électronique. Cette commande
- construira les parties du paquet qui dépendent de l'architecture, en utilisant
- la cible <em>binary-arch</em> de <file>debian/rules</file>.
-<p>
-Si vous travaillez sur une machine Debian pour vos efforts de portage et que
-vous devez signer votre envoi localement pour son acceptation dans l'archive,
-vous pouvez exécuter <prgn>debsign</prgn> sur votre fichier
-<file>.changes</file> pour qu'il soit signé de manière commode ou utilisez le
-mode de signature à distance de <prgn>dpkg-sig</prgn>.
-
- <sect2 id="binary-only-nmu">
- Mises à jour indépendantes binaires ou recompilations
-<p>
-Parfois, l'envoi du portage initial pose problème car l'environnement dans lequel
- le paquet a été construit n'était pas bon (bibliothèques plus à jour ou
- obsolètes, mauvais compilateur, etc.). Il se peut que vous ayez à le recompiler
- dans un environnement mis à jour. Cependant, dans ce cas, vous devez changer
- le numéro de version pour que les mauvais anciens paquets soient remplacés dans
- l'archive Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
- s'ils n'ont pas un numéro de version supérieur à celui actuellement
- disponible).
-<p>
-Vous devez vous assurez que votre mise à jour indépendante binaire ne rend pas
- le paquet non installable. Cela peut arriver si un paquet source génère des
- paquets dépendants et indépendants de l'architecture qui dépendent
- les uns des autres <em>via</em> $(Source-Version).
-
-<p>
- Malgré les modifications nécessaires du changelog, ce type de mise
- à jour reste une mise à jour indépendante binaire — il n'est pas
- nécessaire de reconsidérer le statut des paquets binaires des autres
- architectures pour les marquer périmés ou à recompiler.
-<p>
-Ces recompilations nécessitent des numéros de version « magiques »
- pour que le système de maintenance de l'archive comprennent que, bien qu'il y
- ait une nouvelle version, il n'y a pas eu de modification des sources. Si vous
- ne faites pas cela correctement, les administrateurs de l'archive rejetteront
- votre mise à jour (car il n'y aura pas de code source associé).
-<p>
-Cette « magie » associée à une mise à jour par recompilation est déclenchée en
- utilisant un troisième nombre dans la partie debian du numéro de version. Si,
- par exemple, la dernière version du paquet que vous recompilez était
- « 2.9-3 », votre mise à jour portera le numéro
- « 2.9-3.0.1 ». Si cette version était « 3.4-2.1 » votre
- mise à jour portera le numéro « 3.4-2.1.1 ».
-<p>
-De manière similaire aux envois du porteur initial, la façon correcte d'invoquer
- <prgn>dpkg-buildpackage</prgn> est <tt>dpkg-buildpackage -B</tt> pour ne
- construire que les parties dépendant de l'architecture du paquet.
-
-
- <sect2 id="source-nmu-when-porter">
- Quand faire une mise à jour indépendante source pour un portage ?
-<p>
-Les porteurs qui font des mises à jour indépendantes sources suivent
- généralement les instructions de la section <ref id="nmu"> tout comme les
- non-porteurs. Les délais d'attente sont cependant plus courts car les
- porteurs doivent manipuler un grand nombre de paquets. À nouveau, la
- situation diffère selon la distribution visée. Elle varie également selon que
- l'architecture est candidate pour inclusion dans la prochaine version
- stable ; les responsables de diffusion décident et annoncent quelles
- architectures sont candidates.
-<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). Pour les envois de <em>stable</em> ou
- <em>testing</em>, veuillez tout d'abord vous coordonner avec l'équipe de
- diffusion appropriée.
-
-<p>
-Deuxième différence, les porteurs qui font des mises à jour indépendantes
- sources doivent choisir une gravité <em>sérieuse</em> (i.e. <em>serious</em>)
- ou supérieure quand ils envoient leur rapport au système de suivi des bogues.
- Ceci assure qu'un paquet source unique permet de produire un paquet binaire
- pour chaque architecture supportée au moment de la sortie de la distribution.
- Il est très important d'avoir un paquet source et un paquet binaire pour
- toutes les architectures pour être conforme à plusieurs licences.
-<p>
-Les porteurs doivent éviter d'implémenter des contournements pour des bogues de
- l'environnement de compilation, du noyau ou de la libc. Quelques fois, ces
- contournements sont inévitables. Si vous devez faire quelque chose de ce
- genre, marquez proprement vos modifications avec des <tt>#ifdef</tt> et
- documentez votre contournement pour que l'on sache le retirer une fois que le
- problème aura disparu.
-<p>
-Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de leur
- travail pendant le délai d'attente. Ainsi, d'autres personnes peuvent
- bénéficier du travail du porteur même pendant ce délai. Bien sûr, ces
- adresses n'ont rien d'officiel, alors soyez sur vos gardes si vous les
- utilisez.
-
-
- <sect1 id="porter-automation">
- <heading>Infrastructure de portage et automatisation</heading>
- <p>
-Il existe une infrastructure et plusieurs outils pour faciliter l'automatisation
-du portage des paquets. Cette section contient un bref aperçu de cette
-automatisation et du portage de ces outils ; veuillez vous reporter à la
-documentation des paquets ou les références pour une information complète.</p>
-
- <sect2>
- <heading>Listes de diffusion et pages web</heading>
- <p>
-Les pages web contenant l'état de chaque portage peuvent être trouvées à <url
-id="&url-debian-ports;">.
- <p>
-Chaque portage de Debian possède sa propre liste de diffusion. La liste des
-listes de diffusion de portage peut être trouvée à <url
-id="&url-debian-port-lists;">. Ces listes sont utilisées pour coordonner les
-porteurs et pour mettre en relation les utilisateurs d'un portage donné avec les
-porteurs.</p>
- </sect2>
-
- <sect2>
- <heading>Outils pour les porteurs</heading>
-<p>
-Les descriptions de plusieurs outils de portage peuvent être trouvées dans les
-<ref id="tools-porting">.</p>
-
-
- <sect2 id="buildd">
- <heading><package>buildd</package></heading>
-<p>
-Le système <package>buildd</package> est un système distribué pour la
- compilation d'une distribution. Il est habituellement utilisé en conjonction
- avec des automates de compilation ; ce sont des machines
- « esclaves » qui récupèrent des paquets sources et tentent de les
- compiler. Il est aussi possible d'interagir par courrier électronique avec ce
- système. Cette interface est utilisée par les porteurs pour récupérer un
- paquet source (en général, un paquet qui ne peut être compilé
- automatiquement) et travailler dessus.
-<p>
-<package>buildd</package> n'est pas disponible sous forme de paquet ;
- pourtant, la plupart des équipes de porteurs l'utilisent aujourd'hui ou ont
- prévu de l'utiliser bientôt. L'outil de construction automatisé réel est dans
- le paquet <package>sbuild</package>, voir la description dans <ref
- id="sbuild">. Le système <package>buildd</package> regroupe également un
- ensemble de composants très utiles, continuellement utilisés, mais non encore
- mis en paquet, tels que <prgn>andrea</prgn> et <prgn>wanna-build</prgn>.
-<p>
-Une partie des informations produites par <package>buildd</package>
- — utiles pour les porteurs — est disponible sur la
- toile à l'adresse <url id="&url-buildd;">. Ces informations
- incluent les résultats produits toutes les nuits par
- <prgn>andrea</prgn> (dépendances des sources) et
- <prgn>quinn-diff</prgn> (paquets à recompiler).
-<p>
-Nous sommes très fiers de ce système car il a de nombreux usages potentiels. Des
- groupes de développeurs indépendants peuvent utiliser ce système pour créer
- différentes saveurs de Debian — qui peuvent être ou ne pas être
- intéressantes pour tous (par exemple, une version de Debian compilée avec des
- vérifications relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi
- de recompiler rapidement toute une distribution.
-</sect2>
-
- <sect id="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>
-Cette section ne traite que des mises à jour indépendantes de source, c.-à-d.,
- les mises à jour qui envoient une nouvelle version d'un paquet. Pour les
- mises à jour indépendantes par des porteurs ou des membres de la QA,
- veuillez consulter <ref id="binary-only-nmu">. Pour les envois buildd (qui
- sont également strictement parlant des NMU), veuillez consulter <ref
- id="buildd">.
-<p>
-La raison principale pour laquelle une mise à jour indépendante est réalisée est
- quand un développeur a besoin de corriger des paquets d'un autre
- développeur pour résoudre des problèmes sérieux ou des bogues paralysants
- ou quand le responsable d'un paquet ne peut pas
- fournir une correction dans un délai raisonnable.
-<p>
-Tout d'abord, il est capital que ces mises à jour indépendantes soient aussi peu
- intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
- modules ou des fichiers, ne déplacez pas les répertoires ; plus
- généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi
- petit que possible. Si certaines choses froissent votre sens de l'esthétique,
- parlez-en au responsable du paquet, au responsable amont ou soumettez un
- rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
- pas</em> être effectués lors d'une mise à jour indépendante.
-
-<p>
-Et souvenez-vous du Serment d'Hippocrate « Par dessus tout, ne pas
-faire de mal ». Il est préférable qu'un paquet ait un bogue ouvert grave
-plutôt qu'un correctif non fonctionnel soit appliqué et que le bogue devienne
-caché, mais toujours non résolu.
-
- <sect1 id="nmu-guidelines">Comment faire une mise à jour indépendante ?
- <p>
-Les mises à jour indépendantes qui corrigent des bogues de gravité importante,
-sérieuse et plus élevée sont encouragées et acceptées. Vous devriez vous
-efforcer de contacter le responsable actuel du paquet : il est peut-être
-sur le point d'envoyer un correctif pour le problème ou il a peut-être une
-meilleure solution.
- <p>
-Les mises à jour indépendantes doivent être réalisées pour assister un
-responsable de paquet à résoudre des bogues. Les responsables devraient être
-reconnaissants pour cette aide et les personnes faisant la mise à jour
-indépendante devraient respecter les décisions du responsable et tenter
-d'aider personnellement le responsable dans son travail.
- <p>
-Une mise à jour indépendante devrait suivre toutes les conventions décrites dans
-cette section. Pour un envoi vers <em>testing</em> ou <em>unstable</em>, l'ordre
-suivant des étapes est recommandé :
- <p>
-
-<list>
-<item>Vérifiez que les bogues du paquet qui devraient être corrigés par la
- mise à jour indépendante sont bien référencés dans le système de suivi des
- bogues. S'ils n'y sont pas, faites des rapports de bogue
- immédiatement.
-<item>Attendez la réponse du responsable quelques jours. Si vous n'obtenez
- aucune réponse, vous pouvez l'aider en lui envoyant le correctif qui
- corrige le bogue. N'oubliez pas de marquer le bogue avec le mot-clé
- « patch ».
-<item>Patientez quelques jours. Si vous n'avez toujours aucune réponse du
- responsable, envoyez-lui un courrier annonçant votre intention
- d'effectuer une mise à jour indépendante du paquet. Préparez la NMU comme
- décrit dans <ref id="nmu-guidelines">, testez-la soigneusement sur votre
- machine (cf. <ref id="sanitycheck">). Re-vérifiez que votre correctif
- n'a aucun effet de bord inattendu. Assurez-vous que votre correctif est
- aussi minimaliste et non intrusif que possible.
-<item>Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file> (cf.
- <ref id="delayed-incoming">), envoyez le correctif final au responsable
- par le BTS et expliquez-lui qu'il a 7 jours pour réagir s'il veut annuler
- la NMU.
-<item>Suivez ce qui se passe, vous êtes responsable pour tout bogue que vous
- auriez introduit avec votre NMU. Vous devriez probablement utiliser le
- <ref id="pkg-tracking-system"> (PTS) pour vous tenir informé de l'état du
- paquet après votre NMU.
-</list>
-<p>
-Parfois, le responsable de version ou un groupe organisé de
- développeurs peut annoncer une certaine période de temps au cours de laquelle
- les règles de mise à jour indépendante seront plus souples. Ceci implique
- habituellement une période plus courte d'attente avant d'envoyer des
- correctifs et une période de délai plus courte. Il est important de noter que,
- même au cours de ces « chasses aux bogues », la personne
- désirant faire la mise à jour indépendante doit remplir des bogues et
- contacter en premier le développeur, et ensuite seulement passer à
- l'action.
-
-Veuillez vous reporter à <ref id="qa-bsp"> pour des détails.
-<p>
-Pour la distribution <em>testing</em>, les règles peuvent être changées par les
-responsables de diffusion. Veuillez porter une attention spéciale au fait que le
-moyen habituel pour un paquet d'entrer dans <em>testing</em> est de passer par
-<em>unstable</em>.
-<p>
-Pour la distribution <em>stable</em>, veuillez y apporter une attention
-supplémentaire. Bien sûr, les responsables de version peuvent également modifier
-les rêgles ici. Veuillez vérifier avant l'envoi que tous vos changements sont
-acceptables pour inclusion dans la prochaine version stable par le responsable
-de diffusion.
-<p>
-Quand un bogue de sécurité est détecté, l'équipe de sécurité peut effectuer une
-mise à jour indépendante en utilisant ses propres règles. Veuillez vous référer
-à <ref id="bug-security"> pour plus d'informations.
-<p>
-Pour les différences pour les mises à jour indépendantes par les porteurs,
-veuillez voir <ref id="source-nmu-when-porter">.
-<p>
-Bien sûr, il est toujours possible de s'accorder avec un responsable pour des
-règles spéciales (comme quand le responsable demande « merci d'envoyer le
-correctif directement pour moi et pas de diff nécessaire »).
-
- <sect1 id="nmu-version">Numéro de version pour les mises à jour
- indépendantes
-<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>révision-debian</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>révision-debian</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 ».
-<p>
-Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>, vous devrez
- parfois créer une branche (« fork ») dans l'arbre de numéro des version. Pour cela, vous
- pouvez utiliser des numéros de version comme 1.1-3sarge0.1.
-
-
- <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>
-Et si vous recompilez simplement le paquet ? Si vous avez simplement besoin
- de recompiler le paquet pour une seule architecture, vous pouvez faire une
- NMU binaire seulement comme décrit dans <ref id="binary-only-nmu"> qui ne
- nécessite pas qu'un correctif soit envoyé. Si vous désirez que le paquet soit
- recompilé pour toutes les architectures, vous devez alors faire une NMU
- source et vous devrez envoyer un correctif.
-<p>
-Si la mise à jour indépendante source (<em>source NMU</em>) corrige des bogues,
- ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système de
- suivi des bogues plutôt que clos. Par convention, seul le responsable du
- paquet et la personne qui a ouvert le rapport de bogue ferment les
- rapports. Heureusement, le système d'archivage Debian reconnaît les mises à
- jours indépendantes et positionne correctement le statut des bogues à
- <em>fixed</em> si la personne qui fait la mise à jour a listé tous les bogues
- dans le fichier changelog en utilisant la syntaxe <tt>Closes:
- bug#<var>nnnnn</var></tt> (voir <ref id="upload-bugfix"> pour en savoir plus
- sur la fermeture de bogue par le fichier <file>changelog</file>). Ce passage
- au statut <em>fixed</em> assure que chacun sait que le bogue est corrigé par
- une mise à jour indépendante tout en laissant le rapport de bogue ouvert
- jusqu'à ce que le responsable du paquet incorpore les modifications de cette
- mise à jour dans la version officielle du paquet.
-<p>
-Après avoir fait une mise à jour indépendante, il vous faudra aussi envoyer
- cette information aux bogues existants que vous avez corrigés par votre NMU
- en incluant le diff unifié. Sinon, vous pouvez créer un nouveau rapport de
- bogue et inclure un correctif comprenant toutes les modifications que vous
- avez réalisées. Le responsable officiel
- pourra choisir d'appliquer le correctif, il pourra aussi employer une autre
- méthode pour régler le problème. Certains bogues sont corrigés dans la
- version amont, ce qui est une bonne raison pour annuler les modifications
- d'une mise à jour indépendante. Si le responsable choisit de mettre à jour le
- paquet plutôt que d'utiliser les correctifs de la mise à jour indépendante,
- il devra s'assurer que cette nouvelle version corrige effectivement chacun
- des bogues corrigés dans la mise à jour indépendante.
-<p>
-De plus, le responsable officiel devrait <em>toujours</em> conserver les entrées
- documentant une mise à jour indépendante dans le fichier
- <file>changelog</file>.
-
-
- <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="distribution"> en suivant toutes les
- prescriptions de la section <ref id="upload">.
-<p>
-Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt> dans
- le fichier <file>debian/control</file>. Votre nom, mentionné dans l'entrée du
- fichier <file>debian/changelog</file> concernant la mise à jour, sera utilisé
- pour signer le fichier <file>.changes</file>.
-
- <sect1 id="ack-nmu">Valider une mise à jour indépendante
-<p>
-Si l'un de vos paquets a subi une mise à jour indépendante, vous devez récupérer
- les changements dans votre copie des sources. Ceci est aisé, vous avez
- simplement à appliquer le correctif qui vous a été envoyé. Une fois ceci fait,
- vous devez fermer les bogues qui ont été marqués comme fixés par la mise à
- jour. Le moyen le plus simple est d'utiliser l'option <tt>-v</tt> de
- <prgn>dpkg-buildpackage</prgn> car cela vous permet d'inclure tous les
- changements depuis votre dernier envoi de responsable. Sinon, vous pouvez soit
- les fermer manuellement en envoyant les courriers
- nécessaires au BTS soit ajouter les <tt>closes: #nnnn</tt> nécessaires dans
- l'entrée du changelog de votre prochain envoi.
-<p>
-Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une NMU n'est
- pas une attaque personnelle contre le responsable. C'est une preuve que le
- paquet est important pour quelqu'un et qu'il est désireux de vous aider dans
- votre travail, vous devriez donc lui être reconnaissant. Vous pouvez également
- lui demander s'il serait intéressé pour vous aider sur une base plus régulière
- comme co-responsable ou responsable de secours (cf. <ref
- id="collaborative-maint">).
-
- <sect1 id="nmu-vs-qa">Mise à jour indépendante ou envoi de QA ?
-<p>
-Sauf si vous savez que le responsable est toujours actif, il est sage de
-vérifier le paquet pour voir s'il n'a pas été abandonné. La liste actuelle des
-paquets orphelins pour lesquel le champ responsable n'a pas été positionné
-correctement est disponible à <url id="&url-debian-qa-orphaned;">. Si vous
-effectuez une mise à jour indépendante sur un paquet incorrectement orphelin,
-veuillez positionner le responsable à « Debian QA Group
-<packages@qa.debian.org> ».
-
- <sect1 id="nmu-who">Qui peut faire une mise à jour indépendante ?
-<p>
-Seuls les responsables Debian officiels peuvent faire des mises à jour
- indépendantes binaire ou source. Un responsable officiel est une personne dont la clé est dans le
- porte-clés Debian. Tout autre personne est toutefois invitée à télécharger les paquets sources
- pour corriger des bogues ; au lieu de faire des mises à jour
- indépendantes, ils pourront soumettre les correctifs qui le méritent au système
- de suivi des bogues. Les responsables apprécient presque toujours les
- correctifs et les rapports de bogue soignés.
-
- <sect1 id="nmu-terms">Terminologie
-<p>
-Deux nouvelles expressions sont introduites dans cette section :
- « mise à jour indépendante source » et « mise à jour
- indépendante binaire ». Ces deux expressions ont une signification
- technique précise dans ce document. Elles correspondent toutes deux au même type d'activité ;
- elles impliquent toutes deux qu'une personne fait une mise à jour d'un paquet
- alors qu'elle n'est pas officiellement responsable de ce paquet. C'est pourquoi
- nous qualifions ces mises à jours
- d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser
- entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas
- question d'agir sans prévenir le responsable au préalable (voir <ref
- id="nmu-guidelines">).</footnote>.
-<p>
-Une mise à jour indépendante source est une livraison de paquet faite par une
- personne qui n'est pas le responsable officiel de ce paquet avec pour objectif
- de corriger un bogue dans le paquet. Une mise à jour indépendante source
- implique toujours une modification des sources du paquet, même s'il ne s'agit
- que d'un changement dans le fichier <file>debian/changelog</file>. Ce
- changement peut tout aussi bien concerner la partie amont du source que la
- partie spécifique à Debian. Une mise à jour indépendante source peut aussi
- inclure des paquets spécifiques à une architecture tout comme un fichier
- <em>diff</em> modifié.
-<p>
-Une mise à jour indépendante binaire est constitué par la recompilation et
- l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du
- résultat d'un effort de portage. Une mise à jour indépendante binaire est la
- livraison d'un paquet compilé (souvent pour une autre architecture) à condition
- que cette compilation n'ait pas nécessité de modifications des sources. Dans de
- nombreux cas, les porteurs sont obligés de modifier les sources pour les rendre
- compilables sur leur architecture cible ; il s'agira alors d'une mise à
- jour indépendante source et non d'une mise à jour indépendante binaire. Comme
- vous pouvez le remarquer, nous ne faisons pas de distinction entre les mises à
- jour indépendantes faites par des porteurs et les autres mises à jour
- indépendantes.
-<p>
-Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
- par l'expression « mise à jour indépendante »
- (NMU<footnote><p>Non-maintainer upload</footnote>). Pourtant, cela conduit
- souvent à des confusions car beaucoup associent « mise à jour
- indépendante » et « mise à jour indépendante source ». Il faut
- donc rester vigilant. Il est préférable de toujours utiliser « mise à jour
- indépendante binaire » ou «NMU binaire » pour les mises à jour
- indépendantes de binaires seuls.
-
-
- <sect id="collaborative-maint">
- <heading>Maintenance collective</heading>
-<p>
-« Maintenance collective » est un terme décrivant le partage des
- devoirs de la maintenance d'un paquet Debian par plusieurs personnes. Cette
- collaboration est presque toujours une bonne idée car il en résulte
- généralement une meilleure qualité et un temps de correction de bogues plus
- petit. Il est fortement recommandé que les paquets de priorité
- <tt>Standard</tt> ou qui font partie de la base aient des co-responsables.
-<p>
-Habituellement, il y a un responsable principal et un ou plusieurs
- co-responsables. Le responsable principal est la personne dont le nom est indiqué
- dans le champ <tt>Maintainer</tt> du fichier <file>debian/control</file>. Les
- co-responsables sont tous les autres responsables.
-<p>
-Dans sa forme la plus simple, ajouter un nouveau co-responsable est assez
- simple :
-<list>
-<item><p> Donner au co-responsable un accès aux sources à partir desquelles vous
- construisez le paquet. Habituellement, cela implique que vous utilisiez un
- système de contrôle de version comme <prgn>CVS</prgn> ou
- <prgn>Subversion</prgn>.
-</item>
-<item><p> Ajouter les nom et adresse correctes du co-responsable au champ
- <tt>Uploaders</tt> dans la partie globale du fichier
- <file>debian/control</file>.
-<example>
-Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
-</example>
-</item>
-<item><p>
- En utilisant le PTS (<ref id="pkg-tracking-system">), les
- co-responsables devraient s'inscrire eux-mêmes aux paquets sources
- appropriés.
-</item>
-</list>
-<p>
-La maintenance collaborative peut souvent être facilitée par l'utilisation
-d'outils sur Alioth (voir <ref id="alioth">).
- </sect>
-
- <sect id="testing">
- <heading>La distribution <em>testing</em></heading>
- <p>
- <sect1 id="testing-basics">
- <heading>Bases</heading>
- <p>
-Les paquets sont habituellement installés dans la distribution <em>testing</em>
-après avoir atteint un certain degré de test dans <em>unstable</em>.
- <p>
-Ils doivent être en synchronisation pour toutes les architectures et ne doivent
-pas avoir de dépendances qui les rendraient ininstallables ; ils doivent
-également n'avoir aucun bogue bloquant l'inclusion du paquet dans une version
-stable (« release-critical ») au moment où ils sont installés dans
-<em>testing</em>. Ainsi, <em>testing</em> devrait toujours être prête pour être
-une version candidate stable. Veuillez voir ci-dessous pour les détails.
-
- <sect1 id="testing-unstable">
- <heading>Mises à jour depuis <em>unstable</em></heading>
- <p>
-Les scripts qui mettent à jour la distribution <em>testing</em> sont exécutés
- chaque jour après l'installation des paquets mis à jour. Ils fabriquent les
- fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils
- le font d'une manière intelligente pour éviter toute incohérence et essayer de
- n'utiliser que des paquets sans bogue.
- <p>
-L'inclusion d'un paquet d'<em>unstable</em> est soumise aux conditions
-suivantes :
-<list>
- <item>
-Le paquet doit avoir été disponible dans <em>unstable</em> depuis 2, 5 ou
-10 jours selon le champ d'urgence de l'envoi (élevée, moyenne ou basse).
-Veuillez noter que cette urgence est « collande » (« sticky »), ce qui
-veut dire que l'envoi avec l'urgence la plus élevée depuis la dernière
-transition dans <em>testing</em> est prise en compte. Ces délais peuvent être
-doublés lors d'un gel de distribution, ou la transition dans <em>testing</em>
-peut être complètement désactivée ;
- <item>
-Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
-version disponible dans <em>testing</em> ;
- <item>
-Il doit être disponible pour toutes les architectures pour lesquelles
-il a été auparavant construit. <ref id="madison"> peut être
-intéressant pour vérifier cette information ;
- <item>
-Il ne doit pas casser les dépendances d'un paquet qui est déjà
-disponible dans <em>testing</em> ;
- <item>
-Les paquets dont il dépend doivent soit être déjà disponibles dans
-<em>testing</em> soit être acceptés dans <em>testing</em> au
-même moment (et ils doivent respecter tous les critères nécessaires).
-</list>
- <p>
-Pour savoir si un paquet a progressé ou non dans <em>testing</em>, veuillez voir la
-sortie du script de <em>testing</em> sur la <url name="page web de la distribution testing"
-id="&url-testing-maint;"> ou utilisez le programme <prgn>grep-excuses</prgn>
-inclus dans le paquet <package>devscripts</package>. Si l'on veut rester
-informé de la progression de ses paquets dans <em>testing</em>, on peut
-facilement le mettre dans la <manref section="5" name="crontab">.
- <p>
-Le fichier <file>update_excuses</file> ne donne pas toujours la raison précise
- pour laquelle un paquet est refusé, on peut avoir à la chercher soi-même en
- regardant ce qui serait cassé avec l'inclusion du paquet. La <url
- id="&url-testing-maint;" name="page web de la distribution testing"> donne plus
- d'informations à propos des problèmes courants qui peuvent occasionner cela.
- <p>
-Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce que le
- jeu des inter-relations est trop compliqué et ne peut être résolu par le
- script. Voir ci-dessous pour des détails.
- <p>
-Des analyses de dépendances plus avancées sont présentées sur
-<url id="http://bjorn.haxx.se/debian/"> – mais, attention, elles affichent
-également les dépendances de construction qui ne sont pas considérées par
-britney.
-
- <sect2 id="outdated">
- <heading>Désynchronisation</heading>
- <p>
-Pour le script de migration dans <em>testing</em>, « désynchronisé »
-(<em>outdated</em> veut dire ceci : il y a différentes versions dans
-<em>unstable</em> pour les architectures de version (à l'exception des
-architectures dans fuckedarches ; fuckedarches est une liste des
-architectures qui ne suivent pas le rythme (dans update_out.py), mais
-actuellement cette liste est vide). « Désynchronisé » n'a rien à voir
-avec les architectures que le paquet fournit pour <em>testing</em>.
- <p>
-Considérons cet exemple :
- <p>
- <example>
-foo | alpha | arm
----------+-------+----
-testing | 1 | -
-unstable | 1 | 2
-</example>
- <p>
-Le paquet est désynchronisé pour alpha dans <em>unstable</em> et n'entrera pas
-dans <em>testing</em>. Supprimer foo de <em>testing</em> n'aiderait en rien, le
-paquet serait toujours désynchronisé pour alpha et ne se propagerait pas dans
-<em>testing</em>.
- <p>
-Cependant, si ftp-master supprime un paquet d'<em>unstable</em> (ici pour arm) :
- <p>
- <example>
-foo | alpha | arm | hurd-i386
----------+-------+-----+----------
-testing | 1 | 1 | -
-unstable | 2 | - | 1
- </example>
- <p>
-Dans ce cas, le paquet est synchronisé pour toutes les architectures de version
-dans <em>unstable</em> (et l'architecture supplémentaire hurd-i386 ne compte pas
-car ce n'est pas une architecture de version).
- <p>
-Quelquefois, la question est soulevée pour savoir s'il est possible de permettre
-à des paquets de passer dans <em>testing</em> qui ne sont pas encore construits
-pour toutes les architectures : non. Simplement non. (Excepté si vous êtes
-responsable de glibc ou équivalent).
-
- <sect2 id="removals">
- <heading>Suppressions de <em>testing</em></heading>
- <p>
-Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre
-paquet : ceci ne se produit que pour permettre à un <em>autre</em> paquet
-d'entrer, ce dernier paquet doit être prêt pour tous les autres critères.
-Considérons par exemple qu'un paquet a est en conflit avec la nouvelle version
-de b alors a peut être supprimé pour permettre l'entrée de b.
- <p>
-Bien sûr, il existe une autre raison pour supprimer un paquet de
-<em>testing</em> : le paquet est trop bogué (et avoir un seul bogue RC est
-suffisant pour être dans cet état).
-
- <sect2 id="circular">
- <heading>Dépendances circulaires</heading>
- <p>
-Une situation qui n'est pas très bien gérée par britney est si un paquet a
-dépend de la nouvelle version d'un paquet b et vice versa.
- <p>
-Voici un exemple :
- <p>
- <example>
- | testing | unstable
---+-----------------+------------
-a | 1; dépend: b=1 | 2; dépend: b=2
-b | 1; dépend: a=1 | 2; dépend: a=2
- </example>
- <p>
-Le paquet a n'est pas considéré pour la mise à jour, le paquet b non plus.
- <p>
-Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de
-diffusion. Veuillez les contacter en envoyant un courrier électronique à
-debian-release@lists.debian.org si cela se produit pour l'un de vos paquets.
-
-
- <sect2>
- <heading>Influence de paquet dans <em>testing</em></heading>
- <p>
-Généralement, l'état d'un paquet dans <em>testing</em> ne change rien pour la
-transition de la prochaine version d'<em>unstable</em> vers <em>testing</em>,
-avec deux exceptions : si le nombre de bogues RC du paquet est réduit, le
-paquet peut migrer même s'il a encore des bogues RC. La seconde exception est
-que si la version du paquet dans <em>testing</em> est désynchronisée entre les
-différentes architectures, alors toute architecture peut être mise à jour vers
-la version du paquet source ; cependant, cela ne peut se produire que si le
-paquet a été précédemment forcé, si l'architecture est dans fuckedarches ou s'il
-n'y avait pas du tout de paquet binaire de cette architecture présent dans
-<em>unstable</em> lors de la migration dans <em>testing</em>.
- <p>
-En résumé, cela veut dire : la seule influence qu'un paquet de
-<em>testing</em> a sur la nouvelle version du même paquet est que la nouvelle
-version peut rentrer plus facilement.
-
- <sect2 id="details">
- <heading>Détails</heading>
- <p>
-Si vous êtes intéressé par les détails, voici comment fonctionne britney :
- <p>
-Les paquets sont examinés pour savoir si ce sont des candidats valides. Cela
-donne le fichier « update excuses ». Les raisons les plus communes
-pour lesquelles un paquet n'est pas considéré sont la jeunesse du paquet, le
-nombre de bogues RC et la désynchronisation pour certaines architectures. Pour
-cette partie, les responsables de version ont des marteaux de toute taille pour
-forcer britney à considérer un paquet. (Le gel de la base est également codé
-dans cette partie de britney.) (Il y a une chose semblable pour les mises à jour
-binaires pures, mais cela n'est pas décrit ici. Si vous êtes intéressé par cela,
-veuillez utiliser le code.)
- <p>
-Maintenant, la partie la plus complexe se produit : britney tente de mettre
-à jour <em>testing</em> avec des candidats valides ; en premier, chaque
-paquet individuellement, puis des groupes de plus en plus larges de paquets
-ensemble. Chaque tentative est acceptée si <em>testing</em> n'est pas moins
-ininstallable après la mise à jour qu'avant celle-ci. (Avant et après cette
-partie, certains coups de pouce sont traités ; mais, comme seuls les
-responsables de version peuvent positionner des coups de pouce, cela n'est
-probablement pas très important pour vous.)
- <p>
-Si vous voulez voir plus de détails, vous pouvez le voir dans
-merkel:/org/ftp.debian.org/testing/update_out/ (ou dans
-~aba/testing/update_out pour voir une configuration avec un fichier de paquets
-plus petit). Par le web, c'est à <url
-id="http://ftp-master.debian.org/testing/update_out_code/">.
- <p>
-Les coups de pouce sont visibles sur <url
-id="http://ftp-master.debian.org/testing/hints/">.
-
-
- <sect1 id="t-p-u">
- <heading>Mises à jour directes dans <em>testing</em></heading>
- <p>
-La distribution <em>testing</em> est peuplée avec des paquets en provenance
-d'<em>unstable</em> selon des règles expliquées ci-dessus. Cependant, dans
-certains cas, il est nécessaire d'envoyer des paquets construits seulement pour
-<em>testing</em>. Pour cela, vous pouvez envoyer vos paquets vers
-<em>testing-proposed-updates</em>.
- <p>
-Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement,
-ils doivent passer entre les mains du responsable de distribution. Vous devez
-donc avoir une bonne raison pour les y envoyer. Pour savoir ce que
-représente une bonne raison aux yeux du responsable de distribution, vous
-devriez lire les instructions données qu'il envoie régulièrement sur
-&email-debian-devel-announce;.
- <p>
-Vous ne devriez pas envoyer un paquet à <em>testing-proposed-updates</em> quand
-vous pouvez le mettre à jour par <em>unstable</em>. Si vous ne pouvez faire
-autrement (par exemple, parce que vous avez une nouvelle version de
-développement dans <em>unstable</em>), vous pouvez l'utiliser, mais il est
-recommandé de demander l'autorisation du responsable de distribution auparavant.
-Même si un paquet est gelé, des mises à jour par <em>unstable</em> sont possibles
-si l'envoi dans <em>unstable</em> ne tire pas de nouvelle dépendance.
- <p>
-Les numéros de version sont habituellement choisis en ajoutant le nom de
-code de la distribution <em>testing</em> et un numéro d'incrémentation, comme
-1.2sarge1 pour le premier envoi dans <em>testing-proposed-updates</em> du paquet
-en version 1.2.
-
-
- <sect1 id="faq">
- <heading>Questions fréquemment posées</heading>
- <p>
-
- <sect2 id="rc">
- <heading>Qu'est-ce que sont les bogues bloquant l'intégration dans la
- version stable et comment sont-ils comptés ?</heading>
- <p>
-Tous les bogues de gravité assez élevée sont par défaut considérés
-comme bloquant l'intégration du paquet dans la version stable ;
-actuellement, ce sont les bogues critiques, graves et sérieux.
- <p>
-Certains bogues sont supposés avoir un impact sur les chances que le paquet a
-d'être diffusé dans la version stable de Debian : en général, si un paquet
-a des bogues bloquants, il n'ira pas dans <em>testing</em> et par conséquent,
-ne pourra pas être diffusé dans <em>stable</em>.
- <p>
-Le compte des bogues de <em>testing</em> pour un paquet est considéré comme
-étant à peu près le nombre de bogue lors du dernier pointage quand la version
-<em>testing</em> a été égale à la version <em>unstable</em>. Les bogues marqués
-<em>woody</em> ou <em>sarge</em> ne sont pas comptés. Cependant les bogues
-marqués <em>sid</em> sont comptés.
-
-
- <sect2>
- <heading>Comment est-ce que l'installation d'un paquet dans
- <em>testing</em> peut casser d'autres paquets ?</heading>
- <p>
-La structure des archives de la distribution est faite de telle façon qu'elles
-ne peuvent contenir qu'une version d'un paquet ; un paquet est défini par
-son nom. Donc, quand le paquet source acmefoo est installé dans
-<em>testing</em> avec ses paquets binaires acme-foo-bin, acme-bar-bin,
-libacme-foo1 et libacme-foo-dev, l'ancienne version est supprimée.
- <p>
-
-Cependant, l'ancienne version pouvait fournir à un paquet binaire un vieux
-soname d'une bibliothèque, comme libacme-foo0. Supprimer l'ancien acmefoo va
-supprimer libacme-foo0, ce qui va casser tout paquet qui en dépend.
- <p>
-Évidemment, cela touche principalement des paquets qui fournissent des jeux
-changeants de paquets binaires dans différentes version (par suite,
-principalement des bibliothèques). Cependant, cela va aussi toucher des paquets
-sur lesquels une dépendance versionnée a été déclarée du type ==, <= ou <<.
- <p>
-Quand le jeu de paquets binaires fournis par un paquet source change de cette
-façon, tous les paquets qui dépendent des anciens binaires doivent être mis à
-jour pour dépendre de la nouvelle version à la place. Comme l'installation d'un
-tel paquet source dans <em>testing</em> casse tous les paquets qui en dépendent
-dans <em>testing</em>, une certaine attention doit y être portée : tous les
-paquets en dépendant doivent être mis à jour et prêts à être installés eux-même
-pour qu'ils ne cassent pas et, une fois que tout est prêt, une intervention
-manuelle du responsable de version ou d'un de ses assistants est normalement
-requise.
- <p>
-Si vous avez des problèmes avec des groupes compliqués de paquets comme ceci,
-contactez debian-devel ou debian-release en demandant de l'aide.
- </sect>
-
-
- <chapt id="best-pkging-practices">
- <heading>Les meilleurs pratiques pour la construction des paquets
-<p>
-La qualité de Debian est principalement due à la <url id="&url-debian-policy;"
-name="charte Debian"> qui définit explicitement les obligations que tous les
-paquets doivent suivre. Mais c'est également grâce à une histoire partagée
-d'expériences qui va au-delà de la charte Debian, une accumulation d'années
-d'expérience pour la construction des paquets ; des développeurs de grand
-talent ont créé de bons outils qui vous aideront, vous, responsable Debian, à
-créer et maintenir d'excellents paquets.
-
-<p>
-Ce chapitre fournit les meilleurs pratiques pour les développeurs Debian. Ce ne
-sont que des recommandations, non pas des obligations ou des règles. Ce sont
-seulement des astuces et conseils subjectifs et des liens collectés pour les
-développeurs Debian. Prenez et choisissez ce qui vous convient le mieux.
-
- <sect id="bpp-debian-rules">
- <heading>Les meilleures pratiques pour le fichier <file>debian/rules</file></heading>
- <p>
-Les recommandations suivantes s'appliquent au fichier <file>debian/rules</file>.
-Comme ce fichier contrôle le processus de compilation et qu'il sélectionne les
-fichiers inclus dans le paquet (directement ou indirectement), il s'agit
-habituellement du fichier sur lequel les responsables passent le plus de temps.
-
-
- <sect1 id="helper-scripts">Scripts d'aide
-<p>
-La raison sous-jacente à l'utilisation des scripts d'aide dans le fichier
-<file>debian/rules</file> est que cela permet aux responsables d'utiliser et de
-partager une logique commune pour un grand nombre de paquets. Prenez, par
-exemple, l'installation des entrées de menu : vous avez besoin de
-placer un fichier dans <file>/usr/lib/menu</file> et d'ajouter des commandes aux
-scripts de maintenance pour enregistrer et désenregistrer ces entrées de menu.
-Comme il s'agit d'une chose très commune, pourquoi chaque
-responsable devrait-il écrire sa propre version, parfois avec des bogues ?
-Supposons également que le répertoire de menu soit modifié, chaque paquet
-devrait être modifié.
-<p>
-Les scripts d'aide peuvent résoudre ces problèmes. En supposant que vous vous
-conformiez aux conventions attendues par le script d'aide, celui-ci prend soin
-de tous les détails. Les changements dans la charte peuvent alors être faits
-dans le script d'aide, les paquets ont alors simplement besoin d'être
-reconstruits avec la nouvelle version du script et sans aucun changement
-supplémentaire.
-<p>
-L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus
-courant et le meilleur (à notre avis) système est <package>debhelper</package>.
-Les précédents systèmes d'aide comme <package>debmake</package> étaient
-« monolithiques » : vous ne pouviez pas choisir quelles parties
-intéressantes vous pouviez utiliser, mais vous étiez obligé de choisir le
-système pour tout faire. <package>debhelper</package>, à l'inverse, consiste en
-un certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple,
-<prgn>dh_installman</prgn> installe et compacte les pages de manuel,
-<prgn>dh_installmenu</prgn> installe les fichiers de menu et ainsi de suite.
-Ainsi, il offre une flexibilité suffisante pour pouvoir utiliser les scripts
-d'aide quand ils sont utiles, en complément de commandes définies manuellement
-dans le fichier <file>debian/rules</file>.
-<p>
-Vous pouvez débuter avec <package>debhelper</package> en lisant <manref
-name="debhelper" section="1"> et en regardant les exemples fournis avec le
-paquet. <prgn>dh_make</prgn> du paquet <package>dh-make</package> (voir <ref
-id="dh-make">) peut être utilisé pour convertir un paquet source
-« vierge » en une version utilisant <package>debhelper</package>. Ce
-raccourci ne devrait cependant pas vous faire croire que vous n'avez pas besoin
-de comprendre les scripts individuels <prgn>dh_*</prgn>. Si vous comptez
-utiliser un système d'aide, vous devez prendre le temps d'apprendre à utiliser
-ce système pour savoir ce que vous pouvez en attendre ainsi que son
-comportement.
-<p>
-Plusieurs personnes pensent que des fichiers <file>debian/rules</file> vierges
-sont préférables car vous n'avez pas à apprendre les détails internes d'un
-quelconque système d'aide. La décision vous appartient complètement. Utilisez ce
-qui vous convient. Plusieurs exemples de fichiers <file>debian/rules</file> sont
-disponibles à <url id="&url-rules-files;">.
-
- <sect1 id="multiple-patches">
- <heading>Séparer vos correctifs en plusieurs fichiers</heading>
-<p>
-Les gros paquets peuvent avoir plusieurs bogues que vous devez gérer. Si
- vous corrigez sans faire attention les bogues dans les sources, vous ne
- pourrez pas différencier facilement les nombreux correctifs que vous aurez
- appliqués. Cela peut devenir trés compliqué de mettre à jour le paquet avec
- une nouvelle version amont qui intègre certains correctifs (mais pas tous).
- Vous ne pouvez pas prendre l'ensemble des correctifs (par exemple, dans les
- fichiers <file>.diff.gz</file>) et décider quels correctifs il vous faut
- enlever parce que les bogues ont été corrigés en amont.
-<p>
-Malheureusement, le système de création des paquets tel qu'il est actuellement
-ne fournit pas de moyen de séparer les correctifs en plusieurs fichiers.
-Cependant, il existe des moyens de séparer les correctifs : les fichiers
-correctifs sont livrés dans le fichier correctif Debian
-(<file>.diff.gz</file>), habituellement dans le répertoire <file>debian/</file>.
-La seule différence est qu'ils ne sont pas appliqués immédiatement par
-dpkg-source, mais par la règle <tt>build</tt> du fichier
-<file>debian/rules</file>. Inversement, ils sont annulés par la règle
-<tt>clean</tt>.
-<p>
-<prgn>dbs</prgn> est l'une des approches les plus populaires pour cela. Il fait
-ce qui est décrit ci-dessus et fournit la possibilité de créer de nouveaux
-correctifs et de mettre à jour d'anciens correctifs. Veuillez vous reporter au
-paquet <package>dbs</package> pour plus d'informations et au paquet
-<package>hello-dbs</package> pour un exemple.
-<p>
-<prgn>dpatch</prgn> fournit également ces fonctions, mais il est prévu pour être
-encore plus facile d'utilisation. Veuillez voir le paquet
-<package>dpatch</package> pour la documentation et des exemples (dans
-<file>/usr/share/doc/dpatch</file>).
-<p>
-
- <sect1 id="multiple-binary">Paquets binaires multiples
-<p>
-Un simple paquet source va souvent permettre de construire plusieurs paquets
- binaires différents, que ce soit pour fournir plusieurs saveurs du même
- paquet (par exemple, le paquet source <package>vim</package>) ou pour créer
- plusieurs petits paquets au lieu d'un seul gros (par exemple, si
- l'utilisateur peut n'installer que la partie dont il a besoin et ainsi
- économiser de l'espace disque).
-<p>
-Le second cas peut facilement être géré dans le fichier
- <file>debian/rules</file>. Vous avez simplement besoin de déplacer les fichiers
- appropriés du répertoire de construction dans les arborescence temporaires du
- paquet. Vous pouvez le faire en utilisant <prgn>install</prgn>
- ou <prgn>dh_install</prgn> du paquet <package>debhelper</package>.
- Assurez-vous de vérifier les différentes permutations de paquets, en
- garantissant que vous avez bien défini les dépendances entre les paquets dans
- le fichier <file>debian/control</file>.
-<p>
-Le premier cas est un peu plus diffile car il implique de multiples
- recompilations du même logiciel, mais avec différentes options de
- configuration. Le paquet source <package>vim</package> est un exemple de la
- façon de gérer cela avec un fichier <file>rules</file> écrit à la main.
-
-<!-- &FIXME; Find a good debhelper example with multiple configure/make cycles
- -->
-</sect1>
-
-
- <sect id="bpp-debian-control">
- <heading>Les meilleures pratiques pour le fichier
- <file>debian/control</file></heading>
- <p>
-Les pratiques suivantes sont relatives au fichier <file>debian/control</file>.
-Elles viennent en complément des <url
-id="&url-debian-policy;ch-binary.html#s-descriptions" name="règles pour
-les descriptions des paquets">.
-<p>
-La description du paquet, telle qu'elle est définie par le champ correspondant
-dans le fichier <file>control</file>, contient à la fois le résumé du paquet et
-la description longue pour le paquet. <ref id="bpp-desc-basics"> décrit des
-lignes générales pour les deux parties de la description. Ensuite, <ref
-id="bpp-pkg-synopsis"> fournit des principes spécifiques pour le résumé et <ref
-id="bpp-pkg-desc"> contient des principes spécifiques pour la description
-longue.
-
- <sect1 id="bpp-desc-basics">
- <heading>Les règles générales pour les descriptions des paquets</heading>
-<p>
-La description du paquet devrait être écrite pour l'utilisateur moyen,
-l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple, les paquets
-de développement sont pour les développeurs et leur description peut utiliser un
-langage technique. Pour les applications à but plus général comme un éditeur, la
-description devrait être écrite pour un non-spécialiste.
-<p>
-Notre critique des descriptions des paquets nous amène à conclure que la plupart
-des descriptions des paquets sont techniques, c'est-à-dire, qu'elles ne sont pas
-écrites pour être comprises par les non-spécialistes. À moins que
-votre paquet ne soit que pour les techniciens, c'est un problème.
-<p>
-Comment écrire pour les non-spécialistes ? Évitez le jargon.
-Évitez de vous référer à d'autres applications et cadres de travail avec
-lesquels l'utilisateur n'est pas forcément familier — « GNOME »
-ou « KDE » sont corrects car les utilisateurs sont probablement
-familiers avec ces termes, mais « GTK+ » ne l'est probablement pas.
-Ne supposez aucune connaissance. Si vous devez utiliser des termes techniques,
-introduisez-les.
-<p>
-Soyez objectif. Les descriptions de paquet ne sont pas un endroit pour
-promouvoir votre paquet, quel que soit l'amour que vous lui portez.
-Rappelez-vous que le lecteur n'a pas forcément les mêmes priorités que vous.
-<p>
-Des références aux noms de tout autre paquet de logiciels, noms de protocoles,
-standards ou spécifications devraient utiliser leurs formes canoniques si elles
-existent. Par exemple, utilisez « X Window System », « X11 »
-ou « X » et non « X Windows », « X-Windows » ou
-« X Window ». Utilisez « GTK+ » et non « GTK » ou
-« gtk ». Utilisez « GNOME » et non « Gnome ».
-Utilisez « PostScript » et non « Postscript » ou
-« postscript ».
-<p>
-Si vous avez des problèmes pour écrire votre description, vous pouvez l'envoyer à
-&email-debian-l10n-english; et demander un retour d'informations.
-
- </sect1>
-
-<sect1 id="bpp-pkg-synopsis">
- <heading>Le résumé du paquet ou description courte</heading>
-<p>
-La ligne de résumé (la description courte) devrait être concise. Elle ne doit
-pas répéter le nom du paquet (c'est une règle).
-<p>
-C'est une bonne idée de penser au résumé comme à une clause apposée et non une
-phrase complète. Une clause apposée est définie dans WordNet comme une relation
-grammaticale entre un mot et une phrase pronominale qui la suit, par exemple
-« Rudolph, le renne au nez rouge ». La clause apposée ici est
-« le renne au nez rouge ». Comme le résumé est une clause et non une
-phrase complète, nous recommandons de ne pas la commencer par une majuscule et
-de ne pas la finir par un point. Il ne doit pas non plus commencer avec un
-article, défini (« le ») ou indéfini (« un »).
-<p>
-Cela peut vous aider d'imaginer le résumé combiné avec le nom du paquet de
-la façon suivante :
-
-<example><var>nom-paquet</var> est un <var>résumé</var>.</example>
-
-Sinon, il peut être plus compréhensible de le voir comme
-
-<example><var>nom-paquet</var> est <var>résumé</var>.</example>
-
-ou, si le nom du paquet est lui-même un pluriel (comme
-« developer-tools »)
-
-<example><var>nom-paquet</var> sont <var>résumé</var>.</example>
-
-Cette façon de former une phrase à partir du nom du paquet et du résumé devrait
-être considérée comme une heuristique et non comme une règle stricte. Il y a
-certains cas où cela n'a aucun sens de former une phrase.
-
- </sect1>
-
- <sect1 id="bpp-pkg-desc">
- <heading>La description longue</heading>
-<p>
-La description longue du paquet est la première information dont dispose
-l'utilisateur avant d'installer un paquet. Aussi, elle devrait fournir toutes
-les informations nécessaires pour le laisser décider de l'installation du
-paquet. Vous pouvez supposer que l'utilisateur a déjà lu le résumé du paquet.
-<p>
-La description longue devrait toujours être constituée de phrases complètes.
-<p>
-Le premier paragraphe de la description longue devrait répondre aux questions
-suivantes : qu'est-ce que fait le paquet ? Quelle tâche aide-t-il
-l'utilisateur à accomplir ? Il est important de décrire ceci d'une manière
-non technique, à moins que le paquet ne s'adresse qu'à un auditoire de techniciens.
-<p>
-Les paragraphes suivants devraient répondre aux questions suivantes :
-Pourquoi, en tant qu'utilisateur, ai-je besoin de ce paquet ? Quelles
-sont les autres fonctionnalités dont dispose le paquet ? Quelles
-sont les fonctionnalités marquantes et les déficiences de ce paquet comparé à
-d'autres paquets (par exemple, « si vous avez besoin de X, utilisez Y à la
-place ») ? Est-ce que le paquet est lié à d'autres paquets d'une
-certaine façon qui n'est pas gérée par le gestionnaire de paquet (par exemple,
-« il s'agit d'un client pour le serveur foo ») ?
-<p>
-Soyez attentif à éviter les fautes d'orthographe et de grammaire. N'oubliez
-pas votre vérificateur orthographique. <prgn>ispell</prgn> possède une option
-spéciale (<tt>-g</tt>) pour cela :
-
-<example>ispell -d american -g debian/control</example>
-
- <p>
-L'utilisateur s'attend habituellement à ce que les réponses aux questions
-suivantes soient présentes dans la description du paquet.
- <list>
- <item>
-Qu'est-ce que fait le paquet ? Si c'est un ajout d'un autre paquet, la
-description courte du paquet dont il est un ajout devrait le spécifier.
- <item>
-Pourquoi est-ce qu'il voudrait installer ce paquet ? Ceci est lié à ce qui
-est ci-dessus, mais pas tout à fait (c'est un client de messagerie ; il
-est cool, rapide, s'interface avec pgp, ldap et imap, a les fonctionnalités
-X, Y et Z).
- <item>
-Si ce paquet ne devrait pas être installé directement, mais être tiré par un
-autre paquet, cela devrait être mentionné.
- <item>
-Si le paquet est expérimental, ou s'il y a d'autres raisons pour lesquelles il
-ne devrait pas être utilisé, si un autre paquet devrait être utilisé à la place,
-cela devrait également être présent.
- <item>
-En quoi le paquet est différent des paquets concurrents ? Est-ce que c'est
-une meilleure implémentation ? A-t-il plus de fonctionnalités, des
-fonctionnalités différentes ? Pourquoi devrait-il choisir ce paquet (2.
-devrait parler de la classe des paquets et ceci à propos de ce paquet
-particulier, si vous avez des informations liés au deux).
- </list>
-
- </sect1>
-
- <sect1 id="bpp-upstream-info">
- <heading>Page d'accueil amont</heading>
- <p>
-Nous vous recommandons d'ajouter l'adresse de la page d'accueil du paquet à la
-description du paquet dans le fichier <file>debian/control</file>. Cette
-information devrait être ajoutée à la fin de la description en utilisant le
-format suivant :
-
-<example> .
- Homepage: http://some-project.some-place.org/</example>
-
-Veuillez noter les espaces au début de la ligne, ils servent à séparer les
-lignes correctement. Pour voir un exemple de ce que cela affiche, veuillez vous
-reporter à <url id="&url-eg-desc-upstream-info;">.
- <p>
-Ne mettez rien s'il n'existe pas de page pour le logiciel.
-
- <p>
-Veuillez noter que nous espérons que ce champ sera remplacé par un
-vrai champ de <file>debian/control</file> que comprendraient <prgn>dpkg</prgn>
-et <tt>&packages-host;</tt>. Si vous ne voulez pas vous embêter à déplacer la
-page d'accueil depuis la description vers ce nouveau champ, vous devriez
-probablement attendre qu'il soit disponible.</p>
- </sect1>
- </sect>
-
-
- <sect id="bpp-debian-changelog">
- <heading>Les meilleures pratiques pour le fichier <file>debian/changelog</file></heading>
- <p>
-Les pratiques suivantes viennent en complément de la <url name="directive sur
-les fichiers changelog" id="&url-debian-policy;ch-docs.html#s-changelogs">.</p>
-
- <sect1 id="bpp-changelog-do">
- <heading>Écrire des entrées de changelog utiles</heading>
- <p>
-L'entrée de changelog pour une révision de paquet documente les changements dans
-cette révision et seulement ceux-ci. Concentrez-vous sur la description des
-changements significatifs et visibles de l'utilisateur qui ont été effectués
-depuis la dernière version.
- <p>
-Ciblez <em>ce</em> qui a été changé — qui, comment et quand cela a été fait
-est généralement de moindre importance. Ceci dit, rappelez-vous de nommer
-poliment les personnes qui ont fourni une aide notable pour réaliser le
-paquet (par exemple, ceux qui ont envoyé des correctifs).
- <p>
-Vous n'avez pas besoin de détailler les changements triviaux et évidents. Vous
-pouvez également regrouper plusieurs de ces changements dans une seule entrée.
-D'un autre côté, ne soyez pas trop concis si vous avez entrepris un changement
-majeur. Soyez tout spécialement clair s'il y a des changements qui modifient le
-comportement du programme. Pour plus d'explications, utilisez le fichier
-<file>README.Debian</file>.
- <p>
-Utilisez un langage anglais commun pour que la majorité des lecteur puissent le
-comprendre. Évitez les abbréviations, le parler technique et le jargon quand
-vous expliquez des changements fermant un bogue, spécialement pour les rapports
-de bogue créés par des utilisateurs qui ne vous paraissent pas particulièrement
-à l'aise techniquement. Vous devez être poli et ne pas jurer.
- <p>
-Il est parfois désirable de préfixer les entrées de changelog avec le nom des
-fichiers qui ont été modifiés. Cependant, il n'est pas besoin de lister
-explicitement tous les fichiers modifiés, particulièrement si la modification
-est petite ou répétitive. Vous pouvez utiliser les caractères génériques.
- <p>
-Quand vous faites référence aux bogues, ne supposez rien a priori. Dites ce
-qu'était le problème, comment il a été résolu et ajoutez la chaîne de caractères
-« closes: #nnnnn ». Veuillez voir <ref id="upload-bugfix"> pour plus
-d'informations.
-
- <sect1 id="bpp-changelog-misconceptions">
- <heading>idées fausses communes sur les entrées de changelog</heading>
- <p>
-Les entrées de changelog <strong>ne devraient pas</strong> documenter des
-problèmes génériques d'empaquetage (« Hé, si vous cherchez foo.conf, il
-est dans /etc/blah/. ») car les administrateurs et utilisateurs sont
-supposés être au moins vaguement rompus à la façon dont les choses sont
-arrangées sur un système Debian. Mentionnez cependant tout changement
-d'emplacement d'un fichier de configuration.
- <p>
-Les seuls bogues fermés par une entrée de changelog devraient être ceux qui sont
-vraiment corrigés dans la même révision du paquet. Fermer des bogues non liés
-par le fichier changelog est considéré comme une très mauvaise pratique.
-Veuillez voir <ref id="upload-bugfix">.
- <p>
-Les entrées de changelog <strong>ne devraient pas</strong> être le lieu de
-discussions avec les émetteurs de bogues (« Je ne vois pas de segfaults
-lors du lancement de foo avec l'option bar ; envoyez-moi plus
-d'informations. »), ni celui de phrases génériques sur la vie, l'univers et
-tout le reste (« Désolé, cet envoi m'a pris du temps, mais j'avais attrapé
-la grippe ») ou celui de demandes d'aide (« La liste des bogues sur
-ce paquet est énorme, donnez-moi un coup de main »). Ceci ne sera
-généralement pas remarqué par les personnes ciblées, mais peut ennuyer les
-personnes qui désirent lire des informations sur les changements réels du
-paquet. Veuillez vous reporter à <ref id="bug-answering"> pour plus
-d'informations sur la façon d'utiliser le système de suivi des bogues.
- <p>
-C'est une vieille tradition de valider les bogues fixés par une mise à jour
-indépendante dans la première entrée du changelog de l'envoi du vrai
-responsable, par exemple, dans une entrée de changelog comme ceci :
-<example>
- * Maintainer upload, closes: #42345, #44484, #42444.
-</example>
-Ceci fermera les bogues NMU marqués comme corrigé (« fixed ») quand le
-paquet arrivera dans l'archive. Le bogue pour le fait qu'une NMU a été faite
-peut être fermé de la même façon. Bien sûr, il est également parfaitement
-acceptable de fermer les bogues corrigés par NMU par d'autres moyens ; voir
-<ref id="bug-answering">.
-</sect1>
-
- <sect1 id="bpp-changelog-errors">
- <heading>Erreurs communes dans les entrées de changelogs</heading>
-<p>
-Les exemples suivants montrent des erreurs communes ou des exemples de mauvais
-style dans les entrées de changelog<footnote>NdT : Les entrées de
-changelog sont ici affichées en français pour faciliter la compréhension, mais
-vos entrées devront naturellement être rédigées en anglais.</footnote>.
-
-<p>
-<example>
- * Corrige tous les bogues restants.
-</example>
-<p>
-Ceci n'indique visiblement rien d'utile au lecteur.
-<p>
-<example>
- * Correctif de Jane Random appliqué.
-</example>
-Sur quoi portait le correctif ?
-
-<p>
-<example>
- * Révision de cible d'installation la nuit dernière.
-</example>
-Qu'a accompli la révision ? Est-ce que la mention de la nuit dernière
-est supposée nous rappeler que nous ne devons pas faire confiance à ce
-code ?
-
-<p>
-<example>
- * Corrige MRD vsync av. anciens CRTs.
-</example>
-Trop d'acronymes et il n'est pas très clair de ce qu'était vraiment cette...
- euh... merde (oups, un mot interdit !) ou comment cela a été corrigé.
-
-<p>
-<example>
- * Ceci n'est pas un bogue. Closes: #nnnnnn.
-</example>
-Premièrement, il n'y a absolument pas besoin d'envoyer un paquet pour
-communiquer cette information ; à la place, utilisez le système de suivi des
-bogues. Deuxièmement, il n'y a aucune explication concernant la raison
-pour laquelle le rapport n'était pas un bogue.
-
-<p>
-<example>
- * A été fixé il y a longtemps, mais j'ai oublié de le fermer. Closes: #54321.
-</example>
-Si, pour toute raison, vous n'aviez pas indiqué le numéro du bogue dans une
-précédente entrée de changelog, ceci n'est pas un problème, fermez simplement le
-bogue normalement dans le BTS. Il n'y a pas besoin de modifier le fichier
-changelog, en supposant que la description de la correction est déjà intégrée
-(ceci s'applique aux correctifs par les auteurs/responsables amont également,
-vous n'avez pas à suivre les bogues qui ont été corrigés il y a longtemps dans
-votre changelog).
-
-<p>
-<example>
- * Closes: #12345, #12346, #15432.
-</example>
-Où est la description ?! Si vous n'arrivez pas à trouver un message
-descriptif, commencez par insérer le titre de chacun des différents bogues.
-<p>
-</sect1>
-
- <sect1 id="bpp-news-debian">
- <heading>Compléter les changelogs avec les fichiers NEWS.Debian</heading>
- <p>
-Les nouvelles importantes à propos des changements dans un paquet peuvent
-également être placées dans les fichiers NEWS.Debian. Ces nouvelles seront
-affichées par des outils comme apt-listchanges, avant le reste des changelogs.
-Ceci est le moyen préféré pour informer les utilisateurs des changements
-significatifs dans un paquet. Il est préférable d'utiliser ce fichier plutôt que
-d'utiliser des notes debconf car c'est moins ennuyeux et l'utilisateur peut y
-revenir et se référer au fichier NEWS.Debian après l'installation. Et c'est
-mieux que de lister les changements principaux dans README.Debian car
-l'utilisateur peut facilement rater de telles notes.
- <p>
-Le format du fichier est le même que pour un fichier de changelog Debian, mais
-il n'utilise pas d'astérisques et décrit chaque élément de nouvelle dans un
-paragraphe complet si nécessaire plutôt que les résumés concis qui iraient dans un
-changelog. C'est une bonne idée de passer votre fichier par dpkg-parsechangelog
-pour vérifier son formatage car il n'est pas vérifié automatiquement pendant la
-construction comme le changelog. Voici un exemple d'un vrai fichier NEWS.Debian :
-<example>
-cron (3.0pl1-74) unstable; urgency=low
-
- The checksecurity script is no longer included with the cron package:
- it now has its own package, "checksecurity". If you liked the
- functionality provided with that script, please install the new
- package.
-
- -- Steve Greenland <stevegr&debian.org> Sat, 6 Sep 2003 17:15:03 -0500
-</example>
- <p>
-Le fichier NEWS.Debian est installé comme
-/usr/share/doc/<package>/NEWS.Debian.gz. Il est compressé et a toujours ce
-nom même dans les paquets natifs Debian. Si vous utilisez debhelper,
-dh_installchangelogs installera les fichiers debian/NEWS pour vous.
- <p>
-À la différence des fichiers changelog, vous n'avez pas besoin de mettre à jour
-les fichiers NEWS.Debian à chaque nouvelle version. Ne les mettez à jour que si
-vous avez quelque chose de particulièrement important que l'utilisateur a
-besoin de savoir. Si vous n'avez pas de nouvelles du tout, il n'est pas
-nécessaire de fournir de fichier NEWS.Debian dans votre paquet. Pas de
-nouvelles, bonne nouvelle !
-
-</sect>
-
-<!-- <sect1 id="pkg-mgmt-cvs">Managing a package with CVS
- <p>
- &FIXME; presentation of cvs-buildpackage, updating sources
- via CVS (debian/rules refresh).
- <url id="http://www.debian.org/devel/cvs_packages">
--->
-
- <sect id="bpp-debian-maint-scripts">
- <heading>Les meilleures pratiques pour les scripts de
- maintenance</heading>
- <p>
-Les scripts de maintenance incluent les fichiers <file>debian/postinst</file>,
-<file>debian/preinst</file>, <file>debian/prerm</file> et
-<file>debian/postrm</file>. Ces scripts prennent soin de la configuration
-d'installation ou de désinstallation des paquets, ce qui n'est pas simplement créer ou
-supprimer des fichiers et des répertoires. Les instructions suivantes
-complètent la <url id="&url-debian-policy;" name="charte Debian">.
- <p>
-Les scripts de maintenance doivent être idempotents. Cela veut dire que vous
-devez vous assurer que rien de grave ne se produit si un script est appelé deux
-fois là où il ne devrait habituellement être appelé qu'une fois.
- <p>
-Les entrée et sortie standard peuvent être redirigées (par exemple, dans des
-tubes<footnote><p>pipes</p></footnote>) pour des besoins d'enregistrement
-d'activité, donc vous ne devez pas supposer que ce sont des tty.
- <p>
-Tous les affichages et les configurations interactives devraient être
-minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet
-<package>debconf</package> pour l'interface. Rappelez-vous que, dans tous les
-cas, l'affichage ne doit se faire que dans l'étape de configuration,
-<tt>configure</tt> du script de post-installation, <file>postinst</file>.
- <p>
-Gardez les scripts de maintenance aussi simples que possible. Nous vous
-suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que si vous
-avez besoin d'une fonctionnalité de Bash, le script de maintenance doit
-l'indiquer dans sa première ligne. Un shell POSIX ou Bash sont préférés à
-Perl car ils permettent à <package>debhelper</package> d'ajouter facilement des
-parties aux scripts.
- <p>
-Si vous modifiez les scripts de maintenance, assurez-vous de tester la
-suppression du paquet, la double installation et la purge complète. Assurez-vous
-qu'il ne reste rien d'un paquet purgé, c'est-à-dire, que la purge doit enlever
-tout fichier créé, directement ou indirectement, par les scripts de
-maintenance.
- <p>
-Si vous avez besoin de vérifier l'existence d'une commande, vous devriez
-utiliser quelque chose comme :
-<example>if [ -x /usr/sbin/install-docs ]; then ...</example>
-
-Si vous ne désirez pas mettre en dur le chemin de la commande dans le script de
-maintenance, la fonction de shell suivante conforme à POSIX peut vous
-aider :
-
-&example-pathfind;
-
-Vous pouvez utiliser cette fonction pour rechercher le <tt>$PATH</tt> pour un
-nom de commande passé en argument. Il renvoie vrai (zéro) si la commande a été
-trouvée et faux sinon. Il s'agit réellement de la façon la plus portable de faire
-car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn> ne sont pas
-POSIX.
-<p>
-Bien que <prgn>which</prgn> soit une alternative acceptable car il est
-présent dans le paquet classé <em>required</em> <package>debianutils</package>, il n'est pas
-présent dans la partition racine. Autrement dit, il est placé dans
-<file>/usr/bin</file> au lieu de <file>/bin</file>, il n'est donc pas possible
-de l'utiliser dans les scripts qui sont exécutés avant que la partition
-<file>/usr</file> soit montée. Cependant, la plupart des scripts n'auront pas ce
-problème.
- </sect>
-
- <sect id="bpp-config-mgmt">
- <heading>Gestion de la configuration avec <package>debconf</package></heading>
-
- <p>
-<p>
-<package>Debconf</package> est un système de gestion de configuration qui
- peut être utilisé par les divers scripts de maintenance (principalement
- en post-installation dans le fichier <file>postinst</file>) pour demander à
-l'utilisateur des informations concernant la configuration du paquet. Il
-faut maintenant éviter les interactions directes avec l'utilisateur et
-préférer les interactions utilisant <package>debconf</package>. Ceci permettra
- à l'avenir des installations non interactives.
- <p>
-Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs erreurs
- communes sont référencées dans la page de manuel <manref section="7"
- name="debconf-devel">. Vous devriez vraiment lire cette page si vous décidez
- d'utiliser debconf.
- </sect>
-
-
- <sect id="bpp-i18n">
- <heading>Internationalisation</heading>
-
-
-
- <sect1 id="bpp-i18n-debconf">Gestion des traductions de
- debconf
-<p>
-Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur
- un grand nombre de paquets et doivent donc collaborer avec plusieurs
- responsables différents. De plus, la plupart du temps, l'anglais n'est pas leur
- langue maternelle, il se peut que vous deviez être particulièrement patient
- avec eux.
-<p>
-Le but de <package>debconf</package> était de faciliter la configuration des
-paquets aux responsables et aux utilisateurs. À l'origine, les
-traductions des questionnaires debconf étaient gérées avec
-<prgn>debconf-mergetemplate</prgn>. Cependant, cette technique est maintenant
-déconseillée ; la meilleure façon pour l'internationalisation de
-<package>debconf</package> est d'utiliser le paquet
-<package>po-debconf</package>. Cette méthode est plus facile et pour le
-responsable et pour les traducteurs ; des scripts de transition sont
-fournis.
-<p>
-Lors de l'utilisation de <package>po-debconf</package>, la traduction est
-stockée dans des fichiers <file>po</file> (à l'instar des techniques de
-traduction de <prgn>gettext</prgn>). Des fichiers modèles contiennent les
-messages d'origine et indiquent quels sont les champs traduisibles. Quand vous
-modifiez l'état d'un champ traduisible en appelant
-<prgn>debconf-updatepo</prgn>, la traduction est marquée comme ayant besoin de
-l'attention des traducteurs. Puis, lors de la construction du paquet, le
-programme <prgn>dh_installdebconf</prgn> prendra soin de toute la magie
-nécessaire à l'ajout du modèle avec les traductions à jour dans les paquets
-binaires. Veuillez vous reporter à la page de manuel <manref name="po-debconf"
-section="7"> pour les détails.
- </sect1>
-
- <sect1 id="bpp-i18n-docs">
- <heading>Documentation traduite</heading>
- <p>
-La traduction de la documentation est cruciale pour les utilisateurs, mais elle
-représente un important travail. Il n'existe aucun moyen d'éliminer ce travail,
-mais vous pouvez faciliter les choses pour les traducteurs.
- <p>
-Si vous êtes responsable d'une documentation quelle que soit sa taille, il est
-plus facile pour les traducteurs d'avoir accès à un système de contrôle de
-source. Ceci permet aux traducteurs de voir les différences entre deux versions
-de la documentation, pour, par exemple, qu'ils puissent voir ce qui a besoin
-d'être retraduit. Il est recommandé que le document traduit inclue une note à
-propos de la révision de contrôle du source sur laquelle la traduction est
-basée. Un système intéressant est fourni par <url id="&url-i18n-doc-check;"
-name="doc-check"> dans le paquet <package>boot-floppies</package> qui donne un
-aperçu de l'état de la traduction pour une langue donnée, en utilisant les
-commentaires structurés pour une révision donnée du fichier à traduire et, pour
-un fichier traduit, la révision du fichier d'origine sur laquelle la traduction
-est basée. Vous pouvez vouloir adapter et fournir ceci dans votre référentiel CVS.
- <p>
-Si vous maintenez de la documentation au format XML ou SGML, nous vous suggérons
-d'isoler les informations indépendantes de la langue et de les définir
-comme des entités dans un fichier séparé qui sera inclus par les différentes
-traductions. Ceci aide, par exemple, à garder à jour les adresses pour
-plusieurs fichiers.
- </sect1>
- </sect>
-
-
- <sect id="bpp-common-situations">
- <heading>Pratiques communes d'empaquetage</heading>
-
-<!--
- <sect1 id="bpp-kernel">Kernel modules/patches
-<p>
-
- &FIXME; Heavy use of kernel-package. provide files in
- /etc/modutils/ for module configuration.
--->
-
- <sect1 id="bpp-autotools">
- <heading>Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
-<p>
-Conserver à jour les fichiers d'<prgn>autoconf</prgn>, <file>config.sub</file>
-et <file>config.guess</file>, est critique pour les porteurs, spécialement pour
-les architectures plus changeantes. De très bonnes pratiques d'empaquetage
-utilisant <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été regroupées
-dans &file-bpp-autotools; du paquet <package>autotools-dev</package>. Vous êtes
-vivement encouragé à lire ce fichier et à suivre les recommandations indiquées.
-
-
- <sect1 id="bpp-libraries">Bibliothèques
-<p>
-Pour diverses raisons, il a toujours été difficile d'empaqueter les
-bibliothèques. La charte impose plusieurs contraintes pour faciliter la maintenance
- et pour garantir que les mises à jour sont aussi simples que possible quand une
- nouvelle version amont est disponible. Une erreur dans une bibliothèque peut
- rendre défectueux une douzaine de paquets qui en dépendent.
-<p>
-Les bonnes pratiques d'empaquetage des bibliothèques ont été regroupées dans
- <url id="&url-libpkg-guide;" name="le guide d'empaquetage des
- bibliothèques">.
-
- <sect1 id="bpp-docs">Documentation
- <p>
-Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html"
-name="règles sur la documentation">.</p>
- <p>
-Si votre paquet contient de la documentation construite à partir de XML ou SGML,
-nous vous recommandons de ne pas fournir le source XML ou SGML dans le(s)
-paquet(s) binaire(s). Si les utilisateurs désirent avoir le source de la
-documentation, ils peuvent récupérer le paquet source.</p>
- <p>
-La charte spécifie que la documentation doit être fournie au format HTML.
-Nous vous recommandons également de la fournir au format PDF et texte simple si
-c'est adapté et qu'une sortie de qualité est possible. Cependant, il n'est
-généralement pas approprié de fournir des versions en texte simple pour la
-documentation dont le format source est du HTML.</p>
- <p>
-Les principaux manuels fournis devraient être enregistrés par le paquet
-<package>doc-base</package> à l'installation. Reportez-vous à la documentation
-du paquet <package>doc-base</package> pour plus d'information.</p>
-
-
-
- <sect1 id="bpp-other">Types spécifiques de paquets
-<p>
-Plusieurs types spécifiques de paquets ont des sous-chartes spéciales et des
- règles et pratiques d'empaquetage correspondantes :
-<list>
-<item>
- Les paquets liés à Perl ont leur <url id="&url-perl-policy;" name="charte
- Perl">, quelques exemples de paquets qui suivent cette charte sont
- <package>libdbd-pg-perl</package> (module perl binaire) ou
- <package>libmldbm-perl</package> (module perl indépendant de
- l'architecture).
-</item>
-<item>
- Les paquets liés à Python ont leur charte Python ; voir
- &file-python-policy; dans le paquet <package>python</package>.
-</item>
-<item>
- Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;"
- name="charte Emacs">.
-</item>
-<item>
- Les paquets liés à Java ont leur <url id="&url-java-policy;" name="charte
- Java">.
-</item>
-<item>
- Les paquets liés à Ocaml ont leur propre charte que l'on trouve dans
- &file-ocaml-policy; du paquet <package>ocaml</package>. Un bon exemple est
- le paquet source <package>camlzip</package>.
-</item>
-<item>
- Les paquets fournissant des DTDs XML ou SGML devraient se conformer aux
- recommandations que l'on peut trouver dans le paquet
- <package>sgml-base-doc</package>
-<item>
- Les paquets Lisp devraient s'enregistrer avec le paquet
- <package>common-lisp-controller</package> pour lequel vous pouvez vous
- reporter au fichier &file-lisp-controller;.
-</list>
-
- </sect1>
-
- <sect1 id="bpp-archindepdata">Données indépendantes de l'architecture
- <p>
- Il n'est pas rare d'avoir une grande quantité de données indépendantes de
- l'architecture fournie avec un programme. Par exemple, des fichiers
- audio, une collection d'icônes, des motifs de papiers peints ou autres
- fichiers graphiques. Si la taille des données est négligeable par
- rapport à la taille du reste du paquet, il est probablement mieux de
- tout garder dans le même paquet.
-
- <p>
- Cependant, si la taille des données est considérable, vous devez
- envisager de les partager dans un paquet séparé et indépendant de
- l'architecture (« _all.deb »). Ainsi, en faisant cela, vous
- évitez une duplication inutile des mêmes données dans onze fichiers
- .debs pour chaque architecture. Bien que ceci ajoute une surcharge
- supplémentaire aux fichiers <file>Packages</file>, ceci sauve beaucoup
- d'espace disque sur les miroirs Debian. Séparer les données
- indépendantes de l'architecture réduit également le temps de traitement
- de <prgn>lintian</prgn> ou de <prgn>linda</prgn> (voir <ref
- id="tools-lint">) quand ils sont exécutés sur l'ensemble de l'archive
- Debian.
- </sect1>
-
- <sect1 id="bpp-locale">
- <heading>Avoir besoin d'une certaine locale pendant la construction</heading>
- <p>
-Si vous avez besoin d'une certaine locale pendant la construction, vous pouvez
-créer un fichier temporaire par cette astuce :
- <p>
-Si vous positionnez LOCPATH à l'équivalent de /usr/lib/locale, et LC_ALL au nom
-de la locale que vous générez, vous devriez obtenir ce que vous voulez sans être
-root. Quelque chose comme ceci :
-
-<example>
-LOCALE_PATH=debian/tmpdir/usr/lib/locale
-LOCALE_NAME=en_IN
-LOCALE_CHARSET=UTF-8
-
-mkdir -p $LOCALE_PATH
-localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"