- </list>
- Ces informations permettent aux utilisateurs d'estimer la menace pesant
- sur leurs systèmes.
-
-</item>
-<item>
- les numéros de version des paquets affectés,
-</item>
-<item>
- les numéros de version des paquets corrigés,
-</item>
-<item>
- une information sur la façon de récupérer les paquets mis à jour
- (habituellement l'archive de sécurité Debian),
-</item>
-<item>
- des références à des annonces amont, des identifiants <url
- id="http://cve.mitre.org" name="CVE"> et toute autre information utile
- pour recouper les références de la vulnérabilité.
-</item>
-</list>
-
- <sect2 id="bug-security-building">
- <heading>Préparer les paquets pour corriger des problèmes de sécurité
-<p>
-Une façon d'aider l'équipe de sécurité dans ses travaux est de leur fournir des
- paquets corrigés convenables pour une annonce de sécurité pour la version
- <em>stable</em> de Debian
-<p>
-Quand une mise à jour de la version <em>stable</em> est effectuée, un soin
- particulier doit être apporté pour éviter de modifier le comportement du
- système ou d'introduire de nouveaux bogues. Pour cela, faites le moins de
- changements possibles pour corriger le bogue. Les utilisateurs et les
- administrateurs s'attendent à un comportement identique dans une version
- lorsque celle-ci est diffusée, donc tout changement qui est fait est
- susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour
- les bibliothèques : assurez-vous ne de jamais changer l'API ou l'ABI,
- quelque minimal que soit le changement.
-<p>
-Cela veut dire que passer à une version amont supérieure n'est pas une bonne
-solution. À la place, les changements pertinents devraient être rétroportés
-vers la version présente dans la distribution <em>stable</em> de Debian.
-Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de
-sécurité Debian peut le faire.
-<p>
-Dans certains cas, il n'est pas possible de rétroporter un correctif de
-sécurité, par exemple, quand de grandes quantités de code source doivent être
-modifiées ou récrites. Si cela se produit, il peut être nécessaire de passer à
-une nouvelle version amont. Cependant, ceci n'est fait que dans des situations
-extrêmes et vous devez toujours coordonner cela avec l'équipe de sécurité au
-préalable.
-<p>
-Il existe une autre règle de conduite liée à cela : testez toujours vos
-changements. Si une exploitation du problème existe, essayez-la et
-vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet
-corrigé. Testez aussi les autres actions normales car parfois un correctif de
-sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas
-liées.
-<p>
-N'incluez <strong>PAS</strong> de changements dans votre paquet qui ne soient
-pas liés directement à la correction de la vulnérabilité. Ceux-ci devraient être
-ensuite enlevés et cela perd du temps. S'il y a d'autres bogues dans votre
-paquet que vous aimeriez corriger, faites un envoi vers
-proposed-updates de la façon habituelle, après l'envoi de l'alerte de sécurité.
-Le mécanisme de mise à jour de sécurité n'est pas un moyen d'introduire des
-changements dans votre paquet qui seraient sinon rejetés de la distribution
-stable, n'essayez donc pas de faire cela, s'il vous plaît.
-<p>
-Examinez et testez autant que possible vos changements. Vérifiez les différences
-avec la version précédente de manière répétée (<prgn>interdiff</prgn> du
-paquet <package>patchutils</package> et <prgn>debdiff</prgn> du paquet
-<package>devscripts</package> sont des outils utiles pour cela, voir <ref
-id="debdiff">).
-<p>
-Assurez-vous de conserver les points suivants à l'esprit :
-
-<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">. Si un buildd construit et
- envoie un paquet, cela est également à strictement parler une NMU binaire.
- Veuillez consulter <ref id="buildd"> pour plus d'informations.
-<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 cette section et 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 lesquels 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> ». Dans ce cas, les bogues du paquet sont
-fermés et pas simplement marqués comme corrigés.
-
- <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 : utilisez toujours « 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 collective 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 « collante » (« sticky »), ce qui
-veut dire que l'envoi avec l'urgence la plus élevée depuis la précédente
-transition dans <em>testing</em> est prise en compte. Ces délais peuvent être
-doublés lors d'un gel de distribution, ou les transitions dans <em>testing</em>
-peuvent être complètement désactivées ;
- <item>
-Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
-version actuellement 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 remplire 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 vous voulez rester
-informé de la progression de vos paquets dans <em>testing</em>, vous pouvez
-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, cette page affiche
-également les dépendances de construction qui ne sont pas considérées par
-britney.
-
- <sect2 id="outdated">
- <heading>Désynchronisation</heading>
- <p>
-<!-- FIXME: better rename this file than document rampant professionalism? -->
-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 doit être prêt pour tous les autres critères.
-Considérons, par exemple, qu'un paquet <em>a</em> est en conflit avec la nouvelle version
-de <em>b</em> alors <em>a</em> peut être supprimé pour permettre l'entrée de <em>b</em>.
- <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 <em>a</em>
-dépend de la nouvelle version d'un paquet <em>b</em> 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>
-Aucun des paquets <em>a</em> et <em>b</em> ne sera considéré pour mise à jour.
- <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 étudier attentivement 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>unstable</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 des responsables de distribution, vous
-devriez lire les instructions données qu'ils envoient 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 utiliser cette facilité, 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 nouvelles dépendances.
- <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 incrémenté, comme
-1.2sarge1 pour le premier envoi dans <em>testing-proposed-updates</em> du paquet
-en version 1.2.
- <p>
-Veuillez vous assurer que vous n'oubliez aucun des éléments suivants lors de
-votre envoi :
-<list>
-<item> vérifiez que votre paquet doit vraiment aller dans
-<em>testing-proposed-updates</em> et ne peut pas passer par
-<em>unstable</em> ;
-<item> vérifiez que vous n'incluez que le minimum de changements ;
-<item> vérifiez que vous incluez une explication appropriée dans le
-changelog ;
-<item> vérifiez que vous avez bien indiqué <em>testing</em> ou
-<em>testing-proposed-updates</em> comme votre distribution cible ;
-<item> vérifiez que vous avez construit et testé votre paquet dans
-<em>testing</em> et non dans <em>unstable</em> ;
-<item> vérifiez que votre numéro de version est plus élevé que les versions de
-<em>testing</em> et de <em>testing-proposed-updates</em> et moins élevé que
-celle de <em>unstable</em> ;
-<item> après l'envoi et la construction réussie sur toutes les plates-formes,
-contactez l'équipe de diffusion à &email-debian-release; et demandez-leur
-d'approuver votre envoi.
-</list>
-
-
- <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 d'<em>unstable</em> est effectué avec tous les bogues
-bloquants sans étiquette de version (comme <em>potato</em>, <em>woody</em>) ou
-avec une étiquette <em>sid</em> et également s'ils ne sont ni corrigés ou
-marqués avec <em>sarge-ignore</em>.
-Le compte des bogues de <em>testing</em> pour un paquet est condiséré comme à
-peu près le nombre de bogues d'<em>unstable</em> lors du dernier pointage quand
-la version <em>testing</em> a été égale à la version <em>unstable</em>.
- <p>
-Cela changera après la sortie de <em>Sarge</em> dès que nous aurons des versions
-dans le système de suivi des bogues.
-
- <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 difficile 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>
-Les utilisateurs s'attendent 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 c'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 ?
-<!-- FIXME: what's this?
-+(the second questions is about the class of packages, and
- this about this particular package, if you have information related to both).
-+-->
- </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 abré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
-préciser bash 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 d'une 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. Nous documentons également plusieurs des meilleures
- pratiques ici.
- <p>
-Ces lignes directives incluent plusieurs recommandations de style d'écriture et
-de typographie, des considérations générales à propos de l'utilisation de
-debconf ainsi que des recommandations plus spécifiques pour certaines parties de
-la distribution (par exemple, le système d'installation).
-
- <sect1>N'abusez pas de debconf
- <p>
-Depuis que debconf est apparu dans Debian, il a été largement abusé et plusieurs
-critiques reçues par la distribution Debian proviennent d'utilisation abusive de
-debconf avec la nécessité de répondre à un grand nombre de questions avant
-d'avoir n'importe quel petit logiciel d'installé.
- <p>
-Garder les notes d'utilisation à leur place : le fichier NEWS.Debian ou le
-fichier README.Debian. N'utilisez des notes que pour des notes importantes
-qui peuvent directement concerner l'utilisation du paquet. Rappelez-vous que les
-notes bloqueront toujours l'installation avant leur confirmation ou qu'elles
-embêtent l'utilisateur par un courriel.
- <p>
-Choisissez avec soin les priorités des questions dans les scripts de
-responsable. Reportez-vous à <manref name="debconf-devel" section="7"> pour plus
-de détails sur les priorités. La plupart des questions devraient utiliser un
-priorité moyenne ou basse.
-
- <sect1>Recommandations générales pour les auteurs et traducteurs
- <p>
- <sect2>Écrivez un anglais correct
- <p>
-La plupart des responsables de paquets Debian n'ont pas l'anglais comme langue
-maternelle. Écrire des modèles correctement rédigés peut donc ne pas être facile
-pour eux.
- <p>
-Veuillez utiliser (et abuser de) la liste de discussions
-debian-l10n-english@lists.debian.org. Faites relire vos questionnaires.
- <p>
-Des questionnaires écrits incorrectement donne une pauvre image de votre paquet,
-de votre travail... ou même de Debian elle-même.
- <p>
-Évitez le jargon technique autant que possible. Si certains termes vous semble
-courants, ils peuvent être impossibles à expliquer à d'autres personnes. Si vous
-ne pouvez pas les éviter, essayez de les expliquer (en utilisant la description
-étendue). Quand vous faites cela, essayez d'équilibrer la verbosité et la
-simplicité.
-
- <sect2>Être courtois avec les traducteurs
- <p>
-Les questionnaires debconf peuvent être traduits. Debconf, avec son paquet-frêre
-po-debconf, offre un cadre de travail simple pour obtenir des questionnaires
-traduits par les équipes de traduction ou même par des individus isolés.
- <p>
-Veuillez utiliser les questionnaires basés sur gettext. Installez po-debconf sur
-votre système de développement et lisez sa documentation (« man
-po-debconf » est un bon début).
- <p>
-Évitez de changer vos questionnaires trop souvent. Modifier le texte des
-questionnaires entraîne plus de travail pour les traducteurs dont les
-traductions seront rendues « floues » (« fuzzy »). Si vous
-prévoyez des modifications dans vos questionnaires d'origine, veuillez contacter
-les traducteurs. La plupart des traducteurs actifs sont très réactifs et obtenir
-leur travail inclus avec vos questionnaires modifiés vous économisera des envois
-supplémentaires. Si vous utilisez des modèles basés sur gettext, le nom et
-l'adresse électronique du traducteur sont mentionnés dans les en-têtes des
-fichiers PO.
- <p>
-En cas de doutes, vous pouvez également contacter l'équipe de traduction pour
-une langue donnée (debian-l10n-xxxxx@lists.debian.org) ou la liste de discussions
-debian-i18n@lists.debian.org.
-
- <sect2>Ne faites pas de suppositions à propos des interfaces
- <p>
-Le texte des modèles ne doit pas faire référence aux composants appartenant à
-l'une des interfaces debconf. Des phrases comme « If you answer
-Yes... » n'a aucun sens pour les utilisateurs d'interfaces graphiques qui
-utilisent des cases à cocher pour les questions booléennes.
- <p>
-Plus généralement, essayez d'éviter de vous référer à toute action de
-l'utilisation. Donnez simplement des faits.
-
- <sect2>N'utilisez pas la première personne
- <p>
-Vous devriez éviter d'utiliser la première personne (« I will do
-this... » ou « We recommend... »). L'ordinateur n'est pas une
-personne et les qustionnaires debconf ne parlent pas pour les développeurs
-Debian. Vous devriez utiliser une construction neutre et souvent une forme
-passive. Pour ceux d'entre vous qui écrivent déjà des publications
-scientifiques, écrivez simplement vos questionnaires comme vous écriveriez un
-papier scientifique.
-
- <sect2>Soyez neutre dans le genre
- <p>
-Le monde est fait d'hommes et de femmes. Veuillez utiliser des constructions
-neutres dans le genre dans votre texte. Ce n'est pas du politiquement correct,
-c'est simplement montrer du respect pour toute l'humanité.
-
-
- <sect1>Définition des champs de questionnaires
- <p>
-Cette partie donne plusieurs informations qui sont principalement extraites de
-la page de manuel <manref name="debconf-devel" section="7">.
-
- <sect2>Type
- <p>
-
- <sect3>string: (chaîne de caractères)
- <p>
-Résulte en un champ d'entrée libre dans lequel l'utilisateur peut écrire toute chaîne.
-
- <sect3>password: (mot de passe)
- <p>
-Demande un mot de passe à l'utilisateur. Veuillez utiliser ce champ avec
-précaution ; soyez conscient que le mot de passe que l'utilisateur entre
-sera écrit dans la base de données debconf. Vous devriez probablement enlever
-cette valeur de la base de données dès que possible.
-
- <sect3>boolean: (booléen)
- <p>
-Un choix vrai/faux. Rappelez-vous : vrai/faux, PAS OUI/NON...
-
- <sect3>select: (sélection)
- <p>
-Un choix parmi un certain nombre de valeurs. Les choix doivent être spécifiés
-dans un champ nommé « Choices ». Séparez les valeurs possibles par des
-virgules et des espaces ainsi : Choices: yes, no, maybe
-
- <sect3>multiselect: (sélection multiple)
- <p>
-Comme le type de données select, excepté que l'utilisateur peut choisir un
-nombre quelconque d'éléments dans la liste de choix (ou aucun d'entre eux).
-
- <sect3>note: (note)
- <p>
-Plutôt que d'être une question en tant que telle, ce type de donnée indiqué une
-note qui peut être affichée à l'utilisateur. Il ne devrait être utilisé que
-pour des données importantes que l'utilisateur doit réellement voir, car debconf
-fera tout ce qu'il peut pour s'assurer que l'utilisateur le voit ; il
-stoppera l'installation en attendant que l'utilisateur appuie sur une touche ou
-il leur enverra même la note par courrier dans certains cas.
-
- <sect3>text: (texte)
- <p>
-Ce type est maintenant considéré comme obsolète : ne l'utilisez pas.
-
- <sect3>error: (erreur)
- <p>
-<strong>CE TYPE DE MODÈLE N'EST PAS ENCORE GÉRÉ PAR DEBCONF.</strong>
- <p>
-Il a été ajouté à cdebconf, la version C de debconf, utilisé en premier dans
-l'installateur Debian.
- <p>
-Veuillez ne pas l'utiliser à moins que debconf ne le prennent en charge.
- <p>
-Ce type est conçu pour gérer des messages d'erreur. Il est presque semblable au
-type « note ». Des interfaces peuvent le présenter différemment (par
-exemple, l'interface dialog de cdebconf affiche un écran rouge au lieu de
-l'écran bleu habituel).
-
-
- <sect2>Description: description courte et étendue
- <p>
-Les descriptions des modèles sont composées de deux parties : une courte et
-une étendu. La description courte est dans la ligne « Description: »
-du questionnaire.
- <p>
-La description courte devrait être gardée courte (50 caractères ou moins)
-poru qu'elle puissent être ajustée par la plupart des interfaces debconf. La
-garder courte aide également les traducteurs, car les traductions ont tendance à
-être plus longue que l'originale.
- <p>
-La description courte devrait se suffire à elle-même. Certaines interfaces
-n'affichent pas la description longue par défaut ou seulement si l'utilisateur
-la demande explicitement ou même ne l'affichent pas du tout. Évitez des choses
-comme « What do you want to do ? ».
- <p>
-Il n'est pas nécessaire que la description courte soit une phrase complète. Cela
-fait partie de la recommandation « gardez-la courte et efficace ».
- <p>
-La description étendu ne devrait pas répétée la description courte mot pour mot.
-Si vous ne trouvez pas de description longue, commencez par à y réfléchir plus.
-Envoyez un message sur debian-devel. Demandez de l'aide. Suivez un cours
-d'écriture ! La description étendue est imprtante. Si, après tout cela,
-vous ne trouvez toujours rien, laissez-la vide.
- <p>
-La description étendue devrait utiliser des phrases complètes. Des paragraphes
-devraient être gardés court pour améliorer la lisibilité. Ne mélangez pas deux
-idées dans le même paragrpahe, mais utilisez plutôt un autre paragraphe.
- <p>
-Ne soyez pas trop verbeux. Certaines interfaces debconf ne gèrent pas très bien
-les descriptions de plus de 20 lignes, essayez donc de les conserver sous
-cette limite.
- <p>
-Pour des règles spécifiques selon le type de questionnaire (chaîne de
-caractères, booléen, etc.), veuillez lire ci-dessous.
-
- <sect2>Choices (choix)
- <p>
-Ce champ devrait utilisé pour des types Select et Multiselect. Il contient les
-choix possibles qui seront présentés aux utilisateurs. Ces choix devraient être
-séparés par des virgules.
-
-
- <sect2>Default (valeur par défaut)
- <p>
-Ce champ est facultatif. Il contient la réponse par défaut pour les modèles
-chaîne de caractères, sélection et multi-sélection. Pour des questionnaires
-multi-sélection, il peut contenir une liste de choix séparés par des virgules.
-
- <sect1>Guide de style spécifique par champ de questionnaires
- <p>
-
- <sect2>Champ Type
- <p>
-Aucun indication spécifique excepté : utilisez le type approprié en vous
-référant à la section précédente.
-
- <sect2>Champ Description
- <p>
-Voici ci-dessous des instructions spécifiques pour écrire correctement la
-description (courte et étendue) selon le type de questionnaire.
-
- <sect3>questionnaire chaîne de caractères/mot de passe
- <p>
-<list>
-<item> La description courte est une invite et NON un titre. Évitez des invites
- de style question (« IP Address? ») en faveur d'invites
- « ouvertes »à (« IP address: »). L'utilisation des
- deux-points est recommandée.
-
-<item> La description étendue est un complément à la description courte. Dans la
- partie étendue, expliquez ce qui est demandé, plutpot que de poser la même
- question à nouveau en utilisant des mots plus longs. Utilisez des phrases
- complètes. Un style d'écriture trop concis est fortement découragé.
-</list>
-
- <sect3>modèles booléens
- <p>
-<list>
-<item> La description courte devrait être rédigée sous la forme d'une question
- qui devrait être gardée courte et devrait généralement se termier par un
- point d'interrogation. Un style d'écriture concis est permis et même
- encouragé si la question est plutôt longue (rappelez-vous que les
- traductions sont souvent plus longue que les versions d'origine)
-
-<item> La description étendu ne devrait PAS inclure de question.
-
-<item> À nouveau, veuillez éviter de vous référer à des composants d'interface
- spécifiques. Une erreur courante pour de telles questionnaires est les
- constructions du type « if you answer Yes ».
-</list>
-
- <sect3>sélection/multi-sélection
- <p>
-<list>
-<item> La description courte est une invite et NON un titre. N'utilisez PAS des
- constructions inutiles du type « Please choose... ». Les
- utilisateurs sont assez intelligents pour réaliser qu'ils doivent choisir
- quelque chose...:)
-
-<item> La description étendu devra compléter la description courte. Elle peut se
- référer aux choix disponibles. Elle peut également mentionner que
- l'utilisateur peut choisir plus d'un des choix disponibles si le
- questionnaire est du type sélection multiple (bien que l'interface rende
- soivent cela clair).
-</list>
-
- <sect3>Notes
- <p>
-<list>
-<item> La description courte devrait être considéré comme un *titre*.
-
-<item> La description étendue est ce qui sera affiché comme une description plus
- détaillée de la note. Faites de phrases, n'utilisez pas un style d'écriture
- trop concis.
-
-<item> N'ABUSEZ PAS DE DEBCONF. Les notes sont le moyen le plus courant d'abus
- de debconf. Comme il est écrit dans la page de manuel de
- debconf-devel : il est préférable de ne les utiliser que pour des
- avertissements à propos de problèmes très sérieux. Les fichiers NEWS.Debian
- ou README.Debian sont les endroits appropriés pour un grand nombre de notes.
- Si, en lisant ceci, vous envisagez de convertir vos modèles de type note en
- entrées dans NEWS/Debian ou README.Debian, veuillez considérer de conserver
- les traductions existantes pour une utilisation future.
-</list>
-
-
- <sect2>Champ de choix
- <p>
-S'il est probable que les choix changent souvent, veuillez considérer
-l'utilisation de l'astuce « __Choices ». Cela séparera chaque choix
-individuel en une chaîne de caractères seule, ce qui aidera considérablement les
-traducteurs à faire leur travail.
-
- <sect2>Champ par défaut
- <p>
-S'il est probable que la valeur par défaut d'un modèle « select »
-change selon la langue de l'utilisateur (par exemple, s'il s'agit d'un choix de
-langue), veuillez utiliser l'astuce « _DefaultChoice ».
- <p>
-Ce champ spécial permet aux traducteurs de positionner le choix le plus
-approprié selon leur propre langue. Cela deviendra le choix par défaut quand
-leur langue sera sélectionné alors votre choix par défaut sera utilisé pour
-l'anglais.
- <p>
-Un exemple tiré des modèles du paquet geneweb :
-<example>
-Template: geneweb/lang
-Type: select
-__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
-# This is the default choice. Translators may put their own language here
-# instead of the default.
-# WARNING : you MUST use the ENGLISH FORM of your language
-# For instance, the french translator will need to put "French (fr)" here.
-_DefaultChoice: English (en)[ translators, please see comment in PO files]
-_Description: Geneweb default language:
-</example>
- <p>
-Notez l'utilisation de crochets qui permettent des commentaires internes dans
-les champs debconf. Notez également l'utilisation de commentaires qui
-apparaîtront dans les fichiers sur lesquels travailleront les traducteurs.
- <p>
-Les commentaires sont nécessaires car l'astuce DefaultChoice est un peu
-déroutante : les traducteurs peuvent y placer leur propre choix.
-
- <sect2>Champ par défau
- <p>
-N'utilisez PAS de champ par défaut vide. Si vous ne voulez pas utiliser de
-valeurs par défaut, n'utilisez pas simplement pas du tout Default.
- <p>
-Si vous utilisez po-debconf (et vous DEVRIEZ le faire, voir 2.2), veuillez
-considérer de rendre ce champ traduisible, si vous pensez qu'il peut être
-traduit.
- <p>
-Si la valeur par défaut peut varier selon la langue ou le pays (par exemple, la
-valeur par défaut pour un choix de langue), veuillez considérer l'utilisation du
-type spécial « _DefaultChoice » documenté dans <manref
- name="po-debconf" section="7">).
- </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;.
-<!-- TODO: mozilla extension policy, once that becomes available -->
-</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