X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.fr.sgml;h=a19b95f4373c803fb29880857c415ad5cb5baa1b;hb=56be954825226e76604cd85b6e781ad141cc9389;hp=a6a076d136bafd1e836d2e4cf89c6b6b8825b85f;hpb=8d178df39aeb90c802320e15b17c308c5077174b;p=developers-reference.git diff --git a/developers-reference.fr.sgml b/developers-reference.fr.sgml index a6a076d..a19b95f 100644 --- a/developers-reference.fr.sgml +++ b/developers-reference.fr.sgml @@ -4,12 +4,13 @@ %versiondata; %commondata; + %dynamicdata; - + - + FIXME: "> @@ -30,10 +31,10 @@ version française par Frédéric Bothamy (traducteur actuel) et Antoine Hulin (ancien traducteur) et les membres de la liste debian-l10n-french@lists.debian.org - Version &version;, &date-fr; (version française 20050109). + Version &version;, &date-fr; (version française 20050412). - Copyright © 2004 Andreas Barth + Copyright © 2004—2005 Andreas Barth Copyright © 1998—2003 Adam Di Carlo Copyright © 2002—2003 Raphaël Hertzog Copyright © 1997, 1998 Christian Schwarz. @@ -54,6 +55,12 @@ le fichier &file-GPL; de la distribution &debian-formal; ou sur la toile : . Vous pouvez également l'obtenir en écrivant à la &fsf-addr;. + +Si vous désirez imprimer cette référence, vous devriez utiliser la . +]]> + Portée de ce document @@ -250,7 +257,34 @@ Quand vous avez choisi la mani l'assurance qualité (QA), vous pouvez contacter les responsables qui travaillent déjà sur ces tâches et proposer des correctifs et des améliorations. + + Mentors et parrains Debian +

+La liste de diffusion &email-debian-mentors; a été mise en place pour +les responsables débutants recherchant de l'aide avec l'empaquetage +initial et d'autres problèmes de développeur. Chaque nouveau développeur +est invité à s'abonner à cette liste (voir pour +les détails). +

+Ceux qui préfère recevoir une aide plus personnalisée (par exemple, par +courriels privés) devraient également envoyer des messages à cette liste +et un développeur expériementé se proposera de les aider. +

+De plus, vous avez des paquets prêts à être inclus dans Debian, mais que +vous attendez que votre demande pour devenir responsable soit acceptée, +vous pouvez trouver un parrain pour envoyer vos paquets pour vous. Les +parrains sont des développeurs Debian officiels qui sont volontaires +pour critiquer et envoyer vos paquets pour vous. + +Veuillez lire en premier la FAQ non officielle de debian-mentors à . +

+Si vous désirez être un mentor et/ou un parrain, vous pouvez trouver +plus d'informations à . S'enregistrer comme responsable Debian

@@ -277,7 +311,7 @@ Le processus d'enregistrement a pour but de v

Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail et que vous serez un bon contributeur. Pour cela, vous pourrez proposer des correctifs - par le système de suivi des bogues (BTS) ou maintenir un paquet parrainé + par le système de suivi des bogues (BTS) et maintenir un paquet parrainé pendant un temps. Nous attendons aussi des contributeurs qu'ils soient intéressés par le projet dans son ensemble et pas uniquement par leurs propres paquets. Si vous pouvez aider d'autres responsables en fournissant des @@ -289,12 +323,11 @@ Pour votre candidature, vous devrez signée, vous devriez essayer de rencontrer un responsable Debian pour le faire. La devrait vous aider à trouver un responsable Debian près de chez vous. - (Si vous ne trouvez pas de responsable près de chez vous, il existe un second - moyen pour valider votre identité. Vous pouvez envoyer une photo d'identité - signée avec votre clé GnuPG. Privilégiez tout de même la clé GnuPG signée pour - valider une identité. Reportez-vous à la pour en savoir plus sur ces deux options). - + (S'il n'y a pas de responsable près de chez vous, il peut y + avoir des moyens alternatifs pour valider votre identité en tant + qu'exception absolue étudiée au cas par cas. Veuillez vous + reporter à la pour en savoir plus).

Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin d'une clé OpenPGP pour signer et vérifier les mises à jour de paquets. Vous lirez la @@ -311,9 +344,8 @@ Debian utilise GNU Privacy Guard (paquet gnupg id="&url-rfc2440;" name="RFC 2440">.

-L'algorithme à clé publique recommandé pour les développements Debian est DSA - (parfois appelé « DSS » ou « DH\ElGamal »). Vous pouvez - aussi utiliser d'autres types de clés. La longueur de votre clé doit être au +Vous avez besoin d'une clé de type 4 à utiliser pour le + développement Debian. La longueur de votre clé doit être au minimum de 1024 bits ; il n'y a pas de raison d'utiliser une clé plus courte et le faire serait beaucoup moins sûr. Votre clé doit être signée avec votre propre identifiant ; cela évite les falsifications. GNU @@ -328,8 +360,7 @@ Si votre cl Certains pays limitent l'usage des logiciels de cryptographie. Cela ne devrait cependant pas avoir d'impact sur l'activité d'un responsable de paquet car il peut être tout à fait légal d'utiliser des logiciels de cryptographie pour - l'authentification plutôt que pour le chiffrement. &debian-formal; ne nécessite - en aucune façon l'utilisation de chiffrement. Si vous vivez dans un pays où + l'authentification plutôt que pour le chiffrement. Si vous vivez dans un pays où l'utilisation de la cryptographie pour authentification est interdite, contactez-nous pour que nous prenions des dispositions particulières.

@@ -356,27 +387,6 @@ Pour en savoir plus, consultez le Mentors et parrains Debian -

-La liste de diffusion &email-debian-mentors; a été créée pour les responsables - débutants qui cherchent de l'aide pour leur première création de paquet ainsi - que pour des problèmes spécifiques aux développeurs. Tout responsable débutant - est invité à s'y inscrire (voir pour plus de détails). -

-Ceux qui préfèrent une aide personnalisée (via une correspondance privée) - doivent aussi poster dans cette liste, un développeur expérimenté se portera - volontaire pour les aider. -

-Si vos paquets sont prêts à être intégrés mais que vous attendiez le - résultat de votre candidature, vous pouvez chercher un parrain qui téléchargera - les paquets à votre place. Les parrains sont des responsables Debian officiels - volontaires pour examiner et télécharger vos paquets. Vous pouvez - demander un parrainage à l'adresse . Veuillez tout - d'abord lire la FAQ non officielle de debian-mentors à . -

-Si vous désirez être mentor ou parrain, reportez-vous à . - - Les charges du responsable Debian Mise à jour de vos références Debian @@ -476,6 +486,14 @@ L'autre chose base de données Debian LDAP (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 ! +

+Idéalement, vous devriez vous connecter sur le + +quand vous réservez pour des vacances et vérifier si quelqu'un recherche +un échange de signatures. Cela est particulièrement important quand des +personnes vont à des endroits exotiques où nous n'avons pas encore de +développeurs, mais où il y a des personnes intéressées pour poser leur +candidature. Coordination avec les développeurs amont

@@ -662,10 +680,8 @@ Comme #debian-devel est un canal ouvert, vous ne devriez pas y parler

Il existe d'autres canaux dédiés à des sujets spécifiques. #debian-bugs est utilisé pour la coordination des chasses aux bogues. - #debian-boot est utilisé pour la coordination du travail sur les - disquettes de démarrage (i.e., l'installateur). - -#debian-doc est utilisé + #debian-boot est utilisé pour la coordination du travail sur + l'installateur Debian. #debian-doc est utilisé occasionnellement pour travailler sur la documentation comme celle que vous lisez actuellement. D'autres canaux sont dédiés à une architecture ou un ensemble de paquets : #debian-bsd, #debian-kde, @@ -679,6 +695,17 @@ Certains canaux pour d Il existe également des canaux dédiés pour Debian sur d'autres réseaux IRC, notamment sur le réseau IRC . +

+Pour obtenir un uniforme (« cloak ») sur freenode, vous devez +envoyer un courriel signé à Göran Weinholt +<weinholt@debian.org> dans lequel vous indiquez quel est votre +pseudonyme (« nick ». Mettez « cloak » quelque part +dans le sujet. Votre pseudonyme devrait être enregistré : +. Le courriel doit être signé par une clé +du porte-clés Debian. Veuillez consulter la + pour plus d'informations sur les uniformes. Documentation @@ -1227,11 +1254,19 @@ Le syst &ftp-master-host; et sur &non-us-host;.

Les paquets sont envoyés par tous les responsables Debian dans un répertoire - nommé unchecked. Ce répertoire est parcouru toutes les 15 minutes + nommé UploadQueue. Ce répertoire est parcouru toutes les + quelques minutes par un démon appelé queued, les fichiers + *.command sont exécutés et les fichiers + *.changes restants et correctement signés sont déplacés + avec leurs fichiers correspondants dans le répertoire + unchecked. Ce répertoire n'est pas visible de la plupart + des développeurs car ftp-master est à accès restreint ; + il est parcouru toutes les 15 minutes par le script katie qui vérifie l'intégrité des paquets envoyés et leurs signatures de chiffrage. Si le paquet est considéré comme prêt à être installé, il est déplacé dans le répertoire accepted. S'il s'agit - du premier envoi du paquet, il est déplacé dans le répertoire new + du premier envoi du paquet (ou s'il a de nouveaux paquets binaire), il + est déplacé dans le répertoire new où il attend l'approbation des ftpmasters. Si le paquet contient des fichiers devant être installés à la main, il est déplacé dans le répertoire byhand où il attend une installation manuelle par les ftpmasters. @@ -1241,10 +1276,11 @@ Les paquets sont envoy Une fois que le paquet est accepté, le système envoie une confirmation par courrier au responsable et ferme les bogues corrigés par l'envoi, puis les compilateurs automatiques peuvent commencer la recompilation. Le paquet est - maintenant accessible publiquement à (une telle - adresse n'existe pas pour les paquets de l'archive non-US) jusqu'à ce qu'il - soit vraiment installé dans l'archive Debian. Ceci se produit seulement une - fois par jour, le paquet est alors supprimé de Incoming et + maintenant accessible publiquement à jusqu'à + ce qu'il soit vraiment installé dans l'archive Debian. Cela se produit + seulement une fois par jour (et c'est également appelé une + « exécution dinstall » pour des raisons historiques) ; + le paquet est alors supprimé de Incoming et installé dans le pool avec les autres paquets. Une fois que toutes les autres mises à jour (fabrication des nouveaux fichiers d'index Packages et Sources par exemple) ont été effectuées, un script spécial est @@ -1259,6 +1295,10 @@ de diffusion appropri « experimental », l'annonce sera à la place envoyée à &email-debian-devel-changes;.

+Bien que ftp-master soit à accès restreint, une copie de l'installation + est disponible à tous les développeurs sur &ftp-master-mirror;. + Informations sur un paquet

@@ -2171,7 +2211,10 @@ Voici une liste des Si le bogue est réel, mais est causé par un autre paquet, réattribuez simplement le bogue à l'autre paquet. Si vous ne savez pas à quel paquet il doit être réattribué, vous pouvez demander de l'aide sur - IRC" ou sur &email-debian-devel;. + IRC ou sur &email-debian-devel;. + Veuillez vous assurer que le (ou les) responsable(s) du paquet + sur lequel est réattribué le paquet sait pourquoi vous l'avez + ainsi réattribué.

Parfois, vous devez également ajuster la gravité du bogue pour qu'elle corresponde à notre définition de gravité des bogues. C'est dû au @@ -2180,6 +2223,19 @@ Voici une liste des certains bogues peut même être rétrogradée en wishlist (souhait) quand le changement demandé est seulement d'ordre cosmétique. + + Si le bogue est réel, mais que le problème a déjà été rapporté + par quelqu'un d'autre, les deux rapports de bogues pertinents + devraient être fusionnés en un seul en utilisant la commande + merge (fusion) du BTS. Ainsi, quand le bogue sera + corrigé, tous les créateurs de rapport de bogue en seront + informés (notez, cependant, que les courriels envoyés à l'un des + créateurs de rapport de bogue ne seront pas automatiquement envoyés + aux autres créateurs de rapport de bogue). Pour plus de + détails sur les technicités de la commande de fusion et sa + voisine, la commande unmerge (séparation), veuillez + consulter la documentation du serveur de contrôle du BTS. + Le rapporteur de bogue peut avoir oublié de fournir certaines informations. Dans ce cas, vous devez lui demander les informations @@ -3319,6 +3375,20 @@ Seuls les responsables Debian officiels peuvent faire des mises de suivi des bogues. Les responsables apprécient presque toujours les correctifs et les rapports de bogue soignés. + Comment dak détecte les mises à jour indépendantes +

+Le fait qu'un envoi soit traité par les scripts d'archive et par le +système de suivi des bogues (voir ) comme une mise +à jour indépendante ou comme un envoi par le responsable n'est +pas décidé en regardant le numéro de version (voir ). Au lieu de cela, un envoi est géré comme une mise à +jour indépendante si l'adresse du responsable dans le fichier +.changes n'est pas la même binairement que l'adresse du champ +Maintainer ou que l'une des adresses du champ Uploaders +du fichier dsc et également si l'adresse du responsable n'est +pas spéciale (c.-à-d. elle n'est pas positionnée à l'adresse du groupe +d'Assurance Qualité). + Terminologie

Deux nouvelles expressions sont introduites dans cette section : @@ -3426,7 +3496,8 @@ une version candidate stable. Veuillez voir ci-dessous pour les d Mises à jour depuis unstable

Les scripts qui mettent à jour la distribution testing sont exécutés - chaque jour après l'installation des paquets mis à jour. Ils fabriquent les + chaque jour après l'installation des paquets mis à jour ; ces + scripts sont appelés britney. Ils fabriquent les fichiers Packages pour la distribution testing, mais ils le font d'une manière intelligente pour éviter toute incohérence et essayer de n'utiliser que des paquets sans bogue. @@ -3841,7 +3912,7 @@ 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 vim) 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 + l'utilisateur peut n'installer que la partie nécessaire et ainsi économiser de l'espace disque).

Le second cas peut facilement être géré dans le fichier @@ -4009,9 +4080,9 @@ En quoi le paquet est diff une meilleure implémentation ? A-t-il plus de fonctionnalités, des fonctionnalités différentes ? Pourquoi devrait-il choisir ce paquet ? +--> @@ -4357,10 +4428,10 @@ pour eux. Veuillez utiliser (et abuser de) la liste de discussions debian-l10n-english@lists.debian.org. Faites relire vos questionnaires.

-Des questionnaires écrits incorrectement donne une pauvre image de votre paquet, +Des questionnaires écrits incorrectement donnent une pauvre image de votre paquet, de votre travail... ou même de Debian elle-même.

-Évitez le jargon technique autant que possible. Si certains termes vous semble +Évitez le jargon technique autant que possible. Si certains termes vous semblent 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 @@ -4404,7 +4475,7 @@ l'utilisation. Donnez simplement des faits.

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 +personne et les questionnaires 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 @@ -4482,13 +4553,13 @@ l' Description: description courte et étendue

Les descriptions des modèles sont composées de deux parties : une courte et -une étendu. La description courte est dans la ligne « Description: » +une étendue. La description courte est dans la ligne « Description: » du questionnaire.

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 +pour qu'elle puisse ê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. +être plus longues que l'originale.

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 @@ -4498,15 +4569,15 @@ comme 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 ».

-La description étendu ne devrait pas répétée la description courte mot pour mot. +La description étendue ne devrait pas répéter 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, +d'écriture ! La description étendue est importante. Si, après tout cela, vous ne trouvez toujours rien, laissez-la vide.

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. +idées dans le même paragraphe, mais utilisez plutôt un autre paragraphe.

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 @@ -4533,7 +4604,7 @@ multi-s Champ Type

-Aucun indication spécifique excepté : utilisez le type approprié en vous +Aucune indication spécifique excepté : utilisez le type approprié en vous référant à la section précédente. Champ Description @@ -4550,7 +4621,7 @@ description (courte et deux-points est recommandée. 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 + partie étendue, expliquez ce qui est demandé, plutôt 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é. @@ -4564,7 +4635,7 @@ description (courte et encouragé si la question est plutôt longue (rappelez-vous que les traductions sont souvent plus longue que les versions d'origine) - La description étendu ne devrait PAS inclure de question. + La description étendue ne devrait PAS inclure de question. À nouveau, veuillez éviter de vous référer à des composants d'interface spécifiques. Une erreur courante pour de telles questionnaires est les @@ -4579,7 +4650,7 @@ description (courte et utilisateurs sont assez intelligents pour réaliser qu'ils doivent choisir quelque chose...:) - La description étendu devra compléter la description courte. Elle peut se + La description étendue 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 @@ -4644,7 +4715,7 @@ appara Les commentaires sont nécessaires car l'astuce DefaultChoice est un peu déroutante : les traducteurs peuvent y placer leur propre choix. - Champ par défau + Champ par défaut

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. @@ -4680,7 +4751,7 @@ traductions des questionnaires debconf debconf-mergetemplate. Cependant, cette technique est maintenant déconseillée ; la meilleure façon pour l'internationalisation de debconf est d'utiliser le paquet -po-debconf. Cette méthode est plus facile et pour le +po-debconf. Cette méthode est plus facile pour le responsable et pour les traducteurs ; des scripts de transition sont fournis.

@@ -4890,6 +4961,206 @@ description courte. Si vous cherchez des exemples, ex apt-cache search .|grep transitional. + + Les meilleures pratiques pour les fichiers orig.tar.gz +

+Il existe deux types d'archives tar (« tarball ») source +d'origine : les sources vierges et les sources amont réempaquetées. +

+ + Sources vierges +

+La caractéristique définissant une archive source vierge est que le +fichier .orig.tar.gz est identique octet-pour-octet à l'archive tar +officielle distribuée par l'auteur amont. + +Nous ne pouvons pas empêcher les auteurs amont de changer l'archive tar +qu'ils distribuent sans également incrémenter le numéro de version, il +ne peut donc pas y avoir de garantie qu'une archive vierge est identique +à ce que l'auteur amont distribue actuellement à tout moment. +La seule chose à laquelle on peut s'attendre est que c'est identique à +quelque chose que l'amont a un jour distribué. + +Si une différence se produit plus tard (par exemple, si l'amont remarque +qu'il n'a pas utilisé la compression maximale pour sa distribution +d'origine et qu'il la recompresse), c'est vraiment trop dommage. +Comme il n'y a pas de bonne façon d'envoyer un nouveau .orig.tar.gz +pour la même version, il n'y a même pas de raison de traiter cette +situation comme un bogue. + +Cela rend possible d'utiliser des vérifications de somme pour vérifier +facilement que tous les changements entre la version Debian et celle de +l'amont sont contenus dans le fichier diff Debian. Également, si le source +amont est énorme, les auteurs amont et d'autres qui ont déjà l'archive +tar amont peuvent économiser du temps de téléchargement s'ils veulent +inspecter votre empaquetage en détail. +

+

+Il n'y a pas de règles universellement acceptées suivies par les auteurs +amont concernant la structure des répertoires dans leur archive tar, mais +dpkg-source est cependant capable de traiter la plupart des +archives tar comme source vierge. Sa stratégie est équivalente à la +suivante : +

+

+ + +Il décompacte l'archive tar dans un répertoire temporaire vide par + + +zcat path/to/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf - + + + +Si, après cela, le répertoire temporaire ne contient qu'un +répertoire et pas d'autres fichiers, dpkg-source renomme ce +répertoire en +<packagename>-<version-amont>(.orig). Le nom du +répertoire de premier niveau dans l'archive tar n'a pas d'importance et +est oublié. + + +Sinon, l'archive tar a du être empaqueté sans répertoire de premier +niveau commun (honte à l'auteur amont !). Dans ce cas, +dpkg-source renomme le répertoire temporaire +lui-même en +<packagename>-<version-amont>(.orig). + + +

+ + + Réempaquetage des sources amonts +

+Vous devriez envoyer des paquets sources avec une +archive tar vierge si possible, mais il peut y avoir diverses raisons +pour lesquelles cela n'est pas possible. C'est le cas si l'amont ne +distribue pas le source comme un tar gzipé du tout ou si l'archive tar +amont contient du matériel non libre au sens des DFSG que vous devez +supprimer avant l'envoi. +

+

+Dans tous ces cas, le développeur doit construire un fichier +.orig.tar.gz convenable lui-même. Nous nous référérons à une telle +archive tar comme un « source amont réempaqueté ». Notez qu'un +« source amont réempaqueté » est différent d'un paquet natif +Debian. Un source réempaqueté est toujours fourni avec des changements +spécifiques Debian dans un fichier .diff.gz séparé et il a +toujours un numéro de version composé de <source-amont> +et de <debian-revision>. +

+

+Il peut y avoir des cas où il est désirable de réempaqueter le source +même si l'amont distribue un fichier .tar.gz qui pourrait en +principe être utilisé dans sa forme vierge. Le plus évident est si des +économies d'espaces significatives peuvent être réalisées en +recompressant l'archive tar ou en supprimant des parties +fondamentalement inutiles de l'archive source. Agissez à votre guise à +cet endroit, mais soyez prêt à défendre votre décision si vous +réempaquetez un source qui aurait pu être vierge. +

+

+Un .orig.tar.gz réempaqueté : +

+

+ + +

+doit contenir des informations détaillées sur la façon +dont a été obtenu le source réempaqueté et comment cela peut être +reproduit dans le fichier README.Debian-source ou un +fichier similaire. Ce fichier devrait être dans la partie +diff.gz du paquet source Debian, habituellement dans le +répertoire debian, pas dans le +orig.tar.gz réempaqueté. C'est également une bonne idée de +fournir une cible get-orig-source dans votre fichier +debian/rules qui répète le processus, comme décrit dans la +Charte, . +

+ + +ne devrait pas contenir de fichiers qui ne viennent pas de +l'auteur amont ou dont vous avez changé le contenu. + +Comme exception spéciale, si l'omission d'un fichier non libre +entraînerait l'échec de la compilation du source sans assistance du diff +Debian, il peut être approprié au lieu de cela d'éditer les fichiers, en +omettant seulement les parties non libres de ceux-ci et/ou d'expliquer +la situation dans un fichier README.Debian-source + à la racine de l'arborescence du source. Mais +dans ce cas, veuillez également demander instamment à l'auteur amont de +faciliter la séparation des composants non libres du reste du source. + + + +

+devrait, sauf cas impossible pour des raisons légales, +préserver l'infrastructure de construction entière et de portabilité +fournie par l'auteur amont. Par exemple, ce n'est pas une raison +suffisante pour omettre un fichier qui n'est utilisé que pour la +construction sur MS-DOS. De manière similaire, un Makefile fourni par +l'amont ne devrait pas être réécrit en exécutant un script configure. +

+

+(Explication : il est courant que les utilisateurs Debian qui +ont besoin de reconstruire un logiciel pour des plates-formes non-Debian +récupèrent le source d'un miroir Debian plutôt que de chercher à +localiser un point de distribution amont). +

 + +devrait utiliser +<nom-du-paquet>-<version-amont>.orig comme nom du +répertoire de premier niveau dans son archive tar. Cela rend +possible la distinction entre des archives tar vierges d'archives +réempaquetées. + + +devrait être gzipé avec une compression maximale. + + +

+

+La façon canonique de réaliser les deux derniers points est de laisser +dpkg-source -b construire l'archive tar réempaquetée à partir +du répertoire décompacté. +

+ + + Changer des fichiers binaires dans le diff.gz +

+Il est parfois nécessaire de changer des fichiers binaires +contenus dans l'archive tar d'origine ou d'ajouter des fichiers binaires +qui ne sont pas dans celle-ci. Si cela est fait en copiant simplement les +fichiers dans l'arborescence de l'archive debianisée, +dpkg-source ne pourra pas gérer cela. D'un autre côté, +selon les règles détaillées ci-dessus, vous ne pouvez pas inclure un tel +fichier binaire modifié dans un fichier orig.tar.gz +réempaqueté. Au lieu de cela, incluez le fichier dans le répertoire +debian dans un format uuencode (ou semblable) + +Le fichier devrait avoir un nom qui indique clairement quel fichier +binaire il encode. Habituellement, un postfixe indiquant le codage +devrait être ajouté au nom du fichier d'origine. +. +Le fichier sera ensuite décodé et copié à son emplacement pendant +l'étape de construction. Le changement sera donc visible assez facilement. +

+

+Certains paquets utilisent dbs pour gérer les correctifs à +leur source amont et créent toujours un nouveau fichier +orig.tar.gz contenant le vrai orig.tar.gz dans son +répertoire de premier niveau. Cela est discutable concernant la +préférence pour un source vierge. D'un autre côté, il est facile de +modifier ou d'ajouter des fichiers binaires dans ce cas : placez +les simplement dans le fichier orig.tar.gz nouvellement créé à +côté du vrai et copiez les au bon endroit pendant l'étape de +construction. +

+ + + + @@ -4952,8 +5223,8 @@ De temps en temps, vous pourrez vouloir v rapportés, vous avez simplement besoin d'aller à http://&bugs-host;/from:<votre-adresse-de-courrier>. - Ouvrir un grand nombre de rapports d'un seul - coup + Ouvrir un grand nombre de rapports en + une seule fois (« mass bug filing »)

Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de paquets — plus de dix — est une pratique que nous déconseillons. @@ -4962,7 +5233,8 @@ Ouvrir un grand nombre de rapports pour le m paquet lintian pour générer une erreur ou un avertissement.

Si vous ouvrez plus de dix rapports sur le même sujet, il est préférable - d'indiquer votre intention sur la liste &email-debian-devel;. Cela donnera à + d'indiquer votre intention sur la liste &email-debian-devel; et de + mentionner le fait dans le sujet de votre message. Cela donnera à d'autres développeurs la possibilité de vérifier que le problème existe vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent les mêmes rapports de bogue simultanément. @@ -5145,9 +5417,11 @@ Parrainer un paquet veut dire envoyer un paquet pour un responsable qui n'est pas encore autorisé à le faire lui-même, un candidat nouveau responsable. Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité.

+ Les nouveaux responsables ont habituellement certaines difficultés à créer des paquets Debian — ceci est bien compréhensible. C'est pourquoi le parrain est là pour vérifier que le paquet parrainé est assez bon pour être inclus @@ -5256,7 +5530,7 @@ t Pour les messages des programmes, l'infrastructure gettext est utilisée pour la plupart d'entre eux. La plupart du temps, la traduction est gérée en amont dans des projets comme le -, le ou . @@ -5529,7 +5803,7 @@ en Python plut debdiff (du paquet devscripts, ) compare des listes de fichiers et des fichiers de contrôle de deux paquets. C'est un simple test de régression qui peut vous aider à remarquer -si le nombre de paquets binaires à changer depuis le dernier envoi ou si autre +si le nombre de paquets binaires a changé depuis le dernier envoi ou si autre chose a changé dans le fichier de contrôle. Bien sûr, certains des changements qu'il indique sont normaux, mais il peut aider à empêcher différents accidents.