<!-- common, language independant entities -->
<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.17 $">
+ <!entity cvs-rev "$Revision: 1.23 $">
<!-- if you are translating this document, please notate the RCS
revision of the developers reference here -->
<!--
- <!entity cvs-en-rev "1.70">
+ <!entity cvs-en-rev "1.71">
-->
]>
<debiandoc>
<book>
-<title>Manuel de référence du développeur Debian
+<title>Référence du développeur Debian
<author>Adam Di Carlo, responsable actuel <email>aph@debian.org</email>
<author>Christian Schwarz <email>schwarz@debian.org</email>
<author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
<author>
-<author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.fr</email>
-<author>avec la participation de Alain Meessen
-<author>et des membres de la liste
+<author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.org</email>
+<author>et les membres de la liste
<email>debian-l10n-french@lists.debian.org</email>
-<version>version &version;, &date-fr;
+<version>Version &version;, &date-fr; (version française 20011227).
<copyright>
<p>
Ce manuel est un logiciel libre ; il peut être redistribué et/ou modifié selon
-les termes de la licence grand public du projet GNU (GNU GPL), telle que
+les termes de la licence publique générale du projet GNU (GNU GPL), telle que
publiée par la « Free Software Foundation » (version 2 ou toute
version supérieure).
<p>
Il est distribué dans l'espoir qu'il sera utile, mais <em>sans aucune
garantie</em>, sans même la garantie implicite d'une possible valeur marchande
-ou d'une adéquation à un besoin particulier. Consultez la licence grand public
+ou d'une adéquation à un besoin particulier. Consultez la licence publique générale
du projet GNU pour plus de détails.
<p>
-Une copie de la licence grand public du projet GNU est disponible dans le
+Une copie de la licence publique générale du projet GNU est disponible dans le
fichier &file-GPL; de la distribution Debian GNU-Linux ou sur la toile : <url
-id="&url-gpl" name="la licence grand public du projet GNU">. Vous pouvez
+id="&url-gpl" name="la licence publique générale du projet GNU">. Vous pouvez
également l'obtenir en écrivant à la &fsf-addr;.
distribution. Bogues de gravité <em>critique</em>, <em>grave</em>
et <em>sérieuse</em>. Ces bogues ne doivent pas apparaître dans une
distribution <em>stable</em>. Ils doivent être corrigés ou bien les
- paquets en cause doivent être supprimés (<ref id="rc-bug">).
+ paquets en cause doivent être supprimés (<ref id="rc-bugs">).
<item><em>Unstable</em> : Nom de la distribution en cours de
développement. Cette distribution contient les paquets envoyés par
<chapt id="developer-duties">Les charges du responsable Debian
- <sect>Mise à jour de vos références Debian
+ <sect id="user-maint">Mise à jour de vos références Debian
<p>
Une base de données LDAP contient de nombreuses informations concernant
Il y a deux choses à faire pour informer les autres développeurs.
Premièrement, envoyer un courrier électronique indiquant vos dates de vacances
à &email-debian-private;, vous pouvez aussi donner quelques instructions pour
-indiquer comment agir si un problème survenait. Deuxièmement, il faut mettre
+indiquer comment agir si un problème survenait. Notez bien que certaines
+personnes ne sont pas intéressées par les annonces de vacances et ne
+veulent pas les lire ; ajoutez '[VAC] ' à l'objet de votre courrier
+pour qu'il soit facilement filtré.
+
+<p>
+Deuxièmement, il faut mettre
à jour la base de données Debian LDAP et vous signaler « en
vacances » (l'accès à cette information est réservé aux développeurs).
N'oubliez pas de retirer votre indicateur « en vacances » lorsque
-celles-ci sont terminées.
+celles-ci sont terminées !
corrigés dans les prochaines versions. Il n'est pas de votre responsabilité
de corriger les bogues qui ne sont pas spécifiques à Debian. Toutefois,
si vous êtes capable de le faire, nous vous encourageons à contribuer au
-développement amont en proposant un <em>patch</em> qui corrige ce bogue.
-Les utilisateurs et responsables Debian proposent souvent des <em>patches</em>
-pour corriger des bogues amonts, il vous faudra alors évaluer ce
-<em>patch</em> puis le transmettre aux développeurs amonts.
+développement amont en proposant une rustine qui corrige ce bogue.
+Les utilisateurs et responsables Debian proposent souvent des rustines
+pour corriger des bogues amonts, il vous faudra alors évaluer cette
+rustine puis la transmettre aux développeurs amonts.
<p>
Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
-paquet conforme à la charte Debian, alors vous devriez proposer un
-<em>patch</em> aux développeurs amonts pour qu'il soit inclus dans leur
+paquet conforme à la charte Debian, alors vous devriez proposer une
+rustine aux développeurs amonts pour qu'elle soit incluse dans leur
version. Ainsi, vous n'aurez plus besoin de modifier les sources lors des
mises à jour amonts suivantes. Quels que soient les changements dont vous
avez besoin, il faut toujours essayer de rester dans la lignée des sources
- <sect id="rc-bug">Gestion des bogues bloquants pour la distribution
+ <sect id="rc-bugs">Gestion des bogues bloquants pour la distribution
<p>
Les bogues bloquants pour la distribution<footnote>Traduction de l'anglais
- <sect1>Experimental
+ <sect1><em>Experimental</em>
<p>
La distribution <em>experimental</em> est une distribution particulière. Ce
<em>unstable</em>. Elle est prévue pour servir de plate-forme de développement
pour les projets expérimentaux qui ont de grandes chances de détruire le
système ou bien pour des logiciels qui sont vraiment trop instables pour être
-inclus dans la distribution <em>unstable</em> (mais qui ont néanmoins une
-bonne raison pour être mis en paquet). Les utilisateurs qui téléchargent et
+inclus dans la distribution <em>unstable</em> (mais pour qui une mise en
+paquet est justifiée). Les utilisateurs qui téléchargent et
installent des paquets depuis
<em>experimental</em> sont prévenus : on ne peut pas faire confiance à la
distribution <em>experimental</em>.
<p>
-S'il y a des chances pour qu'un logiciel cause des dégats importants, il sera
+Si un logiciel risque de causer des dégats importants, il sera
sûrement préférable de le mettre dans la distribution <em>experimental</em>.
Un système de fichier compressé, par exemple, devrait probablement aller dans
<em>experimental</em>.
<p>
-Une nouvelle version amont qui ajoute des nouvelles fonctions et en supprime
-beaucoup de plus anciennes ne devra pas être téléchargée dans l'archive
+Une nouvelle version amont qui ajoute de nouvelles fonctions tout en
+supprimant de nombreuses autres ne devra pas être téléchargée dans l'archive
Debian, elle pourra cependant être téléchargée dans <em>experimental</em>. Une
nouvelle version non finalisée d'un logiciel qui utilise une méthode de
configuration complètement différente pourrait aller dans
-<em>experimental</em> à la discrétion du responsable. Si vous travaillez sur
+<em>experimental</em> au gré du responsable. Si vous travaillez sur
un cas de mise à jour complexe ou incompatible vous pouvez aussi utiliser
<em>experimental</em> comme plate-forme d'intégration et ainsi fournir un
accès aux testeurs.
<em>stable</em>.
<p>
-Un nouveau logiciel qui a peu de chance d'endommager le système ira
+Un nouveau logiciel qui ne risque pas d'endommager le système ira
directement dans <em>unstable</em>.
<p>
</list>
- <sect1 id="upload-checking">Vérifier le paquet avant la mise à jour
+ <sect id="upload-checking">Vérifier le paquet avant la mise à jour
<p>
Avant de mettre à jour votre paquet vous ferez quelques tests de base. Vous
devrez au moins faire les tests suivants (il vous faut une ancienne version
-du paquet pour cela) :
+du paquet) :
<list compact>
<item>
Installez le paquet et vérifiez que le logiciel fonctionne. Si le
<prgn>lintian</prgn> comme suit : <tt>lintian -v
<var>package-version</var>.changes</tt>. Ce programme fera une
vérification sur les paquets source et binaire. Si vous ne comprenez
- pa
r les messages générés par <prgn>lintian</prgn> essayez l'option
+ pa
s les messages générés par <prgn>lintian</prgn> essayez l'option
<tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
bavard dans sa description du problème.
<p>
amont donnée, le fichier <tt>tar</tt> de cette version amont doit être
téléchargé et mentionné dans le fichier <tt>.changes</tt>. Par la suite, ce
fichier <tt>tar</tt> sera utilisé pour générer les fichiers <tt>diff</tt> et
-<tt>.dsc</tt> et il ne sera pas nécessaire de le re-télécharger.
+<tt>.dsc</tt> et il ne sera pas nécessaire de le télécharger à nouveau.
<p>
Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn>
<p>
Si la mise à jour ne contient pas le fichier <tt>tar</tt> des sources
originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
-fichiers <tt>.dsc</tt> et <tt>diff</tt> de la mise à jour, utiliser un fichier
+fichiers <tt>.dsc</tt> et <tt>diff</tt> de la mise à jour, utilisez un fichier
<tt>tar</tt> identique à l'octet près à celui sur le serveur. Si pour une
raison ou pour une autre il y a une différence, la nouvelle version de ce
fichier doit à nouveau être incluse dans la mise à jour (en utilisant l'option
important car même une modification triviale peut causer un bogue plus
tard. Livrer une nouvelle version amont d'un logiciel pour corriger un
problème de sécurité est désapprouvé ; dans la plupart des cas la
-bonne solution consiste à prendre le <em>patch</em> correspondant de la
+bonne solution consiste à prendre la rustine correspondante de la
nouvelle version amont et à l'appliquer à l'ancienne (faire un
-<em>backport</em> du <em>patch</em>).
+portage (<em>backport</em>) de la rustine.
<p>
Les paquets livrés pour <em>stable</em> doivent être compilés avec la
distribution <em>stable</em> pour que leurs dépendances se limitent aux
bibliothèques (et autres paquets) disponibles dans <em>stable</em> ;
un paquet livré pour la distribution <em>stable</em> qui dépend d'une
-librairie qui n'est disponible que dans <em>unstable</em> sera rejeté.
+bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté.
Modifier les dépendances d'autres paquets (en manipulant le champ
<tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
ininstallables, est fortement déconseillé.
<p>
Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs
possibilités. L'une d'elles consiste à télécharger vos fichiers dans
-<tt>Incoming</tt> en passant par le serveur <tt>chiark</tt> en Europe. Comme
-cette file d'attente des mises à jour est redirigée vers <tt>ftp-master</tt>,
+<tt>Incoming</tt> en passant par le serveur <tt>chiark</tt> en Europe. Pour
+les détails consultez <url id="&url-chiark-readme;">.
+
+<p>
+Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux
+lois de contrôle des exportations américaines sur <tt>chiark</tt>.
+Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>,
les indications de la section <ref id="upload-ftp-master"> sont applicables ici
aussi.
processus.
<p>
-<em>Note :</em> ne téléchargez pas de paquets contenant des logiciels tombant
-sous le coup de la loi de contrôle des exportations américaine sur
-<tt>erlangen</tt>. Comme les paquets téléchargés ici vont vers
-<tt>ftp-master</tt>, les règles décrites dans la section <ref
-id="upload-ftp-master"> sont applicables ici aussi.
+Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux
+lois de contrôle des exportations américaines sur <tt>erlangen</tt>.
+Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>,
+les indications de la section <ref id="upload-ftp-master"> sont applicables ici
+aussi.
<p>
Le programme <prgn>dupload</prgn> est capable de télécharger sur
indépendantes. Un responsable officiel est une personne dont la clé est dans
le porte-clés Debian. Toute personne est invitée à télécharger les paquets
sources pour corriger des bogues ; au lieu de faire des mises à jour
-indépendantes, ils pourront soumettre les <em>patch</em> qui le méritent au
+indépendantes, ils pourront soumettre les rustines qui le méritent au
système de suivi des bogues. Les responsables apprécient presque toujours les
-<em>patch</em> et les rapports de bogue soignés.
+rustines et les rapports de bogue soignés.
<sect id="nmu-when">Quand faire une mise à jour indépendante source ?
pour corriger le bogue. Donnez-lui quelques jours.
<item>
- Lancez-vous. Corrigez le bogue et envoyez votre <em>patch</em> au système de
+ Lancez-vous. Corrigez le bogue et envoyez votre rustine au système de
suivi des bogues. Construisez le paquet et testez-le comme décrit dans
la section <ref id="upload-checking">. Utilisez le paquet chez vous.
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 <em>patch</em> aussi petit que
+corrigez pas ce qui n'est pas cassé. Faites une rustine aussi petite que
possible. Si certaines choses froissent votre sens de l'esthétique, parlez-en
au responsable du paquet, au responsable amont ou soumettez un rapport de
bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent pas</em>
à 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. Si nécessaire, ouvrez des rapports de bogue
-avec les <em>patch</em> correspondants ou assurez-vous que l'un des rapports de
-bogue déjà ouverts comporte ces <em>patch</em>.
+avec les rustines correspondantes ou assurez-vous que l'un des rapports de
+bogue déjà ouverts comporte ces rustines.
<p>
-Le responsable officiel pourra choisir d'appliquer le <em>patch</em>, il pourra aussi
+Le responsable officiel pourra choisir d'appliquer la rustine, il pourra aussi
employer une autre méthode pour régler le problème. Certains bogues sont
corrigés dans la version amont, ce qui est une bonne raison pour annuler les
modifications d'une mise à jour indépendante. Si le responsable choisit de
-mettre à jour le paquet sans utiliser les <em>patch</em> de la mise à jour
+mettre à jour le paquet sans utiliser les rustines de la mise à jour
indépendante, il devra s'assurer que cette nouvelle version corrige
effectivement chacun des bogues corrigés dans la mise à jour indépendante.
autres. Sélectionnez une distribution en utilisant les règles décrites dans
la section <ref id="upload-dist"> et construisez un fichier <tt>.changes</tt>
classique avec tout ce qui l'accompagne conformément à la description <ref
-id="upload">.
+id="uploading">.
<p>
En fait, toutes les prescriptions de la section <ref id="upload"> sont
~ianmdlvl / developers-reference.git / blobdiff