-Pour en savoir plus sur le fichier <em>override</em>, reportez-vous à <manref
-name="dpkg-scanpackages" section="8">, &file-bts-mailing; et &file-bts-info;.
-
-
-
-
- <chapt id="nmu">Mise à jour indépendante
-
-<p>
-Dans certaines circonstances il est nécessaire qu'une personne autre que le
-responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de mise à
-jour est désigné en anglais par l'expression <em>non-maintainer upload
-(NMU)</em>. Dans le présent document, nous traduisons librement cette
-expression par « mise à jour indépendante ».
-
-<p>
-Ces mises à jour indépendantes font partie du travail normal des porteurs qui
-compilent les paquets pour d'autres architectures (voir <ref id="porting">).
-Nous faisons aussi des mises à jour indépendantes quand un développeur Debian
-corrige le paquet d'un autre développeur pour éliminer un trou de sécurité
-ou un bogue paralysant. Cela se produit plus particulièrement en période de
-gel de la distribution de développement ou quand le responsable officiel du
-paquet ne peut pas fournir une correction dans un délai raisonnable.
-
-<p>
-Ce chapitre contient des informations qui vous expliqueront quand et comment
-faire des mises à jour indépendantes. Une distinction fondamentale doit être
-faite entre les mises à jour indépendantes sources et les mises à jour
-indépendantes binaires. Elle est explicitée dans la section suivante.
-
-
- <sect id="nmu-terms">Terminologie
-
-<p>
-Deux nouvelles expressions sont introduites dans cette section :
-« mise à jour indépendante source » et « mise à
-jour indépendante binaire ». Ces expressions ont une définition
-précie dans le monde Debian. Elles correspondent toutes deux au même type
-d'activité ; elles impliquent toutes deux qu'une personne fait une mise à
-jour d'un paquet alors qu'elle n'est pas officiellement responsable de ce
-paquet. C'est pourquoi nous qualifions ces mises à jours
-d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser
-entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas
-question d'agir sans prévenir le responsable au préalable (voir <ref
-id="nmu-guidelines">).</footnote>.
-
-<p>
-Une mise à jour indépendante source est une livraison de paquet faite par
-une personne qui n'est pas le responsable officiel de ce paquet avec pour
-objectif de corriger un bogue dans le paquet. Une mise à jour indépendante
-source implique toujours une modification des sources du paquet, même s'il
-ne s'agit que d'un changement dans le fichier <file>debian/changelog</file>.
-Ce changement peut tout aussi bien concerner la version amont du source que la
-partie du source spécifique à Debian.
-
-<p>
-Une mise à jour indépendante binaire est une recompilation et un archivage
-d'un paquet pour une nouvelle architecture. Il s'agit souvent du résultat d'un
-effort de portage. Une mise à jour indépendante binaire est la livraison d'un
-paquet compilé (souvent pour une autre architecture) à condition que cette
-compilation n'ait pas nécessité de modifications des sources. Dans de
-nombreux cas, les porteurs
-sont obligés de modifier les sources pour les rendre compilables sur leur
-architecture cible ; il s'agira alors d'une mise à jour indépendante source et
-non d'une mise à jour indépendante binaire. Comme vous pouvez le remarquer,
-nous ne faisons pas de distinction entre les mises à jour indépendantes
-faites par des porteurs et les autres mises à jour indépendantes.
-
-<p>
-Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
-par l'expression « mise à jour indépendante »
-(NMU<footnote>Non-maintainer upload</footnote>). Pourtant cela conduit souvent
-à des confusions car beaucoup associent « mise à jour indépendante »
-et « mise à jour indépendante source ». Il faut donc rester
-vigilant. Dans ce chapitre, si j'utilise « mise à jour
-indépendante » seul, il s'agit des deux types de livraisons.
-
-
-
-
-
- <sect id="nmu-who">Qui peut faire une mise à jour indépendante ?
-
-<p>
-Seuls les responsables Debian officiels peuvent faire des mises à jour
-indépendantes. Un responsable officiel est une personne dont la clé est dans
-le porte-clés Debian. Toute personne est invitée à télécharger les paquets
-sources pour corriger des bogues ; au lieu de faire des mises à jour
-indépendantes, ils pourront soumettre les <em>patch</em> 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.
-
-
- <sect id="nmu-when">Quand faire une mise à jour indépendante source ?
-
-<p>
-Les recommandations pour déterminer quand faire une mise à jour indépendante
-source dépendent de la distribution visée (i.e. stable, instable ou
-gelée). Les porteurs, ayant une activité particulière, obéissent à des règles
-légèrement différentes (voir <ref id="source-nmu-when-porter">).
-
-<p>
-La distribution stable ne peut recevoir que des corrections critiques ou des
-mises à jour de sécurité. Quand une faille de sécurité est détectée, un
-paquet corrigé doit être livré le plus tôt possible. Dans ce cas, le responsable de
-sécurité Debian<footnote>Debian Security Manager</footnote> entrera en contact
-avec le responsable du paquet pour s'assurer qu'un paquet corrigé sera livré dans
-un délai raisonnable (moins de 48 heures). Si le mainteneur ne peut
-fournir une mise à jour suffisamment vite ou s'il ne peut être joint à temps, le
-responsable de sécurité pourra corriger le paquet (i.e. faire une mise à jour
-indépendante source).
-
-<p>
-Pendant la phase de gel (voir <ref id="upload-frozen">), les livraisons qui
-corrigent les bogues de sévérité <em>sérieuse</em> (i.e. <em>serious</em>) et
-supérieures sont encouragées et acceptées. Même pendant cette période, vous
-devrez tenter d'entrer en contact avec le responsable du paquet ; il pourrait
-bien être sur le point de livrer un paquet corrigé lui aussi. Comme pour
-n'importe quelle mise à jour indépendante source, les recommandations de la
-section <ref id="nmu-guidelines"> doivent être respectées.
-
-<p>
-Les mises à jour indépendantes sont aussi acceptable pour la distribution
-instable mais seulement en dernier ressort
-ou avec une autorisation. Essayez d'abord ce qui suit et si cela ne fonctionne
-pas il est probablement correct de faire une mise à jour indépendante
-<em>(NMU)</em> :
-
-<p>
- <list compact>
- <item>
- Vérifiez que le bogue est bien référencé dans le système de suivi des
- bogues. S'il n'y est pas, faites un rapport de bogue.
-
- <item>
- Envoyez un courrier au responsable du paquet et proposez votre aide
- pour corriger le bogue. Donnez-lui quelques jours.
-
- <item>
- Lancez-vous. Corrigez le bogue et envoyez votre <em>patch</em> au système de
- suivi des bogues. Construisez le paquet et testez-le comme décrit dans
- la section <ref id="upload-checking">. Utilisez le paquet chez vous.
-
- <item>
- Attendez une réponse pendant quelques semaines.
-
- <item>
- Envoyez un courrier au responsable lui demandant son accord pour faire
- une mise à jour indépendante <em>(NMU)</em>.
-
- <item>
- Vérifiez une nouvelle fois que votre modification n'a pas d'effet de
- bord inattendu et qu'elle est aussi minimaliste et peu intrusive que
- possible.
-
- <item>
- Attendez une réponse une semaine encore.
-
- <item>
- Faites votre mise à jour indépendante comme décrit dans la section
- <ref id="nmu-guidelines">.
-
- </list>
-
-
-
-
-
-
- <sect id="nmu-guidelines">Comment faire une mise à jour indépendante
- source ?
-
-<p>
-Les règles qui suivent s'appliquent aux porteurs tant qu'ils jouent le double
-rôle de correcteur de bogue et de porteur. Si un porteur doit modifier le
-paquet source, cette mise à jour est automatiquement une mise à jour
-indépendante source et est soumise aux règles qui suivent. Si un porteur
-construit un paquet binaire recompilé, les règles sont différentes (voir <ref
-id="porter-guidelines">.
-
-<p>
-Tout d'abord il est capital que ces mises à jour indépendantes soient aussi peu
-intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
-modules ou des fichiers, ne déplacez pas les répertoires ; plus généralement ne
-corrigez pas ce qui n'est pas cassé. Faites un patch 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 faits lors d'une mise à jour indépendante.
-
-
-
-
-
- <sect1 id="nmu-version">Numéro de version pour les mises à jour
- indépendantes sources
-
-<p>
-Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
-changer, même pour la plus triviale des modifications. Notre système de
-gestion de paquets s'appuie sur ces numéros de version.
-
-<p>
-Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
-un numéro de version mineur à la partie <var>debian-revision</var> du numéro
-de version (la partie qui suit le dernier trait d'union). Ce numéro
-supplémentaire débutera à « 1 ». Prenons pour exemple le paquet
-« foo » qui porte le numéro de version 1.1-3. Dans l'archive, le
-fichier de contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
-version amont est « 1.1 » et la révision Debian est « 3 ».
-La mise à jour indépendante suivante ajouterait le numéro de version mineur
-« .1 » au numéro de révision Debian; le nouveau fichier de contrôle
-du paquet source serait alors <file>foo_1.1-3.1.dsc</file>.
-
-<p>
-Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro
-de version au responsable officiel du paquet, ce qui pourrait perturber son
-travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas
-été livré par le responsable officiel.
-
-<p>
-S'il n'y a pas de partie <var>debian-revision</var> dans le numéro de version
-du paquet, il faut en créer une en démarrant à « 0.1 ». S'il est
-absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
-fasse une livraison basée sur une nouvelle version amont, cette personne
-doit choisir « 0.1 » comme numéro de révision Debian. Le mainteneur
-du paquet doit, lui, démarrer sa numérotation à « 1 ». Notez que pour
-faire cela vous devrez utiliser <prgn>dpkg-buildpackage</prgn> avec l'option
-<tt>-sa</tt> pour le forcer à utiliser le nouveau paquet source (par défaut il
-reconnaît les numéros de révisions « 0 » ou « 1 » -- il
-n'est pas suffisamment intelligent pour reconnaître « 0.1 »).
-
-<p>
-Attention, les porteurs qui ne font que recompiler les paquets pour d'autres
-architectures n'ont pas besoin de renuméroter les paquets. Les porteurs ne
-doivent utiliser de nouveaux numéros de version que s'ils modifient les
-paquets sources qu'ils recompilent, c'est-à-dire s'ils font une mise à jour
-indépendante source et non une mise à jour indépendante binaire.
-
-
-
-
-
- <sect1 id="nmu-changelog">
- <heading>Les mises à jour indépendantes sources doivent être
- mentionnées dans le fichier changelog</heading>
-
-<p>
-Une personne qui fait une mise à jour indépendante source doit ajouter une
-entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
-et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
-comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
-version livrée.
-
-<p>
-Par convention, dans le cas d'une mise à jour indépendante source
-<em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne
-
-<example>
- * Non-maintainer upload
-</example>
-
-
-
-
-
- <sect1 id="nmu-patch">Mise à jour indépendante source et système
- de suivi des bogues
-
-<p>
-Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
-modifications que possible et doit toujours envoyer ses modifications au
-système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).
-
-<p>
-En cas de simple recompilation du paquet, le processus diffère
-suivant que vous agissez en tant que porteur ou pas. Si vous faites une mise
-à jour indépendante qui ne nécessite rien de plus qu'une recompilation et
-n'agissez pas en temps que porteur (i.e. une nouvelle bibliothèque partagée
-est disponible, un bogue a été corrigé dans <package>debhelper</package>),
-vous devez tout de même ajouter une entrée dans le fichier <em>changelog</em>;
-il y aura donc une modification. Si vous êtes porteur, vous êtes probablement
-en train de faire une mise à jour indépendante binaire. (Note : ce système ne
-tient pas compte des porteurs qui font des recompilations -- tenez cela pour
-une faiblesse de notre système de gestion des paquets.)
-
-<p>
-Si la mise à jour indépendante source corrige des bogues, vous devez le
-<em>notifier</em> au système de suivi des bogues mais vous ne devez pas
-<em>clore</em> les rapports de bogue. Seul le responsable officiel d'un paquet
-et le rapporteur du bogue sont autorisés à fermer un rapport de bogue.
-Cependant, la personne qui fait une mise à jour indépendante doit envoyer une
-note à chaque bogue concerné expliquant qu'il est corrigé par cette mise à
-jour indépendante. Cette personne doit ensuite utiliser l'adresse
-<email>control@bugs.debian.org</email> pour modifier la sévérité des bogues
-corrigés et leur donner la valeur <em>corrigé</em> (i.e. <em>fixed</em>).
-Cela permet de s'assurer 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. 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>.
-
-<p>
-Le responsable officiel pourra choisir d'appliquer le <em>patch</em>, 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
-indépendante, il devra s'assurer que cette nouvelle version corrige
-effectivement chacun des bogues corrigés dans la mise à jour indépendante.
-
-<p>
-De plus, le responsable officiel devrait <em>toujours</em> conserver les
-entrées documentant une mise à jour indépendante dans le fichier
-<file>changelog</file>.
-
-
-
-
-
-
- <sect1 id="nmu-build">Fabriquer une mise à jour indépendante source
-
-<p>
-Les paquets faisant l'objet d'une mise à jour indépendante source sont
-construits comme les
-autres. Sélectionnez une distribution en utilisant les règles décrites dans
-la section <ref id="upload-dist"> et construisez un fichier <tt>.changes</tt>
-classique avec tout ce qui l'accompagne conformément à la description <ref
-id="upload">.
-
-<p>
-En fait, toutes les prescriptions de la section <ref id="upload"> sont
-applicables ici, y compris l'obligation d'annoncer la mise à jour sur la liste
-idoine.
-
-<p>
-Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt>
-dans le fichier <file>debian/control</file>. Votre nom, mentionné dans
-l'entrée du fichier <file>debian/changelog</file> concernant la mise à jour,
-sera utilisé pour signer le fichier <tt>.changes</tt>.
-
-
-
-
- <chapt id="porting">Le portage
-
-<p>
-Debian supporte un nombre croissant d'architectures. Même si vous n'êtes pas
-un porteur et même si vous n'utilisez qu'une architecture, il est de votre
-responsabilité de développeur d'être attentif aux questions de portabilité.
-C'est pourquoi il est important que vous lisiez ce chapitre même si vous
-n'êtes pas un porteur.
-
-<p>
-Porter un paquet consiste à faire un paquet binaire pour une architecture
-différente de celle du paquet binaire fait par le responsable du paquet.
-C'est une
-activité remarquable et essentielle. En fait, les porteurs sont à l'origine
-de la plupart des compilations de paquet Debian. Pour un paquet binaire
-<em>i386</em>, par exemple, il faut compter une recompilation pour chaque
-autre architecture, soit un total de cinq recompilations.
-
-
-
-
- <sect id="kind-to-porters">Être gentil avec les porteurs
-
-<p>
-Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un
-grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
-modification. Malheureusement, c'est rarement le cas. Cette section contient
-une liste d'erreurs commises régulièrement par les responsables Debian --
-problèmes courants qui bloquent souvent les porteurs et compliquent
-inutilement leur travail.
-
-<p>
-Ici, le mot d'ordre est de répondre rapidement aux rapports de bogues et
-remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
-étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine
-manière).
-
-<p>
-Les problèmes les plus couramment rencontrés par les porteurs sont causés par
-des erreurs de mise en paquet dans le paquet source. Voici une
-<em>checklist</em> de choses auxquelles vous devez être attentif :
-
- <enumlist>
- <item>
- Ne choisissez pas d'autre valeur que <em>all</em> ou <em>any</em> pour
- le champ architecture sans avoir de bonnes raisons pour le faire. Trop
- souvent, les développeurs ne respectent pas les instructions du
- <url id="&url-debian-policy;" name="Debian Policy Manual">. Choisir
- la valeur « i386 » est la plupart du temps incorrect.
-
- <item>
- Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
- <var>package</var>.dsc</tt> pour vous assurer que le paquet se
- désarchive correctement. En utilisant le résultat de ce test,
- construisez votre paquet binaire à l'aide de la commande
- <tt>dpkg-buildpackage</tt>.
-
- <item>
- Vérifiez que les fichiers <file>debian/files</file> et
- <file>debian/substvars</file> ne sont pas dans votre paquet source.
- Ils doivent être effacés par la cible <em>clean</em> de
- <file>debian/rules</file>.
-
- <item>
- Assurez-vous que vous ne vous appuyez pas sur des éléments de
- configuration ou des logiciels installés ou modifiés localement. Par
- exemple, vous ne devriez jamais appeler des programmes du répertoire
- <file>/usr/local/bin</file> ou de répertoires équivalents. Essayez de ne pas vous
- appuyer sur des logiciels configurés de manière spéciale. Essayez de
- construire votre paquet sur une autre machine, même s'il s'agit de la
- même architecture.
-
- <item>
- Ne vous appuyez pas sur une installation préexistante de votre paquet
- (un sous-cas de la remarque précédente).
-
- <item>
- Ne supposez pas qu'<prgn>egcc</prgn> est disponible, ni que vous
- utilisez une version précise de <prgn>gcc</prgn>.
-
- <item>
- Vérifiez que votre <file>debian/rules</file> distingue les cibles
- <em>binary-arch</em> et <em>binary-indep</em> comme l'exige le
- <em>Debian packaging manual</em>. Vérifiez que ces cibles sont
- indépendantes l'une de l'autre, c'est à dire qu'il n'est pas
- nécessaire d'invoquer l'une de ces cibles avant d'invoquer l'autre.
- Pour vérifier cela, essayez d'exécuter <tt>dpkg-buildpackage -b</tt>.
-
- </enumlist>
-
-
-
-
- <sect id="porter-guidelines">Instructions pour les mises à jour des
- porteurs
-
-<p>
-Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez
-de la chance et votre travail est facile. Cette section s'applique dans ce
-cas ; elle décrit comment construire et installer correctement votre mise à
-jour indépendante binaire dans l'archive Debian. Si vous devez modifier le
-paquet pour le rendre compilable sur votre architecture cible vous devez faire
-une mise à jour des sources, consultez la section <ref id="nmu-guidelines">.
-
-<p>
-Pour une mise à jour indépendante binaire, ne faites pas de changement
-dans les sources. Vous n'avez pas besoin de modifier les fichiers du paquet
-source (cela inclut <file>debian/changelog</file>).
-
-<p>
-Parfois il est nécessaire de recompiler des paquets quand d'autres paquets,
-tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez
-changer le numéro de version pour que le système de gestion des paquets
-fonctionne correctement. Ce type de mise à jour reste une mise à jour
-indépendante binaire -- il n'est pas nécessaire de faire une recompilation sur
-toutes les architectures. Vous devez utiliser la même règle de numérotation
-que pour une mise à jour indépendante mais en ajoutant « .0. »
-devant le numéro de révision Debian. Par exemple une recompilation du paquet
-source « foo_1.3-1 » portera le numéro de version
-<tt>foo_1.3-1.0.1</tt>.
-
-<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 portions du paquet qui dépendent de l'architecture, en
-utilisant la cible <em>binary-arch</em> de <file>debian/rules</file>.
-
-
-
-
-
-
- <sect1 id="source-nmu-when-porter"> <heading>Quand faire une mise à
- jour indépendante source pour un portage ?</heading>
-
-<p>
-Les porteurs qui font des mises à jour indépendantes sources suivent
-généralement les instructions de la section <ref id="nmu"> tout comme les
-non-porteurs. Les délais d'attente sont cependant plus courts car les porteurs
-doivent manipuler un grand nombre de paquets.
-
-<p>
-À nouveau, la situation diffère selon la distribution visée. Une correction
-cruciale (i.e. rendre un paquet compilable sur une architecture supportée par
-la prochaine distribution) peut être installée <em>sans</em> délai pour la
-distribution gelée.
-
-<p>
-Si vous êtes porteur et faites une mise à jour pour <em>unstable</em>, les
-instructions précédentes sont applicables à deux différences près. Tout
-d'abord, le temps d'attente raisonnable -- délai entre le moment où vous
-envoyez un rapport au système de suivi des bogues et le moment où vous pouvez
-faire une mise à jour indépendante <em>(NMU)</em> -- est de sept jours. Ce
-délai peut être raccourci si le problème est crucial et met l'effort de
-portage en difficulté : c'est à la discrétion de l'équipe de portage.
-(Souvenez-vous, il ne s'agit pas d'un règlement mais de recommandations
-communément acceptées).
-
-<p>
-Deuxième différence, les porteurs qui font des mises à jour indépendantes
-sources doivent choisir une sévérité <em>sérieuse</em> (i.e.
-<em>serious</em>) ou supérieure quand ils envoient leur rapport au système de
-suivi des bogues. Ceci assure qu'un paquet source unique permet de produire un
-paquet binaire pour chaque architecture supportée au moment de la sortie de la
-distribution. Il est très important d'avoir un paquet source et un paquet
-binaire pour toutes les architectures pour être conforme à plusieurs licences.
-
-<p>
-Les porteurs doivent éviter d'implémenter des contournements pour
-des bogues de l'environnement de compilation, du noyau ou de la libc. Quelques
-fois ces contournements sont inévitables. Si vous devez faire quelque chose de
-ce genre, marquez proprement vos
-modifications avec des <tt>#ifdef</tt> et documentez votre contournement pour
-que l'on sache le retirer une fois que le problème aura disparu.
-
-<p>
-Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de
-leur travail pendant le délai d'attente. Ainsi d'autres personnes peuvent
-bénéficier du travail du porteur même pendant ce délai. Bien sûr ces adresses
-n'ont rien d'officiel alors soyez sur vos gardes si vous les utilisez.
-
-
-
-
- <sect>Outils pour les porteurs
-
-<p>
-Il y a plusieurs outils pour le travail de portage. Cette section contient
-une courte description de ces outils ; reportez-vous à la documentation de
-leurs paquets ou aux références citées ci-après pour une description complète.
-
-
-
-
- <sect1 id="quinn-diff">
- <heading><package>quinn-diff</package>
-
-<p>
-<package>quinn-diff</package> est utilisé pour localiser les différences d'une
-architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de
-l'architecture <var>X</var> doivent être portés sur l'architecture <var>Y</var>.
-
-
-
-
-
- <sect1 id="buildd">
- <heading><package>buildd</package>
-
-<p>
-Le système <package>buildd</package> est un système distribué pour la
-compilation d'une distribution. Il est habituellement utilisé en conjonction
-avec des automates de compilation ; ce sont des machines « esclaves »
-qui récupèrent des paquets sources et tentent de les compiler. Il est aussi
-possible d'interagir par courrier électronique avec ce système. Cette
-interface est utilisée par les porteurs pour récupérer un paquet source (en
-général un paquet qui ne peut être compilé automatiquement) et travailler
-dessus.
-
-<p>
-<package>buildd</package> n'est pas disponible sous forme de paquet ;
-pourtant, la plupart des équipes de porteurs l'utilisent aujourd'hui ou ont prévu
-de l'utiliser bientôt. Il regroupe un ensemble de composants très utiles,
-continuellement utilisés mais non encore mis en paquet, tels que
-<prgn>andrea</prgn>, <prgn>sbuild</prgn> et <prgn>wanna-build</prgn>.
-
-<p>
-Une partie des informations produites par <package>buildd</package> -- utiles
-pour les porteurs -- est disponible sur la toile à l'adresse <url
-id="&url-buildd;">. Ces informations incluent les résultats produits toutes
-les nuits par <prgn>andrea</prgn> (dépendances des sources) et
-<prgn>quinn-diff</prgn> (paquets à recompiler). <p> Nous sommes très
-enthousiasmés par ce système car il a de nombreux usages potentiels. Des
-groupes de développeurs indépendants peuvent utiliser ce système pour créer
-différentes saveurs de la Debian -- qui peuvent être ou ne pas être
-intéressantes pour tous (une version de Debian compilée avec des vérifications
-relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi de recompiler
-rapidement toute une distribution.
-
-
-
-
- <sect1 id="dpkg-cross">
- <heading><package>dpkg-cross</package>
-
-<p>
-<package>dpkg-cross</package> est un outil qui installe les bibliothèques et
-les entêtes nécessaires à une compilation croisée<footnote><em>cross-compilation</em>
-</footnote> d'une manière similaire à <package>dpkg</package>. De plus
-<prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
-améliorés pour supporter les compilations croisées.
-
-
-
-
-
- <chapt id="archive-manip">
- <heading>Déplacer, effacer, renommer, adopter et abandonner des
- paquets</heading>
-
-<p>
-Certaines manipulations de l'archive ne sont pas accessibles avec le processus
-de mise à jour automatisé. Elles sont appliquées manuellement par les
-développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.
-
-
-
-
- <sect>Déplacer des paquets
-