<!-- common, language independant entities -->
<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.11 $">
+ <!entity cvs-rev "$Revision: 1.13 $">
<!-- if you are translating this document, please notate the RCS
revision of the developers reference here -->
<!--
- <!entity cvs-en-rev "1.63">
+ <!entity cvs-en-rev "1.65">
-->
]>
<debiandoc>
Copyright ©1997, 1998 Christian Schwarz.</copyrightsummary>
<p>
-Ce manuel est un logiciel libre ; il peut être redistribué et/ou modifié selon
+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
publiée par la « Free Software Foundation » (version 2 ou toute
version supérieure).
<item><em>Debian maintainer</em> : responsable Debian, développeur
Debian (parfois mainteneur). Personne qui fait officiellement
partie du projet Debian. Elle a accès aux serveurs Debian et participe
- au développement -- au sens large -- de la distribution (<ref
+ au développement — au sens large — de la distribution (<ref
id="developer-duties">). La plupart des responsables font de la mise
en paquet mais il existe d'autres activités telles que documentation,
site web, création des cédéroms, administration des serveurs...
<item><em>Upstream version</em> : version amont. Il s'agit du
- logiciel tel qu'il est fournit par le responsable amont -- par
+ logiciel tel qu'il est fournit par le responsable amont — par
opposition à la version fournie par la distribution Debian. (Voir
<ref id="upstream-coordination">.)
<sect id="inform-vacation">Prendre des vacances courtoisement
<p>
-La plupart des développeurs prennent des vacances ; généralement, cela signifie
+La plupart des développeurs prennent des vacances ; généralement, cela signifie
qu'ils ne peuvent ni travailler pour Debian ni être joints par
courrier électronique si un problème se présentait. Les autres développeurs
-ont besoin de savoir que vous êtes en vacances ; ainsi ils sauront comment
+ont besoin de savoir que vous êtes en vacances ; ainsi ils sauront comment
réagir en cas de problème. En général, cela signifie que les autres
développeurs sont autorisés à modifier votre paquet (voir <ref id="nmu">) en
cas de gros problème (bogues bloquants pour la distribution, mise à jour de
des rapports de bogue qui ne sont pas spécifiques à Debian. Vous devez
transmettre ces rapports de bogue aux développeurs amonts pour qu'ils soient
corrigés dans les prochaines versions. Il n'est pas de votre responsabilité
-de corriger les bogues qui ne sont pas spécifiques à Debian. ### However ###,
+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éveloppements amonts en proposant un <em>patch</em> qui corrige ce bogue.
Les utilisateurs et responsables Debian proposent souvent des <em>patches</em>
et essaient de vous aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas
corriger un bogue de ce type dans les deux semaines, vous devriez soit
demander de l'aide en envoyant un courrier à l'équipe d'assurance qualité
-(<em>QA group</em> &email-debian-qa;), soit vous expliquer et présenter un
-plan pour corriger le problème en répondant au rapport de bogue
+(<em>QA group</em> &email-debian-qa;), soit expliquer vos difficultés et
+présenter un plan pour corriger le problème en répondant au rapport de bogue
concerné. Si rien n'est fait, des personnes de l'équipe d'assurance qualité
pourraient chercher à corriger votre paquet (voir <ref id="nmu">) après avoir
tenté de vous contacter. Ils pourraient attendre moins longtemps que
activité ne leur est pas réservée. Vous pouvez participer à cet effort en
éliminant, autant que faire se peut, tout bogue de vos paquets et en observant
les remarques émises par <prgn>lintian</prgn> (voir <ref id="lintian-reports">). Si cela
-vous semble tout à fait impossible, il faudrait songer à abandonner certains
-de vos paquets, vous pourrez ainsi faire du bon travail avec les paquets dont
-vous restez responsable (voir <ref id="orphaning">). Vous pouvez aussi
+ne vous semble pas possible, il faudrait songer à abandonner certains
+de vos paquets (voir <ref id="orphaning">). Vous pouvez aussi
demander l'aide d'autres personnes pour rattraper votre retard dans la liste
des bogues (vous pouvez demander de l'aide sur les listes &email-debian-qa;
et &email-debian-devel;).
l'archive et aux logiciels qui l'accompagnent. Le premier répertoire contient
les distributions <em>stable</em>, <em>testing</em> et <em>unstable</em>. Le
découpage en sous-répertoires est identique d'un répertoire de distribution à
-l'autre ; nous nous contenterons donc d'exposer ce découpage pour la
+l'autre ; nous nous contenterons donc d'exposer ce découpage pour la
distribution <em>stable</em>. Les fichiers <tt>Packages</tt> et
<tt>Sources</tt> qui se trouvent dans les répertoires de distribution peuvent
faire référence à des fichiers du répertoire <tt>pool/</tt>.
<em>experimental</em>.
<p>
-Un système de fichier crypté, par exemple, devrait probablement aller dans
+Un système de fichier compressé, par exemple, devrait probablement aller 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. Un nouveau logiciel
<p>
Par contre, utiliser <em>experimental</em> comme plate-forme n'est pas
-toujours la meilleure idée. Vous ne pouvez pas remplacer ou mettre à jour des
-paquets dans cet espace vous-même (c'est le logiciel de maintenance de
-l'archive qui s'en charge). De plus, il vous faudra penser à demander la
-suppression de vos paquets à l'équipe d'administration de l'archive une fois
-qu'ils seront installés dans <em>unstable</em>. Utiliser vos pages web
-personnelles sur le serveur <tt>klecker.debian.org</tt> est en général une
-meilleure idée, cela permet de décharger l'équipe de maintenance de l'archive.
+toujours la meilleure idée, surtout pour les paquets éphémères.
+Vous ne pouvez pas effacer un paquet qui a été installé dans cet espace
+vous même ; cela doit être fait par l'équipe d'administration de l'archive.
+Une solution consiste à utiliser vos pages web personnelles sur le serveur
+<tt>klecker.debian.org</tt> (c.-à-d. <tt>people.debian.org</tt>).
<p>
Chaque distribution Debian diffusée a un nom : Debian 1.1 s'appelle
« buz » ; Debian 1.2, « rex » ; Debian 1.3 « bo » ;
-Debian 2.0, « hamm » ; Debian 2.1, « slink » et Debian 2.2
-« potato ». Il y a aussi une pseudo-distribution nommée
+Debian 2.0, « hamm » ; Debian 2.1, « slink »; Debian 2.2
+« potato » et Debian 3.0 « woody ». Il y a aussi une pseudo-distribution nommée
« sid », il s'agit de la distribution <em>unstable</em> ; comme les
paquets vont de <em>unstable</em> à <em>testing</em> quand ils approchent de
la stabilité, la distribution « sid » n'est jamais diffusée. En plus
<p>
Le sujet de votre rapport de bogue devra être <ITP<footnote><em>Intent To
Package</em> : intention de mise en paquet</footnote> :
-<var>NomDuPaquet</var> -- <var> courte description </var>>, en remplaçant
+<var>NomDuPaquet</var> — <var> courte description </var>>, en remplaçant
<var>NomDuPaquet</var> par le nom du paquet. La sévérité du bogue sera
<em>whishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
&email-debian-devel; en mettant cette adresse dans le champs X-Debbugs-CC: de
<p>
Il est tentant de toujours mettre en paquet la dernière version d'un logiciel
-pour Debian ; mais il est bien plus important que le système soit stable et
+pour Debian ; mais il est bien plus important que le système soit stable et
qu'il fonctionne de la manière attendue.
<p>
<p>
Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la
section lintian <ref id="lintian">. <item> Faites régresser le paquet
- vers sa version précédente si elle existe -- cela permet de tester les
+ vers sa version précédente si elle existe — cela permet de tester les
scripts <tt>postrm</tt> et <tt>prerm</tt>.
<item>
<p>
Les administrateurs de l'archive Debian sont responsables de l'installation
des mises à jour. La plupart des mises à jour sont gérées
-quotidiennement par le logiciel de gestion de l'archive <prgn>dak</prgn>
-(aussi appelé <prgn>katie</prgn> ou <prgn>dinstall</prgn>). Les mises à jour
+quotidiennement par le logiciel de gestion de l'archive <prgn>katie</prgn>.
+Les mises à jour
de paquets sur la distribution <em>unstable</em>, en particulier, sont
installés ainsi. Dans les autres cas et notamment dans le cas d'un nouveau
paquet, celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois
<p>
Dans tous les cas vous recevrez un accusé de réception par courrier
-électronique indiquant que votre paquet a été installé. Lisez attentivement ce
-courrier. Vous pourriez remarquer que votre paquet n'a pas été installé dans
-la section que vous aviez désignée. La raison de ce changement sera dans le
-courrier.
+électronique indiquant que votre paquet a été installé et quels rapports
+de bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous
+les rapports de bogues que vous vouliez clore sont bien dans cette liste.
+
+<p>
+L'accusé de réception indique aussi la section dans laquelle le paquet a
+été installé. S'il ne s'agit pas de votre choix, vous recevrez un second
+courrier qui vous informera de cette différence (voir plus loin).
<p>
Les administrateurs de l'archive indiquent les sections et priorités des paquets
-dans le fichier <em>override</em>. De temps en temps, ce fichier doit être
-corrigé. Modifier le fichier <file>control</file> du paquet n'aura aucun
-effet. Il vous faudra écrire à &email-override; ou faire un rapport de bogue
-sur le pseudo-paquet <package>ftp.debian.org</package>.
+dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le
+fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez
+informé par courrier électronique quand votre paquet sera installé dans
+l'archive. Vous pourrez corriger votre fichier <em>debian/control</em>
+avant votre prochain téléchargement ou alors vous aurez envie de modifier le
+fichier <em>override</em>.
+
+<p>
+Pour modifier la section dans laquelle un paquet est archivé, vous devez
+d'abord vérifier que fichier <file>debian/control</file> est correct. Ensuite,
+envoyez un courrier à &email-override; ou un rapport de bogue sur le pseudo
+paquet <package>ftp.debian.org</package> demandant la modification de la
+section ou de la priorité de votre paquet. Exposez bien les raisons qui vous
+amènent à demander ces changements.
<p>
Pour en savoir plus sur le fichier <em>override</em>, reportez-vous à <manref
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.
+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 architectures, un fichier <em>diff</em>
+modifié ou, plus rarement, des nouveaux sources amonts.
<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
+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
(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
+vigilant. Dans ce chapitre, si nous utilisons « mise à jour
indépendante » seul, il s'agit des deux types de livraisons.
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
+reconnaît les numéros de révisions « 0 » ou « 1 » — il
n'est pas suffisamment intelligent pour reconnaître « 0.1 »).
<p>
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
+tient pas compte des porteurs qui font des recompilations — tenez cela pour
une faiblesse de notre système de gestion des paquets.)
<p>
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.
+autre architecture, soit un total de &number-of-arches; recompilations.
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 --
+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.
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).
+manière). Merci pour votre indulgence envers des rapport de bogues succints ou
+peu clair ; 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
<enumlist>
<item>
+ Vérifiez que les champs <tt>Build-Depends</tt> et
+ <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</tt> sont
+ corrects. Le meilleur moyen pour vérifier cela est d'utiliser le
+ paquet <package>debootstrap</package> pour créer un environnement
+ <em>unstable</em> <em>chrooter</em>. 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 cette
+ environnement.
+ <p>
+ Consultez le <url id="&url-debian-policy;" name="Debian Policy
+ Manual"> pour en savoir plus sur les dépendances de fabrication.
+ <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
(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>.
+ Si possible, ne vous appuyez pas sur une particularité présente dans
+ un compilateur précis ou dans certaines 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 surement les problèmes car quelques architectures pourraient
+ choisir un compilateur différent.
<item>
Vérifiez que votre <file>debian/rules</file> distingue les cibles
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 -e<var>adresse-porteur</var></tt>. Bien sûr,
utilisant la cible <em>binary-arch</em> de <file>debian/rules</file>.
+ <sect1 id="recompile-nmu-versioning">
+ <heading>Numéro de version des mises à jour indépendantes
+ binaires</heading>
+
+<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 comparaison des numéros de
+version fonctionne correctement. Ce type de mise à jour reste une mise à jour
+indépendante binaire — il n'est pas nécessaire de reconcidérer le status
+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 rejeteront
+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&nbps;».
<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
+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
+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
<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 »
+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
<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
+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
+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.
<tt>maintainer</tt> du paquet et faire un rapport de bogue sur le
pseudo-paquet <tt>wnpp</tt>. Le titre de votre rapport de bogue devra être
« <tt>O<footnote><em>Orphaned</em> : abandonné.</footnote>:
-<var>paquet</var> -- <var>courte description</var></tt> » pour indiquer
+<var>paquet</var> — <var>courte description</var></tt> » pour indiquer
que le paquet est orphelin. La sévérité du bogue sera <em>normale</em>.
Si vous le jugez nécessaire, envoyez une copie à
&email-debian-devel; en mettant cette adresse dans le champs X-Debbugs-CC: de
Si le paquet est particulièrement important pour la distribution il vous
faudra faire un rapport de bogue sur le pseudo-paquet <tt>wnpp</tt>, titrer
« <tt>RFA<footnote><em>Request For Adoption</em> : offre
-d'adoption.</footnote>: <var>paquet</var> -- <var>courte
+d'adoption.</footnote>: <var>paquet</var> — <var>courte
description</var></tt> » et lui affecter la sévérité <em>importante</em>.
Envoyez une copie de votre rapport de bogue à la liste debian-devel comme
décrit précédemment.
<p>
Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
-correct -- ce serait une prise d'otage. Vous pouvez prendre contact avec le
+correct — ce serait une prise d'otage. Vous pouvez prendre contact avec le
responsable actuel et lui demander si vous pouvez prendre en charge ce paquet.
Vous ne pouvez le faire sans son accord. Qu'il vous ignore n'est pas une
raison suffisante pour le faire. Si vous avez le sentiment qu'un responsable
est facilement repérable dans le fichier <file>changelog</file>.
<p>
-Si vous voulez fermer un rapport de bogue manuellement -- à l'ancienne -- il
+Si vous voulez fermer un rapport de bogue manuellement — à l'ancienne — il
suffit d'envoyer le fichier <tt>.changes</tt> à l'adresse
<email>XXX-done@bugs.debian.org</email> où <var>XXX</var> est le numéro du
bogue.
<p>
Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
-paquet -- plus de dix -- est une pratique que nous déconseillons. Prenez
+paquet — plus de dix — est une pratique que nous déconseillons. Prenez
toutes les mesures possibles pour éviter cette situation. Si le problème peut
être détecté automatiquement par exemple, ajoutez un nouveau test dans le
paquet <package>lintian</package> pour générer une erreur ou un avertissement.
<p>
Les nouveaux responsables éprouvent souvent quelques difficultés pour créer
-des paquets Debian -- ce qui est bien compréhensible. C'est là que le parrain
+des paquets Debian — ce qui est bien compréhensible. C'est là que le parrain
intervient. Il doit verifier que le paquet est suffisamment bon pour intégrer
la distribution. Notez que si le paquet est nouveau les administrateurs FTP
devront eux aussi inspecter ce paquet avant de le laisser entrer.
Le paquet <package>dpkg-dev</package> contient les outils (y compris
<prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des
paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas
-niveau indispensables pour créer et manipuler les paquets ; en tant que tels,
+niveau indispensables pour créer et manipuler les paquets ; en tant que tels,
ils sont indispensables à tout responsable Debian.
<heading><package>debmake</package>
<p>
-<package>debmake</package> -- un précurseur de <package>debhelper</package> --
+<package>debmake</package> — un précurseur de <package>debhelper</package> —
est un assistant moins modulaire pour manipuler le fichier
<file>debian/rules</file>. Il inclut deux programmes principaux :
<prgn>deb-make</prgn>, utile au développeur Debian pour convertir un paquet
~ianmdlvl / developers-reference.git / blobdiff