path: root/french/international/french/translations/policy.fr.sgml

<!DOCTYPE debiandoc SYSTEM [
<!-- include version information so we don't have to hard code it
     within the document -->
<!-- arch devel-3.7-patch-26 -->
<!--entity % versiondata SYSTEM "version.ent"> &versiondata; -->
]>

<!-- IMPORTANT : AVANT DE COMMITER, SUPPRIMER LE DOUBLE "" LIGNE 5505 -->

<debiandoc>
  
  <book>
    <titlepag>
      <title>La Charte Debian</title>
      <author><qref id="authors">La liste de diffusion Debian-Policy</qref></author>
      <version>version 3.7.2.2</version>

      <abstract>
	Ce manuel est la charte de la distribution Debian
GNU/Linux. Sont abordés la structure et le contenu d'une archive Debian,
certaines questions sur la conception du système d'exploitation,
ainsi que les exigences techniques que chaque paquet doit satisfaire afin
d'être inclus dans la distribution.
      </abstract>

      <copyright>
	<copyrightsummary>
	  Copyright &copy; 1996,1997,1998 Ian Jackson
	  et Christian Schwarz.
	</copyrightsummary>
	<p>
	  Ce manuel est un logiciel libre&nbsp;; il peut être redistribué 
et modifié selon les termes de la licence publique générale du projet GNU
(GNU GPL), telle que publiée par la «&nbsp;Free Software Foundation&nbsp;»  
(version 2 ou toute version supérieure).
	</p>
	<p>
	  Il est distribué dans l'espoir qu'il sera utile, mais <em>sans aucune
garantie</em>&nbsp;; sans même la garantie implicite d'une possible valeur 
marchande ou d'une adéquation à un besoin particulier. 
Consultez la licence publique générale du projet GNU pour plus de détails.
	</p>
	<p>
Une copie de la licence publique générale est disponible à
<tt>/usr/share/common-licenses/GPL</tt> dans la distribution Debian GNU/Linux
ou sur la «&nbsp;Toile&nbsp;»&nbsp;: 
<url id="http://www.gnu.org/copyleft/gpl.html" name=" La licence publique générale du projet GNU">.
Vous pouvez également l'obtenir en écrivant à la
Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
Boston, MA 02110-1301, USA.
	</p>
      </copyright>
    </titlepag>
    <toc detail="sect1">
<chapt id="scope">
      <heading>À propos de ce manuel</heading>
      <sect>
	<heading>Les objectifs de ce manuel</heading>
	<p>
	  Ce manuel est la charte de la distribution 
Debian GNU/Linux. Sont abordés la structure et le contenu d'une archive 
Debian, certaines questions sur la conception du système d'exploitation,
ainsi que les exigences techniques que chaque paquet doit satisfaire afin
d'être inclus dans la distribution.
	  </p>
<p>
Ce manuel décrit aussi la politique Debian en ce qui concerne la création 
des paquets. Ce n'est pas un cours sur la construction des paquets et il ne
décrit pas complètement le comportement du système de gestion des paquets. 
Il essaye plutôt de définir la seule interface que doivent maîtriser les 
développeurs 
<footnote><p>
D'une manière informelle, l'intégration de «&nbsp;matériel&nbsp;» se fait 
selon les critères suivants&nbsp;:
<taglist compact="compact">
<tag>Interfaces standards</tag>
<item> <p>
Le «&nbsp;matériel&nbsp;» présenté est une interface au système de gestion de 
paquets dont l'utilisation est obligatoire&nbsp;; un nombre significatif de paquets
l'utilise et elle ne sera pas modifiée sans une étude sérieuse. Les
responsables de paquet peuvent donc compter sur la stabilité de cette 
interface et les auteurs du système de gestion des paquets doivent assurer
la compatibilité avec les définitions de ces interfaces. Le format des 
fichiers «&nbsp;control&nbsp;» et «&nbsp;changelog&nbsp;» en est un exemple.
</p>
               </item>
               <tag>Convention choisie</tag>
               <item>
                 <p>
Quand on a besoin, pour des raisons d'inter-opérabilité, de faire un choix
parmi un certain nombre de possibilités techniquement valides. Le numéro
de version est un exemple.
</p></item></taglist>
Veuillez noter que ces critères ne s'excluent pas mutuellement&nbsp;; une 
convention choisie devient souvent une interface standard.
	    </p>
	  </footnote>.
	</p>
<p>
Les notes de ce manuel ne font pas partie de la Charte et sont purement 
documentaires.
</p>
<p>
Les annexes de ce manuel ne sont pas non plus normatives.
Voyez <ref id="pkg-scope"> pour des informations supplémentaires.
	</p>

<p>
Dans la partie normative de ce manuel, les mots <em>must</em>, 
<em>should</em>, <em>may</em> et les adjectifs
<em>required</em>, <em>recommended</em> et <em>optional</em> servent à
distinguer la signification des diverses directives contenues dans cette
charte. La distribution Debian ne considérera généralement pas comme
acceptables les paquets qui ne se conforment pas aux directives dénotées par
<em>must</em> (ou <em>required</em>)<footnote><p>
En français, nous employons le verbe «&nbsp;devoir&nbsp;» et ses déclinaisons.
</p></footnote>. Une non-conformité à une directive
dénotée par <em>should</em> (ou <em>recommended</em>) sera en général
considérée comme un bogue, mais cela n'empêchera pas nécessairement la
distribution du paquet.<footnote><p>
En français, nous employons le futur de l'indicatif et jamais le verbe
«&nbsp;devoir&nbsp;».</p></footnote>.
Les directives dénotées par <em>may</em> (ou <em>optional</em>) sont 
véritablement facultatives et sont laissées à l'appréciation du responsable 
de paquet.
</p>
<p>
Ce classement est en gros équivalent à celui des bogues&nbsp;: <em>serious</em>
(pour les violations des directives <em>must</em> ou <em>required</em>),
<em>minor</em>, <em>normal</em> ou <em>important</em> (pour les violations 
des directives <em>should</em> ou <em>recommended</em>) et <em>wishlist</em> 
(pour les éléments <em>optional</em>)
<footnote>Comparez avec la RFC 2119.
Remarquez cependant que ces mots sont employés différemment dans ce
document.</footnote>.
</p>
	<p>
	  La plupart des informations de ce manuel seront également utiles
pour la création de paquets que l'on doit distribuer d'une autre façon
ou qui sont destinés à un usage local.
	</p>
      </sect>
      <sect>
	
<heading>Nouvelles versions de ce document</heading>

	<p>
Ce document est distribué dans le paquet Debian 
<package><url name="debian-policy" id="https://packages.debian.org/debian-policy"></package>
          (<httpsite>packages.debian.org</httpsite> 
         <httppath>/debian-policy</httppath>).
	</p>

	<p>
La dernière version de ce document est aussi disponible sur les miroirs web
de Debian, 
<tt><url name="/doc/debian-policy/"
                id="https://www.debian.org/doc/debian-policy/"></tt>.
          (<httpsite>www.debian.org</httpsite>
          <httppath>/doc/debian-policy/</httppath>)
Dans le même répertoire, d'autres formats existent&nbsp;: 
<file>policy.html.tar.gz</file>,
(<httppath>/doc/debian-policy/policy.html.tar.gz</httppath>),
 <file>policy.pdf.gz</file> 
(<httppath>/doc/debian-policy/policy.pdf.gz</httppath>)
et 
<file>policy.ps.gz</file>
(<httppath>/doc/debian-policy/policy.ps.gz</httppath>).
        </p>

<p>
Le paquet <package>debian-policy</package> contient aussi le fichier 
<tt>upgrading-checklist.txt.gz</tt> qui liste les changements entre les versions 
de ce document.
</p>
      </sect>

      <sect id="authors">
	<heading>Auteurs et responsables</heading>

	<p>
Ce manuel, appelé «&nbsp;Debian GNU/Linux Policy Manual&nbsp;», a été
rédigé d'abord par Ian Jackson en 1996, puis révisé par David A. Morris le 27
novembre 1996. Christian Schwarz ajouta de nouvelles sections le 15 mars
1997 et retravailla le texte entre les mois d'avril et de Juin 1997.
Christoph Lameter a apporté la contribution sur le «&nbsp;Web Standard&nbsp;».
Et il a été grandement restructuré en 2001 par Julian Gilbey.
	</p>
<p>
Depuis septembre 1998, la <url name="liste de discussion debian-policy"
          id="mailto:debian-policy@lists.debian.org"> est responsable
du contenu de ce document. Les propositions y sont discutées, puis, quand
un consensus est dégagé, elles sont introduites dans le document.
<!-- insert shameless policy-process plug here eventually -->
L'édition est faite par un groupe de responsables sans pouvoir
rédactionnel, dont voici la liste actuelle&nbsp;:
          <enumlist>
            <item>Julian Gilbey</item>
            <item>Branden Robinson</item>
            <item>Josip Rodin</item>
            <item>Manoj Srivastava</item>
          </enumlist>
        </p>

	<p>
	Bien que les auteurs de ce document aient veillé à ne pas introduire
de coquilles ou d'autres erreurs, il en reste toujours.
Si vous découvrez des erreurs dans cette version du manuel ou si
vous voulez faire part de vos commentaires, suggestions ou
critiques, veuillez envoyer un courrier électronique sur la liste de diffusion
«&nbsp;Debian Policy&nbsp;», <email>debian-policy@lists.debian.org</email>,
ou un rapport de bogue concernant le paquet <tt>debian-policy</tt>.
	</p>
<p>
N'essayez pas, s'il vous plaît, de contacter personnellement les auteurs et
les responsables de ce document dans le but de modifier la Charte Debian.
	</p>
</sect>
      <sect id="related">
        <heading>Documents associés</heading>

        <p>
Plusieurs autres documents sont nécessaires pour comprendre pleinement les
règles et les procédures Debian.
        </p>

        <p>
Ces documents complémentaires sont référencés dans&nbsp;:
          <list compact="compact">
            <item><ref id="fhs"></item>
            <item><ref id="virtual_pkg"></item>
            <item><ref id="menus"></item>
            <item><ref id="mime"></item>
            <item><ref id="perl"></item>
            <item><ref id="maintscriptprompt"></item>
            <item><ref id="emacs"></item>
          </list>
        </p>

        <p>
En dehors de ces documents normatifs, il y a aussi la référence du
développeur Debian. Ce document décrit les procédures et les ressources
disponibles aux développeurs Debian, mais il <em>n'est pas</em> normatif.
Il comprend des éléments qui n'ont pas valeur de règle mais qui sont
considérés comme des pratiques exemplaires pour les développeurs.
        </p>

        <p>
La référence des développeurs Debian est disponible dans le paquet
<package>developers-reference</package>. On peut aussi le trouver sur les
miroirs web de Debian, <tt><url name="/doc/developers-reference/"
                id="https://www.debian.org/doc/developers-reference/"></tt>.
        </p>
      </sect>

<sect id="extra-trans-">
<heading>À propos de la traduction</heading>
<p>
Depuis la version 3.5.0.0, la charte Debian regroupe le 
<em>Debian Policy Manual</em> et des éléments tirés du 
<em>Debian Packaging Manual</em>.</p>
<p>
Serge Stinckwich et David Rocher ont initié la traduction du 
<em>Debian Policy Manual</em> et ils furent rejoints par Christophe Le Bars, 
Benjamin Drieu, Laurent Pelecq, Christophe Mertz, Olivier Ripoll, 
Georges Mariano, Hugues Marilleau, Michel Court et les relecteurs de la liste 
de diffusion <em>debian-l10n-french</em>. Il a ensuite été repris
par Philippe Batailler.
</p>
<p>
David Curé et Christian Jacolot ont traduit les passages 
du <em>Debian Packaging Manual</em> intégrés dans la charte.
</p>
<p>
Si vous voulez faire part de vos commentaires, suggestions ou critiques sur
cette traduction, vous pouvez envoyer un courriel à Frédéric Bothamy <email>
frederic.bothamy@free.fr</email>, ou à la liste <em>debian-l10n-french</em>,
<email>debian-l10n-french@lists.debian.org</email>.
</p>
	      </sect>
    </chapt>
   
 <chapt id="archive">
      <heading>L'archive Debian</heading>
       <p>
	Le système Debian GNU/Linux est maintenu et distribué sous la forme
d'un ensemble de <em>paquets</em>. Très nombreux (plus de 15000), ces paquets
sont répartis en plusieurs <em>sections</em> et on leur donne des
<em>priorités</em> afin de simplifier leur traitement.
      </p>
      <p>
	Le projet Debian s'efforce de construire un système
d'exploitation libre, mais tous les paquets que nous voulons rendre
accessibles ne sont pas <em>libres</em> selon notre définition
(voir plus loin les Directives Debian pour le logiciel libre) ou ne peuvent
pas être importés ou exportés sans restrictions. L'archive a donc été
divisée en zones de distributions ou catégories définies par les licences des
logiciels ou par certaines restrictions.
     </p>
      <p>
Nos buts sont les suivants&nbsp;:
        <list compact="compact">
          <item>offrir le plus grand nombre possible de logiciels&nbsp;;</item>
          <item>encourager chacun à écrire des logiciels libres&nbsp;;</item>
          <item>et faciliter la production de cédéroms de notre système en
évitant que des licences, des restrictions d'importation ou d'exportation 
ou des lois quelconques ne soient violées.</item>
        </list>
      </p>
 
<p>
	La catégorie <em>main</em> constitue la <em>distribution Debian
	GNU/Linux</em>.
</p>
      <p>
	Les paquets des autres zones de distribution (<tt>contrib</tt>,
<tt>non-free</tt>) ne sont pas considérés comme faisant
partie de la distribution Debian, bien que nous	soutenions leur utilisation
à travers notre infrastructure (comme notre système
de suivi des bogues et nos listes de diffusion). La <em>Charte Debian</em> 
s'applique aussi à ces paquets.
</p>

      <sect id="dfsg">
	<heading>Les directives Debian pour le logiciel libre</heading>
	<p>
	  Les directives Debian pour le logiciel libre (DFSG : 
«&nbsp;Debian Free Software Guidelines&nbsp;») suivantes constituent notre 
définition du «&nbsp;logiciel libre&nbsp;».
	  <taglist>
	    <tag>Redistribution autorisée
	    </tag>
	    <item>
	      <p>
		La licence d'un composant Debian ne doit pas empêcher quiconque
 de vendre ou de donner ce logiciel en tant qu'élément d'une distribution
 logicielle qui regroupe des programmes de différentes sources. La licence
 ne doit pas demander le paiement de droits ou de redevances
 pour une telle vente.
	      </p>
	    </item>
	    <tag>Code source
	    </tag>
	    <item>
	      <p>
		Le programme doit inclure son code source et doit permettre sa
 distribution en tant que code source et sous forme compilée.
	      </p>
	    </item>
	    <tag>Travaux dérivés
	    </tag>
	    <item>
	      <p>
		La licence doit autoriser les modifications et les travaux 
dérivés. Elle doit autoriser leur distribution selon les termes mêmes de
la licence du logiciel original.
	      </p>
	    </item>
	    <tag>Intégrité du code source de l'auteur
	    </tag>
	    <item>
	      <p>
		La distribution d'un code source modifié peut être limitée
par la licence <em>seulement</em> si des fichiers «&nbsp;patch&nbsp;», joints 
avec le code source, permettent de modifier le programme au moment de sa 
compilation. La licence doit explicitement permettre la redistribution de 
logiciels construits à partir de code source modifié. La licence peut exiger 
que les travaux dérivés portent un nom différent ou un numéro de version 
différent du logiciel initial. (C'est un  compromis. Le projet Debian 
encourage tous les auteurs à ne pas limiter les modifications de fichier, 
source ou binaire.)
	      </p>
	    </item>
	    <tag>Non-discrimination envers des personnes ou groupes 
de personnes
	    </tag>
	    <item>
	      <p>
		La licence ne doit faire aucune discrimination à l'encontre 
d'une personne ou d'un groupe de personnes.
	      </p>
	    </item>
	    <tag>Non-discrimination envers des champs d'activités
	    </tag>
	    <item>
	      <p>
		La licence ne doit pas empêcher l'usage du programme dans un
 champ spécifique d'activité. Par exemple, elle ne doit pas empêcher 
 l'utilisation du programme dans le cadre d'une activité commerciale ou
 pour faire de la recherche génétique.
	      </p>
	    </item>
	    <tag>Distribution de licence
	    </tag>
	    <item>
	      <p>
		Les droits attachés au programme doivent s'appliquer à tous 
ceux à qui le logiciel est redistribué sans que ceux-ci aient besoin 
d'une licence supplémentaire.
	      </p>
	    </item>
	    <tag>La licence ne doit pas être spécifique à Debian
	    </tag>
	    <item>
	      <p>
		Les droits attachés à un programme ne doivent pas être liés
à l'appartenance de ce programme à un système Debian. Si ce programme
est extrait de Debian et est utilisé ou distribué sans Debian mais
dans les termes de la licence du programme, toutes les parties à
qui ce programme a été redistribué doivent avoir les mêmes droits
que ceux qui sont accordés avec le système Debian.
	      </p>
	    </item>
	    <tag>La licence ne doit pas contaminer d'autres logiciels
	    </tag>
	    <item>
	      <p>
		La licence ne doit pas apporter des restrictions à d'autres 
logiciels distribués avec le logiciel en question. Par exemple, la licence ne
doit pas exiger que tous les autres programmes distribués sur le même
support soient des logiciels libres.
	      </p>
	    </item>
	    <tag>Exemples de licence
	    </tag>
	    <item>
	      <p>
		Les licences «&nbsp;GPL&nbsp;», «&nbsp;BSD&nbsp;» et 
«&nbsp;Artistic&nbsp;» sont des exemples de licence que nous considérons 
comme <em>libres</em>.
	      </p>
	    </item>
	  </taglist>
	</p>
      </sect>

      <sect id="sections">
        <heading>Les catégories</heading>

      <sect1 id="main">
	<heading>La catégorie «&nbsp;main&nbsp;»</heading>
	<p>
	  Tous les paquets dans <em>main</em> doivent se conformer aux <em>DFSG</em>
(«&nbsp;Debian Free Software Guidelines&nbsp;» &mdash; Les principes du logiciel
libre selon Debian).
	</p>

	<p>
	  De plus, les paquets dans <em>main</em>
	  <list compact="compact">
	    <item>
	      <p>
ne doivent pas demander un paquet extérieur à <em>main</em> pour leur 
compilation ou leur exécution (ainsi les paquets ne doivent pas déclarer de 
relation «&nbsp;Depends&nbsp;», «&nbsp;Recommends&nbsp;» ou 
«&nbsp;Build-Depends&nbsp;» avec un paquet qui n'est pas contenu dans 
<em>main</em>),
	      </p>
	    </item>
	    <item>
	      <p>
		ne doivent pas être tellement bogués que nous refusions de les 
soutenir, 
	      </p>
	    </item>
	    <item>
	      <p>
		et doivent se conformer à toutes les règles énoncées 
dans ce manuel.
	      </p>
	    </item>
	  </list>
	</p>

	</sect1>

      <sect1 id="contrib">
	<heading>La catégorie «&nbsp;contrib&nbsp;»</heading>
	<p>
	 Tous les paquets dans <em>contrib</em> doivent se conformer aux
	 «&nbsp;DFSG&nbsp;».
	</p>
	<p>
De plus, les paquets dans <em>contrib</em>
	  <list compact="compact">
	    <item>
	      <p>
ne doivent pas être tellement bogués que nous refusions de les soutenir, 
		</p>
	      </item>
<item>
<p>
et doivent se conformer à toutes les règles énoncées dans ce manuel.
		</p>
	      </item>
	    </list>
</p>
<p>		
Voici des exemples de paquets que l'on peut mettre dans <em>contrib</em>&nbsp;:
<list compact="compact">
<item><p>
des paquets libres qui demandent pour leur compilation ou 
leur exécution des paquets appartenant aux sections <em>contrib</em>, 
<em>non-free</em> ou des paquets qui ne sont pas contenus dans notre archive&nbsp;;
	      </p>
	    </item>
	    <item>
	      <p>
des paquets «&nbsp;wrapper&nbsp;», et des accessoires libres pour des 
programmes non libres.
	      </p>
	    </item>
	  </list>
	</p>
      </sect1>
      <sect1 id="non-free">
	<heading>La catégorie «&nbsp;non-free&nbsp;»</heading>
	<p>
On doit placer dans les sections <em>non-free</em>
les paquets qui ne se conforment pas aux «&nbsp;DFSG&nbsp;», ou bien les 
paquets dont la distribution est rendue problématique par des brevets ou des 
questions légales.
	  </p>
<p>
De plus les paquets dans <em>non-free</em>
<list compact="compact">
<item>
<p>
ne doivent pas être tellement bogués que nous refusions de les soutenir, 
		</p>
	      </item>
<item>
<p>
et doivent se conformer, autant qu'il leur est possible, à toutes les règles 
énoncées dans ce manuel<footnote><p>
Il se peut que certains paquets ne puissent pas respecter telle règle&nbsp;; 
p. ex. les sources ne sont pas disponibles. Ces situations seront examinées au 
cas par cas.
</p>
		  </footnote>.</p>
	      </item>
	    </list>
</p>
     </sect1>

      <sect id="pkgcopyright">
        <heading>Considérations sur le copyright</heading>

	<p>
Tous les paquets doivent être accompagnés d'une copie <em>verbatim</em>
de leur copyright et de leur licence dans le fichier
	  <file>/usr/share/doc/<var>paquet</var>/copyright</file> 
(voir <ref id="copyrightfile"> pour des précisions).
</p>
	<p>
	  Nous nous réservons le droit d'empêcher l'inclusion de fichiers 
dans nos archives si
	  <list compact="compact">
	    <item>
		 leur utilisation ou leur distribution violent une loi&nbsp;;
	    </item>
	    <item>
	leur utilisation ou leur distribution créent un conflit éthique&nbsp;;
	    </item>
	    <item>
		nous sommes obligés de signer une licence pour les utiliser&nbsp;;
	    </item>
	    <item>
		leur distribution entre en conflit avec des politiques 
du projet Debian.
	    </item>
	  </list>
	</p>

	<p>
	  Les programmes dont les auteurs encouragent l'utilisateur à faire des
dons conviennent très bien à la section <em>main</em>, sauf si les auteurs
affirment que ne pas faire de don est immoral, non éthique, illégal 
ou quelque chose de similaire&nbsp;; dans ce cas, ces programmes 
doivent être placés dans la section <em>non-free</em>.
</p>

	<p>
	  Les paquets dont les notices de copyright (ou des problèmes de 
brevet) ne permettent pas la redistribution, même sous forme binaire, 
et pour lesquels aucune permission spéciale n'a été obtenue, ne doivent pas 
être placés sur le site FTP de Debian et ses miroirs.</p>

	<p>
On notera que dans la loi internationale du copyright (ceci s'applique aussi
aux États-Unis), <em>aucune</em> distribution ou modification d'un travail 
n'est autorisée sans une mention explicite. C'est pourquoi un programme sans
notice de copyright <em>est</em> protégé et vous ne pouvez rien en faire
sans risquer d'être poursuivi. De même, un programme, avec une notice
de copyright qui n'énoncerait pas explicitement ce qui est permis,
interdit tout.
</p>

	<p>
Beaucoup d'auteurs de logiciels prétendument libres ignorent les problèmes
posés aux utilisateurs par des copyrights restrictifs (ou l'absence
de notice de copyright). Il est souvent intéressant de contacter
diplomatiquement de tels auteurs pour leur demander de modifier les
termes de leur licence. Cependant cela peut être politiquement difficile
et vous devriez au préalable demander conseil sur la liste
de diffusion <tt>debian-legal</tt>, comme il est expliqué plus bas.
</p>

	<p>
En cas de doute à propos d'un copyright, envoyez un courrier électronique à
<email>debian-legal@lists.debian.org</email>. Soyez prêt à nous donner
le copyright complet. Les logiciels couverts par la «&nbsp;GPL&nbsp;», les 
logiciels du domaine public et les copyrights de type «&nbsp;BSD&nbsp;» sont 
sûrs&nbsp;; méfiez-vous d'expressions comme «&nbsp;utilisation commerciale 
interdite&nbsp;» et «&nbsp;distribution limitée&nbsp;».
</p>
      </sect>
      
      <sect id="subsections" >
	<heading>Les sections</heading>

	<p>
Les paquets des catégories (<em>main</em>, <em>contrib</em> et <em>non-free</em>
sont regroupés en <em>sections</em> pour simplifier leur traitement.
</p>

	<p>
	  La catégorie et la section seront spécifiées dans le champ de 
contrôle <tt>Section</tt> de chaque paquet. Toutefois, le responsable de
l'archive Debian peut modifier ce choix afin d'assurer la cohérence de la 
distribution Debian. le champ <tt>Section</tt> sera de la forme&nbsp;:
<list compact="compact">
<item>
<p>
<em>section</em> si le paquet appartient à la catégorie <em>main</em>,
</p>
	      </item>
<item>
<p>
<em>segment/section</em> si le paquet appartient aux zones de distribution
<em>contrib</em> ou <em>non-free</em>.
		</p>
	      </item>
           </list>
         </p>

	<p>
Les responsables de l'archive Debian donnent la liste des sections
autorisées&nbsp;:
            <em>admin</em>, <em>base</em>, <em>comm</em>,
            <em>contrib</em>, <em>devel</em>, <em>doc</em>,
            <em>editors</em>, <em>electronics</em>, <em>embedded</em>,
	    <em>games</em>, <em>gnome</em>, <em>graphics</em>, 
	    <em>hamradio</em>, <em>interpreters</em>, <em>kde</em>, 
	    <em>libs</em>, <em>libdevel</em>, <em>mail</em>,
            <em>math</em>, <em>misc</em>, <em>net</em>, <em>news</em>,
            <em>non-free</em>, <em>oldlibs</em>,
            <em>otherosfs</em>, <em>perl</em>, <em>python</em>, 
	    <em>science</em>, <em>shells</em>,
            <em>sound</em>, <em>tex</em>, <em>text</em>,
            <em>utils</em>, <em>web</em>, <em>x11</em>.
	  </p>
      </sect>

<sect id="priorities">
	<heading>Les priorités</heading>
	  
	<p>
	  Chaque paquet aura une <em>priorité</em> spécifiée dans son
<em>fichier de contrôle</em> (voir <ref id="f-Priority">). Cette information, 
utilisée par les outils de gestion des paquets Debian, permet de séparer les 
paquets prioritaires de ceux qui le sont moins.
</p>
	<p>
	  Les outils de gestion des paquets Debian reconnaissent
les <em>niveaux de priorité</em> suivants&nbsp;:

	  <taglist>
	    <tag><tt>required</tt></tag>
	    <item>
	      <p>
Ce sont les paquets nécessaires au bon fonctionnement du système. 
Cela signifie que les fonctionnalités de dpkg dépendent de ces paquets.
Vous ne devez pas les enlever sous peine de rendre votre système complètement 
inutilisable&nbsp;; vous ne pourrez probablement même plus utiliser 
<prgn>dpkg</prgn> pour remettre les choses en place. Les systèmes composés 
uniquement de paquets <tt>required</tt> sont probablement inutilisables, 
mais ils disposent des fonctionnalités suffisantes pour permettre à 
l'administrateur système d'amorcer le système et d'installer d'autres logiciels.
 </p>
	    </item>
	    <tag><tt>important</tt></tag>
	    <item>
	      <p>
Ces paquets incluent ceux que l'on s'attend à trouver  sur un système de type 
Unix. Si l'on pense qu'un expert Unix, détectant l'absence d'un programme 
s'exclamera&nbsp;: «&nbsp;Que se passe-t-il&nbsp;!? Où est le programme 
<prgn>foo</prgn>&nbsp;?&nbsp;», alors celui-ci doit être dans 
<tt>important</tt>
<footnote>
<p>
C'est un critère fort, car nous cherchons à produire, entre autres choses, un 
Unix libre.</p>	</footnote>. Les autres paquets sans
lesquels le système ne fonctionne pas bien ou est inutilisable
doivent avoir cette priorité. Cela <em>n'inclut pas</em>
«&nbsp;Emacs&nbsp;», «&nbsp;X11&nbsp;», «&nbsp;TeX&nbsp;» ou d'autres 
grosses applications. Les paquets <tt>important</tt> constituent simplement un 
ensemble minimal d'outils nécessaires et communément attendus.
 </p>
	    </item>
	    <tag><tt>standard</tt></tag>
	    <item>
	      <p>		
Ces paquets fournissent un système en mode caractère, relativement
petit mais pas trop limité. Ils seront installés par défaut si
l'utilisateur ne sélectionne rien d'autre. Ce niveau laisse de côté
beaucoup de grosses applications. 
</p>
	    </item>
	    <tag><tt>optional</tt></tag>
	    <item>
	      <p>		
En un sens, ce qui n'est pas obligatoire est facultatif, mais
ici «&nbsp;optional&nbsp;» ne doit pas être compris ainsi. Ce sont tous les
logiciels que l'on pourrait raisonnablement vouloir installer quand on ne les
connaît pas et que l'on a pas d'exigences particulières. Cela constitue un 
système nettement plus gros et contient «&nbsp;X11&nbsp;», la distribution 
complète de «&nbsp;TeX&nbsp;» et de nombreuses applications. Notez qu'il ne
doit pas y avoir de conflit entre les paquets optionnels.
</p>
	    </item>
	    <tag><tt>extra</tt></tag>
	    <item>
	      <p>
Sont regroupés là les paquets qui sont en conflit avec d'autres
paquets dont les priorités sont «&nbsp;required&nbsp;», «&nbsp;important&nbsp;», «&nbsp;standard&nbsp;»
ou «&nbsp;optional&nbsp;», ou bien les paquets utiles uniquement
si vous savez déjà ce qu'ils font, ou bien les paquets qui ont des
exigences spécifiques.	
	      </p>
	    </item>
	  </taglist>
	</p>
	  
	<p>
	Les paquets ne doivent pas dépendre de paquets dont les priorités 
sont de valeur inférieure (hors dépendances pour la construction).
Pour cela, on pourra ajuster les priorités d'un ou de plusieurs paquets.
	</p>
      </sect>
    </chapt>
	  
      <chapt id="binary">
	<heading>Les paquets binaires</heading>
	  
	<p>
La distribution Debian GNU/Linux est fondée sur le système Debian de gestion de
paquets, appelé <prgn>dpkg</prgn>. Par conséquent, tous les
paquets de la distribution Debian doivent être fournis au format de
fichier <tt>.deb</tt>.
</p>
	
	<sect>
	  <heading>Le nom d'un paquet</heading>
	    
	  <p>
Chaque paquet doit avoir un nom unique dans l'archive Debian.
</p>
	  <p>
Le nom d'un paquet est inclus dans le champ de contrôle <tt>Package</tt>
dont le format est décrit dans <ref id="f-Package">.
Le nom d'un paquet fait aussi partie du nom du fichier <tt>.deb</tt>.
	  </p>
	</sect>

      <sect id="versions">
        <heading>La version d'un paquet</heading>
<p>
Chaque paquet possède un numéro de version enregistré dans le champ
<tt>Version</tt> de son fichier de contrôle, voir <ref id="f-Version">.
</p>
<p>
Le système de gestion des paquets impose un ordre aux numéros de 
version&nbsp;: il peut ainsi connaître quel type de mise à niveau est en 
cours et les applications qui lui servent d'interface peuvent dire si un 
paquet disponible est plus récent que celui installé sur le système. La 
partie la plus significative (du moins en ce qui concerne la comparaison) du 
format des numéros de version se trouve au début.
      </p>

<p>
Quand la numérotation d'un paquet pose problème, elle sera convertie en un
format utilisable dans le champ <tt>Version</tt>.
      </p>

	<sect1>
	  <heading>La numérotation des versions fondée sur des dates</heading>

<p>
En règle générale, les paquets Debian utiliseront les mêmes numéros de 
version que les sources.</p>

<p>
Cependant, la numérotation des sources est parfois fondée sur une date (par
exemple, un instantané d'une version de développement)&nbsp;; le système de 
gestion des paquets ne peut pas manipuler cette numérotation sans les
<em>epochs</em>. Et <prgn>dpkg</prgn> par exemple considère que
«&nbsp;96May01&nbsp;» est plus grand que «&nbsp;96Dec24&nbsp;».
</p>

<p>
Pour éviter l'utilisation d'<em>epochs</em> à chaque nouvelle version source,
on emploiera pour la partie date du numéro de version le format suivant&nbsp;: 
«&nbsp;19960501&nbsp;», «&nbsp;19961224&nbsp;».
Le responsable de paquet décidera d'embêter ou non le responsable des
sources avec une demande de modification de la numérotation de ses versions. 
	</p>

<p>
Il faut noter que d'autres formats fondés sur les dates et qui sont 
correctement analysés par le système de gestion des paquets <em>ne doivent
pas</em> être modifiés.
	</p>

<p>
Les paquets «&nbsp;Debian pure souche&nbsp;» (c.-à-d. écrits spécialement 
pour Debian) 
dont les numéros de version comprennent des dates utiliseront toujours le
format suivant&nbsp;: «&nbsp;AAAAMMJJ&nbsp;».
	</p>
	</sect1>
      </sect>
	        
	<sect>
	  <heading>Le responsable d'un paquet</heading>
	    
	  <p>
	    Chaque paquet doit avoir un responsable Debian (quelqu'un ou 
un groupe de personnes, qu'on peut joindre à une adresse électronique, telle
que, par exemple, une liste de diffusion). Le responsable assure que la 
licence du logiciel du paquet suit les règles des distributions auxquelles 
il appartient.
</p>
	  <p>
Le responsable doit être indiqué dans le champ <tt>Maintainer</tt> avec son 
nom correct et une adresse électronique valable. Quand une personne s'occupe 
de plusieurs paquets, elle essaiera d'éviter d'avoir différents noms ou 
adresses dans les champs <tt>Maintainer</tt> des différents paquets.
</p>
        <p>
Le format du champ <tt>Maintainer</tt> est décrit dans <ref id="f-Maintainer">.
        </p>
	    
	  <p>
Quand la personne en charge d'un paquet quitte le projet Debian,
c'est le groupe Debian QA <email>packages@qa.debian.org</email>
qui reprend la maintenance du paquet jusqu'à ce qu'un volontaire 
se propose pour cette tâche.
Ces paquets sont appelés <em>paquets orphelins</em>
<footnote>
La façon élégante de le faire peut être trouvée dans le 
« Debian Developer's Reference », voyez <ref id="related">.
            </footnote>.
</p>
      </sect>
	    
	    	<sect id="descriptions">
	  <heading>La description d'un paquet</heading>
	    
	  <p>
Chaque paquet Debian doit avoir une description complète enregistrée
dans les champs <em>ad hoc</em> de son <em>fichier de contrôle</em>.
L'information technique sur le format du champ <tt>Description</tt> se trouve 
dans <ref id="f-Description">.
        </p>
<p>
La description donnera assez d'informations sur le paquet (le programme) pour 
qu'un utilisateur (un administrateur système) n'ayant jamais rencontré ce 
paquet puisse décider de l'installer. La description ne reprendra pas 
simplement la documentation du programme.
	</p>
<p>
Mettez les informations importantes d'abord, à la fois dans le résumé et
dans la description longue. Parfois, seule la première partie du résumé ou
de la description longue est affichée. On peut assumer malgré tout qu'il y a 
une façon de voir toute la description longue.
	</p>
<p>
La description donnera aussi des informations sur les dépendances et les
conflits significatifs entre ce paquet et les autres&nbsp;: l'utilisateur
saura ainsi pourquoi ces dépendances et ces conflits ont été déclarés.
	</p>
<p> Les instructions de configuration ou d'utilisation du paquet ne doivent 
pas en faire partie (c'est le rôle des scripts d'installation, des pages de 
man, des fichiers infos, etc.), non plus que les notices de copyright et les
autres écrits administratifs (c'est le rôle des fichiers de copyright).
</p>

<sect1 id="synopsis"><heading>Le résumé sur une seule ligne</heading>

<p>
La ligne de résumé sera brève -- moins de 80 caractères.
	  </p>

<p>
Ne mettez pas le nom du paquet dans la ligne de résumé. Le logiciel
sait déjà l'afficher, et ce n'est pas nécessaire de l'indiquer. N'oubliez pas
que dans beaucoup de cas, l'utilisateur ne peut lire que la ligne de 
résumé&nbsp;: il faut donc la rendre aussi instructive que possible.
	  </p>
	</sect1>

<sect1 id="extendeddesc"><heading>La description étendue</heading>

<p>
N'essayez pas de poursuivre la ligne du résumé dans la description étendue. 
Cela ne fonctionnera pas correctement quand la description complète est 
affichée et cela n'aura aucun sens quand seul le résumé est disponible.
	  </p>
<p>
La description étendue décrira ce que fait le paquet, et comment il
se relie au reste du système (en termes, par exemple, de sous-systèmes,
de partie de ...).
	  </p>
<p>
Le champ description doit être compréhensible par tout le monde, y compris
par ceux qui n'ont aucune idée de ce que fait le paquet <footnote>
<p>
Le commentaire, qui est fourni par un programme dans ses fichiers
d'annonces ou dans les fichiers <tt>README</tt>, est rarement approprié pour 
une utilisation dans une description. Il est habituellement conçu pour les
gens qui connaissent déjà le paquet.
	      </p>
	    </footnote>.
	  </p>

	</sect1>
      </sect>
	    
	<sect>
	  <heading>Les dépendances</heading>
	    
	  <p>
Chaque paquet doit indiquer ses relations de dépendance avec les
paquets dont il a besoin pour fonctionner correctement.
</p>
	  <p>
Par exemple, une relation de dépendance doit être déclarée pour toute 
bibliothèque partagée qui est demandée par un exécutable 
dynamiquement lié d'un paquet.
</p>
	    
	  <p>
Il n'est pas nécessaire d'indiquer les dépendances d'un paquet envers
des paquets étiquetés <tt>Essential</tt> (voir ci-dessous), et on ne doit 
pas le faire, à moins que ce ne soit une dépendance pour une version
précise de tel paquet.<footnote>
            <p>
<tt>Essential</tt> est défini comme l'ensemble minimal de fonctionnalités qui
doivent être disponibles et utilisables sur le système même quand les paquets
sont dans un état non configuré (mais dépaqueté). Cela est nécessaire pour
éviter des boucles de dépendances non solutionnables lors des mises à jour. Si
des paquets ajoutent des dépendances inutiles sur des paquets de cet ensemble,
les possibilités qu'il y <strong>aura</strong> une boucle de dépendance non
solutionnable induite par le forçage de configuration de ces paquets essentiels
avant que cela ne soit nécessaire est fortement augmenté. Cela augmente
également les possibilités que des frontaux ne seront pas capable de
<strong>calculer</strong> un chemin de mise à jour, même si celui-ci existe.
            </p>
            <p>
De plus, il est peut probable qu'une fonctionnalité d'<tt>Essential</tt> soit
jamais supprimée (ce qui est une raison pour laquelle une attention particulière
doit être prise avant de faire un ajout à l'ensemble des paquets
d'<tt>Essential</tt>), mais des <em>paquets</em> ont été retirés de l'ensemble
<tt>Essential</tt> quand la fonctionnalité a été déplacée dans un paquet
différent. Donc, dépendre de ces paquets <em>au cas où</em> ils ne seraient plus
essentiels pose plus de problèmes que cela n'en résoud.
            </p>
          </footnote>
</p>
	  <p>
Dans certains cas, l'installation d'un paquet exige l'installation 
<em>et</em> la configuration préalables d'un autre paquet. Il faut alors 
déclarer une relation <tt>Pre-Depends</tt> pour ce paquet.</p>
	    
	  <p>
Vous ne déclarerez pas une relation <tt>Pre-Depends</tt>
pour un paquet avant qu'une discussion dans la liste de diffusion 
<tt>debian-devel</tt> n'ait abouti à un consensus sur le sujet.
</p>
        <p>
Le format des champs concernant les relations entre paquets est décrit dans
<ref id="relationships">.
        </p>
      </sect>

	<sect id="virtual_pkg">
	  <heading>Les paquets virtuels</heading>
	    
	  <p>
Parfois il y a des paquets qui font plus ou moins la même chose.
Dans ce cas, il est utile de définir un <em>paquet virtuel</em> dont
le nom décrit la fonction de ces paquets. Les paquets virtuels existent
de manière logique et non physique&nbsp;; c'est pour cela qu'ils sont appelés
<em>virtuels</em>. Les paquets assurant cette fonction viendront 
<em>pourvoir</em> ce paquet virtuel. Ainsi, tout autre paquet qui a besoin 
de cette fonction pourra simplement dépendre du paquet virtuel, sans
avoir à énumérer tous les paquets possibles.
</p>
	    
	  <p>
Tous les paquets utiliseront les noms de paquets virtuels
quand il conviendra de le faire&nbsp;; ils s'arrangeront pour en créer de
nouveaux quand ce sera nécessaire. On n'utilisera que les paquets 
virtuels qui ont été acceptés et qui apparaissent dans la liste des noms de 
paquets virtuels 
(sauf de manière privée, pour un ensemble local de paquets corrélés).
Voir aussi <ref id="virtual">.
</p>
	    
	  <p>
La version la plus récente de la liste officielle des paquets virtuels se 
trouve dans le paquet <tt>debian-policy</tt>. Elle est aussi disponible sur
les miroirs web de Debian,
<tt><url name="/doc/packaging-manuals/virtual-package-names-list.txt"
                id="https://www.debian.org/doc/packaging-manuals/virtual-package\-names-list.txt"></tt>.
         </p>
<p>
 La procédure de mise à jour de la liste est décrite au début de la liste.
</p>
</sect>
	    
	<sect>
	  <heading>Le système de base</heading>
	    
	  <p>
Le système de base est le sous-ensemble minimal du système Debian
GNU/Linux qui est installé, avant tout autre chose, sur un nouveau système.
Ainsi, seulement un tout petit nombre de paquets peut aller dans
la section <tt>base</tt> afin de minimiser la quantité d'espace disque
nécessaire à une installation.
</p>	    
	  <p>
La plupart de ces paquets auront le niveau de priorité
<tt>required</tt> ou au moins <tt>important</tt> et beaucoup d'entre eux
seront étiquetés <tt>essential</tt> (voir ci-dessous).
</p>
	    
      </sect>
	    
	<sect>
	  <heading>Les paquets «&nbsp;essential&nbsp;»</heading>
	    
	  <p>
Certains paquets sont marqués <tt>essential</tt>, pour les systèmes qui
utilisent ce champ <tt>Essential</tt> dans le fichier de contrôle.
Le format de ce champ est décrit dans <ref id="f-Essential">.
	</p>
	  <p>
Comme ces paquets ne peuvent pas être facilement supprimés
(il faut ajouter une option de <em>forçage</em> de <prgn>dpkg</prgn>),
l'indicateur <tt>essential</tt> ne doit être utilisé que si
c'est absolument nécessaire.
Un paquet comprenant une bibliothèque partagée ne doit pas être étiqueté
<em>essential</em>&nbsp;; les dépendances empêchent sa suppression
prématurée, or il doit être possible de supprimer le paquet quand la 
bibliothèque est périmée.
</p>
<p>
Comme <prgn>dpkg</prgn> n'empêche pas la mise à jour de paquets alors qu'un 
paquet <em>essential</em> n'est pas configuré, tous les paquets 
<em>essential</em> doivent fournir l'essentiel de leurs fonctions même s'ils
ne sont pas configurés. Quand un paquet ne peut pas satisfaire à cette
exigence, il ne doit pas être étiqueté <em>essential</em>&nbsp;; et tous les 
paquets qui en dépendent doivent, comme il est de règle, expliciter leurs 
dépendances.
</p>
	    
	  <p>
Vous ne devez pas étiqueter un paquet comme <tt>essential</tt> avant qu'une
discussion dans la liste de diffusion <tt>debian-devel</tt>
n'ait abouti à un consensus sur le sujet.
</p>
      </sect>

	<sect id="maintscripts">
	  <heading>Les scripts du responsable de paquet</heading>
	    
	  <p>
Les scripts d'installation d'un paquet éviteront d'afficher des
messages que l'utilisateur n'a pas besoin de voir et s'appuieront
sur <prgn>dpkg</prgn> pour sauver de l'ennui un utilisateur qui
installe de nombreux paquets. Cela signifie entre autres choses qu'il faut
utiliser l'option <tt>--quiet</tt> de <prgn>install-info</prgn>.
</p>
	    
	  <p>
Les scripts d'installation doivent détecter toute erreur qui se produit et
doivent arrêter immédiatement l'installation en cours.
</p>
	    
	  <p>
On remarquera que la section <ref id="scripts">, s'applique généralement
aussi aux scripts des responsables de paquet.
</p>

<p>
On n'utilisera pas <prgn>dpkg-divert</prgn> sur un fichier appartenant à 
un autre paquet sans avoir consulté au préalable le responsable du paquet en 
question.
</p>

<p>
Tous les paquets qui donnent une valeur au nom «&nbsp;partagé&nbsp;» d'une 
commande (en général, c'est un nom de fichier), utiliseront en général
<prgn>update-alternatives</prgn>, de manière à rendre possible leur
installation simultanée. Quand on n'emploie pas 
<prgn>update-alternatives</prgn>, chaque paquet doit utiliser 
<tt>Conflicts</tt> pour s'assurer que les autres paquets ne sont pas
installés. On peut spécifier dans ce cas un conflit avec quelques
versions antérieures d'un paquet qui n'utilisait pas
<prgn>update-alternatives</prgn>&nbsp;; c'est une exception à la règle
habituelle qui demande d'éviter les conflits de version.
</p>

<sect1 id="maintscriptprompt">
<heading>Poser des questions via les scripts du responsable</heading>
<p>
Les scripts du responsable de paquet peuvent interroger l'utilisateur quand
c'est nécessaire. L'interrogation se fera par l'intermédiaire d'un programme,
tel que <prgn>debconf</prgn>, qui se conforme à la spécification Debian pour
les systèmes de configuration, version 2 ou supérieure.
On peut interroger par d'autres moyens, notamment 
<em>à la main</em>&nbsp;<footnote>
Tiré du Jargon&nbsp;: <em>à la main</em> 2. Par extension, écrire du code pour
faire quelque chose explicitement ou à un bas niveau alors qu'une routine
de bibliothèque (<em>debconf, dans ce cas</em>) est déjà disponible.
              </footnote> mais c'est déconseillé.
</p>

           <p>
La spécification Debian pour les systèmes de configuration se trouve dans le
fichier <file>debconf_specification</file> du paquet 
<package>debian-policy</package>. Elle est aussi disponible sur les miroirs
web de Debian, 
            <tt><url name="/doc/packaging-manuals/debconf_specification.html"
                id="https://www.debian.org/doc/packaging-manuals/debconf_specifi\cation.html"></tt>.
          </p>
<p>
Les paquets qui utilisent les règles Debian de gestion de la configuration
peuvent contenir un script supplémentaire <prgn>config</prgn> et un fichier
<tt>templates</tt> dans leur archive de contrôle <footnote>
Le fichier control.tar.gz dans le .deb.
Voyez <manref name="deb" section="5">.
           </footnote>.
Le script
<prgn>config</prgn> peut être lancé avant le script <prgn>preinst</prgn> et
avant que le paquet soit dépaqueté ou bien avant que ses dépendances et
pré-dépendances soient satisfaites : il doit donc fonctionner en utilisant
seulement les outils présents dans les paquets <em>Essential</em> <footnote>
<p>
<package>Debconf</package> ou tout autre outil qui met en ½uvre les règles 
Debian de gestion de la configuration est aussi installé, et toutes les 
dépendances concernant des versions sont satisfaites avant le commencement de 
la configuration préalable.
		</p>
	      </footnote>.
	    </p>
	    
<p>
Les paquets essaieront de minimiser le nombre de questions posées et 
s'assureront que chaque question ne sera posée qu'une seule fois. Cela 
signifie que les paquets doivent essayer d'utiliser les fichiers de 
configuration partagés (comme <tt>/etc/papersize</tt> ou 
<tt>/etc/news/server</tt>) et les variables partagées de 
<package>debconf</package>, plutôt que de redemander, chacun, la même 
information.
</p>
	  
<p>
Cela signifie aussi que, lors d'une mise à niveau, on ne doit pas poser
encore les mêmes questions, à moins que l'utilisateur n'ait utilisé
<tt>dpkg --purge</tt> pour supprimer les fichiers de configuration. Les
réponses aux questions de configuration seront sauvegardées à l'endroit
approprié dans <tt>/etc</tt>, et l'on documentera le processus&nbsp;; ainsi 
l'utilisateur pourra les modifier.
	    </p>
	  <p>
Quand un paquet doit donner une information importante à l'utilisateur
(comme&nbsp;: «&nbsp;n'exécutez pas directement ce programme, vous devez 
d'abord
modifier les fichiers de configuration suivants sinon votre système
émettra des messages mal formatés&nbsp;»), il affichera ce message
dans le script <prgn>config</prgn> ou dans le script <prgn>postinst</prgn>).
Il demandera ensuite à l'utilisateur de taper sur la touche
«&nbsp;retour-chariot&nbsp;» quand il a pris connaissance du message. Les 
messages de copyright et les instructions d'utilisation ne sont pas considérés
comme des messages vitaux. Ils doivent apparaître respectivement
dans <tt>/usr/share/doc/<var>paquet</var>/copyright</tt> et dans la
documentation en ligne, où tous les utilisateurs peuvent les consulter.
</p>
	    
	  <p>
Presque toujours, seuls les scripts <prgn>config</prgn> et 
<prgn>postinst</prgn> poseront les questions nécessaires&nbsp;; quand on utilise
le script <prgn>postinst</prgn>, il doit empêcher, par une condition 
quelconque, qu'elles soient posées en cas d'échec de l'installation d'un 
paquet ou s'il est appelé avec <tt>abort-upgrade</tt>, <tt>abort-remove</tt> ou
<tt>abort-deconfigure</tt>.
</p>
	</sect1>
      </sect>
    </chapt>

<chapt id="source">
	<heading>Les paquets sources</heading>
	  
      <sect id="standardsversion">
	  <heading>La conformité aux manuels Debian</heading>

 <p>
On indiquera la version la plus récente de la <em>Charte Debian</em> à 
laquelle s'est conformé le paquet lors de sa mise à jour la plus récente. 
	</p>
          <p>
On peut utiliser cette valeur pour remplir automatiquement des rapports de
bogue quand le paquet est vraiment trop vieux.
</p>
<p>
La version est indiquée dans le champ de contrôle <tt>Standards-Version</tt>. 
Le format de ce champ est décrit dans <ref id="f-Standards-Version">.
</p>
	  <p>
Vous consulterez régulièrement, et notamment si votre paquet est obsolète,
la plus récente version de la <em>Charte Debian</em>, et vous mettrez à jour 
votre paquet si nécessaire.
Lorsque le paquet est conforme à la nouvelle norme,
vous mettrez à jour le champ <tt>Standards-Version</tt>
du paquet source et vous le diffuserez
<footnote><p>
Consultez le fichier <tt>upgrading-checklist</tt> pour connaître les
changements entre différentes versions de ce document.</p>
	  </footnote>.
</p>
      </sect>

         <sect id="pkg-relations">
           <heading>Les relations entre paquets</heading>
 
           <p>
Les paquets source préciseront les paquets binaires qui doivent être 
installés et ceux qui ne doivent pas l'être, pour que leur construction 
réussisse.
Si l'on doit, par exemple, compiler un paquet avec un compilateur particulier,
une dépendance de compilation sera déclarée envers ce paquet.
           </p>
 
           <p>
Pour un très petit nombre de paquets, ceux dont on a toujours besoin pour 
compiler, lier et insérer dans un paquet Debian un programme classique écrit 
en C ou C++ comme «&nbsp;Hello world!&nbsp;», il n'est pas nécessaire de 
déclarer explicitement des relations de dépendance. Ces paquets, sur lesquels
on peut trouver des renseignements dans la liste 
<tt>/usr/share/doc/build-essential/list</tt> (contenue dans le
paquet <tt>build-essential</tt>), sont marqués <em>build-essential</em>
<footnote>
<p>
Le raisonnement&nbsp;: 
<list compact="compact">
<item>
<p>
on peut ainsi maintenir une liste distincte de la Charte (une liste nécessite 
moins de contrôle que la Charte)&nbsp;;
		    </p>
		  </item>
<item>
<p>
un paquet distinct permet l'installation des paquets 
«&nbsp;build-essential&nbsp;» sur une machine, et permet aussi que d'autres 
paquets tels que les tâches installent les paquets 
«&nbsp;build-essential&nbsp;» à travers une relation de dépendance&nbsp;;
		    </p>
		  </item>
<item>
<p>
un paquet distinct permet de séparer les rapports de bogues concernant la 
liste du processus de gestion de la charte dans le «&nbsp;BTS&nbsp;»
(système de suivi des bogues).
		    </p>
		  </item>
		</list></p>
	    </footnote>.
</p>
 
           <p>
La liste des dépendances de compilation ne contiendra que les paquets
explicitement nécessaires à la compilation. Les paquets simplement demandés
parce qu'un paquet de cette liste dépend d'eux ne doivent pas être déclarés
<footnote><p>
La raison en est que les relations de dépendance changent et vous ne 
déclarerez que les paquets et <em>seulement ceux-là</em> dont <em>vous</em> 
avez besoin. Ce dont les autres ont besoin est leur affaire. Si, par exemple,
vous utilisez la bibliothèque <tt>libimlib</tt>, vous aurez besoin d'une
dépendance de construction pour le paquet <package>libimlib2-dev</package>&nbsp;;
mais vous n'avez pas besoin de dépendance pour les paquets <tt>libjpeg*</tt>,
même si <tt>libimlib2-dev</tt> dépend de ces paquets&nbsp;: l'installation de
<package>libimlib2-dev</package> s'assurera que toutes les dépendances
nécessaires à son exécution sont satisfaites.</p>
	    </footnote>.
           </p>
 
           <p>
Quand les relations de dépendance de compilation sont indiquées, on doit
pouvoir compiler un paquet et produire un binaire opérationnel sur un
système où les paquets <tt>essential</tt> et <tt>build-essential</tt> sont 
installés ainsi que ceux nécessaires pour que les relations de dépendance de 
compilation soient satisfaites (y compris les implicites). Cela signifie en 
particulier que, dans les relations de 
dépendance de compilation, on doit traiter rigoureusement les questions de
version de manière à éviter les paquets mal ou stupidement configurés quand
les relations de dépendances sont correctement satisfaites.
</p>
         <p>
        Le chapitre <ref id="relationships"> explique les détails techniques.
         </p>
      </sect>

	<sect>
	  <heading>Les modifications dans les sources amont</heading>
	    
	  <p>
Si vous modifiez le code source d'une manière qui n'est pas liée au système
Debian, vous enverrez 
ces changements aux auteurs, dans la forme qu'ils préféreront, de manière à
ce qu'ils puissent être intégrés dans la version originale.
</p>
	    
	  <p>
Si vous avez besoin de configurer le paquet de façon différente sous 
Debian et sous Linux et si les sources originaux ne proposent pas de manière
de le faire, veuillez ajouter ces moyens de configuration.
C'est, par exemple, un nouveau test d'<prgn>autoconf</prgn> ou un
<tt>#define</tt>. Envoyez ensuite le correctif aux auteurs,
en choisissant comme valeur par défaut la configuration qu'ils
avaient choisie.  Vous pouvez facilement remplacer la valeur par défaut
dans votre <tt>debian/rules</tt> ou dans tout autre endroit approprié.
</p>
	  <p>
Vous vérifierez que l'outil <prgn>configure</prgn>
détecte la bonne déclaration d'architecture (reportez-vous à la section 
<ref id="arch-spec"> pour plus de précisions).
</p>
	  <p>
Si vous avez besoin de modifier un <prgn>Makefile</prgn> qui utilise
des scripts <prgn>configure</prgn> de style «&nbsp;GNU&nbsp;», vous modifierez
les fichiers <tt>.in</tt>, plutôt que directement le
<prgn>Makefile</prgn>. Cela permet à l'utilisateur de reconfigurer
le paquet si nécessaire. Vous <em>ne devez pas</em>
configurer le paquet et modifier le <prgn>Makefile</prgn> produit&nbsp;!
Cela rend impossible la reconfiguration ultérieure du paquet par
un autre utilisateur sans perdre vos modififications.
</p>
      </sect>
	    
    <sect id="dpkgchangelog">
<heading>Changelog Debian : <file>debian/changelog</file></heading>
<p>
Ce fichier, <file>debian/changelog</file>, enregistre les modifications 
apportées à la version d'un paquet Debian. <footnote>
<p>
Plutôt que de <em>ré-écrire l'histoire</em> en rectifiant les anciennes
entrées, il vaut mieux en écrire de nouvelles pour corriger les
erreurs de ce fichier.</p></footnote>
Cela comprend les modifications
du paquet Debian par rapport au paquet source ainsi que les autres
changements et mises à jour concernant le paquet
<footnote><p>
Bien que rien n'empêche un auteur qui est aussi le 
responsable Debian d'utiliser ce fichier pour tous les changements, il faudra 
modifier son nom si les responsables Debian et les auteurs deviennent 
différents. Mais dans ce cas, il vaudrait mieux considérer le paquet comme
n'étant pas un paquet Debian «&nbsp;pure souche&nbsp;».
	</p></footnote>.
	</p>

<p>
Son format spécial permet aux outils de construction de paquets
de découvrir quelle version du paquet est en train de se construire
et de trouver des informations spécifiques à cette version.
	</p>

<p>
Le format ressemble à une suite d'entrées&nbsp;:

<example compact="compact">
<var>paquet</var> (<var>version</var>) <var>distribution(s)</var>; 
urgency=<var>urgency</var>
<comment>
<p>[ ligne(s) vide(s) facultative(s), enlevée(s)]</p>
	    </comment>
  * <var>détails des modifications</var>
    <var>plus de détails</var>
<comment>
<p>[ligne(s) vide(s), apparaissant dans la sortie de dpkg-parsechangelog]</p>
	    </comment>
  * <var>encore plus de détails</var>
<comment>
<p>[ligne(s) vide(s) facultative(s), enlevée(s)]</p>
	    </comment>
 -- <var>nom du responsable</var> &lt;<var>adresse électronique</var>&gt;
<var>[deux espaces]</var>  <var>date</var>
</example>
	</p>

<p>
Les entrées <var>paquet</var> et <var>version</var> représentent le nom du 
paquet source et le numéro de version.
	</p>

<p>
L'entrée <var>distribution(s)</var> liste les distributions dans lesquelles 
cette version sera installée. Elle est copiée dans le champ 
<tt>Distributions</tt> du fichier <tt>.changes</tt>.
Voyez <ref id="f-Distribution">.
	</p>

<p>
<var>urgency</var> est la valeur pour le champ <tt>Urgency</tt>
du fichier <tt>.changes</tt> pour l'envoi du paquet sur le serveur (voir
<ref id="f-Urgency">).
Une <var>urgency</var> ne peut pas contenir de virgules&nbsp;; les virgules sont 
utilisées pour séparer les couples 
<tt><var>mot-clé</var>=<var>valeur</var></tt> dans le format du fichier
d'enregistrement de <tt>dpkg</tt> (bien qu'il n'y ait pour
l'instant qu'un seul <var>mot-clé</var> utile&nbsp;: <tt>urgency</tt>)
<footnote><p>
les valeurs habituelles pour <tt>urgency</tt> sont&nbsp;: <tt>low</tt>, 
<tt>medium</tt>, <tt>high</tt> et <tt>emergency</tt>. Elles influent sur la
rapidité avec laquelle on envisagera l'installation du paquet dans la 
distribution <tt>testing</tt> et elles donnent une indication de l'importance
des corrections contenues dans cette mise à jour.</p>
	  </footnote>.
	</p>

<p>
L'énoncé des modifications peut n'être qu'une suite de lignes 
commençant par au moins deux espaces, mais par convention, on commence
une modification par une étoile «&nbsp;*&nbsp;» suivie d'une espace&nbsp;; les 
lignes de continuation sont décalées pour les amener en face du texte de la 
ligne précédente. On peut séparer si l'on veut les groupes de modifications
par des lignes vides.
	</p>

<p>
Si par cette mise à jour sont corrigés des bogues enregistrés par le système 
de suivi de bogues (BTS), ils seront automatiquement fermés par l'installation
de ce paquet dans l'archive Debian et une chaîne 
<tt>closes: Bug#<var>nnnnn</var></tt> sera insérée dans les notes de
modifications<footnote>
<p>
Pour être précis, cette chaîne doit correspondre à l'expression rationnelle
Perl suivante :
              <example>
/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
              </example>
	</p>
<p>
Alors tous les numéros de bogues listés seront fermés par le script de
maintenance de l'archive (<prgn>katie</prgn>), ou, dans le cas d'une mise à
jour par un suppléant du responsable (Non-maintainer-upload), seront
marqués comme corrigés.</p>
	  </footnote>.
Cette information est transmise par le champ <tt>Closes</tt> du fichier
<tt>.changes</tt> (voir <ref id="f-Closes">).
        </p>
<p>
Le nom du responsable et son adresse électronique utilisés dans le 
<em>changelog</em> seront ceux de la personne installant <em>cette</em>
version. Ils <em>ne sont pas</em> nécessairement ceux du responsable habituel
du paquet. Ces informations seront copiées dans le champ <tt>Changed-By</tt>
du fichier <tt>.changes</tt>, (voir <ref id="f-Changed-By">), et plus tard, 
utilisées pour envoyer un 
accusé de réception quand le chargement aura été installé.
    </p>
<p>
La date doit être dans le format RFC 822
<footnote><p>Elle est produite par le programme <prgn>822-date</prgn>.
</p></footnote>&nbsp;;
elle doit inclure le nom du fuseau horaire spécifié
sous forme de chiffre, et en option le nom du fuseau ou son abréviation entre
parenthèses.
    </p>
<p>
La première ligne de «&nbsp;titre&nbsp;» avec le nom du paquet commencera
sur la marge de gauche, la ligne de «&nbsp;fin&nbsp;» avec les renseignements 
sur le responsable et la date, doit être précédée par exactement
une espace. Les éléments responsable et date doivent être
séparés exactement par deux espaces.
	</p>

        <p>
Veuillez consulter <ref id="changelogs"> pour des informations 
supplémentaires sur la manière de placer les fichiers changelog dans les
paquets binaires.
        </p>

<sect1>
<heading>Autres formats pour le fichier changelog</heading>
<p>
Pour les paquets non expérimentaux, le fichier <file>debian/changelog</file> 
doit utiliser un format reconnu par la version la plus récente de 
<prgn>dpkg</prgn>.
	  </p>
<p>
Si vous souhaitez utiliser un autre format, vous pouvez le faire tant que
vous fournissez un outil d'analyse («&nbsp;parser&nbsp;») pour ce format. Cet
outil doit avoir une API compatible avec celle attendue par
<prgn>dpkg-genchanges</prgn> et par <prgn>dpkg-gencontrol</prgn> <footnote>
Si ce nouveau format reçoit un assentiment partagé, vous contacterez le
responsable de <package>dpkg</package> afin qu'il ajoute le script analyseur
de votre format dans le paquet <prgn>dpkg</prgn>. Vous accepterez ainsi que
l'analyseur et sa page de manuel soient distribués sous la licence
«&nbsp;GNU GPL&nbsp;», comme l'est le reste du paquet <prgn>dpkg</prgn>.
	    	    </footnote> 
et il ne doit pas interagir avec l'utilisateur.
</p>
	</sect1>
      </sect>

      <sect id="dpkgcopyright">
	<heading>Copyright&nbsp;: <file>debian/copyright</file></heading>
        <p>
          Tout paquet doit être accompagné par une copie verbatim de son
	  copyright et de sa licence de distribution dans le fichier
	  <file>/usr/share/doc/<var>paquet</var>/copyright</file>
	  (voir <ref id="copyrightfile"> pour plus de détails). Veuillez
	  également consulter <ref id="pkgcopyright"> pour d'autres
	  considérations reliées aux copyrights des paquets.
        </p>
      </sect>

      <sect>
	  <heading>La détection des erreurs dans les makefiles</heading>
	    
	  <p>
Quand <prgn>make</prgn> appelle une commande dans un makefile (incluant les 
makefiles originaux de votre paquet et <tt>debian/rules</tt>), cela se fait par
<tt>sh</tt>. Or <tt>sh</tt> traite mal les erreurs&nbsp;:
si vous incluez un mini-script shell en tant que
commande dans votre makefile, vous constaterez que si
vous n'avez pas de mécanisme de détection d'erreur, <prgn>make</prgn> 
continuera aveuglément malgré les problèmes rencontrés.
</p>
	    
	  <p>
Chaque fois que vous mettez plus d'une commande shell (cela
inclut l'utilisation d'une boucle) dans une commande
du makefile, vous devez vous assurer que les erreurs
sont détectées. Pour de simples commandes composées comme changer de 
répertoire et exécuter un programme,
il est suffisant d'utiliser <tt>&amp;&amp;</tt> à la place
du point-virgule.
Pour des commandes plus complexes incluant la plupart des boucles et 
des instructions conditionnelles, vous ajouterez la commande <tt>set -e</tt> 
au début de chacun de ces mini-scripts shell que sont les commandes d'un 
makefile.
</p>
      </sect>


<sect id="timestamps">
<heading>Cachets de date</heading>

<p>
Les responsables de paquets préserveront, autant que possible, 
les dates de modification des fichiers sources d'un paquet<footnote>
<p>
Le raisonnement est que la connaissance de l'âge d'un fichier apporte 
certaines informations&nbsp;; par exemple, on peut reconnaître l'ancienneté de telle
documentation en regardant la date de modification. Et donc il serait bon de 
préserver les dates de modification des fichiers sources.</p>
	  </footnote>.
</p>
      </sect>

<sect id="restrictions">
<heading>Restrictions sur les objets dans les paquets source</heading>

<p>
Un paquet source ne peut pas contenir des liens «&nbsp;en dur&nbsp;» <footnote>
<p>On ne les détecte pas encore pendant la phase de construction du paquet
source, mais seulement pendant la phase d'extraction.
</p>
<p>
À l'avenir, les liens «&nbsp;en dur&nbsp;» pourraient être autorisés d'une 
manière ou d'une autre, mais cela demandera beaucoup de travail.
	    </p>
	  </footnote>,
des fichiers spéciaux pour les périphériques, des <em>sockets</em> ou des 
fichiers <em>setuid</em> ou <em>setgid</em><footnote>
<p>
Les répertoires <em>setgid</em> sont autorisés.
	    </p>
	  </footnote>.
	</p>
      </sect>

<sect id="debianrules">
<heading><file>debian/rules</file>, le principal script
          de construction</heading>

<p>
Ce fichier doit être un <em>makefile</em> exécutable et doit contenir des 
règles permettant la compilation du paquet et la construction de paquet(s)
binaire(s) à partir des sources.
	</p>

<p>
Il doit commencer par la ligne <tt>#!/usr/bin/make -f</tt>,
afin de pouvoir être appelé directement sans passer par <prgn>make</prgn>.
	</p>

<p>
Puisqu'un script <tt>debian/rules</tt> interactif ne peut pas compiler un
paquet automatiquement et empêche une reproduction de ce paquet binaire par 
d'autres personnes, toutes les <em>cibles exigées</em> DOIVENT ne pas être
interactives. Au minimum, les cibles exigées sont celles qu'appelle
<prgn>dpkg-buildpackage</prgn>, à savoir, <em>clean</em>, <em>binary</em>,
<em>binary-arch</em>, <em>binary-indep</em>, et <em>build</em>. Il s'ensuit 
qu'une cible dont dépendent ces cibles, doit être aussi non interactive.
	</p>
<p>
Les cibles (toutes nécessaires sauf celles marquées facultatives) sont&nbsp;:

<taglist>
<tag><tt>build</tt></tag>
<item>
<p>
La cible <tt>build</tt> procédera à la configuration et à la compilation du 
paquet. Quand un paquet
possède une routine interactive de configuration préalable à la construction, 
soit le paquet source debianisé doit être construit après cette opération 
(afin qu'il puisse être construit sans ré-exécuter cette configuration), soit
la routine de configuration doit devenir non interactive. Cette dernière façon
est préférable quand la routine détecte des caractéristiques propres à
l'architecture.
	      </p>

<p>
Pour certains paquets, notamment ceux où la même arborescence source est 
compilée différemment pour obtenir des paquets binaires différents, la cible 
<tt>build</tt> n'a aucun sens. Pour ces paquets, il suffit de prévoir deux 
cibles ou plus (<tt>build-a</tt>, <tt>build-b</tt>, ...) pour chaque manière 
de construire le paquet et une cible <tt>build</tt> qui ne produit rien. La 
cible <tt>binary</tt> s'occupera de construire le paquet pour chaque cas 
possible et de créer le paquet binaire correspondant à chacun d'eux.
	      </p>

<p>
La cible <tt>build</tt> ne doit pas effectuer d'actions qui exigent les 
privilèges du super-utilisateur.
	      </p>

<p>
La cible <tt>build</tt> peut avoir besoin d'exécuter d'abord la 
cible <tt>clean</tt>. Voir ci-dessous.
	      </p>

<p>
Quand un paquet possède une routine de configuration qui prend du temps, ou 
quand le <em>makefile</em> est pauvrement conçu, ou quand <tt>build</tt> 
a d'abord besoin d'exécuter <tt>clean</tt>, il est alors intéressant 
d'exécuter <tt>touch build</tt> quand le processus de construction est 
terminé. On s'assure ainsi que si <tt>debian/rules build</tt> est lancé à
nouveau, il ne reconstruira pas le programme complet
<footnote><p>
Une autre façon de faire est que <tt>build</tt> dépende de 
<prgn>build-stamp</prgn> sans rien faire d'autre, et que 
<prgn>build-stamp</prgn> fasse le travail et se termine par 
<tt>touch build-stamp</tt>. C'est particulièrement utile si la routine
crée un fichier ou un répertoire appelé <tt>build</tt>&nbsp;; <tt>build</tt>
doit alors être déclaré comme une cible <tt>.PHONY</tt>. Consultez la
documentation de <prgn>make</prgn> pour des renseignements sur les cibles
«&nbsp;phony&nbsp;»</p>
		</footnote>.
	      </p>
	    </item>
   <tag><tt>build-arch</tt> (facultative),
                 <tt>build-indep</tt> (facultative)
            </tag>
            <item>
<p>
Un paquet peut aussi proposer les deux cibles <tt>build-arch</tt> et 
<tt>build-indep</tt>. Si la cible <tt>build-arch</tt> existe, elle fera
la configuration et la compilation nécessaires pour
créer les paquets binaires pour chaque architecture (ce sont les paquets
dont le champ <tt>Architecture</tt> dans le fichier <tt>debian/control</tt>
est différent de <tt>all</tt>). De même, si la cible <tt>build-indep</tt>
existe, elle fera la configuration et la compilation
nécessaires pour créer les paquets binaires indépendant d'une architecture (ce
sont les paquets dont le champ <tt>Architecture</tt> dans le fichier
<tt>debian/control</tt> vaut <tt>all</tt>). La cible <tt>build</tt> dépendra
des cibles <tt>build-arch</tt> et <tt>build-indep</tt> qui sont données par
le fichier <em>rules</em>.
		</p>
<p>
Quand manque l'une des cibles <tt>build-arch</tt> et <tt>build-indep</tt> (ou
les deux), un appel à <tt>debian/rules</tt> avec l'une des cibles manquantes
provoquera un code d'erreur égal à 2. Quand une cible manque, <prgn>make</prgn>
produit automatiquement ce code.
		</p>
<p>
Les cibles <tt>build-arch</tt> et <tt>build-indep</tt> ne 
doivent pas effectuer d'actions qui exigent les privilèges de root.
	      </p>
	    </item>

<tag><tt>binary</tt>, <tt>binary-arch</tt>, <tt>binary-indep</tt></tag>
<item>
<p>
La cible <tt>binary</tt> doit comprendre tout ce qui est nécessaire à 
l'utilisateur pour construire le(s) paquet(s) binaire(s) à partir du paquet
source. Cette cible a deux parties : <prgn>binary-arch</prgn> construit les 
paquets binaires qui sont spécifiques à une architecture particulière, et 
<tt>binary-indep</tt> construit les paquets qui ne le sont pas.
	      </p>
<p>
<tt>binary</tt> peut être (et c'est communément le cas) une cible sans 
commande, qui dépend simplement de <tt>binary-arch</tt> et de 
<tt>binary-indep</tt>.
	      </p>
<p>
Les deux cibles <tt>binary-*</tt> dépendront soit de la cible 
<tt>build</tt>, soit de l'une des cibles <tt>build-arch</tt> ou 
<tt>build-indep</tt> si elles sont proposées, afin que le paquet soit
construit s'il ne l'a pas déjà été. Les paquets binaires pertinents seront 
ensuite créés en  utilisant <prgn>dpkg-gencontrol</prgn> pour créer leurs 
fichiers de contrôle et <prgn>dpkg-deb</prgn> pour construire les binaires et 
les placer dans le répertoire parent du répertoire le plus élevé.
	      </p>

<p>
Les cibles <tt>binary-arch</tt> et <tt>binary-indep</tt> 
<em>doivent</em> exister.
Si l'une des deux cibles <tt>binary-*</tt> n'a rien à faire (ce sera 
toujours le cas si le source crée un seul paquet binaire, qu'il soit 
dépendant de l'architecture ou pas), elle doit tout de même exister,
et doit toujours se dérouler correctement.
	      </p>

<p>
Les cibles <tt>binary</tt> doivent être invoquées avec les privilèges de root
<footnote><p>
Le paquet <prgn>fakeroot</prgn> permet souvent de construire correctement
un paquet tout en n'étant pas root.</p>
		</footnote>.
	      </p>
	    </item>
<tag><tt>clean</tt></tag>
            <item>

<p>
Cette cible doit nettoyer les effets obtenus par les cibles
<tt>build</tt> et <tt>binary</tt>, mais elle doit laisser les 
fichiers de sortie créés par la cible <tt>binary</tt> dans le répertoire 
parent.
	      </p>

<p>
Si un fichier <tt>build</tt> est créé par <prgn>touch</prgn> à la fin
de la cible <tt>build</tt>, comme suggéré ci-dessus, c'est la première 
chose qui sera effacée par la cible <tt>clean</tt>&nbsp;; ainsi 
<tt>build</tt>, exécuté de nouveau après un nettoyage (<tt>clean</tt>)
interrompu, ne pensera pas que tout est déjà fait.
	      </p>

<p>
La cible <tt>clean</tt> peut être invoquée par root, si 
<tt>binary</tt> a été invoqué depuis le dernier <tt>clean</tt>, ou 
si <tt>build</tt> a été invoqué par root (étant donné que 
<tt>build</tt> peut créer des répertoires par exemple).
	      </p>
	    </item>
<tag><tt>get-orig-source</tt> (facultative)</tag>
<item>
<p>
Cette cible va chercher la plus récente version du paquet original dans un 
site d'archive autorisé (par FTP ou WWW, par exemple), s'occupe des 
arrangements nécessaires pour le mettre sous la forme d'un fichier tar (une 
archive source) décrite ci-dessus, et le laisse dans le répertoire en cours.
	      </p>
<p>
Cette cible peut être invoquée dans n'importe quel répertoire et s'occupera
de supprimer tous ses fichiers temporaires. 
	      </p>
<p>
Elle est facultative mais la proposer, quand c'est possible, est une bonne 
idée.
	      </p>
	    </item>
	  </taglist>
    </p>
<p>
Les cibles <tt>build</tt>, <tt>binary</tt> et <tt>clean</tt> 
doivent être invoquées avec comme répertoire courant, le répertoire de plus
haut niveau du paquet.
	</p>
<p>
Des cibles supplémentaires peuvent exister dans <file>debian/rules</file>, soit
comme des interfaces publiées ou non documentées soit pour l'utilisation 
interne du paquet.
	</p>
<p>
Ce sont les variables de <prgn>make</prgn> à travers 
<qref id="pkg-dpkg-architecture"> <prgn>dpkg-architecture</prgn></qref> 
qui déterminent l'architecture <em>sur</em> 
laquelle et <em>pour</em> laquelle on construit. On peut obtenir, aussi bien
pour la machine sur laquelle on construit que pour la machine pour laquelle
on construit, la chaîne indiquant l'architecture Debian et la chaîne
indiquant l'architecture à la façon <em>GNU</em>. Voici une liste de
variables acceptées par <prgn>make</prgn>&nbsp;:
<list compact="compact">
            <item>
              <p><tt>DEB_*_ARCH</tt> (l'architecture Debian)</p>
</item>
            <item>
              <p><tt>DEB_*_GNU_TYPE</tt> (l'architecture indiquée à la
                façon <em>GNU</em>)</p>
            </item>
            <item>
              <p><tt>DEB_*_GNU_CPU</tt> (la partie CPU de 
<tt>DEB_*_GNU_TYPE)</tt></p>
            </item>
            <item>
<p><tt>DEB_*_GNU_SYSTEM</tt> (la partie système de <tt>DEB_*_GNU_TYPE)</tt></p>
	</item>
</list>

où «&nbsp;*&nbsp;» représente <tt>BUILD</tt> pour une indication de la 
machine <em>sur</em>
laquelle on construit, ou bien <tt>HOST</tt> pour une indication de la machine
<em>pour</em> laquelle on construit.
	</p>
<p>
On peut assurer une compatibilité ascendante dans le fichier <em>rules</em>
en fixant par défaut les bonnes variables à des valeurs adéquates&nbsp;;
veuillez consulter la documentation de <prgn>dpkg-architecture</prgn>
pour des précisions.
	</p>
<p>
Il est important de comprendre que la chaîne <tt>DEB_*_ARCH</tt> détermine
seulement l'architecture Debian sur ou pour laquelle on construit. On
ne l'utilisera pas pour avoir des renseignements sur le CPU ou le
système&nbsp;; les variables GNU sont là pour ça.
	</p>
      </sect>

<!-- FIXME: section pkg-srcsubstvars is the same as srcsubstvars -->

<sect id="substvars">
<heading><file>debian/substvars</file>
          et le remplacement de variables</heading>

<p>
Quand <prgn>dpkg-gencontrol</prgn>, <prgn>dpkg-genchanges</prgn> et
<prgn>dpkg-source</prgn> créent des fichiers de contrôle, ils procèdent au 
remplacement des variables qu'ils doivent écrire dans ces fichiers. Les
substitutions de variable sont de la forme 
<tt>${<var>variable-nom</var>}</tt>.
Le fichier facultatif <file>debian/substvars</file> contient les 
remplacements de variable à utiliser. On peut aussi fixer directement les 
variables dans le fichier <file>debian/rules</file> en utilisant l'option 
<tt>-V</tt> des commandes d'empaquetage des sources&nbsp;; certaines 
variables pré-définies sont disponibles.
	</p>
<p>
Le fichier <file>debian/substvars</file> est habituellement créé et modifié 
dynamiquement par les cibles de <file>debian/rules</file>, et dans ce cas, il 
doit être supprimé par la cible <tt>clean</tt>.
	</p>

<p>
Voyez <manref name="dpkg-source" section="1"> pour plus de détails sur les
remplacements de variables source, et sur le format de
<file>debian/substvars</file>.
	</p>
      </sect>

      <sect id="debianwatch">
        <heading>Adresse optionnelle du code source amont&nbsp;:
        <file>debian/watch</file></heading>

        <p>
Il s'agit d'un fichier de contrôle optionnel, mais recommandé pour l'utilitaire
<tt>uscan</tt> qui définit comment scanner automatiquement les sites FTP et HTTP
pour des mises à jour nouvellement disponibles du paquet. C'est utilisé par <url
id="http://dehs.alioth.debian.org/"> et d'autres outils d'Assurance Qualité de
Debian pour aider au contrôle de qualité et à la maintenance de la distribution
dans son ensemble.
        </p>

      </sect>

<sect id="debianfiles">
<heading>Liste des fichiers créés : <file>debian/files</file></heading>

<p>
Ce fichier n'est pas un fichier permanent de l'arborescence source ; il est
utilisé pendant la construction des paquets pour enregistrer quels
fichiers sont créés. <prgn>dpkg-genchanges</prgn>
l'utilise quand il crée un fichier <tt>.changes</tt>.
	</p>
<p>
Ce fichier ne doit pas exister dans le paquet source qu'on propose, et il 
doit être supprimé par la règle <tt>clean</tt> (ainsi que n'importe quel 
fichier temporaire ou de sauvegarde tel que <tt>files.new</tt>
<footnote><p><tt>files.new</tt> est utilisé
temporairement par <prgn>dpkg-gencontrol</prgn> et
<prgn>dpkg-distaddfile</prgn>&nbsp;; ils écrivent une nouvelle version
de <file>files</file> avant de le renommer, pour éviter de laisser
une copie corrompue, si une erreur se produit.</p></footnote>).
Il peut aussi être sage, pour garantir un nouveau départ, de l'enlever ou
de le vider au début de la cible <tt>binary</tt>.
	</p>

<p>
Quand <prgn>dpkg-gencontrol</prgn> est exécuté pour un paquet binaire, il
ajoute une entrée dans le fichier <file>debian/files</file> pour le fichier 
<tt>.deb</tt> qui sera créé quand <tt>dpkg-deb --build</tt> sera
exécuté pour ce paquet binaire. Ainsi pour la plupart des paquets, il n'y a 
rien d'autre à faire que de supprimer ce fichier dans la cible 
<tt>clean</tt>.
	</p>

<p>
Quand une installation de paquet inclut des fichiers autres que ceux du paquet
source ou des paquets binaires dont les fichiers de contrôle ont été créés par
<prgn>dpkg-gencontrol</prgn>, ces fichiers seront placés dans le
répertoire parent du répertoire racine du paquet et 
<prgn>dpkg-distaddfile</prgn> sera appelé pour ajouter ces fichiers à la liste
<file>debian/files</file>.
	</p>
      </sect>
    </chapt>


<chapt id="controlfields">
<heading>Les fichiers de contrôle et leurs champs</heading>

<p>
Le système de gestion des paquets manipule les données de
la même façon&nbsp;: des <em>données de contrôle</em> sont stockées dans des 
<em>fichiers de contrôle</em>.
Les paquets source et binaire possèdent des fichiers de contrôle&nbsp;; et
les fichiers <tt>.changes</tt> qui contrôlent l'installation des
fichiers sur le serveur (upload) sont aussi des fichiers de contrôle 
<footnote>Les bases de données internes à 
<tt>dpkg</tt> sont aussi des fichiers de contrôle.
	</footnote>.
  </p>

<sect id="controlsyntax">
<heading>La syntaxe des fichiers de contrôle</heading>
<p>
Un fichier consiste en un ou plusieurs paragraphes comportant des champs 
<footnote> Ces paragraphes sont aussi appelés des strophes.
	  </footnote>. 
Ces paragraphes sont séparés par des lignes blanches. Certains fichiers de
contrôle n'autorisent qu'un seul paragraphe&nbsp;; d'autres en autorisent 
plusieurs, et dans ce cas, chaque paragraphe fait souvent référence à un 
paquet différent. Dans les paquets sources, par exemple, le premier 
paragraphe se réfère au paquet source et les paragraphes suivants aux paquets 
binaires créés à partir de ce source.</p>
<p>
Chaque paragraphe est une série de champs contenant des données&nbsp;; chaque champ
est constitué d'un nom, suivi par deux-points et la valeur associée. Il se
termine à la fin de la ligne (logique). Les espaces horizontaux (espaces et
tabulations) peuvent apparaître immédiatement avant la valeur et après, mais 
là, ils sont ignorés ; par convention, il y a une espace après les deux-points.
Voici un exemple de champ&nbsp;:
<example compact="compact">
Package: libc6
         </example>
Le nom du champ est <tt>Package</tt> et la valeur est <tt>libc6</tt>.
</p>
<p>
Un grand nombre de valeurs de champ peuvent déborder sur plusieurs lignes ; dans ce cas
chaque nouvelle ligne doit commencer par une espace ou une tabulation.
Toutes les espaces ou tabulations restantes en fin de ligne sont ignorées.
	</p>      
<p>
Dans les champs où il est spécifié que les lignes ne peuvent pas déborder,
une seule ligne de données est
autorisée et les espaces ne sont pas significatives dans le corps du
champ. Les espaces ne doivent jamais apparaître dans les noms (de
paquets, d'architectures, de fichiers, etc), dans les numéros de version
ou entre les éléments de relations de version à plusieurs caractères.
	</p>
<p>
Les noms de champs sont indépendants de la casse&nbsp;; en général, ceux-ci 
sont écrits en commençant par une majuscule puis en mélangeant majuscules et
minuscules comme dans les exemples plus bas.
</p>
<p>
Les lignes vides ou les lignes contenant seulement des espaces ou des
tabulations ne sont pas autorisées à l'intérieur des valeurs de champ ou
entre les champs - ce qui signifierait un nouveau paragraphe.
	</p>
      </sect>

      <sect id="sourcecontrolfiles">
<heading>Le fichier de contrôle d'un paquet source&nbsp;: <file>debian/control</file></heading>

<p>
Le fichier <file>debian/control</file> contient les informations les plus 
importantes sur le paquet source et sur les paquets binaires qui sont créés. 
Elles sont indépendantes des versions.
	  </p>
<p>
Le premier paragraphe contient en général les informations sur le paquet 
source&nbsp;; chaque ensemble suivant décrit 
un paquet binaire que l'arbre source construit.
	  </p>
<p>
Les champs du paragraphe général (le premier, concernant le paquet source) 
sont&nbsp;:
          <list compact="compact">
            <item><qref id="f-Source"><tt>Source</tt></qref> (obligatoire)</item>
            <item><qref id="f-Maintainer"><tt>Maintainer</tt></qref> (obligatoire)</item>
            <item><qref id="f-Uploaders"><tt>Uploaders</tt></qref></item>

            <item><qref id="f-Section"><tt>Section</tt></qref> (recommandé)</item>
            <item><qref id="f-Priority"><tt>Priority</tt></qref> (recommandé)</item>
            <item><qref id="sourcebinarydeps"><tt>Build-Depends</tt> et autres</qref></item>
            <item><qref id="f-Standards-Version"><tt>Standards-Version</tt></qref> (recommandé)</item>
          </list>

      </p>
<p>
Les champs des paragraphes pour les paquets binaires sont&nbsp;:
          <list compact="compact">
            <item><qref id="f-Package"><tt>Package</tt></qref> (obligatoire)</item>
            <item><qref id="f-Architecture"><tt>Architecture</tt></qref> (obligatoire)</item>
            <item><qref id="f-Section"><tt>Section</tt></qref> (recommandé)</item>
            <item><qref id="f-Priority"><tt>Priority</tt></qref> (recommandé)</item>
            <item><qref id="f-Essential"><tt>Essential</tt></qref></item>
            <item><qref id="binarydeps"><tt>Depends</tt> et autres</qref></item>
            <item><qref id="f-Description"><tt>Description</tt></qref> (obligatoire)</item>
          </list>
      </p>
<p>
La syntaxe et la sémantique des champs sont décrites ci-dessous.
          </p>
<!-- stuff -->
<p>
Ces champs sont utilisés par <prgn>dpkg-gencontrol</prgn> pour créer
les fichiers de contrôle pour les paquets binaires (voir ci-dessus),
par <prgn>dpkg-genchanges</prgn> pour créer le fichier <tt>.changes</tt>
qui accompagne l'installation sur le serveur et par <prgn>dpkg-source</prgn> 
quand il crée le fichier de contrôle source <tt>.dsc</tt> comme une partie
de l'archive source. Il est permis pour un grand nombre de champs de s'étendre
sur plusieurs lignes dans <file>debian/control</file>, mais pas dans tout autre
fichier de contrôle. Ces outils sont responsables pour supprimer les sauts de
ligne de tels champs quand des champs de <file>debian/control</file> sont
utilisés pour générer d'autres fichiers de contrôle.
	  </p>
<p>
Les champs peuvent contenir des références à des variables, leurs valeurs
seront substituées par <prgn>dpkg-gencontrol</prgn>, 
<prgn>dpkg-genchanges</prgn> ou <prgn>dpkg-source</prgn> quand ils créeront 
les fichiers de sortie. Voir <ref id="substvars"> pour des précisions.
	  </p>
      </sect>

      <sect id="binarycontrolfiles">
<heading>Les fichiers de contrôles des paquets binaires : <file>DEBIAN/control</file></heading>

<p>
Le fichier <file>DEBIAN/control</file> contient les informations les plus
importantes sur le paquet binaire.
Elles sont indépendantes des versions.
          </p>
        <p>
          Les champs de ce fichier sont&nbsp;:

          <list compact="compact">
            <item><qref id="f-Package"><tt>Package</tt></qref> (obligatoire)</item>
            <item><qref id="f-Source"><tt>Source</tt></qref></item>
            <item><qref id="f-Version"><tt>Version</tt></qref> (obligatoire)</item>
            <item><qref id="f-Section"><tt>Section</tt></qref> (recommandé)</item>
            <item><qref id="f-Priority"><tt>Priority</tt></qref> (recommandé)</item>
            <item><qref id="f-Architecture"><tt>Architecture</tt></qref> (obligatoire)</item>
            <item><qref id="f-Essential"><tt>Essential</tt></qref></item>
            <item><qref id="binarydeps"><tt>Depends</tt> et autres</qref></item>
            <item><qref id="f-Installed-Size"><tt>Installed-Size</tt></qref></item>
            <item><qref id="f-Maintainer"><tt>Maintainer</tt></qref> (obligatoire)</item>
            <item><qref id="f-Description"><tt>Description</tt></qref> (obligatoire)</item>
          </list>
        </p>
      </sect>

      <sect id="debiansourcecontrolfiles">
         <heading>Les fichiers de contrôle des sources Debian  -- <tt>.dsc</tt></heading>
<p>
Ce fichier contient une série de champs, identifiés et séparés comme les
champs dans le fichier de contrôle d'un paquet binaire. Les champs sont
listés ci-dessous&nbsp;; leur syntaxe est décrite ci-dessus dans
<ref id="pkg-controlfields">.

        <list compact="compact">
          <item><qref id="f-Format"><tt>Format</tt></qref> (obligatoire)</item>
          <item><qref id="f-Source"><tt>Source</tt></qref> (obligatoire)</item>
          <item><qref id="f-Version"><tt>Version</tt></qref> (obligatoire)</item>
          <item><qref id="f-Maintainer"><tt>Maintainer</tt></qref> (obligatoire)</item>
          <item><qref id="f-Uploaders"><tt>Uploaders</tt></qref></item>
          <item><qref id="f-Binary"><tt>Binary</tt></qref></item>
          <item><qref id="f-Architecture"><tt>Architecture</tt></qref></item>
          <item><qref id="sourcebinarydeps"><tt>Build-Depends</tt> et autres</qref></item>
          <item><qref id="f-Standards-Version"><tt>Standards-Version</tt></qref> (recommandé)</item>
          <item><qref id="f-Files"><tt>Files</tt></qref> (obligatoire)</item>
        </list>

</p>
<p>
Le fichier de contrôle du paquet source est créé par <prgn>dpkg-source</prgn>
quand il crée l'archive source, à partir des autres fichiers
dans le paquet source, décrit ci-dessus. Quand on le déballe, il est
vérifié par rapport aux autres fichiers et répertoires dans les autres
parties du paquet source, comme décrit ci-dessous.
	      </p>
      </sect>

      <sect id="debianchangesfiles">
        <heading>Les fichiers Debian changes&nbsp;: <file>.changes</file></heading>
        <p>
Les fichiers <file>.changes</file> sont utilisés par les logiciels de gestion de l'archive 
Debian pour gérer les mises à jour des paquets.
Ils contiennent un paragraphe d'informations provenant du fichier 
<file>debian/control</file> ainsi que d'autres données concernant le paquet 
source provenant des fichiers
<file>debian/changelog</file> et <file>debian/rules</file>.
        </p>

        <p>
          Les champs de ce fichier sont les suivants&nbsp;:

          <list compact="compact">
            <item><qref id="f-Format"><tt>Format</tt></qref> (obligatoire)</item>
            <item><qref id="f-Date"><tt>Date</tt></qref> (obligatoire)</item>
            <item><qref id="f-Source"><tt>Source</tt></qref> (obligatoire)</item>
            <item><qref id="f-Binary"><tt>Binary</tt></qref> (obligatoire)</item>
            <item><qref id="f-Architecture"><tt>Architecture</tt></qref> (obligatoire)</item>
            <item><qref id="f-Version"><tt>Version</tt></qref> (obligatoire)</item>
            <item><qref id="f-Distribution"><tt>Distribution</tt></qref> (obligatoire)</item>
            <item><qref id="f-Urgency"><tt>Urgency</tt></qref> (recommandé)</item>
            <item><qref id="f-Maintainer"><tt>Maintainer</tt></qref> (obligatoire)</item>
            <item><qref id="f-Changed-By"><tt>Changed-By</tt></qref></item>
            <item><qref id="f-Description"><tt>Description</tt></qref> (obligatoire)</item>
            <item><qref id="f-Closes"><tt>Closes</tt></qref></item>
            <item><qref id="f-Changes"><tt>Changes</tt></qref> (obligatoire)</item>
            <item><qref id="f-Files"><tt>Files</tt></qref> (obligatoire)</item>
          </list>
        </p>
      </sect>

<sect id="controlfieldslist">
<heading>La liste des champs</heading>

        <sect1 id="f-Source">
          <heading><tt>Source</tt></heading>
<p>
Ce champ identifie le nom du paquet source.
	  </p>
<p>
Dans un fichier principal de contrôle de source ou dans un
fichier <file>.changes</file> ou dans un fichier <file>.dsc</file>, ce champ 
peut ne contenir que le nom du paquet source.
</p>
<p>
Dans un fichier de contrôle d'un paquet binaire (ou dans un fichier
<tt>Packages</tt>), il peut être suivi par un numéro de version entre
parenthèses<footnote><p>En général, on laisse une espace après le nom du
paquet si un numéro de version est spécifié.</p></footnote>.
Ce numéro de version peut être omis (et il l'est par <tt>dpkg-gencontrol</tt>) s'il a la même valeur que le champ <tt>Version</tt> du
paquet binaire en question. Le champ lui-même peut être omis d'un
fichier de contrôle d'un paquet binaire quand le paquet source possède
le même nom et la même version que le paquet binaire.
	  </p>
	</sect1>
        <sect1 id="f-Maintainer">
          <heading><tt>Maintainer</tt></heading>
<p>
Ce champ contient le nom du responsable et son adresse électronique.
Le nom vient d'abord, suivi par l'adresse électronique entre
les signes inférieur et supérieur <tt>&lt;&gt;</tt> (au format RFC 822).
	  </p>
<p>
Si le nom du responsable contient un point alors le champ entier ne
fonctionnera pas directement comme une adresse électronique à cause
d'un problème dans la syntaxe spécifiée dans la RFC 822&nbsp;; un programme
utilisant ce champ comme une adresse doit vérifier cela et corriger le
problème si nécessaire (par exemple en mettant entre parenthèses le nom
et en le déplaçant à la fin, et en amenant l'adresse électronique
devant).
	  </p>
	</sect1>
        <sect1 id="f-Uploaders">
          <heading><tt>Uploaders</tt></heading>

          <p>
Liste les noms et les adresses des co-responsables d'un paquet, s'il y en a.
Quand un paquet possède d'autres responsables que celui nommé dans
le <qref id="f-Maintainer">champ « Maintainer »</qref>, leurs noms et adresses
seront indiqués dans ce champ. Le format est le même que celui du champ 
« Maintainer », plusieurs entrées seront séparées par des
virgules. Actuellement, ce champ est limité à une seule ligne de données. C'est
un champ facultatif.
          </p>
	  <p>
Tout analyseur interprétant le champ Uploaders dans <file>debian/control</file>
devrait l'autoriser à s'étendre sur plusieurs lignes<footnote>
Dans le futur, il sera permis que le champ Uploaders de
<file>debian/control</file> (mais pas dans d'autres fichiers de contrôle)
s'étende sur plusieurs lignes et l'interprétation d'un champ Uploaders de
plusieurs lignes devrait être obligatoire.</footnote>. Les sauts de ligne dans
un champ Uploaders qui s'étendent sur plusieurs lignes ne sont pas significatifs
et les sémantiques du champ sont les mêmes que si les sauts de ligne étaient
absents.
	  </p>
        </sect1>

        <sect1 id="f-Changed-By">
          <heading><tt>Changed-By</tt></heading>
          <p>
Le nom et l'adresse électronique de celui qui a modifié ce paquet.
C'est habituellement le nom du responsable du paquet. Toutes les règles qui
s'appliquent au champ Maintainer s'appliquent aussi.
          </p>
        </sect1>

        <sect1 id="f-Section">
          <heading><tt>Section</tt></heading>

<p>
Le champ <tt>Section</tt> représente un secteur d'applications dans laquelle 
le paquet a été classé (voir <ref id="subsections">).
	  </p>
<p>
Quand ce champ apparaît dans le fichier <file>debian/control</file>, il
donne la valeur du sous-champ <tt>Section</tt> du champ <tt>Files</tt> 
du fichier <file>.changes</file>, et il donne la valeur par
défaut de la section pour les paquets binaires.
	  </p>
	</sect1>

        <sect1 id="f-Priority">
          <heading><tt>Priority</tt></heading>
<p>
Le champ <tt>Priority</tt> représente l'importance accordée à un paquet.
Voyez <ref id="priorities">.
	  </p>

<p>
Quand ce champ apparaît dans le fichier <file>debian/control</file>, il
donne la valeur du sous-champ <tt>Priority</tt> du champ <tt>Files</tt>
du fichier <file>.changes</file>, et il donne la valeur par
défaut de la priorité pour les paquets binaires.
          </p>
	</sect1>

<sect1 id="f-Package">
<heading><tt>Package</tt></heading>

<p>
Le nom du paquet binaire. Les noms de paquet sont constitués de
lettres minuscules (<tt>a-z</tt>), de chiffres (<tt>0-9</tt>), et des 
caractères plus (<tt>+</tt>), moins (<tt>-</tt>), ainsi que du point
(<tt>.</tt>). Il doit contenir au moins deux caractères et doit commencer 
par un caractère alphanumérique.
	  </p>
	</sect1>
	
        <sect1 id="f-Architecture">
          <heading><tt>Architecture</tt></heading>
<p>
Selon le contexte et le fichier de contrôle utilisé, le champ 
<tt>Architecture</tt> peut comporter les valeurs suivantes :
            <list>
                <item>Un mot unique identifiant l'architecture d'une machine
                      Debian, voyez <ref id="arch-spec">.
                <item><tt>all</tt>, qui indique un paquet indépendant d'une
                      architecture.
                <item><tt>any</tt>, qui indique un paquet qui peut être
                      construit pour toutes les architectures.
                <item><tt>source</tt>, qui indique un paquet source.
            </list>

	  </p>

<p>
Dans le fichier principal <file>debian/control</file> du paquet source, ou dans
le fichier de contrôle des paquets sources <tt>.dsc</tt>, on peut indiquer 
une liste des architectures (séparées par des espaces) ou bien les valeurs 
spéciales, <tt>any</tt> et <tt>all</tt>.
	  </p>
          <p>
Utiliser la valeur<tt>any</tt> indique que le paquet source ne dépend pas
d'une architecture particulière et qu'il se compile bien sur toute
architecture. Le paquet binaire résultant sera spécifique à 
l'architecture qui a cours <footnote>
                C'est la valeur la plus utilisée et celle qui est conseillée
pour les nouveaux paquets qui ne ne sont pas <tt>Architecture: all</tt>.
            </footnote>.
          </p>
<p>
Utiliser une liste d'architectures indique que le paquet source produira
un paquet dépendant de l'architecture et fonctionnera correctement sur toutes
les architectures listées <footnote>
C'est une valeur utilisée dans une minorité de cas, quand le programme n'est
pas portable. Et elle ne devrait pas être utilisée pour les nouveaux
paquets.    </footnote>.
          </p>

<p>
Dans un fichier <file>.changes</file>, le champ <tt>Architecture</tt> liste la
ou les architectures des paquets qui sont installés sur le serveur. Ce sera 
une liste&nbsp;; si le source du paquet est aussi installé, l'entrée spéciale 
<tt>source</tt> est aussi présente.
	  </p>
<p>
Voir <ref id="debianrules"> pour des informations sur la manière
d'obtenir l'architecture pour le processus de construction.
	  </p>
	</sect1>

        <sect1 id="f-Essential">
          <heading><tt>Essential</tt></heading>
<p>
C'est un champ booléen qui ne peut apparaître que dans un fichier de
contrôle d'un paquet binaire ou dans un paragraphe concernant un 
paquet dans un fichier principal de contrôle de source.
	  </p>
<p>
S'il est positionné à <tt>yes</tt>, le système de gestion des paquets
refusera d'enlever ce paquet (bien qu'il puisse être mis à niveau
ou remplacé). L'autre valeur possible est <tt>no</tt>, ce qui est la
même chose que de ne pas avoir de champ du tout.
	  </p>
	</sect1>

        <sect1>
          <heading>Les champs concernant la relation entre les paquets&nbsp;:
            <tt>Depends</tt>, <tt>Pre-Depends</tt>,
            <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Conflicts</tt>,
            <tt>Provides</tt>, <tt>Replaces</tt>, <tt>Enhances</tt>
          </heading>
<p>
Ces champs décrivent les relations du paquet avec les autres paquets.
Leurs syntaxe et sémantique sont décrites dans <ref id="relationships">.
	  </p>
	</sect1>

        <sect1 id="f-Standards-Version">
          <heading><tt>Standards-Version</tt></heading>

          <p>
Ce champ donne la plus récente version des normes (la charte Debian et les
textes associés) à laquelle se conforme le paquet.
</p>
<p>
Le numéro de version est composé de quatre parties&nbsp;: un numéro de version
majeur et un mineur, un niveau de patch majeur et un mineur. Quand les normes
changent, exigeant des modifications dans tous les paquets, le numéro
majeur est changé. Les changements significatifs, exigeant des évolutions
dans de nombreux paquets, sont signalés par un changement du numéro mineur.
Le niveau majeur de patch sera modifié pour tout changement
limité de la signification des standards. Le niveau de
patch mineur sera changé pour toute amélioration légère (typographique, ou
autres...) qui ne modifie pas le sens de ce document, ou pour des changements
qui n'affectent pas le contenu des paquets.
</p>
          <p>
Seuls les trois premiers chiffres de la version sont significatifs pour le
champ <em>Standards-Version</em>, et on peut choisir
de donner soit les trois chiffres, soit la formule complète
            <footnote>
              <p>
Par le passé, on devait donner la formule complète à quatre chiffres,
par exemple&nbsp;: «&nbsp;2.3.0.0&nbsp;». Mais comme un changement de niveau de
patch n'introduit pas une nouvelle norme, on a trouvé préférable d'assouplir
la règle et de ne demander qu'une formule à trois chiffres, dans ce cas&nbsp;:
«&nbsp;2.3.0&nbsp;». (On peut toujours utiliser la formule complète si l'on
veut.)
              </p>
            </footnote>.
          </p>

	<sect1 id="f-Version">
<heading><tt>Version</tt></heading>

	  <p>	    
Ce champ donne le numéro de version d'un paquet. Son format est le 
suivant&nbsp;: [<var>epoch</var><tt>:</tt>]<var>version_amont</var>[<tt>-</tt><var>révision_debian</var>]
	  </p>
          <p>
     Les trois composantes sont :
<taglist>

<tag><var>epoch</var></tag>
<item>
<p>
C'est simplement un entier non signé (souvent petit). Il peut être
omis et dans ce cas il est égal à 0. S'il est omis, le champ
<var>version_originelle</var> ne peut pas contenir un «&nbsp;:&nbsp;».
</p>
<p>
Il sert à permettre les erreurs dans les numéros des vieilles 
versions d'un paquet, et aussi à abandonner les précédentes structures de 
numérotation concernant les versions d'un paquet.
</p>
	  </item>

<tag><var>version_amont</var></tag>
<item>
<p>
C'est la partie principale du champ. En général, on utilise le numéro de la 
version amont («&nbsp;upstream&nbsp;») du paquet à partir duquel le 
fichier <file>.deb</file> a été créé (s'il est utilisable). Le plus souvent, 
ce champ est dans le même format que celui spécifié par le ou les auteurs 
amont&nbsp;; cependant, il peut devoir être reformaté pour s'adapter au format 
et aux méthodes de comparaison du système de gestion des paquets.
	    </p>
<p>
Les méthodes de comparaison du système de gestion des paquets en ce qui
concerne la partie <var>version_amont</var> sont décrites  ci-dessous. 
Cette partie est obligatoire.
	    </p>
<p>
La partie <var>version_amont</var> ne peut contenir que des
caractères alphanumériques <footnote><p>Les caractères alphanumériques sont&nbsp;:
<tt>A-Za-z0-9</tt></p>
	      </footnote>et les caractères <tt>.</tt>, <tt>+</tt>,
<tt>-</tt> et <tt>:</tt> (point, plus, trait d'union et deux-points)&nbsp;; elle 
commencera par un chiffre. S'il n'y a pas de partie <var>révision_debian</var>
alors le trait d'union «&nbsp;-&nbsp;» n'est pas autorisé. S'il n'y a pas de
partie <var>epoch</var> alors les «&nbsp;:&nbsp;» ne sont pas autorisés.
	    </p>
	  </item>

<tag> <var>révision_debian</var></tag>
<item>
<p>
Cette partie du champ indique le numéro de version du paquet Debian basé sur
la version originelle. Il ne peut contenir que des caractères alphanumériques
et les caractères <tt>+</tt> et <tt>.</tt> (plus et point)&nbsp;; les 
méthodes de comparaison sont les mêmes que pour la partie 
<var>version_amont</var>.
	  </p>
<p>
Cette partie est facultative. Si elle manque, la partie
<var>version_amont</var> ne peut contenir de trait d'union.  
On utilise cette partie quand un morceau de code a été écrit spécialement pour
obtenir un paquet Debian. Il n'y a qu'une seule <em>debianisation</em> de
ce paquet et aucune indication de révision n'est nécessaire.
</p>

<p>
Par convention, la partie <var>révision_debian</var> est remis à 1 à chaque
fois que la partie <var>version_amont</var> est incrémentée.
</p>

<p>
Le système de gestion des paquets sépare les parties 
<var>version_amont</var> et <var>révision_debian</var> au dernier trait 
d'union de la chaîne. Dans une comparaison, l'absence de la partie
<em>révision_debian</em> est détectée plus tôt que sa présence (néanmoins 
la partie <var>révision_debian</var> est la partie la
moins significative du numéro de version).
</p>
	  </item>
</taglist>
      </p>
<p>
Le système de gestion des paquets compare les parties 
<var>version_amont</var> et <var>révision_debian</var> en utilisant le 
même algorithme.
      </p>

<p>
Les chaînes sont comparées de gauche à droite.
      </p>

<p>
Pour chaque chaîne, une partie initiale composée uniquement de
lettres est déterminée. Ces deux parties (l'une peut être vide) sont comparées
lexicalement. Si une différence est trouvée, elle est retournée. La
comparaison lexicale est une comparaison qui utilise des valeurs ASCII 
modifiées de manière à ce que toutes les lettres soient classées avant les 
chiffres et les caractères de ponctuation.
      </p>

<p>
Ensuite, pour ce qui reste de cette chaîne, une partie initiale composée
uniquement de chiffres est déterminée. Les valeurs numériques de ces deux
parties sont comparées, la différence est retournée comme résultat de la
comparaison. Dans ce but, une chaîne vide (qui peut seulement
apparaître à la fin de l'une ou des deux chaînes que l'on compare)
compte pour zéro.
      </p>

<p>
Ces deux phases sont répétées (comparaison et suppression des caractères et 
des chiffres se trouvant au début des chaînes) jusqu'à ce qu'une différence 
soit trouvée ou que les deux chaînes soient terminées.
      </p>

<p>
Le but de la partie <var>epoch</var> est de permettre des erreurs dans la
numérotation de version et de s'arranger avec les situations où la
numérotation de version change. Il <em>ne sert pas</em> à corriger les
numéros de version contenant des chaînes de caractères que le système de
gestion des paquets ne peut pas interpréter (tel que <tt>ALPHA</tt> ou 
<tt>pre-</tt>) ou une numérotation bâtarde (l'auteur de ce manuel a 
entendu parler d'un paquet dont les versions allaient ainsi&nbsp;: 
<tt>1.1.1.2</tt>, <tt>1.3</tt>, <tt>1</tt>, <tt>2.1</tt>, <tt>2.2</tt>, 
<tt>2</tt> et ainsi de suite).
      </p>
	</sect1>

        <sect1 id="f-Description">
          <heading><tt>Description</tt></heading>
<p>
Le champ <tt>Description</tt> dans le fichier de contrôle d'un paquet
source ou binaire comprend deux
parties, le résumé ou courte description et la description étendue. Le
format de ce champ est le suivant&nbsp;:
	</p>
       <p><example>
       Description: &lt;résumé sur une seule ligne&gt;
        &lt;description étendue sur plusieurs lignes&gt;
</example>
</p>

<p>
Les lignes de la description étendue peuvent suivre ces formats&nbsp;:
	  </p>

<p>
<list>
<item>
Les lignes commençant par une espace font partie d'un paragraphe. Les lignes
successives seront mis en forme pour être affichées et l'espace sera supprimée.
			      </item>
<item>
Les lignes commençant par deux espaces ou plus seront affichées 
<em>verbatim</em>. Si elles ne rentrent pas horizontalement, le programme
d'affichage les coupera sans faire attention aux mots coupés. S'il le peut,
le programme terminera les lignes sur la droite. Zéro, une ou deux espaces
peuvent être supprimées mais ce nombre sera le même pour toutes les lignes 
(ainsi l'indentation sera correcte).
	      </item>
<item>
les lignes contenant un seul espace suivi par un seul point seront affichées
comme des lignes blanches. C'est le seul moyen d'obtenir une ligne blanche 
<footnote>
Les lignes complètement vides ne seront pas affichées comme des lignes 
blanches. Elles induisent plutôt que vous commencez un nouvel enregistrement
dans le fichier <em>control</em> et l'analyseur s'arrêtera en constatant une
erreur.</footnote>.
	      </item>
<item>
Les lignes contenant une espace, un point et d'autres caractères serviront
à de prochains développements. Ne les utilisez pas.
	      </item>
	    </list>
	  </p>

<p>
N'utilisez pas le caractère de tabulation, son effet est imprévisible.
	  </p>

          <p>
Voyez <ref id="descriptions"> pour des informations supplémentaires.
          </p>

          <p>
Dans un fichier <file>.changes</file>, le champ <tt>Description</tt>
contient les résumés des descriptions des paquets déposés sur le serveur.
          </p>

          <p>
La partie du champ située avant le premier retour à la ligne est vide&nbsp;;
chaque ligne comprend donc le nom du paquet binaire et sa ligne de
résumé. Chaque ligne commence par une espace.
          </p>

        </sect1>
	
	<sect1 id="f-Distribution">
<heading><tt>Distribution</tt></heading>

	  <p>	    
Dans un fichier <file>.changes</file> ou affiché par l'analyse d'un changelog,
ce champ contient les noms (séparés par des espaces) des distributions dans 
lesquelles cette version du paquet sera installée. Les noms de 
distribution sont déterminés par les responsables de l'archive
	    <footnote><p>
Actuellement, les noms des distributions sont les suivants&nbsp;:
		<taglist compact="compact">
		  <tag><em>stable</em></tag>
		  <item>
		    <p> 
C'est l'édition d'une version à jour de Debian GNU/Linux.
Une fois que la distribution est <em>stable</em>, seule la
correction d'erreurs majeures ou d'erreurs concernant la sécurité est 
autorisée. Quand cette distribution est modifiée, son numéro d'édition est 
incrémenté (par exemple&nbsp;: 1.2r1 devient 1.2r2 puis 1.2r3 etc.).
		    </p>
		  </item>
<tag><em>unstable</em></tag>
                  <item>
                    <p>
Cette valeur de distribution fait référence au côté
<em>développement</em> de l'arbre Debian des distributions. Les nouveaux
paquets, de nouvelles sources pour les paquets et la correction d'erreur
vont dans le répertoire <em>unstable</em>. C'est prendre des risques que
d'utiliser cette distribution.
                    </p>
                  </item>
		  
		  <tag><em>testing</em></tag>
<item>
<p>
Cette valeur de distribution fait référence au côté <em>test</em> de l'arbre 
Debian des distributions. Les paquets qui la composent proviennent de la
distribution <em>unstable</em> où ils sont restés un court moment de manière
à s'assurer qu'ils n'ont pas de défauts graves. Les paquets de cette
distribution sont moins défectueux que ceux de la distribution 
<em>unstable</em> mais comportent des risques. On ne peut pas installer des
paquets dans <em>testing</em>.</p>
		  </item>

		  <tag><em>frozen</em></tag>
		  <item>
		    <p>
De temps en temps, la distribution <em>testing</em> entre dans un état 
dit de «&nbsp;gel du code&nbsp;» qui anticipe la version <em>stable</em>. 
Pendant cette période de test, seules les corrections d'erreurs existantes ou 
nouvellement découvertes sont autorisées. Le détail précis de cette étape est
déterminé par le responsable de l'édition («&nbsp;Release Manager&nbsp;»).
		    </p>
		  </item>
		  
		  <tag><em>experimental</em></tag>
	  <item>
	    <p>
Les paquets qui possèdent cette valeur de distribution sont considérés par
leur responsable comme représentant un grand risque. Souvent, ce sont des
paquets en phase bêta ou en cours de développement, provenant de sources
variées que les responsables veulent faire tester, mais ce ne sont pas des 
paquets qui peuvent être inclus dans d'autres répertoires de l'arbre Debian 
des distributions. À utiliser à ses risques et périls.
		    </p>
		  </item>
		</taglist>

	  </p>
<p>
On listera <em>toutes</em> les distributions dans lesquelles le paquet sera
installé. 
	      </p>
	    </footnote>.
	  </p>
	</sect1>

        <sect1 id="f-Date">
          <heading><tt>Date</tt></heading>
<p>
Ce champ donne la date de la construction de paquet ou de la dernière édition.
          </p>
          <p>
Sa valeur est tirée du fichier <file>debian/changelog</file> - voyez
            <ref id="dpkgchangelog">.
          </p>
        </sect1>

        <sect1 id="f-Format">
          <heading><tt>Format</tt></heading>
<p>
Ce champ indique une révision de format pour le fichier. Le format décrit ici 
est la version <strong>1.5</strong>. La syntaxe de la valeur du format est la 
même que la numérotation de la version des paquets, sauf que epoch et la 
révision Debian ne sont pas autorisés - voir <ref id="versions">.
          </p>
        </sect1>

        <sect1 id="f-Urgency">
          <heading><tt>Urgency</tt></heading>
<p>
Ce champ décrit l'importance de la mise à jour de cette version par rapport 
aux autres versions. Il contient un simple mot-clé qui prend
habituellement une de ces valeurs <tt>low</tt>, <tt>medium</tt> ou 
<tt>high</tt> (peu importe la casse) suivie par un commentaire optionnel 
(séparé par une espace) qui est généralement entre parenthèses. 
Par exemple&nbsp;:
<example>
Urgency: low (HIGH pour les utilisateurs de diversions)
</example>
	  </p>

          <p>
La valeur de ce champ est habituellement tirée du fichier 
<file>debian/changelog</file> - voyez <ref id="dpkgchangelog">.
          </p>
        </sect1>


        <sect1 id="f-Changes">
          <heading><tt>Changes</tt></heading>
<p>
Ce champ contient les données lisibles des changements, décrivant les 
différences entre la dernière version et celle courante.
	  </p>
<p>
Il ne doit rien y avoir dans ce champ avant le première nouvelle ligne&nbsp;;
toutes les lignes suivantes doivent être indentées d'au moins une
espace&nbsp;; les lignes vides doivent être représentées par une ligne
contenant seulement une espace et un point.
      </p>
          <p>
La valeur de ce champ est habituellement tirée du fichier
<file>debian/changelog</file>&nbsp;&ndash; voyez <ref id="dpkgchangelog">.
          </p>

<p>
Chaque information de changement de version doit être précédée par une
ligne de titre donnant au moins la version, la ou les distributions
et l'urgence, d'une façon lisible.
      </p>
<p>
Si les données de plusieurs versions sont retournées, l'entrée de la
plus récente version doit être retournée d'abord, et les entrées
doivent être séparées par une ligne vide (la ligne de titre peut aussi
être suivie par une ligne vide).
	  </p>
	</sect1>

        <sect1 id="f-Binary">
          <heading><tt>Binary</tt></heading>
<p>
Ce champ est une liste de paquets binaires.
      </p>
<p>
Quand il apparaît dans un fichier <tt>.dsc</tt>, il représente la liste
des paquets binaires qu'un paquet source peut produire.
Il ne produit pas nécessairement tous ces paquets binaires pour chaque
architecture. Le fichier de contrôle source ne contient pas les détails
sur les architectures qui sont les plus appropriées pour les paquets
binaires.</p>
<p>

Quand il apparaît dans un fichier <tt>.changes</tt>, il liste les noms des
paquets binaires actuellement installés sur le serveur.</p>
<p>

La syntaxe est une liste de paquets binaires séparée par des
virgules<footnote><p>Par convention, il y a une espace après chaque
virgule.</p></footnote>.
Actuellement, les paquets doivent être séparés en utilisant seulement
des espaces dans le fichier <tt>.changes</tt>.
	  </p>
	</sect1>

        <sect1 id="f-Installed-Size">
          <heading><tt>Installed-Size</tt></heading>
<p>
Ce champ apparaît dans les fichiers de contrôle des paquets binaires, et
dans les fichiers <tt>Packages</tt>. Il donne la capacité totale du disque
nécessaire pour installer le paquet.</p>
<p>

L'espace disque est représenté en Kilo-octets comme un nombre décimal
simple.</p>
	</sect1>

        <sect1 id="f-Files">
          <heading><tt>Files</tt></heading>
<p>
Ce champ contient la liste des fichiers avec des informations sur chacun
d'eux. L'information exacte et la syntaxe exacte varient avec le
contexte. Dans tous les cas, la partie du contenu du champ sur la même
ligne que le nom du champ est vide. Le reste du champ est une ligne par
fichier, chaque ligne est indentée par une espace et contient un nombre
de sous-champs séparés par des espaces.</p>
<p>

Dans le fichier <tt>.dsc</tt> (contrôle des sources Debian), chaque ligne
contient la somme de contrôle MD5, la taille et le nom du fichier tar et
(éventuellement) le fichier diff qui représente le reste du paquet
source<footnote><p>C'est la partie qui n'est pas <tt>.dsc</tt>.</p></footnote>.
Les formes exactes des noms de fichier sont décrites dans
<ref id="pkg-sourcearchives">.
</p>
<p>
Dans le fichier <tt>.changes</tt>, il contient une ligne par fichier
chargé. Chaque ligne contient la somme de contrôle, la taille, la
section et la priorité et le nom du fichier. La 
<qref id="f-Section">section</qref> et la 
<qref id="f-Priority">priorité</qref> sont les valeurs des champs 
correspondants dans le fichier principal de contrôle des sources. Si aucune 
section ou
priorité n'est spécifiée alors <tt>-</tt> doit être utilisé, bien que les
valeurs de section et de priorité doivent être spécifiées pour installer
correctement les nouveaux paquets.
</p>
    <p>
La valeur spéciale <tt>byhand</tt> pour la section dans un fichier
<tt>.changes</tt> indique que le fichier en question n'est pas un fichier
ordinaire de paquet et doit être installé  à la main par les responsables
de la distribution. Si la valeur de la section est <tt>byhand</tt> alors
la valeur de la priorité devrait être <tt>-</tt>.
      </p>
<p>
Si une nouvelle révision Debian d'un paquet est chargée et qu'aucune
archive originale source n'est distribuée, le fichier <tt>.dsc</tt> doit
toujours contenir l'entrée du champ <tt>Fields</tt> pour l'archive
originale source <em>package-upstream-version</em><tt>.orig.tar.gz</tt> mais
le fichier <tt>.changes</tt> devrait l'omettre. Dans ce cas, l'archive
originale source sur le site de distribution doit être exactement, octet
par octet, l'archive originale source qui a été utilisée pour créer le
fichier <tt>.dsc</tt> et le fichier diff qui a été installé sur le serveur.
	  </p>
	</sect1>

        <sect1 id="f-Closes">
          <heading><tt>Closes</tt></heading>

          <p>
Une liste de numéros de rapport de bogues séparés par des espaces qui sont
fermés par le téléchargement défini par le fichier <file>.changes </file>.
          </p>
        </sect1>
      </sect>

      <sect>
        <heading>Champs définis par l'utilisateur</heading>
<p>
Des champs utilisateurs supplémentaires peuvent être ajoutés au fichier
de contrôle du paquet source. Ces champs seront ignorés, ne seront pas
copiés dans les fichiers de contrôle des paquets sources ou binaires
(par exemple) ou dans les fichiers de contrôle de l'installation sur le
serveur.
	    </p>
<p>
Quand on souhaite ajouter des champs supplémentaires non reconnus par
ces fichiers de sortie, on utilisera le mécanisme décrit ci-dessous.
	    </p>
<p>
Les champs du fichier principal de contrôle de source
avec des noms commençant par X, suivis par une ou plusieurs lettres
<tt>BCS</tt> et un trait d'union -, seront copiés vers les fichiers de sortie.
Seule la partie du nom du champ qui se trouve après le trait d'union sera
utilisée dans le fichier de sortie.
Si la lettre <tt>B</tt> est utilisée, le champ apparaîtra dans les fichiers
de contrôle des paquets binaires, si c'est la lettre <tt>S</tt>, dans les 
fichiers de contrôle de paquet source, et si c'est la lettre <tt>C</tt>, dans 
les fichiers de contrôle de l'installation sur le serveur (<tt>.changes</tt>).
	    </p>
<p>
Par exemple, le fichier principal de contrôle de source
contient le champ suivant&nbsp;:

<example>
   XBS-Comment: I stand between the candle and the star.
</example>

alors les fichiers de contrôle des paquets sources et binaires contiendront
le champ&nbsp;:
<example>
Comment: I stand between the candle and the star.
             </example>
	    </p>
      </sect>
    </chapt>

<chapt id="maintainerscripts">
<heading>Les scripts du responsable de paquet
        et la procédure d'installation</heading>

<sect>
<heading>Introduction aux scripts du responsable de paquet</heading>

<p>
Il est possible de fournir des scripts qui seront exécutés
par le système de gestion des paquets lors d'une installation, d'une mise à 
jour ou d'une suppression du paquet.
	</p>

<p>
Ces scripts sont les fichiers <prgn>preinst</prgn>, <prgn>postinst</prgn>, 
<prgn>prerm</prgn> et <prgn>postrm</prgn> contenus dans le répertoire de 
contrôle du paquet. Ils doivent être des fichiers exécutables corrects&nbsp;; 
quand ce sont des scripts (ce qui est recommandé), ils doivent commencer par 
la convention habituelle&nbsp;: <tt>#!</tt>. Ils seront lisibles et exécutables 
par tout le monde mais ils ne doivent pas être modifiables par tout le monde.
	</p> 

<p>
Le système de gestion de paquets teste le code de sortie de ces scripts. Il 
est important que ce code soit différent de zéro quand il y a une erreur&nbsp;;
le système de gestion de paquets peut alors s'interrompre. Pour les
scripts shell, cela signifie que l'on doit <em>presque toujours</em>
utiliser <tt>set -e</tt> (et c'est généralement vrai pour tout script shell).
Bien sûr, il est aussi important que ce code ne soit pas différent de zéro 
quand tout s'est bien passé.
	</p>

<p>
De plus, les paquets interagissant avec les utilisateurs utilisant
<tt>debconf</tt> dans le script <prgn>postinst</prgn> doivent installer un
script <prgn>config</prgn> dans la zone de contrôle, voir <ref
id="maintscriptprompt"> pour plus de détails.
        </p>

<p>
Quand un paquet est mis à jour, une combinaison des scripts de l'ancien et
du nouveau paquet est appelée durant la procédure de mise à jour. Il faut 
faire attention quand les scripts se compliquent et il faut vérifier leurs 
arguments.
	</p>

<p>
D'une manière générale, le script <prgn>preinst</prgn> est appelé avant 
d'installer (une version particulière d') un paquet, et le script 
<prgn>postinst</prgn> après&nbsp;; le script <prgn>prerm</prgn> avant 
d'effacer (une version d') un paquet et <prgn>postrm</prgn> après.
	</p>

<p>
Normalement on ne doit pas préfixer le chemin des programmes appelés par les 
scripts. Avant le début de l'installation, le système de
gestion de paquet vérifie que les programmes <prgn>ldconfig</prgn>, 
<prgn>start-stop-daemon</prgn>, <prgn>install-info</prgn> et 
<prgn>update-rc.d</prgn> peuvent être trouvés via la
variable d'environnement <tt>PATH</tt>. Ces programmes, et n'importe quel
autre programme qu'on s'attend à trouver dans le <tt>PATH</tt>, seront
donc appelés sans nom de chemin absolu.
Les scripts du responsable ne doivent pas non plus réinitialiser la variable
<tt>PATH</tt>, bien qu'ils puissent choisir de la modifier en ajoutant
au début ou à la fin un répertoire spécifique à un paquet.
Ces considérations s'appliquent vraiment à tous les scripts shell.
	</p>
      </sect>

<sect id="idempotency">
        <heading>L'idempotence des scripts du responsable</heading>
<p>
Il est nécessaire pour les procédures de gestion des erreurs que les
scripts soient idempotents. Cela signifie qu'un script, appelé à nouveau
après une exécution réussie, n'explose pas et ne fait pas de dégâts ; il
s'assure simplement que chaque chose est à sa place. Si le premier appel 
échoue, ou s'arrête au milieu du chemin pour une raison ou une autre, le 
second appel fera, s'il y en a, les choses qui n'ont pas été faites la 
première fois et se terminera normalement si tout est correct <footnote><p>
Qu'une erreur arrive -- l'utilisateur interrompt <prgn>dpkg</prgn> ou bien 
quelque chose d'imprévu se passe -- il ne faut pas laisser un paquet 
défectueux à l'utilisateur quand <prgn>dpkg</prgn> essaye de refaire l'action.
	    </p>
	  </footnote>.
	</p>
      </sect>
<sect id="controllingterminal">
    <heading>Les terminaux de contrôle et les scripts du responsable</heading>

<p>
Les scripts du responsable sont assurés de s'exécuter avec un terminal de 
contrôle et de pouvoir interagir avec l'utilisateur. Comme
ces scripts peuvent rediriger leur sortie standard dans un tube à des fins 
d'enregistrement, les scripts Perl utiliseront un mode de sortie sans tampon
mémoire en déclarant <tt>$|=1</tt> de manière à ce que la sortie soit affichée
immédiatement plutôt que d'être mise dans un tampon mémoire.
	</p>
      </sect>
      <sect id="exitstatus">
	<heading>Code de sortie</heading>
<p>
Chaque script retournera un code de sortie égal à zéro en cas de succès et
un code différent de zéro en cas d'échec.

Chaque script doit retourner un code de sortie égal à zéro en cas de succès et
un code différent de zéro en cas d'échec car le système de gestion des paquets
récupère le code de sortie de ces scripts et détermine l'action suivante en
fonction de cette valeur.
	</p>
      </sect>

<sect id="mscriptsinstact">
<heading>Résumé des façons d'appeler les scripts du 
responsable</heading>
<p>

<list compact="compact">
<item> 
<p><var>preinst-du-nouveau-paquet</var> <tt>install</tt></p>
	    </item>
<item> 
<p><var>preinst-du-nouveau-paquet</var> <tt>install</tt> <var>vieille-version</var>
	      </p>
	    </item>
<item> 
<p><var>preinst-du-nouveau-paquet</var> <tt>upgrade</tt> <var>vieille-version</var></p>
	    </item>
<item><p><var>preinst-de-l'ancien-paquet</var> <tt>abort-upgrade</tt> 
<var>nouvelle-version</var></p>
	    </item>
</list>
    </p>
<p>
<list compact="compact">
<item> 
<p><var>postinst</var> <tt>configure</tt> <var>version-la-plus-récemment-configurée</var></p>
	    </item>
<item><p><var>postinst-de-l'ancien-paquet</var> <tt>abort-upgrade</tt> 
<var>nouvelle-version</var></p>
	    </item>
<item><p> <var>postinst-du-paquet-conflictuel</var> <tt>abort-remove</tt> <tt>in-favour</tt>
<var>paquet</var> <var>nouvelle-version</var></p>
	    </item>
 	    <item>
<p><var>postinst</var> <tt>abort-remove</tt></p>
	    </item>
<item><p> <var>postinst-du-paquet-déconfiguré</var> <tt>abort-deconfigure</tt> <tt>in-favour</tt>
<var>paquet-dont-installation-a-échoué</var> <var>version</var> <tt>removing</tt> 
<var>paquet-conflictuel</var> <var>version</var></p>
	    </item>
	  </list>
    </p>
<p>
<list compact="compact">
<item>
<p><var>prerm</var> <tt>remove</tt></p>
	    </item>
<item>
<p> <var>prerm-de-l'ancien-paquet</var> <tt>upgrade</tt> <var>nouvelle-version</var></p>
	    </item>
<item>
<p><var>prerm-du-nouveau-paquet</var> <tt>failed-upgrade</tt> <var>vieille-version</var>
</p>
	    </item>
<item> 
<p><var>prerm-du-paquet-conflictuel</var> <tt>remove</tt> <tt>in-favour</tt> 
<var>paquet</var> <var>nouvelle-version</var></p>
	    </item>
<item>
<p><var>prerm-du-paquet-déconfiguré</var> <tt>deconfigure</tt> <tt>in-favour</tt>
<var>paquet-installé</var> <var>version</var> <tt>removing</tt> 
<var>paquet-conflictuel</var> <var>version</var></p>
	    </item>
</list>
    </p>
<p>
<list compact="compact">
<item>
<p><var>postrm</var> <tt>remove</tt></p>
	    </item>
<item>
<p><var>postrm</var> <tt>purge</tt></p>
	    </item>

<item>
<p><var>postrm-de-l'ancien-paquet</var> <tt>upgrade</tt> <var>nouvelle-version</var></p>
	    </item>
<item>
<p><var>postrm-du-nouveau-paquet</var> <tt>failed-upgrade</tt> <var>vieille-version</var>
	      </p>
	    </item>
<item>
<p> <var>postrm-du-nouveau-paquet</var> <tt>abort-install</tt></p>
	    </item>
<item>
<p><var>postrm-du-nouveau-paquet</var> <tt>abort-install</tt> <var>vieille-version</var>
	      </p>
	    </item>
<item>
<p><var>postrm-du-nouveau-paquet</var> <tt>abort-upgrade</tt> <var>vieille-version</var>
	      </p>
	    </item>
<item>
<p><var>postrm-du-paquet-disparu</var> <tt>disappear</tt> <var>remplaçant</var> 
<var>version-du-remplaçant</var></p>
	    </item>
</list>
	</p>
  </sect>

<sect id="unpackphase">
<heading>Précisions sur la phase de dépaquetage lors 
d'une installation ou d'une mise à jour</heading>

<p>
La procédure lors d'une installation, d'une mise à jour, d'un remplacement ou
d'une disparition (c'est-à-dire quand on exécute <tt>dpkg --unpack</tt>, 
ou bien l'étape <em>unpack</em> de <tt>dpkg --install</tt>) est la suivante. 
Dans chaque cas, si une erreur majeure se produit (à moins d'être listée 
ci-dessous), les actions sont généralement «&nbsp;rembobinées&nbsp;» -- ce 
qui signifie que les scripts du responsable sont 
exécutés dans l'ordre inverse avec des arguments différents. Ce sont les 
appels «&nbsp;correction d'erreur&nbsp;» listés ci-dessous.

<enumlist>
<item>
<p>
     <enumlist>
     <item>
<p>
Si une version du paquet est déjà installée, appel de
	   <example compact="compact">
<var>prerm-de-l'ancien-paquet</var> upgrade <var>nouvelle-version</var>
	   </example>
		</p>
	      </item>
     <item><p>Quand le script se termine avec un code de sortie
différent de zéro, <prgn>dpkg</prgn> essaye&nbsp;:
	   <example compact="compact">
<var>prerm-du-nouveau-paquet</var> failed-upgrade <var>vieille-version</var>
	   </example>
	   Si cela réussit, la mise à jour continue. Sinon, correction
	   d'erreur&nbsp;:
	   <example compact="compact">
<var>postinst-de l'ancien-paquet</var> abort-upgrade <var>nouvelle-version</var>
	   </example>
	   Si cela réussit, alors l'ancienne version est dans l'état
	   «&nbsp;Installed&nbsp;». Sinon, l'ancienne version est dans l'état
	   «&nbsp;Failed-Config&nbsp;».
</p>
		  </item>
     </enumlist>
</p>
	    </item>

<item>
<p>
Si un paquet conflictuel est enlevé en même temps&nbsp;:
     <enumlist>
   
     <item>
<p>
Quand un paquet dépend de ce paquet conflictuel et si l'option
 <tt>--auto-deconfigure</tt> est spécifiée, appel pour chaque paquet&nbsp;:
	<example compact="compact">
<var>prerm-du-paquet-déconfiguré</var> deconfigure in-favour
<var>paquet-à-installer</var> <var>version</var>
removing <var>paquet-conflictuel</var> <var>version</var>
        </example>

	Correction d'erreurs&nbsp;:
	<example compact="compact">
<var>postinst-du-paquet-déconfiguré</var> abort-deconfigure in-favour
<var>paquet-dont-l'installation-a-échoué</var> <var>version</var>
removing <var>paquet-conflictuel</var> <var>version</var>
        </example>
	Les paquets déconfigurés sont indiqués comme nécessitant une
configuration, afin que, si l'option <tt>--install</tt> est utilisée, ils 
soient, si possible, de nouveau configurés.
		    </p>

		  </item>
<item>
<p>
Pour préparer l'effacement du paquet conflictuel, appel de&nbsp;:
	<example compact="compact">
<var>prerm-du-paquet-conflictuel</var> remove in-favour
 <var>paquet</var> <var>nouvelle-version</var>
        </example>
	Correction d'erreurs&nbsp;:
	<example compact="compact">
<var>postinst-du-paquet-conflictuel</var> abort-remove in-favour
 <var>paquet</var> <var>nouvelle-version</var>
        </example>
		    </p>
		  </item>
		</enumlist>
	      </p>
	    </item>

<item>
     <p>
<enumlist>
     <item>
<p>
Si le paquet est mis à jour, appel de&nbsp;:
	<example compact="compact">
<var>preinst-du-nouveau-paquet</var> upgrade <var>vieille-version</var>
        </example>
	Si cela échoue, on appelle&nbsp;:
                      <example>
<var>postrm-du-nouveau-paquet</var> abort-upgrade <var>vieille-version</var>
                      </example>
                      <enumlist>
                        <item>
                          <p>
                            Si cela fonctionne, alors
                            <example>
<var>postinst-de-l'ancien-paquet</var> abort-upgrade <var>nouvelle-version</var>
                            </example>
                            est appelé. Si cela fonctionne, alors l'ancienne
                            version est dans un état «&nbsp;Installed&nbsp;»,
                            sinon elle est laissée dans un état
                            «&nbsp;Unpacked&nbsp;».
                          </p>
                        </item>
                        <item>
                          <p>
                            Si cela échoue, alors l'ancienne version est laissée
                            dans un état «&nbsp;Half-Installed&nbsp;».
                          </p>
                        </item>
                      </enumlist>

		  </item>
<item><p>
Autrement, si le paquet a des fichiers de configuration d'une
          version précédemment installée (c'est-à-dire, s'il ne reste
	  plus du paquet que les fichiers de configuration)&nbsp;:
	<example compact="compact">
<var>preinst-du-nouveau-paquet</var> install <var>vieille-version</var>
	</example>
		 Correction d'erreur :
                      <example>
<var>postrm-du-nouveau-paquet</var> abort-install <var>vieille-version</var>
                      </example>   
                      Si cela échoue, le paquet est laissé dans un état
		      «&nbsp;Half-Installed&nbsp;» qui impose une
		      réinstallation. Si cela réussit, le paquet est laissé dans
		      un état «&nbsp;Config Files&nbsp;».
		    </p>
     </item>
<item>
<p>
Autrement (c'est-à-dire, le paquet a été complètement
effacé)&nbsp;:
	<example compact="compact">
<var>preinst-du-nouveau-paquet</var> install
	</example>

	Correction d'erreurs
	<example compact="compact">
<var>postrm-du-nouveau-paquet</var> abort-install
	</example>
                      Si la correction d'erreur échoue, le paquet est dans un
		      état «&nbsp;Half Installed&nbsp;» et nécessite une
		      réinstallation. Si elle réussit, le paquet n'est plus installé.
		    </p>
		  </item>
		</enumlist>
	      </p>
	    </item>
<item><p>
Les fichiers du nouveau paquet sont dépaquetés, remplaçant ceux qui
peuvent déjà être sur le système, par exemple, les fichiers appartenant à la
vieille version du même paquet ou ceux d'un autre paquet. Les sauvegardes des
vieux fichiers sont laissées, et si quelque chose se passe mal, le système de 
gestion des paquets, dans sa partie «&nbsp;correction d'erreurs&nbsp;» 
essayera de les remettre en place.
	      </p>
<p>
C'est une erreur pour un paquet de contenir des fichiers qui sont sur le
système dans un autre paquet, à moins que <tt>Replaces</tt> ne soit utilisé
(voir <ref id="replaces">). </p>
<!-- The following paragraph is not currently the case: 
Pour l'instant l'option <tt>force-overwrite</tt> -->
<!--est disponible, la dégradant en un avertissement, mais cela ne sera 
peut-être pas toujours le cas.-->
<p>
C'est une erreur plus grave pour un paquet de contenir un simple
fichier ou autre chose qu'un répertoire quand un autre paquet veut un
répertoire (à moins que <tt>Replaces</tt> ne soit utilisé).
Cette erreur peut être évitée si c'est l'effet recherché, en utilisant
<tt>--force-overwrite-dir</tt>, mais ce n'est pas à conseiller.
	      </p>
<p>
Les paquets qui remplacent mutuellement leurs fichiers ont une démarche qui,
bien que déterministe, est difficile à comprendre pour
un administrateur système. Cela peut aisément conduire à des programmes 
annoncés comme «&nbsp;absent&nbsp;» quand, par exemple, un paquet remplaçant 
tel fichier d'un autre paquet est installé puis effacé <footnote><p>Une 
partie du problème vient certainement d'une erreur de <prgn>dpkg</prgn>.
</p></footnote>.
	      </p>
<p>
Un répertoire ne sera jamais remplacé par un lien symbolique vers un
répertoire et vice versa&nbsp;; à la place, l'état existant (lien symbolique
ou non) est conservé et <prgn>dpkg</prgn> suivra les liens s'il y en a.
	      </p>
	    </item>

<item>
<p>   <enumlist>
   <item><p>
Si le paquet est mis à jour, appel de&nbsp;:
	<example compact="compact">
<var>postrm-de l'ancien-paquet</var> upgrade <var>nouvelle-version</var>
	</example></p>
		  </item>

   <item>
<p>Si cela échoue, <prgn>dpkg</prgn> essaye&nbsp;:
	<example compact="compact">
<var>postrm-du-nouveau-paquet</var> failed-upgrade <var>vieille-version</var>
	</example>
        Si cela réussit, l'installation continue. Sinon, correction
	d'erreur&nbsp;:
	<example compact="compact">
<var>preinst-de-l'ancien-paquet</var> abort-upgrade <var>nouvelle-version</var>
	</example>
        Si cela échoue, l'ancienne version est laissée dans un état «&nbsp;Half
	Installed&nbsp;». Si cela réussit, dpkg appelle maintenant&nbsp;:
	<example compact="compact">
<var>postrm-du-nouveau-paquet</var> abort-upgrade <var>vieille-version</var>
        </example>
        Si cela échoue, l'ancienne version est laissée dans un état «&nbsp;Half
	Installed&nbsp;». Si cela échoue, dpkg appelle maintenant&nbsp;:
        <example compact="compact">
<var>postinst-de-l'ancien-paquet</var> abort-upgrade <var>nouvelle-version</var>
        </example>
        Si cela échoue, l'ancienne version est dans un état
	«&nbsp;Unpacked&nbsp;».
		    </p>
		  </item>
		</enumlist>
	  </p>
	</item>
<item><p>
	C'est le point de non-retour. Quand <prgn>dpkg</prgn> atteint ce 
point, il ne revient pas en arrière si une erreur se produit. Le paquet
reste dans un très mauvais état et demande une réinstallation réussie 
pour remettre tout en place&nbsp;; cela arrive quand <prgn>dpkg</prgn> 
commence à faire des choses irréversibles.
	      </p>
	    </item>
	
<item><p>
Tous les fichiers de la version précédente du paquet qui ne sont pas dans la
nouvelle sont effacés.
	      </p>
	    </item>
<item><p>
La nouvelle liste de fichiers remplace la précédente.
	      </p>
	    </item>

<item><p>
Les nouveaux scripts du responsable remplacent les anciens.
	      </p>
	    </item>

<item><p>
Les paquets dont tous les fichiers ont été remplacés pendant
l'installation, et qui ne sont pas nécessaires pour les dépendances,
sont considérés comme effacés. Pour ces paquets :
	<enumlist>
	<item>
<p>
<prgn>dpkg</prgn> appelle&nbsp;:
	      <example compact="compact">
<var>postrm-du-paquet-effacé</var> disappear 
<var>remplaçant</var> <var>version-du-remplaçant</var>
	      </example>
		    </p>
		  </item>

	<item>
<p>Les scripts du responsable de paquet sont effacés.
		    </p>
		  </item>

	<item><p>
Le paquet est inscrit dans la base de données «&nbsp;status&nbsp;»
comme étant dans un état correct, à savoir non installé (ses 
<em>conffiles</em> sont ignorés et non pas supprimés par <prgn>dpkg</prgn>).
Il faut remarquer que <prgn>dpkg</prgn> n'appelle pas le script prerm du paquet
effacé, car il ne sait pas à l'avance que le paquet va disparaître.
		    </p>
		  </item>
	</enumlist>
	      </p>
	    </item>
<item>
<p>
Les fichiers du paquet à installer qui sont aussi répertoriés par d'autres 
paquets sont enlevés des listes de ces paquets, ce qui
lobotomisera la liste de fichiers du paquet «&nbsp;conflictuel&nbsp;», s'il y 
en a un.
	      </p>
	    </item>

<item>
<p>
Les fichiers de sauvegarde faits pendant la phase précédente d'installation
sont effacés.
	      </p>
	    </item>

<item><p>
Le statut du nouveau paquet est correct et enregistré comme
«&nbsp;dépaqueté&nbsp;».</p> 
<p>
C'est un autre point de non-retour - si l'effacement d'un
paquet conflictuel échoue, on ne «&nbsp;rembobine&nbsp;» pas le reste de
l'installation ; le paquet conflictuel est laissé dans un état 
«&nbsp;enlevé à moitié&nbsp;».
	      </p>
	    </item>

<item><p>
Au cas où existe un paquet conflictuel, on procède aux actions
d'effacement (décrites ci-dessus), en commençant par l'effacement des
fichiers du paquet conflictuel (les fichiers qui sont aussi dans le
paquet installé ont déjà été effacés de la liste des fichiers du paquet
conflictuel et ne sont pas enlevés maintenant).
	      </p>
	    </item>
          </enumlist>
	</p>
      </sect>

<sect id="configdetails">
<heading>Précisions sur la configuration</heading>

<p>
Quand on configure un paquet (avec <tt>dpkg --install</tt>, ou avec 
<tt>--configure</tt>), on met à jour d'abord les <tt>conffiles</tt> et
ensuite on appelle :
<example compact="compact">
<var>postinst</var> configure <var>version-la-plus-récemment-configurée</var>
</example>
	</p>
<p>
On n'essaye pas de «&nbsp;rembobiner&nbsp;» après une erreur pendant la
configuration. Si la configuration échoue, le paquet est dans un état
«&nbsp;Failed Config&nbsp;» et un message d'erreur est généré.
	</p>
<p>
S'il n'existe pas de «&nbsp;version-la-plus-récemment-configurée&nbsp;», 
<prgn>dpkg</prgn> passe un argument nul&nbsp;<footnote>
            <p>
Note historique : les versions vraiment anciennes (pre-1997) de 
<prgn>dpkg</prgn> passaient dans ce cas <tt>&lt;unknown&gt;</tt> (avec les 
signes supérieur et inférieur). Et les plus vieilles versions ne passaient 
pas de second argument du tout, quelles que soient les circonstances.
Notez qu'une mise à jour utilisant de telles versions de dpkg ne fonctionnera
vraisemblablement pas, pour d'autres raisons, et même si votre script
postinst gère ce cas.
            </p>
          </footnote>.
	</p>
      </sect>

<sect id="removedetails">
<heading>Précisions sur la phase de suppression sans 
ou avec suppression des fichiers de configuration</heading>

<p>
<enumlist>

<item>
<p>
<example compact="compact">
<var>prerm</var> remove
		</example>
              </p>
              <p>
                Si le script prerm échoue pendant le remplacement à cause d'un conflit
                <example>
<var>postinst-du-paquet-en-conflit</var> abort-remove \
  in-favour <var>paquet</var> <var>nouvelle-version</var>
                </example>
                Ou sinon on appelle&nbsp;:
                <example>
<var>postinst</var> abort-remove
                </example>
              </p>
              <p>
                Si cela échoue, le paquet est dans un état «&nbsp;Failed-Config&nbsp;»
                ou sinon il reste «&nbsp;Installed&nbsp;».
              </p>
	    </item>
<item><p> 
Les fichiers du paquet sont effacés (sauf les <tt>conffiles</tt>).
	      </p>
	    </item>

<item>
<p>
<example compact="compact">
<var>postrm</var> remove
		</example>
              <p>
                Si cela échoue, il n'y a pas de correction d'erreur et le paquet
                est dans un état «&nbsp;Half-Installed&nbsp;».
              </p>
	    </item>

<item> 
<p>Tous les scripts du responsable sont effacés sauf <prgn>postrm</prgn>.
	      </p>
<p>
Si on n'efface pas le paquet, la procédure s'arrête là. Il faut remarquer que
les paquets qui n'ont pas de <prgn>postrm</prgn> ni de <tt>conffiles</tt> sont 
automatiquement purgés pendant l'effacement, puisqu'il n'y pas de différence, 
sauf pour le fichier status de <prgn>dpkg</prgn>.
	      </p>
	    </item>


<item><p>
Les <tt>conffiles</tt> et les fichiers de sauvegarde (fichiers <tt>~</tt>,
fichiers <tt>#*#</tt>, fichiers <tt>&#37;</tt>, <tt>.dpkg-{old, new, tmp}</tt>, 
etc.) sont effacés.
	      </p>
	    </item>

<item><p>
<example compact="compact">
<var>postrm</var> purge
		</example>
              </p>
              <p>
                Si cela échoue, le paquet reste dans un état
                «&nbsp;Config-Files&nbsp;».
              </p>
	    </item>

<item>
<p>La liste des fichiers du paquet est effacée.
	      </p>
	    </item>
</enumlist>
</p>
      </sect>
    </chapt>

<chapt id="relationships">
<heading>Comment déclarer des relations entre les paquets ?</heading>

<sect id="depsyntax">
<heading>La syntaxe des champs de relation</heading>

<p>
Ces champs ont tous la même syntaxe. Ce sont des listes de
noms de paquets séparés par des virgules.
	</p>

<p>
Dans les champs <tt>Depends</tt>, <tt>Recommends</tt>, <tt>Suggests</tt>, 
<tt>Pre-Depends</tt>, <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt> 
(les champs qui déclarent les dépendances d'un paquet envers d'autres 
paquets), ces noms peuvent aussi être des listes de noms de paquets 
alternatifs, séparés par des symboles barre verticale «&nbsp;|&nbsp;» 
(symbole du tube de communication). Si c'est le cas, quand l'un des paquets
alternatifs est installé, on considère que cette partie de la dépendance
est satisfaite.
	</p>

<p>
Tous les champs sauf le champ <tt>Provides</tt> peuvent restreindre leur
application à des versions particulières de chaque paquet nommé. Ces versions
sont indiquées entre parenthèses après chaque nom de paquet ; les
parenthèses contiendront une des relations de la liste ci-dessous,
suivie par un numéro de version, dans le format décrit dans
<ref id="f-Version">.
	</p>

<p>
Les relations autorisées sont : <tt>&lt;&lt;</tt>, <tt>&lt;=</tt>,
<tt>=</tt>, <tt>&gt;=</tt> et <tt>&gt;&gt;</tt> pour
strictement avant, avant ou égal, égal, après ou égal, strictement
après, respectivement. Les formes déconseillées <tt>&lt;</tt> et 
<tt>&gt;</tt> ont été utilisées pour signifier avant/après ou égal, plutôt 
que strictement avant/après, ainsi elles ne doivent pas apparaître dans les 
nouveaux paquets (bien que <prgn>dpkg</prgn> les accepte encore).
	</p>

<p>
Les espaces peuvent apparaître n'importe où dans la spécification de
version sujette aux règles énoncées dans <ref id="controlsyntax">, et doivent 
apparaître là où c'est nécessaire pour supprimer toute ambiguïté ; autrement 
elles ne sont pas significatives. Pour la cohérence et dans le cas de futures 
modifications de <prgn>dpkg</prgn>, il est recommandé de mettre une seule 
espace après une relation de version et avant un numéro de version ; il est 
aussi convenu de mettre une espace après chaque virgule, de chaque côté d'une 
barre verticale, et avant chaque parenthèse ouvrante.
	</p>

<p>
Par exemple, une liste de dépendances peut apparaître ainsi :
<example compact="compact">
Package: mutt
Version: 1.3.17-1
Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
</example>
	</p>

<p>
On peut limiter à un ensemble d'architectures tous les champs qui précisent 
des relations pour la compilation 
(<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts</tt>
et <tt>Build-Conflicts-Indep</tt>). On se sert de crochets après chaque nom
de paquet et l'indication facultative de la version. Les crochets enferment
une liste d'architectures acceptées par Debian, séparées par une espace. Un
point d'exclamation peut être ajouté à chaque nom. On ne peut pas ajouter un
point d'exclamation à certains noms et pas à d'autres. Quand l'architecture de
la machine hôte n'est pas présente dans la liste et qu'il n'y a pas de
point d'exclamation, ou bien quand elle est dans la liste et qu'elle est 
préfixée par un point d'exclamation, le paquet et l'indication de la version 
associée sont complètement ignorés pour ce qui concerne la définition du 
système de relation.
	</p>
<p>
Par exemple&nbsp;:
<example compact="compact">
Source: glibc
Build-Depends-Indep: texinfo
Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
  hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
          </example>
        </p>
<p>
Il faut remarquer que les champs concernant les relations entre paquets
binaires tel que <tt>Depends</tt> apparaissent dans l'une des sections du
fichier de contrôle du paquet binaire, alors que les champs concernant
les relations pour la construction tel que <tt>Build-Depends</tt> apparaissent
dans la première section du fichier de contrôle du paquet source.
	</p>
      </sect>

<sect id="binarydeps">
        <heading>Les dépendances pour les paquets binaires - <tt>Depends</tt>,
          <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
 <tt>Pre-Depends</tt>
        </heading>
<p>
Les paquets peuvent déclarer dans leur fichier de contrôle qu'ils ont
certaines relations avec d'autres paquets - par exemple, qu'ils ne
peuvent pas être installés en même temps que tel paquet, ou qu'ils dépendent 
de la présence de tel autre.
	</p>
<p>
On se sert pour cela des champs du fichier <em>control</em> suivants&nbsp;:
<tt>Depends</tt>, <tt>Pre-Depends</tt>, <tt>Recommends</tt>, 
<tt>Suggests</tt>, <tt>Enhances</tt> et <tt>Conflicts</tt>.
      </p>

<p>
Ces six champs sont utilisés pour déclarer une relation de dépendance d'un
paquet envers un autre paquet. Ils apparaissent dans le fichier 
<em>control</em> du paquet dépendant (binaire), sauf le champ 
<tt>Enhances</tt> qui apparaît dans le fichier de contrôle du paquet 
recommandé.
	</p>

<p>
Un champ <tt>Depends</tt> prend effet <em>seulement</em> lors de la 
configuration du paquet. Il n'empêche pas qu'un paquet soit sur le système 
dans un état «&nbsp;non configuré&nbsp;» et ses dépendances non 
satisfaites&nbsp;; 
il est aussi possible de remplacer un paquet correctement installé et dont 
les dépendances sont satisfaites par une version différente dont les 
dépendances ne sont pas et ne peuvent pas être satisfaites&nbsp;; quand c'est 
le cas, le paquet dépendant est laissé «&nbsp;non configuré&nbsp;» (étant 
donné 
que les tentatives pour le configurer donnent des erreurs) et il ne 
fonctionne pas correctement. On peut utiliser si nécessaire un champ
<tt>Pre-Depends</tt> qui a un effet limité même si le paquet est dans la 
phase de dépaquetage, comme c'est expliqué plus bas. (Les trois autres
champs, <tt>Recommends</tt>, <tt>Suggests</tt> et <tt>Enhances</tt>, ne
sont utilisés que par les différentes interfaces de <prgn>dpkg</prgn>,
telle que <prgn>dselect</prgn>.) 
	</p>

<p>
Pour cette raison, lors d'une installation, les paquets sont généralement
tous installés d'abord et tous configurés ensuite&nbsp;; cela permet que les
dernières versions des paquets ayant des dépendances sur les dernières
versions d'autres paquets voient leurs dépendances satisfaites.
	</p>

<p>
Dans le cas de dépendances circulaires, comme l'ordre d'installation ou de
suppression pour honorer l'ordre des dépendances ne peut être établi, les
boucles de dépendances sont cassées à un certain point (basé sur les règles
ci-dessous) et certains paquets peuvent ne pas pouvoir être certain que leurs
dépendances soient présentes lors de l'installation ou de la suppression selon
de quel côté de la cassure de la boucle de dépendance circulaire ils sont
placés. Si l'un des paquets dans la boucle n'a pas de script postinst, alors le
cycle peut être cassé sur ce paquet pour garantir que tous les scripts postinst
sont exécutés avec leurs dépendances correctement configurés si cela est
possible. Sinon, le point de cassure est arbitraire.
        </p>


<p>
Ainsi le champ <tt>Depends</tt> autorise les responsables de paquet à imposer 
un ordre sur la manière de configurer les paquets.
	</p>


<p>
Voici la signification des cinq champs de dépendance :
<taglist>
<tag><tt>Depends</tt></tag>
<item>
<p>
Ce champ déclare une dépendance absolue. Il n'est pas possible de configurer
un paquet tant que tous les paquets listés dans ce champ n'ont pas été
correctement configurés.
	    </p>
<p>
Le champ <tt>Depends</tt> sera utilisé quand le paquet dépendant a besoin,
pour fonctionner d'une manière intéressante, de tel paquet.
	    </p>
<p>
Le champ <tt>Depends</tt> sera aussi utilisé quand les scripts
<prgn>postinst</prgn>, <prgn>prerm</prgn> ou <prgn>postrm</prgn> demandent
que tel paquet soit présent pour qu'ils puissent fonctionner. Cependant,
il faut noter que le script <prgn>postrm</prgn> ne peut pas compter sur
la présence de paquets «&nbsp;non-essential&nbsp;» pendant la phase de <tt>purge</tt>.
	  </p>
</item>
<tag><tt>Recommends</tt></tag>
<item><p>
Ce champ déclare une dépendance forte, mais pas absolue.
Le champ <tt>Recommends</tt> listera les paquets qu'on trouve habituellement 
avec ce paquet dans toute installation standard.
	    </p>
	  </item>

<tag><tt>Suggests</tt></tag>
<item>
<p>
On se sert de ce champ pour déclarer qu'un paquet serait plus utile avec
un ou plusieurs autres paquets. On indique au système de gestion de
paquet et à l'utilisateur que les paquets listés sont liés au paquet et
qu'ils peuvent peut-être augmenter son utilité, mais qu'une installation 
sans ces paquets est parfaitement concevable.
	    </p>
	  </item>

<tag><tt>Enhances</tt></tag>
<item>
<p>
Ce champ ressemble au champ <tt>Suggests</tt> mais il marche en sens inverse. 
On s'en sert pour déclarer qu'un paquet améliore l'efficacité de tel
autre paquet.
	      </p>
	    </item>
<tag><tt>Pre-Depends</tt></tag>
<item><p>
Ce champ ressemble au champ <tt>Depends</tt>, sauf qu'il force aussi
<prgn>dpkg</prgn> à terminer l'installation des paquets qu'il liste avant 
même de démarrer l'installation du paquet qui déclare ces pré-dépendances.
	    </p>

<p>
Quand un paquet déclarant une relation de pré-dépendance est sur le point 
d'être <em>dépaqueté</em>, cette relation peut être satisfaite si le paquet
exigé par la pré-dépendance est, soit pleinement configuré, <em>soit même</em>
s'il est seulement dépaqueté ou « à demi configuré », pourvu qu'il ait été 
déjà correctement configuré au moins une fois (et pas effacé ou partiellement 
effacé depuis). Dans ce cas, les deux versions,
celle précédemment configurée et celle actuellement dépaquetée ou dans un état
«&nbsp;à moitié configuré&nbsp;», doivent satisfaire à toute clause de version
contenue dans le champ <tt>Pre-Depends</tt>.
</p>

<p>
Quand le paquet déclarant une relation de <tt>Pre-Dépendance</tt> est 
configuré, cette relation sera considérée comme une relation <tt>Depends</tt>
normale&nbsp;; c'est-à-dire, elle sera considérée comme satisfaite seulement 
si le paquet dépendant a bien été configuré.
	    </p>

<p>
Le champ <tt>Pre-Depends</tt> sera utilisé parcimonieusement et de préférence
seulement pour les paquets dont une mise à jour ou une installation
prématurée entraverait la capacité du système à continuer les mises à jour
en cours.
	    </p>
<p>
Des relations <tt>Pre-Depends</tt> sont aussi exigées quand un script
<prgn>preinst</prgn> dépend d'un paquet cité. Il vaut mieux
éviter cette situation.
	  </p>
</item>
	</taglist>
	</p>

<p>
Pour choisir un niveau de dépendance, on mesurera l'importance du paquet
demandé pour les fonctionnalités du paquet qui déclare la dépendance. Certains
paquets sont composés d'éléments plus ou moins importants. Un tel paquet
listera dans le champ <tt>Depends</tt> le ou les paquets qui sont nécessaires 
aux éléments les plus importants. Les autres éléments peuvent
être mentionnés comme des Suggestions ou des Recommandations, selon
l'importance relative de ces éléments.
	</p>
  </sect>

<sect id="conflicts">
<heading>Mettre en conflit des paquets binaires --
          le champ <tt>Conflicts</tt>
        </heading>
<p>
Quand un paquet déclare un conflit avec un autre, en utilisant le champ
<tt>Conflicts</tt>, <prgn>dpkg</prgn> refuse
de les installer en même temps sur le système.
	</p>
<p>
Si l'on veut installer l'un de ces paquets, l'autre doit d'abord être supprimé 
&mdash; si le paquet en cours d'installation est marqué comme remplaçant
(voir <ref id="replaces">) le paquet sur le système, ou si celui-ci est 
marqué comme «&nbsp;désélectionné&nbsp;», ou bien si les deux paquets sont 
marqués <tt>Essential</tt>, alors <prgn>dpkg</prgn> enlève automatiquement le 
paquet qui crée le conflit, ou bien arrête l'installation du nouveau paquet 
par une erreur. Ce mécanisme est spécifiquement conçu pour provoquer une
erreur quand le paquet installé est marqué <tt>Essential</tt> et que le 
nouveau paquet ne l'est pas.
	</p>

<p>
Un paquet ne provoque pas de conflit simplement parce que ses fichiers de
configuration sont toujours installés&nbsp;; il doit être au moins dans l'état 
«&nbsp;à moitié installé&nbsp;».
	</p>

<p>
Une exception spéciale est faite pour les paquets qui déclarent un conflit
avec leur propre nom de paquet, ou avec le paquet virtuel qu'ils
fournissent (voir ci-dessous)&nbsp;: cela n'empêche pas leur installation,
et cela autorise un paquet à déclarer un conflit avec les paquets qui 
peuvent le remplacer. On utilise ce dispositif quand on veut 
que le paquet en question soit le seul paquet à fournir une fonctionnalité
particulière.
	</p>

<p>
Une entrée <tt>Conflicts</tt> ne devrait presque jamais avoir une clause de
version indiquant une relation «&nbsp;avant&nbsp;». Cela empêcherait <prgn>dpkg</prgn> 
de mettre à jour ou d'installer le paquet qui déclare un tel conflit jusqu'à 
ce que la mise à jour ou l'effacement du paquet en conflit ait été terminé.
	</p>
      </sect>

<sect id="virtual">
<heading>Les paquets virtuels -- le champ <tt>Provides</tt></heading>

<p>
Aussi bien que des noms de paquets réels (concrets), les champs de
relation <tt>Depends</tt>, <tt>Recommends</tt>, <tt>Suggests</tt>,
<tt>Enhances</tt>, <tt>Pre-Depends</tt>, <tt>Conflicts</tt>, 
<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts</tt> 
et <tt>Build-Conflicts-Indep</tt> 
peuvent mentionner des noms de «&nbsp;paquets virtuels&nbsp;».
	</p>

<p>
Un paquet «&nbsp;virtuel&nbsp;» est un paquet qui apparaît dans le champ
<tt>Provides</tt> du fichier «&nbsp;control&nbsp;» d'un autre paquet. L'effet 
est le même que si le ou les paquets qui fournissent un paquet virtuel 
particulier avaient été listés par leur nom partout où le nom du paquet virtuel
apparaît. Voir aussi <ref id="virtual_pkg">.
	</p>

<p>
Quand un paquet concret et un paquet virtuel ont le même nom, la dépendance 
peut être satisfaite (ou le conflit provoqué) soit par le paquet concret du 
même nom soit par tout autre paquet concret fournissant le paquet virtuel du
même nom.
Par exemple, en supposant que nous ayons :
<example compact="compact">
Package: foo
Depends: bar
</example>
et que quelqu'un d'autre sorte un paquet <tt>bar</tt> amélioré, il peut
dire&nbsp;:
<example compact="compact">
Package: bar-plus
Provides: bar
</example>

et le paquet <tt>bar-plus</tt> satisfera aussi la dépendance pour le
paquet <tt>foo</tt>.
	</p>

<p>
Quand un numéro de version est attaché à une dépendance ou à un conflit,
seuls les paquets réels seront examinés pour savoir si la relation est
satisfaite (ou, pour un conflit, l'interdiction violée) - on supposera
qu'un paquet réel qui fournit un paquet virtuel n'a pas la «&nbsp;bonne&nbsp;»
version. Ainsi, un champ <tt>Provides</tt> ne peut pas contenir de numéros
de version, et le numéro de version du paquet concret qui fournit un
paquet virtuel particulier n'est pas examiné quand on considère une
dépendance envers ou un conflit avec le nom du paquet virtuel.
	</p>

<p>
Il est probable que la possibilité d'indiquer un numéro de version pour 
chaque paquet virtuel sera ajoutée dans une version prochaine de 
<prgn>dpkg</prgn>. Cette caractéristique n'est pas encore présente et
il est probable qu'elle sera très peu utilisée.
	</p>

<p>
Quand on  veut spécifier quel paquet d'un ensemble de paquets réels
sera celui qui satisfait par défaut une dépendance particulière envers
un paquet virtuel, on listera le paquet réel alternatif
avant le paquet virtuel.
	</p>

  </sect>

<sect id="replaces">
<heading>le champ <tt>Replaces</tt> -- regénérer les fichiers et remplacer les paquets</heading>

<p>
Un paquet peut déclarer dans son fichier <em>control</em> qu'il modifiera
des fichiers appartenant à un autre paquet ou qu'il remplacera complètement
un autre paquet. Le champ <tt>Replaces</tt> du fichier <em>control</em>
remplit ces deux fonctions.
	</p>

<sect1><heading>Regénérer les fichiers appartenant à d'autres paquets</heading>

<p>
Tout d'abord, comme mentionné auparavant, qu'un paquet possède des fichiers 
qui sont sur le système mais dans un autre paquet est généralement une erreur.
	  </p>

<p>
Cependant, si le paquet, qui veut faire un remplacement, déclare, dans le champ
<tt>Replaces</tt>, qu'il remplace le paquet
qui contient le fichier à remplacer, <prgn>dpkg</prgn> procède au
remplacement du fichier de l'ancien paquet par le nouveau. Ce fichier ne
sera plus listé comme faisant partie de l'ancien paquet.
	  </p>

<p>
Quand un paquet est ainsi complètement remplacé, de sorte que
<prgn>dpkg</prgn> ne sait pas quels fichiers il contient encore, on 
considère qu'il a «&nbsp;disparu&nbsp;». Sur le système, il est marqué comme 
«&nbsp;non sélectionné&nbsp;» (sélectionné pour l'effacement) et «&nbsp;non installé&nbsp;». 
Tous les renseignements contenus dans les <tt>conffiles</tt> sont ignorés, vu
que le paquet remplaçant les aura repris. Le script <prgn>postrm</prgn> du 
paquet est exécuté avec un argument particulier pour permettre au paquet de 
faire le nettoyage final nécessaire.
Voir <ref id="mscriptsinstact"> <footnote>
            <p>
Replaces est une relation à sens unique -- vous devez installer le paquet
remplaçant après le paquet remplacé.
             </p>
           </footnote>.
	  </p>

<p>
Avec cette utilisation du champ <tt>Replaces</tt>, et quand on l'examine,
on ne prend pas en compte les paquets virtuels (voyez <ref id="virtual">)
-- les paquets déclarant qu'ils sont remplacés doivent être mentionnés par
leurs noms réels.
</p>

<p>
De plus, cet usage de <tt>Replaces</tt> prend seulement effet quand deux
paquets sont -- au moins partiellement -- en même temps sur le système, et
cela peut seulement se produire s'ils ne sont pas en conflit, ou si le
conflit a été annulé.
          </p>
	</sect1>

<sect1>
<heading>Le remplacement total d'un paquet ; forcer sa suppression</heading>

<p>
Et deuxièmement, le champ <tt>Replaces</tt> permet au système de gestion des
paquets de savoir quel paquet enlever quand il y a un conflit - voir
<ref id="conflicts">. Cet usage prend seulement effet quand deux paquets sont 
réellement en conflit, afin que les deux usages de ce champ n'interfèrent pas 
l'un avec l'autre.
	  </p>
<p>
Dans ce cas, le paquet déclaré comme étant remplacé peut être un paquet
virtuel ; c'est ainsi que les agents de transport du courrier (MTA) pourront
avoir les champs suivants dans leur fichier de contrôle&nbsp;:
           <example compact="compact">
Provides: mail-transport-agent
Conflicts: mail-transport-agent
Replaces: mail-transport-agent
           </example>
On s'assure ainsi qu'un seul MTA peut être installé à la fois.
      </p>
	</sect1>
      </sect>

<sect id="sourcebinarydeps">
<heading>Les relations entre les paquets binaires et les paquets sources
-- les champs <tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
          <tt>Build-Conflicts</tt>, <tt>Build-Conflicts-Indep</tt>
        </heading>
<p>
Les paquets sources peuvent déclarer des relations avec des paquets
binaires si, par exemple, ils ont besoin que tel paquet binaire soit présent 
ou absent au moment de leur construction.
      </p>

<p>
On se sert des champs <tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>, 
<tt>Build-Conflicts</tt> et <tt>Build-Conflicts-Indep</tt> du fichier 
<em>control</em>. 
	</p>
        <p>
Les dépendances de construction sur les paquets binaires appartenant à
«&nbsp;build-essential&nbsp;» peuvent être omises. Voyez 
<ref id="pkg-relations"> pour davantage d'informations.
       </p>

       <p>
Les dépendances ou les conflits qu'ils définissent doivent être résolus 
(comme cela a été défini plus haut pour les paquets binaires) pour pouvoir 
appeler les cibles de <tt>debian/rules</tt><footnote>
<p>
Si vous construisez «&nbsp;build-arch&nbsp;» ou «&nbsp;binary-arch&nbsp;», 
vous avez besoin de Build-Depends. Si vous construisez 
«&nbsp;build-indep&nbsp;» ou «&nbsp;binary-indep&nbsp;», vous avez besoin de 
Build-Depends et de Build-Depends-Indep. Si vous construisez 
«&nbsp;build&nbsp;» ou «&nbsp;binary&nbsp;», vous avez besoin des deux.
	    </p>
<p>
	      «&nbsp;Build-Depends-Arch&nbsp;» n'existe pas&nbsp;; ce rôle est
essentiellement rempli par les Build-Depends. Il est supposé que celui qui veut
construire les cibles <tt>build-indep</tt> et <tt>binary-indep</tt> veut
de toute façon construire le paquet dans son entier et qu'il installe donc
toutes les dépendances de construction. Les constructeurs automatiques
(«&nbsp;autobuilders&nbsp;») utilisent <tt>dpkg-buildpackage -B</tt> qui appelle
<tt>build</tt> (pas <tt>build-arch</tt> car il ne sait pas encore vérifier son
existence) et <tt>binary-arch</tt>.
</p>
<p>
Le but de cette séparation, je m'en rappelle,  était que les constructeurs
automatiques n'aient pas besoin d'installer les paquets supplémentaires
requis par les cibles binary-indep. Mais, sans la séparation
build-arch/build-indep, cela ne marchait pas, car le plus gros du travail
était fait par la cible build et non pas par la cible binary.
           </p>
         </footnote>
comme suit&nbsp;:

<taglist>
            <tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
            <item>
              <p>
Les champs <tt>Build-Depends</tt> et <tt>Build-Conflicts</tt> doivent être
satisfaits quand l'une des cibles suivantes est appelée :
<tt>build</tt>, <tt>clean</tt>, <tt>binary</tt>, <tt>binary-arch</tt>, 
<tt>build-arch</tt>, <tt>build-indep</tt> et <tt>binary-indep</tt>.
              </p>
            </item>
 <tag><tt>Build-Depends-Indep</tt>, 
<tt>Build-Conflicts-Indep</tt></tag>
            <item>
              <p>
Les champs <tt>Build-Depends-Indep</tt> et <tt>Build-Conflicts-Indep</tt> 
doivent être satisfaits quand l'une des cibles suivantes est appelée :
<tt>build</tt>, <tt>build-indep</tt>, <tt>binary</tt> et <tt>binary-indep</tt>.
              </p>
            </item>
          </taglist>
	</p>
      </sect>
    </chapt>


<chapt id="sharedlibs">
<heading>Les bibliothèques partagées</heading>

<p>
On doit construire avec soin les paquets qui contiennent des bibliothèques 
partagées afin de s'assurer que ces bibliothèques seront
toujours disponibles. Et particulièrement, les paquets qui demandent des
bibliothèques vitales, telle que la bibliothèque C, (actuellement&nbsp;: 
<em>libc6</em>).
      </p>

<p>
Un paquet qui contient des bibliothèques partagées sera séparé
en plusieurs paquets binaires. Cette section est consacrée à la façon de
faire cette séparation&nbsp;; les règles pour les fichiers à l'intérieur
des paquets de bibliothèques partagées sont traitées dans 
<ref id="libraries">.
      </p>

      <sect id="sharedlibs-runtime">
       <heading>Les bibliothèques reliables dynamiquement</heading>

      <p>
La bibliothèque partagée doit être placée dans un paquet
dont le nom change chaque fois que la version objet partagée change.
<footnote>
<p>
Puisqu'il est courant d'installer plusieurs versions d'un paquet qui fournit
des bibliothèques partagées, c'est une bonne idée que la bibliothèque ne contienne
pas des fichiers supplémentaires sans version, à moins qu'ils soient placés dans
des répertoires qui ont une version.
</p></footnote>
Le mécanisme le plus courant est de mettre la bibliothèque dans un paquet
appelé <package><var>nom-de-bibliothèque</var><var>version-so</var></package>,
où <file><var>version-so</var></file> est le numéro de version du nom-so de la 
bibliothèque partagée <footnote>
<p>
Le nom-so est le nom du fichier objet partagé&nbsp;: c'est ce qui, entre le moment
de la construction de l'exécutable et celui de son fonctionnement, doit être
exactement le même pour que l'éditeur des liens dynamiques soit capable de 
faire marcher le programme. Par exemple, si le nom-so de la bibliothèque est
<tt>libfoo.so.6</tt>, le paquet de la bibliothèque sera appelé
<tt>libfoo6</tt>.</p>
          </footnote>
Quand cela amène de la confusion d'ajouter directement <var>version-so</var>
à <var>nom-de-bibliothèque</var> (par exemple, quand
<var>nom-de-bibliothèque</var> se termine lui-même par un numéro), on peut
aussi utiliser à la place
<package><var>nom-de-bibliothèque</var>-<var>version-so</var></package> et
<package><var>nom-de-bibliothèque</var>-<var>version-so</var>-dev</package>.
</p>

     <p>                                                                 
Si votre paquet comprend des programmes d'aide exécutables que les utilisateurs
n'ont pas besoin d'appeler eux-mêmes, mais qui sont néammoins nécessaires au
fonctionnement du paquet, il est recommandé de placer ces programmes 
(si ce sont des binaires) dans un répertoire de <file>/usr/lib</file>,
de préférence sous <file>/usr/lib/</file><var>nom-de-paquet</var>.
Si les programmes ne dépendent pas de l'architecture, il est recommandé de les placer
dans un répertoire de <file>/usr/share</file>, de préférence sous
          <file>/usr/share/</file><var>nom-de-paquet</var>.                     
        </p>                                                                 
                                                                            

          <p>
Si vous construisez plusieurs bibliothèques partagées à partir d'un même
arbre de sources, vous pouvez les regrouper dans le même paquet de
bibliothèques, sachant que vous devrez changer tous leurs nom-so
simultanément (pour éviter des conflits de noms de fichiers lors de
l'installation de différentes versions de ce paquet).
</p>
<p>
Une paquet installera les bibliothèques partagées sous
leurs vrais noms. Par exemple, le paquet <package>libgdbm3</package> 
installera <file>libgdbm.so.3.0.0</file> en tant que 
<file>/usr/lib/libgdbm.so.3.0.0</file>.
Aucun script <prgn>prerm</prgn> ou <prgn>postrm</prgn> ne changera le nom de 
ces fichiers ni ne créera de lien pour ces fichiers&nbsp;; 
<prgn>dpkg</prgn> s'occupe des changements de nom et cela, sans troubler les 
programmes en fonctionnement.
Essayer d'interférer avec ce système crée des problèmes.
      </p>

<p>
Les bibliothèques partagées ne doivent pas être installées comme exécutables, 
puisque l'éditeur de liens dynamiques ne le demande pas et que tenter 
d'exécuter une bibliothèque partagée se traduit par un <em>core dump</em>.
</p>

<p>
Le paquet de la bibliothèque partagée comportera le lien symbolique que 
<prgn>ldconfig</prgn> voudra créer pour les bibliothèques partagées. Par 
exemple, le paquet <package>libgdbm3</package> inclura un lien symbolique de
<file>/usr/lib/libgdbm.so.3</file> vers <file>libgdbm.so.3.0.0</file>. C'est
nécessaire pour que l'éditeur des liens dynamiques (<prgn>ld.so</prgn> ou 
<prgn>ld-linux.so.*</prgn>) puisse trouver la bibliothèque entre le
moment où <prgn>dpkg</prgn> l'installe et celui où <prgn>ldconfig</prgn> est 
exécuté par le script <prgn>postinst</prgn> <footnote>
<p>
Le système de gestion des paquets demande que la bibliothèque soit placée avant
le lien symbolique qui pointe vers elle dans le fichier <tt>.deb</tt>. Ainsi,
avant que <prgn>dpkg</prgn> n'installe le lien symbolique (en remplaçant le
lien précédent qui pointe sur une version plus ancienne de la bibliothèque),
la nouvelle bibliothèque est déjà en place. Par le passé, on créait la
bibliothèque dans le répertoire temporaire où l'on faisait le paquet avant de
créer le lien symbolique. Malheureusement, cela ne marchait pas toujours car
la construction du fichier <em>tar</em> pour le fichier <tt>.deb</tt>
dépendait du système de fichier sous-jacent. Des systèmes de fichiers (comme
reiserfs) réordonne les fichiers de sorte que l'ordre dans lequel on les crée 
est oublié. Avec sa version 1.7.0, <prgn>dpkg</prgn> réordonne, 
si nécessaire, les fichiers lors de la construction d'un paquet. Et il n'est
plus nécessaire de se préoccuper de l'ordre de création des fichiers.
</p>
</footnote>. 
      </p>

      <sect1 id="ldconfig">
       <heading><tt>ldconfig</tt></heading>

<p>
Tout paquet qui installe des bibliothèques partagées dans l'un des
répertoires par défaut de l'éditeur de liens dynamiques, (actuellement, 
<tt>/usr/lib</tt> et <tt>/lib</tt>) ou dans un répertoire listé par 
<tt>/etc/ld.so.conf</tt>
<footnote>
<p>
Les voici :
           <list compact="compact">
             <item><p>/usr/local/lib</p></item>
             <item><p>/usr/lib/libc5-compat</p></item>
             <item><p>/lib/libc5-compat</p></item>
           </list>
         </p>
	</footnote>
doit utiliser <prgn>ldconfig</prgn> pour mettre à jour le système des
bibliothèques partagées. 
	  </p>
<p>
Les scripts de responsable de paquet ne doivent appeler <prgn>ldconfig</prgn>
que dans ces circonstances&nbsp;:
            <list compact="compact">
              <item>quand le script <prgn>postinst</prgn> est exécuté avec comme
	        premier paramètre <tt>configure</tt>, le script doit appeler
	        <prgn>ldconfig</prgn> et peut facultativement appeler
	        <prgn>ldconfig</prgn> à d'autres moments.
              </item>
              <item>quand le script <prgn>postrm</prgn> est exécuté avec comme
	        premier paramètre <tt>remove</tt>, le script devrait appeler
		<prgn>ldconfig</prgn>.
              </item>
            </list>
 <footnote>
<p>
Pendant une installation ou une mise à jour, le script preinst est appelé
avant que de nouveaux fichiers ne soient installés&nbsp;: appeler
«&nbsp;ldconfig&nbsp;» est inutile. Le script preinst d'un paquet existant
peut aussi être appelé en cas d'échec de la mise à jour. Cela arrive cependant
au moment critique où une bibliothèque partagée existe sur le disque sous un
nom temporaire. Ainsi, il est dangereux, et c'est interdit par la Charte, 
d'appeler «&nbsp;ldconfig&nbsp;» à ce moment. 
</p>
<p>
Lors de l'installation ou la mise à jour d'un paquet, le script 
«&nbsp;postinst configure&nbsp;» s'exécute après que
les nouveaux fichiers ont été installés de façon certaine sur le disque. 
Puisqu'on peut parfaitement appeler sans condition ldconfig dans un postinst,
un paquet peut mettre ldconfig dans son postinst sans vérifier les arguments.
Le script postinst peut aussi être appelé lors d'un essai de récupération après
l'échec d'une mise à jour. Cela arrive avant que les nouveaux fichiers ne 
soient dépaquetés&nbsp;: il n'y a donc pas besoin d'appeler 
«&nbsp;ldconfig&nbsp;» à ce moment.
	  </p>
<p>
Lors de la suppression d'un paquet, le script prerm est appelé alors que tous 
les fichiers sont intacts&nbsp;: appeler «&nbsp;ldconfig&nbsp;» est inutile. 
Les autres appels de «&nbsp;prerm&nbsp;» se passent lors d'une mise à jour, 
quand tous les fichiers de l'ancien paquet sont sur le disque, et, encore une 
fois, appeler «&nbsp;ldconfig&nbsp;» est inutile. 
	  </p>
<p>
D'un autre côté, le script postrm est appelé avec l'argument <em>remove</em>
juste après que les fichiers ont été supprimés&nbsp;: c'est le moment idéal
pour appeler «&nbsp;ldconfig&nbsp;» et notifier ainsi au système la 
suppression des bibliothèques partagées appartenant au paquet. Le
script postrm peut être appelé à plusieurs moments. Lors de
«&nbsp;postrm purge&nbsp;», de «&nbsp;postrm abort-install&nbsp;» ou de
«&nbsp;postrm abort-upgrade&nbsp;», appeler «&nbsp;ldconfig&nbsp;» est
inutile parce que les fichiers de la bibliothèque partagée ne sont pas sur
le disque. Cependant, lorsque le script postrm est appelé avec les arguments
«&nbsp;upgrade&nbsp;», «&nbsp;failed-upgrade&nbsp;» ou «&nbsp;disappear&nbsp;»,
la bibliothèque partagée peut exister sur le disque sous un nom temporaire.
         </p>
       </footnote>.
      </p>
	</sect1>
    
      </sect>

<sect id="sharedlibs-runtime-progs">
       <heading>Les programmes d'aide au fonctionnement</heading>

          <p>
Si votre paquet contient des programmes d'aide au fonctionnement
qui utilisent la bibliothèque partagée, vous ne devez pas les mettre dans le
paquet de la bibliothèque partagée. Si vous le faites, vous ne pourrez pas
installer plusieurs versions de la bibliothèque sans créer des conflits
de noms de fichiers.
	</p>
<p>
À la place, vous pouvez soit créer un autre paquet pour ces binaires 
fonctionnels (le paquet peut s'appeler
<package><var>nom-de-bibliothèque</var>-runtime</package> -- notez l'absence 
de <var>version-so</var> dans le nom du paquet), soit
inclure ces binaires dans le paquet de développement si celui-ci est petit.
</p>
      </sect>

      <sect id="sharedlibs-static">
       <heading>Les bibliothèques statiques</heading>

      <p>
Une bibliothèque statique (<file><var>nom-de-bibliothèque.a</var></file>)
accompagne généralement la version partagée&nbsp;; elle est placée dans le
paquet de développement. Voyez plus bas.
      </p>
       <p>
Dans les cas suivants, il est acceptable qu'une bibliothèque ne soit
disponible que sous sa forme statique&nbsp;:
         <list>
           <item>
<p>

bibliothèque pour langage dont la version partagée est immature ou
instable&nbsp;;</p>
           </item>
           <item>
             <p>
bibliothèque dont l'interface change constamment ou est en développement
(c'est le cas pour une bibliothèque dont le numéro majeur de version est zéro,
ou dont la compatibilité binaire (<em>ABI</em>) n'est pas assurée pour des
niveaux de patch différents)&nbsp;;
             </p>
           </item>
           <item>
             <p>
bibliothèque explicitement prévue pour n'être disponible que sous une forme
statique par ses auteurs.
              </p>
           </item>
        </list>

      <sect id="sharedlibs-dev">
       <heading>Les fichiers de développement</heading>

      <p>
Les fichiers de développement associés à une bibliothèque partagée seront
placés dans un paquet appelé 
<package><var>nom-de-bibliothèque</var><var>version-so</var>-dev</package>,
ou, si vous préférez ne gérer qu'une version de développement à la fois,
<package><var>nom-de-bibliothèque</var>-dev</package>.
      </p>
<p>
Quand plusieurs versions de développement existent, vous pouvez utiliser le
mécanisme de gestion des conflits de <prgn>dpkg</prgn> (voir
<ref id="conflicts">) pour vous assurer que l'utilisateur ne peut installer 
qu'une seule version de développement à la fois. Plusieurs versions de 
développement auront sans doute les mêmes fichiers d'en-tête, ce qui créera 
un conflit de nom en cas d'installation multiple.
   </p>

<p>
Le paquet de développement contiendra un lien symbolique vers la
bibliothèque partagé qui lui est associée sans le numéro de version.
Par exemple, le paquet <package>libgdbm-dev</package> fera un lien de
<file>/usr/lib/libgdbm.so</file> vers <file>libgdbm.so.3.0.0</file>. 
L'éditeur de liens (<prgn>ld</prgn>) a besoin de ce lien pour la compilation 
des programmes car il ne recherche que <file>libgdbm.so</file> lors
d'une compilation dynamique.
	</p>
      </sect>

     <sect id="sharedlibs-intradeps">
   <heading>Les dépendances entre les paquets d'une même bibliothèque</heading>

       <p>
La version de développement aura une dépendance sur une version précise
de la bibliothèque partagée afin que la compilation et l'édition de liens
s'effectuent correctement. La variable de substitution
<tt>${Source-Version}</tt> peut être utile dans ce cas.
</p>

      </sect>

      <sect id="sharedlibs-shlibdeps">
       <heading>Les dépendances entre une bibliothèque et les paquets -
       le système <tt>shlibs</tt></heading>

<p>
Quand un paquet contient un binaire ou une bibliothèque liés à une
bibliothèque partagée, on doit s'assurer que, lors de l'installation de ce 
paquet sur le système, toutes les bibliothèques nécessaires sont aussi
installées. Cela a conduit à la création du système <tt>shlibs</tt>&nbsp;; de
conception très simple, ce système demande que tout paquet qui fournit 
(champ <em>provides</em>) une bibliothèque partagée donne aussi les
informations de dépendance nécessaires à la présence de cette 
bibliothèque&nbsp;;
ainsi tout paquet qui <em>utilise</em> une bibliothèque partagée, utilise
ces informations pour connaître les dépendances requises. Les fichiers qui
contiennent les relations entre les bibliothèques partagées et les 
informations sur les dépendances nécessaires sont les fichiers <tt>shlibs</tt>.
	</p>
<p>
Ainsi, quand on construit un paquet contenant une bibliothèque partagée,
on doit fournir un fichier <tt>shlibs</tt> utilisable par d'autres 
paquets&nbsp;;
et quand on construit un paquet contenant une bibliothèque partagée ou un
binaire compilé, ce paquet doit exécuter 
<qref id="pkg-dpkg-shlibdeps"><prgn>dpkg-shlibdeps</prgn></qref> pour
ces programmes de manière à connaître les bibliothèques utilisées et donc
les dépendances nécessaires à ce paquet <footnote>
<p>
Par le passé, on appelait <prgn>ldd</prgn> pour connaître les bibliothèques
partagées requises&nbsp;; maintenant on appelle <prgn>objdump</prgn>. Le seul
changement dans la manière de construire un paquet est que l'on doit aussi
exécuter <prgn>dpkg-shlibdeps</prgn> sur les bibliothèques partagées, alors
qu'avant ce n'était pas nécessaire. La suite de cette note explique les
avantages de cette méthode.
</p>
<p>
Un binaire <tt>foo</tt> utilise <em>directement</em> la bibliothèque
<tt>libbar</tt> quand il est lié explicitement à cette bibliothèque (c'est à 
dire qu'il utilise le drapeau <tt>-lbar</tt> pendant la phase de liaison). Les 
autres bibliothèques dont <tt>libbar</tt> a besoin sont liées 
<em>indirectement</em> à <tt>foo</tt>, et l'éditeur de liens dynamiques les 
charge automatiquement quand il charge <tt>libbar</tt>. Un paquet dépendra
des bibliothèques qu'il utilise directement, et les dépendances 
de ces bibliothèques amèneront automatiquement les autres bibliothèques.
</p>
<p>
Malheureusement, le programme <prgn>ldd</prgn> indique toutes les
bibliothèques, celles directement utilisées et celles indirectement utilisées&nbsp;;
ce qui signifie que les dépendances comportent des dépendances directes et
indirectes. Avec <prgn>objdump</prgn>, on évite ce problème en
indiquant seulement les bibliothèques directement utilisées.
</p>
<p>
Voici un exemple qui montre l'intérêt de ce système&nbsp;: on pourrait mettre à 
jour <tt>libimlib</tt> avec une version qui accepte le nouveau format 
graphique <em>dgf</em> (tout en gardant le même numéro majeur de version). En 
utilisant l'ancienne méthode <prgn>ldd</prgn>, chaque paquet qui se sert de
<tt>libimlib</tt> devrait être recompilé pour qu'il dépende aussi de
<tt>libdgf</tt>, sinon il ne marcherait pas à cause de symboles manquants.
Mais, avec le nouveau système, les paquets qui se servent de
<tt>libimlib</tt>  peuvent dépendre simplement de <tt>libimlib</tt> qui
possède elle-même la dépendance envers <tt>libdgf</tt> et ils n'auront pas
besoin d'être mis à jour.
      </p>
</footnote>.
	</p>
<p>
Les sections suivantes décrivent l'emplacement des différents fichiers
<tt>shlibs</tt>, la façon d'utiliser le programme <prgn>dpkg-shlibdeps</prgn>,
et le format du fichier <tt>shlibs</tt> ainsi que la façon de créer ces
fichiers quand un paquet contient une bibliothèque partagée.
</p>
     
<sect1><heading>Les fichiers <tt>shlibs</tt> sur le système</heading>
<p>
On peut trouver des fichiers <tt>shlibs</tt> à plusieurs endroits. La liste
suivante les donne dans l'ordre selon lequel 
<qref id="pkg-dpkg-shlibdeps"><prgn>dpkg-shlibdeps</prgn></qref> les
a lus. Le premier qui donne l'information demandée est utilisé.
</p>
<p>
         <list>
           <item>
             <p><file>debian/shlibs.local</file></p>
             <p>
Cela donne les remplacements à faire pour ce paquet. Son usage est décrit
plus bas (<ref id="shlibslocal">).
	    </p>
	  </item>
           <item>
             <p><file>/etc/dpkg/shlibs.override</file></p>
             <p>
Cela donne les remplacements à faire pour tout le système. Cette liste,
maintenue par l'administrateur local, est normalement vide.
	    </p>
	  </item>
           <item>
             <p>Les fichiers <file>DEBIAN/shlibs</file> dans le « répertoire 
de construction »</p>
             <p>
Quand on construit un paquet, tous les fichiers <file>debian/shlibs</file> sont
copiés dans le répertoire temporaire de construction avec comme nom 
<file>shlibs</file>. Ces fichiers donnent des renseignements sur toutes les
bibliothèques partagées contenues dans le paquet <footnote>
<p>
Un exemple nous aidera&nbsp;: supposons que le paquet source <tt>foo</tt> produit
deux paquets binaires, <tt>libfoo2</tt> et <tt>foo-runtime</tt>. Pour la
construction de ces paquets, on utilise les répertoires <tt>debian/libfoo2</tt>
et <tt>debian/foo-runtime</tt> respectivement (on pourrait utiliser
<tt>debian/tmp</tt> à la place de l'un des deux). Puisque <tt>libfoo2</tt>
fournit la bibliothèque partagée <tt>libfoo</tt>, il demandera un fichier
<tt>shlibs</tt> qui sera installé dans <tt>debian/libfoo2/DEBIAN/shlibs</tt>,
et deviendra finalement <tt>/var/lib/dpkg/info/libfoo2.shlibs</tt>. Maintenant,
quand on exécute <prgn>dpkg-shlibdeps</prgn> pour l'exécutable 
<tt>debian/foo-runtime/usr/bin/foo-prog</tt>, <prgn>dpkg-shlibdeps</prgn>
examine le fichier <tt>debian/libfoo2/DEBIAN/shlibs</tt> pour savoir si les
dépendances de <tt>foo-prog</tt> en ce qui concerne les bibliothèques
sont satisfaites par les bibliothèques fournies par <tt>libfoo2</tt>. Pour
cette raison, on ne doit exécuter <prgn>dpkg-shlibdeps</prgn> qu'après que
tous les fichiers <tt>shlibs</tt> de chaque paquet binaire ont été installés
dans le répertoire de construction.
		</p>
</footnote>.
	    </p>
	  </item>
           <item>
             <p><file>/var/lib/dpkg/info/*.shlibs</file></p>
             <p>
Ce sont tous les fichiers <file>shlibs</file> de tous les paquets installés
sur le système&nbsp;; ils sont maintenus par les responsables des paquets concernés.
	    </p>
	  </item>
           <item>
            <p><file>/etc/dpkg/shlibs.default</file></p>
              <p>
Ce fichier liste toutes les bibliothèques partagées dont les paquets n'ont
pas pu fournir de fichiers <tt>shlibs</tt> corrects. Il était utilisé quand
on a introduit le système <tt>shlibs</tt> pour la première fois&nbsp;; il est
maintenant normalement vide. Il est maintenu par le responsable de 
<tt>dpkg</tt>.
	    </p>
	  </item>
	</list>
      </p>
	</sect1>

<sect1>
<heading>Comment utiliser <prgn>dpkg-shlibdeps</prgn> et les fichiers <file>shlibs</file>&nbsp;? </heading>

<p>
Placez un appel au programme 
<qref id="pkg-dpkg-shlibdeps"><prgn>dpkg-shlibdeps</prgn></qref> dans le 
fichier <tt>debian/rules</tt>. Si le paquet contient seulement des binaires
compilés et des bibliothèques (mais pas de scripts), on peut utiliser la 
commande&nbsp;:
         <example compact="compact">
dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \
  debian/tmp/usr/lib/*
         </example>
Sinon, on devra explicitement lister les binaires compilés et les bibliothèques
<footnote>
<p>
Quand on utilise <tt>debhelper</tt>, le programme <prgn>dh_shlibdeps</prgn>
fera le nécessaire pour vous. Il gérera convenablement les paquets avec 
plusieurs binaires.</p>
</footnote>.
</p>
<p>
Cette commande place les informations sur les dépendances dans le fichier
<file>debian/substvars</file>, qui est ensuite utilisé par 
<prgn>dpkg-gencontrol</prgn>. Vous devrez placer une variable
<tt>${shlibs:Depends}</tt> dans le champ <tt>Depends</tt> du fichier de
contrôle pour que cela marche.
</p>
<p>
Si <prgn>dpkg-shlibdeps</prgn> ne se plaint pas, c'est bon. Sinon, vous
pourriez avoir besoin de créer un fichier <file>debian/shlibs.local</file>,
comme expliqué plus bas (<ref id="shlibslocal">).
</p>
<p>
Si vous avez des paquets contenant plusieurs binaires, vous devrez appeler
<prgn>dpkg-shlibdeps</prgn> sur tous ceux qui ont des binaires compilés et des
bibliothèques. Dans ce cas, vous aurez besoin de l'option <tt>-T</tt> des
outils <tt>dpkg</tt> pour spécifier un fichier <tt>substvars</tt> différent.
</p>
        <p>
Veuillez consulter <ref id="pkg-dpkg-shlibdeps"> et
          <manref name="dpkg-shlibdeps" section="1"> pour des précisions 
sur le programme dpkg-shlibdeps.
        </p>

	</sect1>

<sect1 id="shlibs"><heading>Le format du fichier <file>shlibs</file></heading>

<p>
Chaque fichier <file>shlibs</file> possède le même format. Les lignes
commençant par <tt>#</tt> sont des commentaires et sont ignorées. Chaque
ligne est de la forme&nbsp;:
         <example compact="compact">
<var>nom-de-bibliothèque</var> <var>nomso-version-numéro</var> <var>dépendances ...\</var>
         </example>
       </p>
<p>
Nous allons expliquer cette ligne en prenant comme exemple le paquet
<tt>zlib1g</tt>, qui, au moment où est écrit ce texte, installe la
bibliothèque partagée <tt>/usr/lib/libz.so.1.1.3</tt>.
	</p>
<p>
<var>nom-de-bibliothèque</var> est le nom de la bibliothèque partagée, dans
ce cas&nbsp;: <tt>libz</tt>. Cela doit correspondre à la partie « nom » du 
<em>nomso</em>, voyez plus bas.
	</p>
<p>
<var>nomso-version-numéro</var> est la partie version du <em>nomso</em> de la
bibliothèque. Le <em>nomso</em> est ce qui doit coller exactement pour que la
bibliothèque soit reconnue par l'éditeur des liens dynamiques, et il est habituellement
de la forme&nbsp;: <tt><var>nom</var>.so.<var>version-numéromajeur</var></tt>,
et dans ce cas <tt>libz.so.1</tt><footnote>
<p>
La commande suivante peut le déterminer&nbsp;:
             <example compact="compact">
objdump -p /usr/lib/libz.so.1.1.3 | grep SONAME
              </example>
</p>
</footnote>.
La partie version est la partie qui suit <tt>.so.</tt>, et donc ici&nbsp;: 
<tt>1</tt>.
	</p>
<p>
<var>dépendances</var> possède le même format qu'un champ de dépendances dans
le fichier de contrôle d'un paquet binaire. Cette partie donnera des 
renseignements sur les paquets qui sont demandés pour compiler un binaire
avec la version de la bibliothèque contenue dans le paquet. Voir
<ref id="depsyntax"> pour des précisions.
	</p>
<p>
Dans notre exemple, si la première version du paquet <tt>zlib1g</tt>, contenant
un numéro mineur égal à au moins <tt>1.3</tt>, était de <var>1:1.1.3-1</var>,
alors l'entrée <tt>shlibs</tt> pour cette bibliothèque pourra énoncer&nbsp;:
         <example compact="compact">
libz 1 zlib1g (>= 1:1.1.3)
         </example>
La dépendance pour une version particulière sert à éviter les avertissements
de l'éditeur de liens dynamiques au sujet de l'utilisation d'anciennes 
bibliothèques avec des binaires plus récents.
</p>
	</sect1>

<sect1><heading>Comment créer un fichier <file>shlibs</file> ?</heading>
<p>
Si le paquet fournit une bibliothèque partagée, vous devez créer un fichier
<file>shlibs</file> en suivant le format décrit plus haut. Habituellement, 
on le nomme <file>debian/shlibs</file> (mais si le paquet contient plusieurs 
binaires, on pourra l'appeler <tt>debian/shlibs.<var>package</var></tt>). 
Puis on laissera <file>debian/rules</file> l'installer dans la zone de 
contrôle&nbsp;:
         <example compact="compact">
install -m644 debian/shlibs debian/tmp/DEBIAN
         </example>
ou, en cas de paquet avec de multiples binaires&nbsp;:
         <example compact="compact">
install -m644 debian/shlibs.<var>package</var> debian/<var>package</var>/DEBIAN/shlibs
         </example>
Une autre façon de faire est de créer directement le fichier <tt>shlibs</tt>
dans la zone de contrôle à partir du fichier <tt>debian/rules</tt> sans
utiliser un fichier <tt>debian/shlibs</tt><footnote>
<p>
C'est ce que fait <prgn>dh_makeshlibs</prgn> de la suite <tt>debhelper</tt>.
</p>
</footnote>, 
puisque le fichier <tt>debian/shlibs</tt> lui-même est ignoré par le
programme <prgn>dpkg-shlibdeps</prgn>.
</p>
<p>
Comme <prgn>dpkg-shlibdeps</prgn> lit tous les fichiers <tt>DEBIAN/shlibs</tt>
de tous les paquets binaires construits à partir du paquet source, tous les
fichiers <tt>DEBIAN/shlibs</tt> seront installés avant d'appeler
<prgn>dpkg-shlibdeps</prgn> pour chaque paquet binaire.
	</p>
	</sect1>

<sect1 id="shlibslocal">
<heading>Comment écrire le fichier <file>debian/shlibs.local</file> ?</heading>

<p>
Ce fichier est prévu seulement pour une correction temporaire quand les
binaires ou les bibliothèques dépendent d'une bibliothèque pour laquelle
aucun fichier <tt>shlibs</tt> correct n'est produit par le paquet.
	</p>
<p>
Nous supposons que vous essayez de créer un paquet binaire <tt>foo</tt>. Quand
vous essayez d'exécuter <prgn>dpkg-shlibdeps</prgn>, vous obtenez le message
d'erreur suivant (l'option <tt>-O</tt> affiche les informations de
dépendance sur <tt>stdout</tt> au lieu de les écrire dans le fichier
<tt>debian/substvars</tt>, et les lignes ont été enveloppées pour faciliter
la lecture)&nbsp;:
         <example compact="compact">
$ dpkg-shlibdeps -O debian/tmp/usr/bin/foo
dpkg-shlibdeps: warning: unable to find dependency
  information for shared library libbar (soname 1,
  path /usr/lib/libbar.so.1, dependency field Depends)
shlibs:Depends=libc6 (>= 2.2.2-2)
         </example>
Vous pouvez alors exécuter <prgn>ldd</prgn> sur le binaire pour trouver
l'emplacement exact de la bibliothèque en question&nbsp;:
         <example compact="compact">
$ ldd foo
libbar.so.1 => /usr/lib/libbar.so.1 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x40032000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
         </example>
Ainsi le binaire <prgn>foo</prgn> dépend de la bibliothèque partagée
<prgn>libbar</prgn>, mais aucun paquet ne donne un fichier <tt>*.shlibs</tt>
qui gère <tt>libbar.so.1</tt> dans <tt>/var/lib/dpkg/info/</tt>. Déterminons
le paquet responsable&nbsp;:
          <example compact="compact">
$ dpkg -S /usr/lib/libbar.so.1
bar1: /usr/lib/libbar.so.1
$ dpkg -s bar1 | grep Version
Version: 1.0-1
         </example>
Ce qui nous indique que le paquet <tt>bar1</tt>, version <tt>1.0-1</tt>, est
celui qu'on utilise. Maintenant nous pouvons envoyer un rapport de bogue
contre le paquet <tt>bar1</tt> et créer notre propre fichier
<tt>debian/shlibs.local</tt> pour corriger localement le problème évoqué.
Insérer la ligne suivante dans le fichier <tt>debian/shlibs.local</tt>&nbsp;:
         <example compact="compact">
libbar 1 bar1 (>= 1.0-1)
         </example>
permettra la construction du paquet.
</p>
<p>
Dès que le responsable de <tt>bar1</tt> fournit un fichier <tt>shlibs</tt>
correct, vous supprimerez cette ligne dans le fichier 
<tt>debian/shlibs.local</tt>. Vous aurez sans doute aussi un champ
<tt>Build-Depends</tt> concernant les versions pour <tt>bar1</tt> de
manière à s'assurer que d'autres n'aient pas le même problème pour
construire votre paquet.
	</p>
	</sect1>
      </sect>
    </chapt>

<chapt id="opersys">
<heading>Le système d'exploitation</heading>
	
      
      <sect>
	<heading>La hiérarchie du système de fichiers</heading>
	  
	
	<sect1 id="fhs">
	  <heading>La structure du système de fichiers</heading>
	    
	  <p>
L'emplacement de tous les répertoires et fichiers installés
doit être conforme au standard sur la hiérarchie du système de fichiers 
(FHS, version&nbsp;2.3), avec les exceptions notées ci-dessous et sauf si cela
va à l'encontre d'un principe de la charte Debian.
Les exceptions suivantes au FSH s'appliquent&nbsp;:
            <enumlist>
              <item>
                <p>
                  Les serveurs XFree86 historiques sont autorisés à conserver
                  l'emplacement du fichier de configuration
                  <file>/etc/X11/XF86Config-4</file>.
                </p>
              </item>
              <item>
                <p>
                  Les règles optionnelles relatives aux fichiers de
                  configuration spécifiques à l'utilisateurs pour les
                  applications sont stockées dans le répertoire personnel de
                  l'utilisateur sont réduites. Il est recommandé que de tels
                  fichiers commencent par un point («&nbsp;fichier caché&nbsp;»)
                  et si une application a besoin de créer plus d'un fichier
                  caché, alors l'emplacement préféré est dans un sous-répertoire
                  dont le nom commence par un point («&nbsp;répertoire
                  caché&nbsp;»). Dans ce cas, il est recommandé que les fichiers
                  de configuration ne commencent pas par un point.
                </p>
              </item>
              <item>
                <p>
                  L'obligation pour amd64 d'utiliser <file>/lib64</file> pour
                  les binaires 64&nbsp;bit est supprimée.
                </p>
              </item>
              <item>
                <p>
                  L'obligation que <file>/usr/local/share/man</file> soit
                  «&nbsp;synonyme&nbsp;» de <file>/usr/local/man</file> est
                  réduite à une recommendation.</p>
              </item>
              <item>
                <p>
                  L'obligation que les gestionnaires de fenêtres avec un seul
                  fichier de configuration l'appelle <file>system.*wmrc</file>
                  est supprimée, tout comme la restriction que le
                  sous-répertoire du gestionnaire de fenêtres soit nommée de
                  façon identique au nom du gestionnaire de fenêtres lui-même.
                </p>
              </item>
              <item>
                <p>
                  L'obligation que les fichiers de configuration des
                  gestionnaires d'amorçage soient placés sous <file>/etc</file>
                  ou au moins aient un lien symbolique à cet endroit, est
                  réduite à une recommendation.
                </p>
              </item>
            </enumlist>

          </p>
          <p>
On peut trouver cette version du document dans le paquet 
<tt>debian-policy</tt>  ou, avec ce manuel, sur
<url id="https://www.debian.org/doc/packaging-manuals/fhs/" name="FHS (copie Debian)"> (ou, si le paquet <package>debian-policy</package> est installé, sur
<url id="file:///usr/share/doc/debian-policy/fhs/" name="FHS (copie locale)">).
La version la plus récente (ou simplement une plus récente) se trouve
sur <url id="http://www.pathname.com/fhs/" name="FHS (amont)">.
Toute question relative à la manière de suivre ce standard
peut être posée dans la liste de diffusion
<tt>debian-devel</tt> ou dans la liste consacrée au FHS (voyez, pour des
renseignements supplémentaires, 
<url id="http://www.pathname.com/fhs/" name="le site web du FHS">).
</p>
</sect1>
	    
	<sect1>
	  <heading>Les programmes spécifiques à un site</heading>
	    
	  <p>
Conformément au «&nbsp;FHS&nbsp;», aucun paquet ne doit placer de fichiers
dans<tt>/usr/local</tt>, que ce soit en les mettant dans l'archive 
qui doit être dépaquetée par <prgn>dpkg</prgn> ou
en les manipulant dans les scripts d'installation.
</p>
	  <p>
Cependant, un paquet peut créer des répertoires vides sous <tt>/usr/local</tt>
de manière que l'administrateur système ait un endroit où placer
des fichiers locaux. Ce ne sont pas des répertoires directement <em>dans</em>
<file>/usr/local</file>, mais des sous-répertoires de répertoires dans
<file>/usr/local</file>.  Si ces répertoires (<file>/usr/local/*/dir/</file>)
sont vides, ils seront supprimés quand on supprime le paquet.
</p>
	    
	  <p>
On notera que cela ne s'applique qu'aux répertoires <em>sous</em>
<tt>/usr/local</tt> et non pas <em>dans</em> <tt>/usr/local</tt>. 
Le répertoire <tt>/usr/local</tt> ne doit
contenir lui-même que les répertoires listés dans le FHS,
section 4.5. Cependant vous pouvez créer autant de répertoires que vous voulez
sous ces répertoires. Vous ne devez pas supprimer
les répertoires listés à la section 4.5, même si vous les avez créés.
</p>
	  <p>
Comme <tt>/usr/local</tt> peut être monté depuis un serveur distant et 
n'autoriser que la lecture, on doit créer ces répertoires avec
les scripts de post-installation, <prgn>postinst</prgn> et on doit les
supprimer avec les scripts de pré-désinstallation, <prgn>prerm</prgn>&nbsp;; 
ils ne doivent pas être dans l'archive <tt>.deb</tt>.
Ces scripts ne doivent pas échouer si l'une de ces opérations échoue.
</p>
	    
	  <p>
Par exemple, le paquet <tt>emacsen-common</tt> pourrait contenir
    <example compact="compact">
if [ ! -e /usr/local/share/emacs ]
then
  if mkdir /usr/local/share/emacs 2>/dev/null
  then
    chown root:staff /usr/local/share/emacs
    chmod 2775 /usr/local/share/emacs
  fi
fi
    </example>
dans le script <prgn>postinst</prgn>, et
          <example compact="compact">
rmdir /usr/local/share/emacs/site-lisp 2>/dev/null || true
rmdir /usr/local/share/emacs 2>/dev/null || true
          </example>
dans le script <prgn>prerm</prgn>. Il faut remarquer qu'on utilise cette forme
pour s'assurer que le répertoire <tt>/usr/local/share/emacs</tt> sera encore 
supprimé si le script est interrompu.
</p>
	    
	  <p>
Si vous créez un répertoire dans <tt>/usr/local</tt> pour 
ajouter des éléments à un paquet, vous vous assurerez que le paramétrage 
dans <tt>/usr/local</tt> sera prioritaire par rapport à celui dans 
<tt>/usr</tt>.
</p>

	  <p>
Cependant, puisque <tt>/usr/local</tt> et son contenu sont réservés à 
l'administrateur local, un paquet ne doit pas compter sur la présence ou 
l'absence de fichiers ou répertoires dans <tt>/usr/local</tt>  
pour toute opération normale.
</p>
<p>Le répertoire <tt>/usr/local</tt> lui-même et tous les sous-répertoires
créés par un paquet, auront (par défaut) les droits 2775 (modifiables et 
exécutables par le groupe (bit «&nbsp;set-group-id&nbsp;» positionné)). Ils 
doivent appartenir à <tt>root.staff</tt>.
</p>
</sect1>
<sect1>
<heading>Le répertoire commun pour le courrier</heading>
<p>
Le répertoire commun pour le courrier est <tt>/var/mail</tt>. Ce répertoire
fait partie du système de base et il n'appartiendra à aucun opérateur de
courrier particulier. L'utilisation de l'ancien répertoire 
<tt>/var/spool/mail</tt> est déconseillée, même si le courrier se trouve
toujours physiquement là. Pour garder, lors d'une mise à jour, une 
compatibilité avec les systèmes qui utilisent <tt>/var/spool/mail</tt> comme
répertoire de courrier, les paquets qui se servent de <tt>/var/mail</tt>
doivent dépendre de <package>libc6</package> (&gt;= 2.1.3-13), ou bien de
<package>base-files</package> (&gt;= 2.2.0), et des versions plus récentes
de ces paquets.</p>
	</sect1>
</sect>
	
      <sect>
	<heading>Les utilisateurs et les groupes</heading>
	  
<sect1>
<heading>Introduction</heading>
	<p>
Le système Debian est configuré pour utiliser soit les mots de passe
ordinaires soit les mots de passe masqués («&nbsp;shadow password&nbsp;»).
</p>
	  
	<p>
L'utilisation de quelques identifiants d'utilisateur (UID) et de groupe 
(GID) est réservée à certains paquets. Ces paquets ont besoin
d'inclure des fichiers appartenant à ces utilisateurs ou à ces groupes,
ou bien ont besoin de compiler des binaires avec ces identifiants&nbsp;; c'est 
pourquoi, sur tout système Debian, ces identifiants ne pourront être utilisés 
que dans un cadre prédéfini.
C'est une restriction importante, et on évitera d'interférer avec des 
politiques particulières d'administration système. De nombreux sites 
notamment attribuent des utilisateurs ou des groupes systèmes spécifiques 
à partir de 100.
</p>
	  
	<p>
En dehors de cet aspect, les identifiants seront attribués dynamiquement et
seront rangés selon un ordre raisonnable mais qui peut être redéfini.
</p>
	<p>
Seul le paquet <tt>base-passwd</tt> a le droit de modifier 
<tt>/etc/passwd</tt>, <tt>/etc/shadow</tt>, <tt>/etc/group</tt>
ou <tt>/etc/gshadow</tt>.
</p>
    </sect1>
<sect1><heading>Les classes d'« UID » et de « GID »</heading>
	<p>
Les numéros des «&nbsp;UID&nbsp;» et des «&nbsp;GID&nbsp;» sont rangés en
classes&nbsp;:
	  <taglist>
	    <tag>0-99 :</tag>
	    <item>
	      <p>
Attribués en bloc par le projet Debian, ils doivent être identiques sur tout 
système Debian. Ces identifiants apparaîtront dans les fichiers 
<tt>passwd</tt> et <tt>group</tt> de tout système Debian, tout nouvel
identifiant dans cet intervalle étant automatiquement ajouté quand le paquet 
<tt>base-passwd</tt> est mis à jour.
 </p>
		
	      <p>
Un paquet qui a besoin d'un identifiant UID ou GID unique et attribué de
manière fixe utilisera cet intervalle&nbsp;; le responsable demandera
son obtention au responsable de <tt>base-passwd</tt>.
 </p>
	    </item>
		
	    <tag>100-999 :</tag>
	    <item>
	      <p>
Utilisateurs et groupes système attribués dynamiquement. Les paquets qui 
ont besoin d'un utilisateur ou d'un groupe et qui
tolèrent que cet identifiant soit attribué dynamiquement et différemment
sur chaque système, utiliseront <tt>adduser --system</tt>
pour la création d'un tel groupe ou utilisateur.
Le programme <prgn>adduser</prgn> vérifie qu'un tel groupe ou utilisateur
n'existe pas déjà et utilise si nécessaire un autre identifiant dans 
l'intervalle spécifié par <tt>adduser.conf</tt>.
 </p>
</item>

	    <tag>1000-29999 :</tag>
	    <item>
	      <p>
Comptes utilisateur attribués dynamiquement. Par défaut, <prgn>adduser</prgn> 
choisit les «&nbsp;UID&nbsp;» et les «&nbsp;GID&nbsp;» pour les comptes 
utilisateur dans cet intervalle, bien que <tt>adduser.conf</tt> puisse 
modifier ce comportement.
 </p>
</item>

	    <tag>30000-59999 :</tag>
	    <item>
	      <p>Usage réservé.</p></item>
		
		
	    <tag>60000-64999 :</tag>
	    <item>
	      <p>
Attribués en bloc par le projet Debian, mais ils ne sont créés
qu'à la demande. Les identifiants sont attribués de manière fixe et centralisée
mais les comptes ne sont effectivement créés sur le système qu'à la demande.
 </p>
		
	      <p>
Ces identifiants sont réservés à des paquets obscurs ou à des paquets qui 
demandent de nombreux identifiants attribués de manière fixe. Ces paquets 
doivent s'assurer de l'inexistence de ces comptes dans <tt>/etc/passwd</tt> 
ou dans <tt>/etc/group</tt> et les créer eux-mêmes si nécessaire (en utilisant
si possible <prgn>adduser</prgn>).
Les paquets qui risquent d'avoir besoin de davantage d'identifiants, 
se réserveront un intervalle d'attribution plus large que de besoin, laissant
ainsi des possibilités de développement.
</p>
</item>
		
		
	    <tag>65000-65533 :</tag>
	    <item>
	      <p>Usage réservé.</p></item>
		
		
	    <tag>65534 :</tag>
	    <item>
<p>
Utilisateur <tt>nobody</tt>. Le «&nbsp;gid&nbsp;» correspondant renvoie au 
groupe <tt>nogroup</tt>.
</p>
</item>
		
		
	    <tag>65535 :</tag>
	    <item>
	      <p>
		<tt>(uid_t)(-1) == (gid_t)(-1)</tt>. <em>Ne doit pas</em> être
utilisé car il s'agit de la valeur sentinelle pour retourner une erreur.
 </p>
	    </item>
	  </taglist>
	</p>
    </sect1>
</sect>
      
      <sect id="sysvinit">
	<heading>Les niveaux de fonctionnement du système et les scripts dans <file>init.d</file></heading>
	  
	
	<sect1 id="/etc/init.d">
	  <heading>Introduction</heading>
	    
	  <p>
Le répertoire <file>/etc/init.d</file> contient les scripts exécutés
par <prgn>init</prgn> quand le système démarre et quand l'état
de <prgn>init</prgn> (son «&nbsp;niveau de fonctionnement&nbsp;») est modifié 
(voir <manref name="init" section="8">).
</p>

          <p>
Il y a au moins deux façons, différentes mais fonctionnellement équivalentes,
de se servir de ces scripts. Pour rester simple, on décrit ici la méthode des
liens symboliques. Les scripts du responsable ne doivent cependant pas 
présumer que cette méthode est utilisée, et toute manipulation automatisée 
du comportement des différents niveaux de fonctionnement doit être faite 
avec le programme <prgn>update-rc.d</prgn> comme décrit plus bas, et non pas 
en créant ou en supprimant eux-même les liens symboliques.
Voyez la documentation du paquet <tt>file-rc</tt> pour des renseignements sur 
la mise en ½uvre de l'autre méthode.
</p>

          <p>
Ces scripts sont référencés par des liens symboliques dans les
répertoires <file>/etc/rc<var>n</var>.d</file>. Lorsque le niveau
de fonctionnement change, <prgn>init</prgn> recherche les scripts qu'il doit 
exécuter dans le répertoire <file>/etc/rc<var>n</var>.d</file>, où 
<tt><var>n</var></tt> est soit le niveau de fonctionnement demandé, soit 
<tt>S</tt> pour le démarrage. 
</p>
          <p>
Les noms de ces liens sont tous de la forme 
<file>S<var>mm</var><var>script</var></file> ou de la forme
<file>K<var>mm</var><var>script</var></file>&nbsp;;
<var>mm</var> est un nombre à deux chiffres et <var>script</var>
est le nom du script (qui sera le même que le
véritable script dans <tt>/etc/init.d</tt>).
</p>
	    
          <p>
Lorsque <prgn>init</prgn> change de niveau de fonctionnement, il exécute
d'abord les scripts référencés par les liens dont le nom commence
par <tt>K</tt>, chacun avec un seul argument&nbsp;: <tt>stop</tt>. Puis
<prgn>init</prgn> exécute les scripts préfixés par <tt>S</tt>, avec pour 
chacun un seul argument&nbsp;: <tt>start</tt>. (Les liens appartiennent au 
répertoire de <tt>/etc/rc<var>n</var>.d</tt> qui correspond au nouveau
niveau de fonctionnement.) Les liens <tt>K</tt> sont chargés d'arrêter les 
services et les liens <tt>S</tt> de démarrer les services au démarrage du
niveau de fonctionnement.
</p>
	  <p>
Par exemple, pour passer du niveau 2 au niveau 3, <prgn>init</prgn>
exécutera d'abord tous les scripts préfixés par <tt>K</tt> qu'il trouve dans
<tt>/etc/rc3.d</tt>, puis tous les scripts de ce répertoire préfixés par 
<tt>S</tt>.
Les liens qui commencent par <tt>K</tt> entraîneront l'exécution
des scripts qu'ils référencent avec l'argument <tt>stop</tt> alors que les
liens <tt>S</tt> entraîneront l'exécution des scripts avec
l'argument <tt>start</tt>.
</p>
	    
	  <p>
Le nombre à deux chiffres <var>mm</var> est utilisé pour
décider de l'ordre d'exécution des scripts&nbsp;: les scripts de numéros les 
plus faibles sont exécutés en priorité. Par exemple les scripts <tt>K20</tt>
seront exécutés avant les scripts <tt>K30</tt>. Cela sert quand un service 
doit être démarré avant un autre. Par exemple, il peut être nécessaire de 
démarrer le serveur de noms <prgn>bind</prgn> avant le serveur de nouvelles
<prgn>inn</prgn> afin que <prgn>inn</prgn> puisse
positionner ses listes d'accès.
Dans ce cas, le script de démarrage de <prgn>bind</prgn> doit
avoir un numéro plus faible que le script qui démarre <prgn>inn</prgn>&nbsp;:
      <example compact="compact">
/etc/rc2.d/S17bind
/etc/rc2.d/S70inn
      </example>
</p>

<p>
Les deux niveaux 0 (halt) et 6 (reboot) sont légèrement différents. Dans ces
niveaux, les liens préfixés par <tt>S</tt> sont toujours appelés après les 
liens préfixés par <tt>K</tt>, mais ils sont aussi appelés avec l'unique
argument <tt>stop</tt>.
	  </p>
<p>
De plus, quand le nom du script se termine par <tt>.sh</tt>, le script sera
créé dans le niveau <tt>S</tt> plutôt que d'être exécuté dans un sous-processus
«&nbsp;forké&nbsp;», et dans tous les autres niveaux il sera exécuté par le
programme <prgn>sh</prgn>.
	  </p>

	</sect1>
	  
	<sect1>
	  <heading>L'écriture des scripts</heading>
	    
	  <p>
Les paquets qui mettent en service des «&nbsp;démons&nbsp;» mettront des 
scripts dans <tt>/etc/init.d</tt> pour démarrer ou arrêter des services au 
moment de l'amorçage ou pour un changement du niveau de fonctionnement.
Ces scripts seront nommés <tt>/etc/init.d/<var>paquet</var></tt> et ne 
doivent prendre qu'un seul argument, lequel indique ce qu'il faut faire :
	    
	    <taglist>
	      <tag><tt>start</tt></tag>
	      <item><p>démarrer le service,</p></item>
		  
	      <tag><tt>stop</tt></tag>
	      <item><p>arrêter le service,</p></item>
		  
	      <tag><tt>restart</tt></tag>
	      <item><p>arrêter et redémarrer le service s'il fonctionne déjà,
sinon lancer le service</p></item>
		  
	      <tag><tt>reload</tt></tag>
	      <item><p>chargement d'une nouvelle configuration 
du service sans réellement arrêter et redémarrer le service,
 </p>
</item>
		  
	      <tag><tt>force-reload</tt></tag> <item><p> 
chargement d'une nouvelle configuration si le service le permet,
sinon redémarrer le service.
 </p>
</item>
	    </taglist>
	    
	    Les options <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt> et
<tt>force-reload</tt> seront acceptées par tous les scripts
de <tt>/etc/init.d</tt>&nbsp;; l'option <tt>reload</tt> est facultative.
</p>

	  <p>
Les scripts de <tt>/etc/init.d</tt> doivent avoir un comportement raisonnable quand 
ils sont appelés avec l'option <tt>start</tt> alors que le service tourne 
déjà. Il en est de même pour l'option <tt>stop</tt> quand le service
ne tourne pas. Ils ne doivent pas tuer des processus utilisateur
appelés par mégarde.
Le meilleur moyen est généralement d'utiliser <prgn>start-stop-daemon</prgn>.
</p>
<p>
Quand un service recharge automatiquement sa configuration (comme
c'est le cas de <prgn>cron</prgn> par exemple),
l'option <tt>reload</tt> du script dans <tt>/etc/init.d</tt> 
se comportera comme si la configuration avait été rechargée avec succès.
</p>	    
	    
<p>
Les scripts dans <tt>/etc/init.d</tt> seront considérés comme des fichiers de
configuration, soit en les marquant comme des <tt>conffile</tt>s (s'ils se
trouvent dans le paquet, c'est-à-dire dans le fichier .deb), soit en les
gérant correctement dans les scripts du responsable de paquet (s'ils ne sont
pas présents dans le fichier .deb)&nbsp;: voyez <ref id="config-files">. 
C'est important car nous voulons laisser à 
l'administrateur système la possibilité d'adapter ces scripts à son système 
local&nbsp;&mdash; par exemple, désactiver un service sans désinstaller le paquet,
ou bien spécifier des options particulières sur la ligne de commande au
démarrage d'un service&nbsp;&mdash; tout en assurant que ses modifications ne seront
pas perdues lors de la prochaine mise à jour du paquet.
</p>

	  <p>
Ces scripts ne doivent pas échouer de façon obscure quand ils trouvent dans
le système les fichiers de configuration d'un paquet supprimé&nbsp;; en effet par
défaut, <prgn>dpkg</prgn> conserve ces fichiers de configuration et ne les 
supprime qu'avec l'option <tt>--purge</tt>. En particulier, comme le script 
<tt>init</tt> lui-même est un fichier de configuration (voir 
<ref id="/etc/init.d">), il reste sur le système quand le paquet est supprimé 
avec l'option <tt>remove</tt> et non pas avec l'option <tt>purge</tt>. C'est 
pourquoi vous inclurez une instruction de <tt>test</tt> au début du script, 
comme par exemple&nbsp;:
	    <example compact="compact">
test -f <var>programme-exécuté-plus-tard-dans-le-script</var> || exit 0
	    </example>
</p>
<p>
 Dans les scripts <tt>init.d</tt>, il y a souvent des valeurs
que l'administrateur voudra changer fréquemment. Modifier ces scripts qui
sont souvent des <em>conffiles</em> demande que l'administrateur rajoute
ses modifications à chaque mise à jour du paquet et à chaque modification
des <em>conffiles</em>. Pour rendre la vie des administrateurs système moins
dure, on ne placera pas de telles valeurs configurables directement dans le
script mais plutôt dans un fichier <tt>/etc/default</tt> qui aura, de façon
classique, le même nom que le script d'<tt>init.d</tt>. Ce 
fichier supplémentaire sera lu quand le script démarrera. Il doit seulement
contenir les définitions des variables et des commentaires dans le format
POSIX <prgn>sh</prgn>. Ce peut être aussi bien un <tt>conffile</tt> qu'un
fichier de configuration maintenu avec les scripts du responsable de paquet.
Voir <ref id="config-files"> pour des précisions.
</p>

<p>
Pour s'assurer que des valeurs vitales sont toujours définies et disponibles,
le script <file>init.d</file>, affectera, avant de lire le fichier 
<file>/etc/default/</file>, une valeur par défaut pour chaque variable du 
shell dont il se sert&nbsp;; soit avant de lire le fichier 
<file>/etc/default/</file>, soit après avoir utilisé une syntaxe 
de ce genre&nbsp;: <tt>${VAR:=default}</tt>. Et le script <file>init.d</file> 
doit se comporter raisonnablement et sans échec 
quand le fichier <file>/etc/default</file> est supprimé.
	  </p>
	</sect1>

	  
	<sect1>
	  <heading>L'interfaçage avec le système d'initialisation par script</heading>
	    <p>
Les responsables de paquet utiliseront le modèle abstrait donné par les
programmes <prgn>update-rc.d</prgn> et <prgn>invoke-rc.d</prgn> pour gérer
la façon dont leurs scripts <prgn>postinst</prgn>, <prgn>prerm</prgn> ou 
<prgn>postrm</prgn> gèrent les scripts d'initialisation.
	  </p>
<p>
La gestion directe des liens dans «&nbsp;/etc/rc?.d&nbsp;» et l'appel des 
scripts dans <file>/etc/init.d/</file> seront faits seulement par les paquets 
qui fournissent le sous-système d'initialisation (<prgn>sysv-rc</prgn> et
<prgn>file-rc</prgn>).
	  </p>
         <sect2>
           <heading>La gestion des liens</heading>
<p>
Avec le programme <prgn>update-rc.d</prgn>, les responsables de paquet peuvent
gérer la création et la suppression des liens symboliques dans
<tt>/etc/rc<var>n</var>.d</tt>, ou de leurs équivalents fonctionnels quand une
autre méthode est employée.
Les responsables de paquet peuvent s'en servir dans leurs scripts
<prgn>postinst</prgn> et <prgn>postrm</prgn>.
</p>
  <p>
On ne doit pas inclure des liens symboliques dans le
<tt>/etc/rc<var>n</var>.d</tt> du système réel, ni en créer ou en supprimer
directement dans les scripts du responsable de paquet (cela échouera si le
système d'information sur les niveaux de fonctionnement utilise une autre
méthode)&nbsp;: on doit utiliser le programme <prgn>update-rc.d</prgn>. On ne
doit pas non plus inclure les répertoires <tt>/etc/rc<var>n</var>.d</tt> dans
l'archive. (Seul le paquet <tt>sysvinit</tt> peut le faire.)
</p>
<p>
Par défaut, <prgn>update-rc.d</prgn> démarrera les serveurs
dans chacun des niveaux de fonctionnement du système (2, 3, 4 et 5) pour le
mode multi-utilisateurs et les arrêtera dans le niveau (0) mode arrêt,
le niveau (1) mode mono-utilisateur  et le niveau (6) mode redémarrage.
L'administrateur système pourra paramétrer les
niveaux de fonctionnement soit en ajoutant, supprimant ou déplaçant
les liens symboliques contenus dans <tt>/etc/rc<var>n</var>.d</tt> si la
méthode des liens symboliques est utilisée, soit en modifiant
<tt>/etc/runlevel.conf</tt> quand on utilise la méthode <tt>file-rc</tt>.
</p>
          <p>
Pour obtenir le comportement par défaut pour votre paquet,
mettez dans le script <prgn>postinst</prgn>&nbsp;:

            <example compact="compact">
update-rc.d <var>paquet</var> defaults
            </example>
            et dans votre <prgn>postrm</prgn>
            <example compact="compact">
if [ "$1" = purge ]; then
update-rc.d <var>paquet</var> remove
fi
            </example>
Remarquez que si votre paquet change les niveaux de fonctionnement ou les
priorités, il vous faudra supprimer les liens puis les recréer&nbsp;; sinon
les liens précédents persisteraient. Référez-vous à la documentation de
<prgn>update-rc.d</prgn>. 
</p>
          <p>
Le numéro d'ordre d'exécution par défaut sera égal à 20. Si l'ordre ou
le moment d'exécution du script <tt>init.d</tt> sont indifférents, utilisez
cette valeur par défaut. S'ils sont importants, vous devez en discuter avec le
responsable du paquet <prgn>sysvinit</prgn> ou envoyer
un message à <tt>debian-devel</tt>. Ceci devrait vous
aider à déterminer le numéro d'ordre d'exécution.
</p>
          <p>
Pour plus d'informations sur l'utilisation d'<tt>update-rc.d</tt>,
veuillez consulter sa page de manuel
<manref name="update-rc.d" section="8">.
</p>
	  </sect2>
         <sect2>
           <heading>Comment utiliser les scripts d'initialisation</heading>
           <p>
Le programme <prgn>invoke-rc.d</prgn> facilite l'appel correct d'un script
d'initialisation par les responsables de paquet&nbsp;; cela comprend le
respect du niveau de fonctionnement et des contraintes définies localement
qui pourraient limiter le droit au démarrage d'un paquet, ainsi que la gestion
d'autres services. Les responsables de paquets peuvent utiliser ce programme 
dans leurs scripts.
	    </p>
<p>
Les scripts du responsable de paquet doivent utiliser <prgn>invoke-rc.d</prgn>
pour l'appel des scripts dans <file>/etc/init.d/*</file> au lieu de les appeler
directement.
	    </p>
           <p>
Par défaut, <prgn>invoke-rc.d</prgn> passera toute demande d'action (start, 
stop, reload, restart...) au script <file>/etc/init.d</file> et filtrera les
demandes de démarrage ou de redémarrage d'un service selon ses niveaux de
fonctionnement prévus.
	    </p>
           <p>
La plupart des paquets auront simplement à changer
<example compact="compact">/etc/init.d/&lt;package&gt;
 &lt;action&gt;</example>
dans leurs scripts <prgn>postinst</prgn> et <prgn>prerm</prgn> pour&nbsp;:
<example compact="compact">
          if which invoke-rc.d >/dev/null 2>&1; then
               invoke-rc.d <var>package</var> &lt;action&gt;
          else
                /etc/init.d/<var>package</var> &lt;action&gt;
          fi
             </example>
</p>
           <p>
Davantage d'informations sur l'utilisation de <prgn>invoke-rc.d</prgn> se
trouvent dans sa page de manuel <manref name="invoke-rc.d" section="8">.
	    </p>
	  </sect2>
</sect1>
	    
	    
	<sect1>
	  <heading>L'initialisation au moment de l'amorçage</heading>
	    
          <p>
Classiquement, un autre répertoire, <file>/etc/rc.boot</file>, contenait les
scripts exécutés seulement au démarrage. Mais on préfère maintenant
se servir de liens de <file>/etc/rcS.d</file> vers les fichiers dans
<file>/etc/init.d</file>, comme décrit dans <ref id="/etc/init.d">.
Aucun paquet ne doit placer de fichier dans <file>/etc/rc.boot</file>.
</p>
</sect1>

	    
	<sect1>
	  <heading>Exemple</heading>
	    
	  <p>
Un exemple sur lequel baser
les scripts de <file>/etc/init.d</file> se trouve dans
<file>/etc/init.d/skeleton</file>.
</p>
	    
	</sect1>
</sect>
	

      <sect>
<heading>Les messages de la console provenant des scripts <file>init.d</file></heading>
	  
	<p>
Cette section décrit les formats des messages que les scripts du
répertoire <file>/etc/init.d</file> écrivent sur la sortie standard.
L'objectif est d'améliorer la cohérence du style Debian
en matière de séquences de démarrage et d'arrêt d'un système. Pour cette
raison, veuillez faire très attention aux détails. Nous voulons que les 
messages standardisés fassent une utilisation identique des espaces, de la 
ponctuation et de la casse des lettres.
</p>	  
	<p>
Voici une liste des règles générales à respecter pour la création
de messages provenant des scripts de <file>/etc/init.d</file>.
</p>
	<p>
	  <list>
	    <item>
	      <p>
 Tous les messages tiendront sur une ligne (inférieure à 80 caractères). Ils 
commenceront par une capitale et se termineront par un point «&nbsp;.&nbsp;»
et un saut de ligne (<tt>"\n"</tt>).
 </p>
</item>		

		
<item>
	      <p>
Quand vous voulez signaler que l'ordinateur est occupé (exécution d'une
tâche particulière et non pas le démarrage ou l'arrêt d'un programme),
utilisez une «&nbsp;ellipse&nbsp;», à savoir trois points <tt>...</tt>, 
sans espace avant ou après les points ni de retour à la ligne.
 </p>
</item>
		
	    <item>
	      <p>
Concevez vos messages comme si l'ordinateur vous disait ce qu'il fait
(rendez-le poli&nbsp;:-), mais n'en faites pas un personnage.
Par exemple, si vous voulez dire&nbsp;:
		<example compact="compact">
I'm starting network daemons: nfsd mountd.
		</example>
		dites simplement&nbsp;:
		<example compact="compact">
Starting network daemons: nfsd mountd.
		</example>
</p>
</item>
	  </list>
</p>
	  
	<p>
Il y a des messages standard pour les situations suivantes. Ils seront
utilisés par les scripts d'<tt>init.d</tt>.
</p>
	  
	<p>
	  <list>
	    <item>
	      <p>au lancement d'un démon.</p>
		
	      <p>
Utilisez ce format si votre script démarre un ou plusieurs démons.
Le message en sortie (une seule ligne, sans espace au début)
doit ressembler à ceci&nbsp;:
		<example compact="compact">
Starting <var>description</var>: <var>daemon-1</var> ... <var>daemon-n</var>.
		</example>
	L'élément <var>description</var> décrira le sous-système dont fait 
partie le ou les démons alors que les éléments de <var>daemon-1</var> jusqu'à 
<var>daemon-n</var> indiqueront chacun le nom du démon (habituellement le nom 
du fichier programme).
</p>			
	      <p>
Par exemple, la sortie de <tt>/etc/init.d/lpd</tt> ressemble à&nbsp;:
		<example compact="compact">
Starting printer spooler: lpd.
		</example>
</p>
		
	      <p>
ce qui peut être obtenu en écrivant dans le script&nbsp;:
		<example compact="compact">
echo -n "Starting printer spooler: lpd"
start-stop-daemon --start --quiet --exec /usr/sbin/lpd
echo "."
		</example>
Si vous devez démarrer plusieurs démons, vous pouvez écrire le code
suivant&nbsp;:
		<example compact="compact">
echo -n "Starting remote file system services:"
echo -n " nfsd"; start-stop-daemon --start --quiet nfsd
echo -n " mountd"; start-stop-daemon --start --quiet mountd
echo -n " ugidd"; start-stop-daemon --start --quiet ugidd
echo "."
		</example>
L'utilisateur peut savoir ainsi ce qui prend tant de temps et quand
le dernier démon a été démarré. Vous serez précis avec les espaces&nbsp;: dans 
l'exemple précédent un administrateur système
peut facilement commenter une ligne s'il ne veut pas lancer un démon
particulier&nbsp;; le message affiché reste correct.
 </p>
</item>
		
	    <item>
	      <p>quand un paramètre système est positionné.</p>
		
	      <p>
Si vous devez positionner différents paramètres au démarrage du système,
vous utiliserez ce format&nbsp;:
		<example compact="compact">
Setting <var>parameter</var> to "<var>value</var>".
		</example></p>
		
	      <p>
vous pouvez utiliser le message suivant qui place correctement les
guillemets&nbsp;:
		<example compact="compact">
echo "Setting DNS domainname to \"$domainname\"."
		</example></p>
		
	      <p>

<!-- IMPORTANT : il n'y a qu'un caractère " dans la ligne ci-dessous, -->
<!-- mais un 2e a été ajouté temporairement pour la coloration syntaxique  -->
Il faut noter que le même caractère (<tt>"</tt>) est utilisé pour les
guillemets à gauche et à droite. Un accent grave (<tt>`</tt>) n'est pas
un guillemet gauche&nbsp;; de même, une apostrophe (<tt>'</tt>) n'est pas un
guillemet droit.
		</p></item> 
	      
	    <item>
	      <p>quand on arrête ou relance un démon.</p>
		
	      <p>
Quand vous arrêtez ou relancez un démon, vous devez afficher un message 
similaire à celui du démarrage en remplaçant <tt>Starting</tt> par 
<tt>Stopping</tt> ou <tt> Restarting</tt>.
 </p>
		
	      <p>
Le message à l'arrêt du démon d'impression sera&nbsp;:
		<example compact="compact">
Stopping printer spooler: lpd.
		</example></p></item>
	      
	    <item>
	      <p>quand on exécute un programme.</p>
		
	      <p>
Il y a plusieurs cas où vous devez lancer un programme soit au démarrage
soit à l'arrêt du système pour exécuter des tâches spécifiques. Par
exemple, initialiser l'heure système à l'aide de <prgn>netdate</prgn> ou 
bien tuer tous les processus à l'arrêt du système. Vos messages suivront
cet exemple&nbsp;:
		<example compact="compact">
Doing something very useful...done.
		</example>
Vous afficherez le <tt>done.</tt> immédiatement après la fin de la tâche
de manière que l'utilisateur soit renseigné sur le pourquoi de son attente.
Pour cela, mettez dans votre script&nbsp;:
		<example compact="compact">
echo -n "Doing something very useful..."
do_something
echo "done."
		</example>
</p></item>
	      
	    <item>
	      <p>quand la configuration est rechargée.</p>
		
	      <p>
Quand un démon est forcé de recharger ses fichiers de configuration,
vous utiliserez des messages qui suivent le format suivant&nbsp;:
		<example compact="compact">
Reloading <var>description</var> configuration...done.
		</example>
où <var>description</var> est identique au message de démarrage du démon.
</p>
</item>
	  </list></p>
      </sect>
      <sect>
	<heading>Les travaux de «&nbsp;Cron&nbsp;»</heading>
	  
	<p>
Les paquets ne doivent pas modifier le fichier de configuration
<file>/etc/crontab</file>, ni les fichiers contenus dans
<file>/var/spool/cron/crontabs</file>.
</p>
	  
	<p>
Quand un paquet veut confier une tâche au programme <prgn>cron</prgn>,
il placera un fichier de même nom que lui dans l'un des répertoires
suivants&nbsp;:
	  <example compact="compact">
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly
	  </example>
Comme l'indique le nom de ces répertoires, les fichiers sont exécutés une 
fois par jour, une fois par semaine ou une fois par mois.
Le rythme exact est contenu dans <file>/etc/crontab</file>.
    </p>
	<p>
Tous les fichiers installés dans l'un de ces répertoires
doivent être des scripts (scripts shell, Perl, etc.)
pour que l'administrateur du système local puisse facilement les modifier.
De plus ils seront traités comme des fichiers de configuration.
</p>
<p>
Quand une tâche doit s'exécuter plus souvent
que quotidiennement, le paquet installera un fichier 
<tt>/etc/cron.d/<var>paquet</var></tt>. Ce fichier a la même 
syntaxe que le fichier <tt>/etc/crontab</tt> et est traité automatiquement
par <prgn>cron</prgn>. Il doit aussi être considéré comme un fichier de 
configuration. (On remarquera que le programme <prgn>anacron</prgn> ne se sert
pas des scripts dans le répertoire <tt>/etc/cron.d</tt>. Vous ne 
l'utiliserez donc que pour des tâches qui peuvent être omises si le système
ne tourne pas.)
</p>
	<p>

Les scripts ou les entrées de la «&nbsp;crontab&nbsp;» dans ces répertoires 
doivent vérifier d'abord la présence de tous les fichiers nécessaires à
leur exécution. Sinon, il y aura des problèmes avec les paquets 
qui ont été supprimés sans l'option «&nbsp;purge&nbsp;»,
car, dans ce cas, les fichiers de configuration sont conservés.
</p>
</sect>
	  
	  
      <sect id="menus">
	<heading>Les menus</heading>

	<p>
Le paquet Debian <tt>menu</tt> propose une interface standard entre les
paquets qui fournissent des applications et
<em>les programmes offrant des menus</em> (aussi bien des gestionnaires de
fenêtres sous X que des programmes qui fournissent des menus en mode
texte, comme par exemple <prgn>pdmenu</prgn>).
</p>
	  
	<p>
Les paquets renseigneront une rubrique de menu pour toutes les 
applications qui, pour leur usage normal, n'ont pas besoin 
de recevoir d'argument particulier depuis la ligne de commande.
Ainsi les utilisateurs du paquet <em>menu</em> auront automatiquement des 
rubriques de menu pour ces applications dans leurs 
gestionnaires de fenêtres et dans des shells comme <tt>pdmenu</tt>.
</p>
<p>
Les entrées de menu suivront les règles contenues dans le texte 
<tt>menu-policy</tt>.
	</p>
<p>
On peut trouver ces règles dans les fichiers <tt>menu-policy</tt> du paquet
<tt>debian-policy</tt>. Elles sont aussi disponibles sur les miroirs web de
Debian, 
<tt><url name="/doc/packaging-manuals/menu-policy/"
          id="https://www.debian.org/doc/packaging-manuals/menu-policy/"></tt>.
       </p>
	  
	<p>
Veuillez-vous référer au document <em>Debian Menu System</em>
livré avec le paquet <package>menu</package> pour plus d'informations
sur la manière de déclarer vos applications et vos documents web.
</p>
</sect>
	
      <sect id="mime">
	<heading>Outils pour le multimédia</heading>
	
	<p>
	  MIME (Multipurpose Internet Mail Extensions, RFC 2045-2049) est une
manière de coder les fichiers et les flux de données et de donner des
informations supplémentaires, telles que, par exemple, leur type (par exemple, 
audio ou vidéo) et leur format (par exemple, PNG, HTML, MP3).
	</p>
	
	<p>
La déclaration de la capacité à traiter les types «&nbsp;MIME&nbsp;» 
permet à des programmes comme les logiciels de courriers (MUA) ou les butineurs
web de faire appel à ces outils pour lire, éditer ou afficher les types 
«&nbsp;MIME&nbsp;» qu'ils ne reconnaissent pas directement.
	</p>
        <p>
Les paquets qui proposent des solutions pour lire, afficher, jouer, composer,
modifier ou imprimer les types «&nbsp;MIME&nbsp;» déclareront cette
capacité, et se conformeront ainsi à l'actuelle directive concernant
«&nbsp;MIME&nbsp;».
	</p>
        <p>
On peut trouver les règles concernant MIME dans le fichier 
<tt>mime-policy</tt> du paquet <tt>debian-policy</tt>. Elles sont aussi
disponibles sur les miroirs web de Debian, 
          <tt><url name="/doc/packaging-manuals/mime-policy/"
          id="https://www.debian.org/doc/packaging-manuals/mime-policy/"></tt>.
        </p>

      </sect>

      <sect>
	<heading>La configuration du clavier</heading>
	  
	<p>
Pour obtenir une configuration cohérente du clavier de façon que tous
les programmes interprètent les événements clavier de la même manière, 
tous les programmes de la distribution Debian doivent suivre les directives 
suivantes&nbsp;:
</p>
	  
	<p>
Les touches suivantes doivent être interprétées ainsi&nbsp;:
	  
	  <taglist>
	    <tag><tt>&lt;--</tt></tag>
	    <item><p>supprime le caractère à gauche du curseur</p></item>
		
	    <tag><tt>Delete</tt></tag>
	    <item><p>supprime le caractère à droite du curseur</p></item>
		
	    <tag><tt>Control+H</tt></tag>
	    <item><p>emacs : le préfixe d'aide</p></item>
	  </taglist>
	  
L'interprétation des événements clavier sera indépendante du terminal utilisé 
(la console, X Window, une session rlogin ou telnet, etc.).
</p>
	  
	<p>
La liste suivante explique comment les différents programmes
seront configurés pour y arriver&nbsp;:
</p>
	  
	<p>
	  <list>
	    <item><p><tt>&lt;--</tt> génère KB_BackSpace sous X.</p></item> 
		
	    <item><p><tt>Delete</tt> génère KB_Delete sous X.</p></item>
		
	    <item>
	      <p>
Le mécanisme «&nbsp;X translations&nbsp;» est configuré pour que 
<tt>KB_Backspace</tt> déclenche ASCII DEL et que <tt>KB_Delete</tt> déclenche 
<tt>ESC [ 3 ~</tt> (c'est la séquence d'échappement du vt220 pour la touche 
«&nbsp;delete character&nbsp;»). Il faut charger les ressources sur tous les 
serveurs locaux «&nbsp;X&nbsp;» à l'aide de <prgn>xrdb</prgn> et ne pas 
utiliser les valeurs par défaut des applications pour que les ressources de
translation correspondent aux choix de <prgn>xmodmap</prgn>.
</p>
</item>
		
	    <item>
	      <p>
	La console Linux est configurée pour que la touche <tt>&lt;--</tt>
déclenche DEL et <tt>Delete</tt> déclenche <tt>ESC [ 3 ~</tt>. 
</p></item>
	    <item><p>
Les applications X sont configurées pour que <tt>&lt;--</tt> efface 
à gauche et <tt>Delete</tt> efface à droite. Les applications Motif 
fonctionnent déjà de cette manière.
 </p>
</item>
		
	    <item><p>Les terminaux auront <tt>stty erase ^?</tt> .</p></item>
		
	    <item><p>
L'entrée <tt>xterm</tt> dans terminfo aura <tt>ESC [ 3~</tt> 
pour <tt>kdch1</tt>, tout comme <tt>TERM=linux</tt> et <tt>TERM=vt220</tt>.
 </p>
</item>	
		
	    <item><p>
Emacs est programmé pour associer <tt>KB_Backspace</tt> ou le caractère
<tt>stty erase</tt> à <tt>delete-backward-char</tt>. Il associe 
<tt>KB_Delete</tt> ou <tt>kdch1</tt> à <tt>delete-forward-char</tt> et 
associe <tt>^H</tt> à <tt>help</tt> comme toujours.
 </p>
</item>
		
	    <item><p>
D'autres applications utilisent le caractère <tt>stty erase</tt> et 
<tt>kdch1</tt> comme deux touches d'effacement. ASCII DEL est la 
«&nbsp;suppression du caractère précédent&nbsp;». <tt>kdch1</tt> est la 
«&nbsp;suppression du caractère sous le curseur&nbsp;».
 </p>
</item>
	  </list>
</p>
	  
	<p>
Tout cela résout le problème sauf dans les cas suivants&nbsp;:
	</p>
	  
	<p>
	  <list>
	    <item><p>
Certains terminaux ont une touche <tt>&lt;--</tt> qui ne peut pas
produire autre chose que <tt>^H</tt>. Sur ces terminaux l'aide
d'Emacs ne sera pas accessible à partir de <tt>^H</tt> (en supposant
que le caractère «&nbsp;stty erase&nbsp;» est prioritaire dans Emacs et qu'il 
ait été bien configuré). Les touches <tt>M-x help</tt> ou <tt>F1</tt> (si 
elles sont disponibles) peuvent être utilisées en remplacement.
 </p>
</item>
			
	    <item><p>
Certains systèmes utilisent <tt>^H</tt> pour <tt>stty erase</tt>. 
Cependant les versions modernes de <prgn>telnet</prgn> et toutes les versions
de <prgn>rlogin</prgn> diffusent les configurations <tt>stty</tt>. Presque
toutes les versions d'UNIX acceptent <tt>stty erase</tt>. Quand la 
configuration <tt>stty</tt> n'est pas reproduite correctement, on peut 
résoudre le problème en utilisant <tt>stty</tt> manuellement.
</p></item>
		
	    <item><p>
Certains systèmes (notamment des versions antérieures de Debian) utilisent
<prgn>xmodmap</prgn> pour que <tt>&lt;--</tt> et <tt>Delete</tt> 
déclenchent <tt>KB_Delete</tt>. Nous pouvons changer le comportement de 
leurs clients X à 
l'aide des mêmes ressources que nous avons utilisées ou bien 
configurer nos propres clients avec les ressources de ces systèmes dans le cas
inverse. Sur des serveurs configurés de cette manière, <tt>&lt;--</tt>
fonctionnera mais pas <tt>Delete</tt>.
 </p>
</item>
		
	    <item><p>
Certains systèmes d'exploitation ont d'autres configurations pour 
<tt>kdch1</tt> dans leur base de données <tt>terminfo</tt> pour <tt>xterm</tt>
et consort. Sur ces systèmes, la touche <tt>Delete</tt> ne fonctionnera pas 
quand vous vous connecterez depuis un système qui suit notre politique. Mais 
<tt>&lt;--</tt> fonctionnera.
 </p>
</item>
</list>
</p>
</sect>
	  
      <sect>
	<heading>Les variables d'environnement</heading>
	  
	<p>
Un programme ne doit pas dépendre des variables d'environnement
pour déterminer des valeurs par défaut&nbsp;;
cela impliquerait de définir ces variables globalement au niveau
du système par exemple dans <file>/etc/profile</file>, ce que tous les shells 
ne permettent pas.
</p>
	<p>
Quand un programme dépend de variables d'environnement
pour sa configuration, il doit prévoir, en leur absence, une configuration
raisonnable par défaut.
Si c'est difficile à faire (p. ex. quand le code source d'un programme non 
libre n'est pas disponible), le programme doit être remplacé par un petit 
script shell enveloppant («&nbsp;wrapper&nbsp;») qui positionne les variables 
d'environnement et appelle le programme initial.
</p>
	<p>
Voici un exemple de script enveloppant écrit dans ce but&nbsp;:
	  
	  <example compact="compact">
#!/bin/sh
BAR=${BAR:-/var/lib/fubar}
export BAR
exec /usr/lib/foo/foo "$@"
          </example></p>
	  
	<p>
De plus, comme <file>/etc/profile</file> est un fichier de configuration
du paquet <prgn>bash</prgn>, aucun autre paquet ne peut y ajouter
des variables d'environnement ou des commandes.
</p>
</sect>

      <sect id="doc-base">
        <heading>Enregistrer des documents avec doc-base</heading>

        <p>
 Le paquet <package>doc-base</package> implémente un mécanisme souple
pour la gestion et la présentation de la documentation. Il est recommandé
que chaque paquet Debian enregistre les documents qu'il fournit (autres que
les pages du manuel) avec <package>doc-base</package>, en installant un
fichier de contrôle <package>doc-base</package> grâce aux scripts
<prgn>install-docs</prgn>. Cela se fait au moment de l'installation et lors
de la suppression du paquet, l'enregistrement des documents est supprimé.
        </p>
      <p>
Veuillez vous reporter à la documentation du paquet 
<package>doc-base</package> pour des précisions.
        </p>
      </sect>


</chapt>

    <chapt id="files">
	<heading>Les fichiers</heading>
	  
	
	<sect>
	  <heading>Les fichiers binaires</heading>
	    
	  <p>
Deux paquets ne doivent pas installer des programmes qui ont des
fonctions différentes tout en ayant le même nom.
Le cas de deux programmes avec les mêmes fonctionnalités
mais des implémentations différentes est traité <em>via</em> 
«&nbsp;alternatives&nbsp;» ou par le mécanisme «&nbsp;Conflicts&nbsp;». Voir
<ref id="maintscripts"> et <ref id="conflicts">.
Si ce cas se produit, un des deux programmes doit changer de nom.
Les responsables rapporteront ce problème sur la liste de distribution
<tt>debian-devel</tt> pour essayer de trouver un consensus. Si aucun 
consensus n'est trouvé, le nom des <em>deux</em> programmes doit être 
changé.
</p>
	    
	  <p>
Par défaut, lors de la construction d'un paquet, tous les binaires créés
incluront des informations pour le débogage et seront compilés avec 
optimisation. Vous mettrez aussi tous les avertissements de compilation
qui vous semblent raisonnables&nbsp;: cela facilite la vie des responsables
de portage qui peuvent consulter les journaux de construction en cas de
problèmes. Pour le cas de la programmation en C, 
on utilisera les paramètres de compilation suivants&nbsp;:
              <example compact="compact">
CC = gcc 
CFLAGS = -O2 -g -Wall # les bonnes options peuvent différer selon les programmes 
LDFLAGS = # aucun 
INSTALL = install -s # (ou bien utiliser strip sur les fichiers dans debian/tmp)
             </example>
</p>
	  <p>
On remarquera que tous les binaires installés sont épurés de tout
symbole, soit en utilisant l'option <tt>-s</tt> de <prgn>install</prgn>,
soit en appliquant le programme <prgn>strip</prgn> sur les binaires
après qu'ils ont été copiés dans <tt>debian/tmp</tt> mais avant
qu'une arborescence ne soit faite pour le paquet.
</p>
<p>
Bien que les binaires dans l'arbre de construction soient compilés par 
défaut avec des informations pour le débogage, il est souvent difficile de
déboguer les programmes qui sont soumis à des optimisations pour compilateur.
Pour cette raison, il est conseillé de reconnaître la variable d'environnement
standard <tt>DEB_BUILD_OPTIONS</tt>. Cette variable peut contenir plusieurs
drapeaux de manière à pouvoir modifier la construction et la compilation
d'un paquet.
	</p>
       <p>
         <taglist>
           <tag>noopt</tag>
           <item>
             <p>
La présence de cette chaîne signifie que le paquet ne sera soumis qu'à un
minimum d'optimisation. Pour les programmes en C, il vaut mieux ajouter
<tt>-O0</tt> à <tt>CFLAGS</tt> (bien que ce soit la valeur par défaut). Il peut
arriver que quelques programmes ne se construisent pas ou ne fonctionnent pas
à ce niveau d'optimisation&nbsp;: il peut être nécessaire, par exemple, 
d'utiliser <tt>-O1</tt>.
             </p>
           </item>
           <tag>nostrip</tag>
           <item>
             <p>
Cette chaîne signifie que les symboles de débogage ne seront pas enlevés
du binaire pendant l'installation de manière à ce que les informations
pour le débogage puissent être incluses dans le paquet.
             </p>
           </item>
         </taglist>
	</p>
<p>
Le petit makefile suivant explique comment implémenter les options de 
construction&nbsp;; vous aurez sans doute à l'adapter aux conditions de votre 
paquet. 
             <example compact="compact">
CFLAGS = -Wall -g
INSTALL = install
INSTALL_FILE    = $(INSTALL) -p    -o root -g root  -m  644
INSTALL_PROGRAM = $(INSTALL) -p    -o root -g root  -m  755
INSTALL_SCRIPT  = $(INSTALL) -p    -o root -g root  -m  755
INSTALL_DIR     = $(INSTALL) -p -d -o root -g root  -m  755

ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
endif
           </example>
	</p>  
<p>
C'est au responsable du paquet de décider des meilleures options
de compilation. Certains binaires (comme ceux qui font des 
calculs intensifs) fonctionnent mieux avec certaines options 
(p. ex. <tt>-O3</tt>)&nbsp;; faites comme vous voulez. Utilisez ces options avec 
discernement&nbsp;: pour de bonnes raisons, pas seulement pour elles-mêmes.
Ne craignez pas de remplacer les options qu'avait choisies l'auteur du 
programme original&nbsp;: elles sont souvent inappropriées dans votre environnement.
</p>
</sect>
	    
	<sect id="libraries">
	  <heading>Les bibliothèques</heading>

        <p>
Si le paquet est <strong>architecture: any</strong>, alors les options de
compilation et de liaison de la bibliothèque partagée doivent inclure
<tt>-fPIC</tt>, sinon le paquet ne se construira pas sur certaines des
architectures prises en charge<footnote>
            <p>
              Si vous utilisez GCC, <tt>-fPIC</tt> produira du code avec du code
              indépendant de la position relogeable, ce qui est nécessaire pour
              la plupart des architectures pour créer une bibliothèque partagée,
              avec i386 et peut-être quelques autres où le code non indépendant
              de la position est permis dans une bibliothèque partagée..
            </p>
            <p>
              Le code indépendant de la position peut avoir un impact négatif
              sur les performance, en particulier sur <tt>i386</tt>. Cependant,
              dans la plupart des cas, la perte de performance doit être mesurée
              par rapport à la mémoire gaspillée sur les quelques architectures
              où du code non indépendant de la position est même possible.
            </p>
</footnote>. Toute exception à cette règle doit être discutée sur la liste de
diffusion <em>debian-devel@lists.debian.org</em> et un consensus général
obtenu. Les raisons pour ne pas compiler avec l'option <tt>-fPIC</tt> doivent
être notifiées dans un fichier <tt>README.Debian</tt> et une attention
particulière doit être prise pour restreindre l'architecture ou pour s'arranger
pour que <tt>-fPIC</tt> soit utilisé sur les architectures où cela est
nécessaire.<footnote>
            <p>
              Parmi les raisons pour lesquelles ceci peut être nécessaire, la
              bibliothèque peut contenir du code assembleur écrit manuellement
              qui n'est pas relogeable, l'impact de performance peut être
              excessif pour des bibltiohèques de calcul intensif et des raisons
              similaires.
            </p>
          </footnote>
        </p>
	<p>
Pour les bibliothèques statiques, le cas général est de ne pas avoir de code
relogeable car il n'y a pas de bénéfice sauf dans des cas spécifiques&nbsp;;
c'est pourquoi la version statique ne doit pas être compilée avec l'option
<tt>-fPIC</tt>. Toute exception à cette règle doit être discutée sur la liste de
diffusion <em>debian-devel@lists.debian.org</em> et les raisons pour compiler
avec l'option <tt>-fPIC</tt> doivent être notifiées dans le fichier
<tt>README.Debian</tt>. <footnote>
            <p>
Parmi les raisons pour lier des bibliothèques statiques avec l'option
<tt>-fPIC</tt>, par exemple, on peut avoir besoin d'une API Perl pour une
bibliothèque en développement rapide et qui a une API instable, des
bibliothèques partagées sont alors sans intérêt à ce moment du développement de
la bibliothèque. Dans ce cas, comme perl a besoin d'une bibliothèque avec du
code relogeable, il peut y avoir un intérêt de créer une bibliothèque statique
avec du code relogeable. Une autre raison citée est si vous distillez plusieurs
bibliothèques dans une bibliothèque partagée commune comme le fait
<tt>mklibs</tt> dans le projet de l'installateur Debian.
            </p>
          </footnote>
	</p>
        <p>
En d'autres mots, si à la fois une bibliothèque partagée et une bibliothèque
statique sont à construire, chaque source (fichiers <tt>*.c</tt> pour
les sources C, par exemple) devra être compilé deux fois dans le cas normal.
        </p>

	  <p>
Vous devez indiquer l'option <tt>-D_REENTRANT</tt> de <prgn>gcc</prgn>
quand vous compilez une bibliothèque (statique ou dynamique) pour qu'elle
soit compatible avec les <em>threads</em> Linux.
</p>
        <p>
Bien que les outils de construction ne respectent pas cette règle, les
bibliothèques partagées, tout comme les binaires, doivent être liées à toute 
bibliothèque dont elles utilisent les symboles. Cela permet le bon 
fonctionnement du système <qref id="sharedlibs-shlibdeps">shlibs</qref> et
cela garantit que toutes les bibliothèques peuvent être ouvertes avec
<tt>dlopen()</tt>. Les responsables de paquet peuvent utiliser gcc avec
l'option <tt>-Wl,-z,defs</tt> lors de la construction d'une bibliothèque 
partagée. Cette option effectuant la résolution des symboles au moment de
la construction, une référence à une bibliothèque manquante sera rapidement
transformée en erreur fatale.
        </p>

	  <p>
Toutes les bibliothèques partagées qu'on installe seront épurées de tout 
symbole par :
	    <example compact="compact">
strip --strip-unneeded <var>votre-bibliothèque</var>
	    </example> 
L'option <tt>--strip-unneeded</tt> fait que <prgn>strip</prgn> enlève 
uniquement les symboles qui ne sont pas utiles au mécanisme de réallocation.
Les bibliothèques partagées fonctionnent parfaitement bien quand elles
sont épurées, car les symboles de liens dynamiques
sont dans une autre partie du fichier objet «&nbsp;ELF&nbsp;» <footnote> <p>
Vous pourriez aussi utiliser les options <tt>--remove-section=.comment</tt> et
<tt>--remove-section=.note</tt> sur les bibliothèques partagées et sur les
exécutables, et l'option <tt>--strip-debug</tt> sur les bibliothèques 
statiques.
            </p>
</footnote>.
</p>

	  <p>
Il faut noter que dans certaines circonstances, il peut être utile d'installer
une bibliothèque non épurée, p. ex. pour la construction d'un paquet d'aide au 
débogage.
</p>
<p>
Les fichiers objet partagés (comme les fichiers <file>.so</file>) qui ne sont
pas des bibliothèques publiques, c'est-à-dire que des exécutables tiers (les
binaires d'autres paquets) ne peuvent s'y lier, seront installés dans des
sous-répertoires de <tt>/usr/lib</tt>. De tels fichiers n'ont pas à se plier
aux règles qui gouvernent les bibliothèques partagées ordinaires&nbsp;; mais
ils ne doivent pas être exécutables et seront épurés <footnote>
<p>
Les «&nbsp;plug-ins&nbsp;», ces objets internes partagés, chargés 
dynamiquement par des programmes en utilisant 
<manref name="dlopen" section="3">, en sont un exemple.
	    </p>
	  </footnote>.
</p>	
<p>
Les paquets contenant des bibliothèques partagées qui peuvent être liées à
d'autres binaires mais qui, pour quelque raison <em>contraignante</em>, ne
peuvent être installées dans le répertoire <tt>/usr/lib</tt>, peuvent
installer les bibliothèques partagées dans des sous-répertoires de
<tt>/usr/lib</tt>&nbsp;; dans ce cas, ils ajouteront ce répertoire dans
<tt>/etc/ld.so.conf</tt> avec le script de <em>post-installation</em> du
paquet et le supprimeront avec le script de <em>post-removal</em>.
	</p>

	<p>
Un nombre toujours croissant de paquets utilisent <prgn>libtool</prgn> pour 
l'édition de liens. La plus récente version de «&nbsp;GNU libtools 
(&gt;= 1.3a)&nbsp;» peut se servir avantageusement des meta-données contenues 
dans les fichiers (<tt>*.la</tt>) de <prgn>libtool</prgn>. Le principal
avantage de ces fichiers est que <prgn>libtool</prgn> peut conserver ces 
meta-données et donc y accéder en fonction des bibliothèques qu'il construit. 
<prgn>Libtool</prgn> cherche ces fichiers et les renseignements
utiles qu'ils contiennent à propos des bibliothèques (p. ex. les bibliothèques 
nécessaires pour une édition de liens statiques). Ils sont aussi 
<em>indispensables</em> aux programmes utilisant <tt>libltdl</tt> <footnote>
<p>
Sans doute, <prgn>libtool</prgn> peut faire de l'édition de liens avec des 
bibliothèques qui n'ont pas de fichier <tt>.la</tt>&nbsp;; mais, n'étant qu'un 
simple script shell, il peut augmenter considérablement le temps de 
compilation d'un paquet s'il doit, pour chaque bibliothèque et chaque 
fois qu'elle est liée, déduire tous ces renseignements des premiers principes.
Avec l'apparition de «<prgn>libtool-1.4</prgn> (et dans une moindre mesure de 
<prgn>libtool-1.3</prgn>), les fichiers <tt>.la</tt> gardent des 
renseignements sur les dépendances entre bibliothèques qui ne peuvent pas 
être nécessairement déduits une fois détruit le fichier <tt>.la</tt>.
	</p>
	  </footnote>.
    </p>
	<p>
Les paquets qui se servent de <prgn>libtool</prgn> pour créer des 
bibliothèques partagées mettront les fichiers <tt>.la</tt> dans les 
paquets <tt>-dev</tt>&nbsp;; dans le cas où un paquet compte sur la bibliothèque
<tt>libltdl</tt> de <prgn>libtool</prgn>, les fichiers <tt>.la</tt> iront dans
le paquet de la bibliothèque. 
	</p>
	
	<p>
Vous devez vous assurer que vous n'utilisez que les versions diffusées des 
bibliothèques partagées pour construire vos paquets&nbsp;; dans le cas 
contraire, les autres utilisateurs ne pourront pas exécuter vos binaires 
correctement. Produire des paquets sources qui dépendent de compilateurs
non diffusés est habituellement une mauvaise idée.
</p>
</sect>
	<sect>
	  <heading>Les bibliothèques partagées</heading>

<p>
Cette section a été déplacée dans <ref id="sharedlibs">.
	</p>
</sect>
	    
	<sect id="scripts">
	  <heading>Les scripts</heading>
	    
	  <p>
Tous les scripts de commandes, y compris les scripts inclus dans un paquet 
par le responsable et utilisés par <prgn>dpkg</prgn>, commenceront 
par <tt>#!</tt> et le nom du shell interpréteur.
</p>
	    
	  <p>
Pour les scripts Perl, c'est <tt>#!/usr/bin/perl</tt>.</p>

        <p>
Quand des scripts sont installés dans un répertoire du PATH système, le nom du
script ne devrait pas inclure d'extension comme <tt>.sh</tt> ou <tt>.pl</tt>
indiquant le langage de programmation actuellement utilisé pour l'implémenter.
        </p>
	    
	  <p>
Les scripts shell (<prgn>sh</prgn> et <prgn>bash</prgn>) commenceront presque 
systématiquement par <tt>set -e</tt> pour que les erreurs soient 
détectées. Tous les scripts utiliseront <tt>set -e</tt> ou 
vérifieront l'état de sortie de <em>toutes</em> les commandes.
</p>
	    
	  <p>
L'interpréteur shell de base <tt>/bin/sh</tt> peut être
un lien symbolique vers n'importe quel shell compatible POSIX, si 
<tt>echo -n</tt> ne produit pas une nouvelle ligne <footnote><p>
La charte Debian indique que <tt>/bin/sh</tt> suit la norme POSIX, mais
<tt>echo -n</tt> est largement utilisé dans la communauté Linux (dans cette 
charte, dans les sources du noyau Linux, dans beaucoup de scripts Debian, 
etc.). Ce mécanisme est valable mais n'est pas demandé par POSIX,
d'où cet ajout explicite. D'autre part, la rumeur dit que ce mécanisme
doit devenir de toute façon obligatoire dans la LSB.</p></footnote>. 
Les scripts shell indiquant <tt>/bin/sh</tt> comme interpréteur ne doivent donc
utiliser  que des caractéristiques POSIX. Si un script a besoin des 
caractéristiques non-POSIX d'un interpréteur, celui-ci doit être spécifié 
dans la première ligne du script (par exemple <tt>#!/bin/bash</tt>). Son paquet
doit dépendre du paquet qui fournit le shell (à moins que le
paquet ne soit marqué «&nbsp;Essential&nbsp;», comme par exemple pour
<prgn>bash</prgn>).
</p>
	  <p>
Quand c'est possible, on peut vouloir limiter les scripts aux 
caractéristiques POSIX de manière à utiliser l'interpréteur 
<file>/bin/sh</file>. Si votre script fonctionne avec <prgn>dash</prgn> 
(anciennement <prgn>ash</prgn>), il est probablement 
conforme à POSIX, mais en cas de doute, utilisez <tt>/bin/bash</tt>.
</p>
	  <p>
Les scripts Perl détecteront les erreurs survenant lors de tous les 
appels système, comme <tt>open</tt>, <tt>print</tt>, <tt>close</tt>, 
<tt>rename</tt> et <tt>system</tt>.
</p>
<p>
Les shells <prgn>csh</prgn> et <prgn>tcsh</prgn> seront évités comme langage 
de script. Référez-vous au
document <em>Csh Programming Considered Harmful</em> (Pourquoi
programmer en Csh est risqué), l'une des FAQ du groupe
usenet <tt>comp.unix.*</tt>. Il peut être trouvé sur
<url id="http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/">.
Si un paquet original utilise des scripts <prgn>csh</prgn>
vous devez vous assurer qu'ils commencent par
<tt>#!/bin/csh</tt> et vous devez rendre votre paquet
dépendant du paquet virtuel <prgn>c-shell</prgn>.
</p>
	  <p>
Tout script qui crée des fichiers dans des répertoires où tout le monde peut 
écrire, (p. ex. dans <tt>/tmp</tt>) doit utiliser un mécanisme qui 
provoquera une erreur de façon atomique si un fichier de même nom existe déjà.
</p>
	    
	  <p>
À cet usage, le système Debian de base fournit
les utilitaires <prgn>tempfile</prgn> et <prgn>mktemp</prgn>.
</p></sect>
	    
	<sect>
	  <heading>Les liens symboliques</heading>
	    
	  <p>
En général, les liens symboliques à l'intérieur d'un répertoire de premier 
niveau seront relatifs alors que les liens symboliques qui pointent 
d'un répertoire de premier niveau vers un autre répertoire de premier niveau 
seront absolus. Un répertoire de premier niveau est un sous-répertoire
du répertoire racine <tt>/</tt>.
</p>

	  <p>
De plus, les liens symboliques doivent utiliser un nom de chemin le plus 
court possible&nbsp;; on évitera par exemple le chemin <tt>foo/../bar</tt>.
</p>
	  <p>
On remarquera que pour créer un lien relatif avec <prgn>ln</prgn>,
il n'est pas nécessaire que le fichier cible soit relatif au répertoire où est 
exécuté <prgn>ln</prgn>&nbsp;; de même il n'est pas nécessaire de se déplacer dans 
le répertoire où vous désirez créer le lien.
Donnez simplement à <prgn>ln</prgn> comme premier argument
la chaîne de caractères qui représentera la cible du lien (cette
chaîne doit être un chemin relatif au répertoire contenant le lien).
</p>
	  <p>
Par exemple, dans votre <prgn>Makefile</prgn> ou
dans <tt>debian/rules</tt>, vous pouvez écrire&nbsp;:
	    <example compact="compact">
ln -fs gcc $(prefix)/bin/cc 
ln -fs gcc debian/tmp/usr/bin/cc 
ln -fs ../sbin/sendmail $(prefix)/bin/runq 
ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
	    </example></p>
	    
	  <p>
Un lien symbolique vers un fichier comprimé aura toujours
le même suffixe que le fichier référencé.
(Par exemple, si le fichier <tt>foo.gz</tt> est
référencé par un lien symbolique, le nom du lien doit
aussi se terminer par «&nbsp;<tt>.gz</tt>&nbsp;», comme par exemple
<tt>bar.gz</tt>.)
</p>
</sect>
	    
	<sect>
	  <heading>Les fichiers de périphérique</heading>
	    
	  <p>
Un paquet ne doit pas contenir de fichiers de périphérique
dans son arborescence.
</p>
	  <p>
Si un paquet a besoin d'un fichier de périphérique particulier
qui n'est pas inclus dans le système de base, il doit
appeler <prgn>MAKEDEV</prgn> dans le script <prgn>postinst</prgn>,
après avoir prévenu l'utilisateur <footnote>
           <p>
On peut prévenir l'utilisateur par un message de debconf dont la
priorité sera basse, ou bien par un <em>echo</em> (printf).
	    </p>
         </footnote>.
</p>
	  <p>
Un paquet ne doit pas supprimer de fichier de périphérique
dans le script <prgn>postrm</prgn> ou dans un autre script.
Ceci doit être laissé à l'initiative de l'administrateur système.
</p>
	  <p>
Debian utilise les périphériques série <tt>/dev/ttyS*</tt>. Les programmes qui 
utilisent les anciens périphériques <tt>/dev/cu*</tt> seront
modifiés pour utiliser <tt>/dev/ttyS*</tt>.
</p>
      </sect>
	    
      <sect id="config-files">
	  <heading>Les fichiers de configuration</heading>
	<sect1>
	  <heading>Définitions</heading>
	  <p>
	    <taglist>
	      <tag>fichier de configuration</tag>
	      <item><p>
C'est un fichier qui influe sur le fonctionnement d'un programme,
ou bien qui donne des renseignements particuliers à un site ou à un
hôte, autrement dit un fichier qui singularise le comportement d'un programme.
Classiquement, les fichiers de configuration sont faits pour être modifiés
par l'administrateur système (s'il en a besoin ou s'il le souhaite) de
manière à se conformer aux règles locales ou bien à obtenir un
fonctionnement plus utile au site.
</p>
              </item>


	      <tag><tt>conffile</tt></tag>
	      <item><p>
C'est un fichier répertorié dans le fichier <tt>conffiles</tt>
d'un paquet&nbsp;; <prgn>dpkg</prgn> en fait un usage particulier
(voir <ref id="configdetails">).
</p>
              </item>
            </taglist>
	  </p>

	  <p>
Cette distinction est importante&nbsp;: ce ne sont pas des concepts
interchangeables. Presque tous les <tt>conffile</tt>s sont des fichiers de
configuration, mais beaucoup de fichiers de configuration ne sont pas des
<tt>conffiles</tt>.

	 </p>
 <p>
Il faut noter que les scripts qui renferment des informations de configuration
(ainsi la plupart des fichiers de <tt>/etc/default</tt> et de
<tt>/etc/cron.{daily,weekly,monthly}</tt>) sont <em>de facto</em> des 
fichiers de configuration et seront traités comme tels.
</p>
	</sect1>
<sect1>
<heading>Emplacement</heading>

<p>
Tout fichier de configuration créé ou utilisé par un paquet doit se trouver
dans le répertoire <file>/etc</file>. S'ils sont nombreux, on envisagera la
création d'un sous-répertoire de <file>/etc</file> qu'on nommera d'après le
le nom du paquet.
</p>
<p>
Quand un paquet crée ou utilise des fichiers de configuration qui ne sont
pas dans <file>/etc</file> et qu'il n'est pas facile de modifier ce programme
pour qu'il utilise <file>/etc</file>, on mettra quand même les fichiers dans
<file>/etc</file> et on créera des liens symboliques vers ces fichiers depuis
les emplacements voulus par le paquet.
	  </p>
	</sect1>
<sect1>
<heading>Comportement</heading>
<p>
La gestion des fichiers de configuration doit se conformer aux principes
suivants&nbsp;:
<list compact="compact">
              <item>
                <p>
les changements locaux doivent être préservés pendant
la mise à jour d'un paquet&nbsp;;
</p>
              </item>
              <item>
                <p>
les  fichiers de configuration doivent être préservés quand le paquet est 
supprimé&nbsp;; ils ne sont détruits que si le paquet est
supprimé avec «&nbsp;purge&nbsp;».
</p>
          </item>
            </list>
</p>
<p>
La façon simple d'obtenir cela, c'est que le fichier de configuration soit
un <tt>conffile</tt>. C'est parfait quand on peut distribuer une version par
défaut qui marche pour la plupart des installations, bien que quelques
administrateurs puissent vouloir la modifier. Cela suppose que la version par
défaut fasse partie du paquet et que les scripts du responsable du paquet
ne la modifient pas pendant l'installation (ou à quelque autre moment).
</p>
<p>
Pour faire que les changements locaux soient préservés correctement, nul
paquet ne peut contenir des liens «&nbsp;en dur&nbsp;», ou en créer, vers des
«&nbsp;conffiles&nbsp;»<footnote><p>
Argument : Il y a deux problèmes avec les liens «&nbsp;en dur&nbsp;». Le 
premier, c'est que certains «&nbsp;éditeurs&nbsp;» cassent le lien quand ils 
modifient l'un des fichiers,
et les deux fichiers peuvent devenir involontairement différents. Le second,
c'est qu'il arrive que <prgn>dpkg</prgn> casse le lien pendant une mise à
jour de <tt>conffile</tt>s.</p>
          </footnote>.
	  </p>
<p>
L'autre façon, c'est d'utiliser les scripts du responsable de paquet.
Dans ce cas, le fichier de configuration ne doit pas être un <tt>conffile</tt>
et ne doit pas faire partie du paquet. Si la configuration correcte d'un paquet
demande un fichier, c'est au responsable du paquet,
<em>via</em> ses scripts, de créer, mettre à jour, maintenir et supprimer un 
tel fichier. Voir <ref id="maintainerscripts"> pour des précisions. Ces 
scripts doivent être idempotents (c.-à-d. qu'ils doivent fonctionner
correctement si <prgn>dpkg</prgn> a besoin de les relancer à cause d'erreurs
survenues pendant l'installation ou la suppression)&nbsp;; ils doivent
comprendre toutes les manières de <prgn>dpkg</prgn> en ce qui
concerne l'appel des scripts&nbsp;; ils ne doivent pas remplacer ou même
déformer la configuration de l'utilisateur sans lui demander&nbsp;; ils ne
doivent pas poser des questions sans intérêt (surtout pendant les mises à
jour)&nbsp;; bref, ils doivent être de bons citoyens.
</p>
<p>
Ces scripts n'ont pas à configurer toutes les options possibles d'un paquet,
mais seulement celles qui sont nécessaires à son bon fonctionnement sur un
système donné. Idéalement, un sysadmin ne devrait faire aucune autre
configuration que celle faite presque automatiquement par le script
<tt>postinst</tt>.
</p>
<p>
Une manière commune de faire est de créer un script
<file><var>paquet</var>-configure</file> qu'appellera le script 
<prgn>postinst</prgn> du paquet si et seulement si le fichier de 
configuration n'existe pas déjà.
Parfois, il est bon d'avoir un fichier d'exemple ou un fichier modèle
utilisable par les scripts du responsable. On mettra ces fichiers
dans <file>/usr/share/<var>paquet</var></file> ou dans 
<file>/usr/lib/<var>paquet</var></file> (selon qu'ils sont dépendants d'une
architecture ou non). On créera des liens symboliques vers ces fichiers dans
<file>/usr/share/doc/<var>paquet</var>/examples</file> si ce sont des fichiers
d'exemples&nbsp;; ces fichiers sont des fichiers parfaitement ordinaires pour
<prgn>dpkg</prgn> (ce <em>ne sont pas</em> des fichiers de configuration).
</p>
          <p>
On ne doit pas mélanger ces deux manières de gérer les fichiers de
configuration car alors la folie guette&nbsp;: <prgn>dpkg</prgn> voudra
remplacer le fichier à chaque mise à jour du paquet.
</p>
        </sect1>

<sect1>
          <heading>Partager des fichiers de configuration </heading>
          <p>
On doit indiquer un <em>conflit</em> entre des paquets qui ont le même
fichier <tt>conffile</tt>. C'est une application de la règle générale qui veut
qu'on ne partage pas des fichiers. Ni les <em>alternatives</em> ni les 
<em>diversions</em> ne sont appropriés dans ce cas&nbsp;; en particulier, 
<prgn>dpkg</prgn> ne gère pas bien les <tt>conffile</tt>s déviés (diverted).
	  </p>
	  <p>
Les scripts d'un responsable de paquet ne doivent modifier le 
<tt>conffile</tt> d'<em>aucun</em> paquet, même celui du paquet auquel ils
appartiennent.</p>

	  <p>
Quand deux paquets ou plus ont le même fichier de configuration et qu'il est
raisonnable d'installer les deux paquets, on doit définir l'un des
paquets comme le <em>propriétaire</em> du fichier de configuration, et
ce sera le paquet qui gère ce fichier comme un fichier de configuration. Les 
autres paquets qui utilisent le fichier de configuration doivent déclarer une 
dépendance envers ce paquet s'ils ont besoin de ce fichier de configuration 
pour leur fonctionnement. Quand
ils ne l'utilisent que s'il est présent et qu'ils sont capables de
fonctionner sans lui, ces paquets n'ont pas besoin de déclarer de
dépendance.</p>

	  <p>
Si l'on veut que deux ou plusieurs paquets apparentés partagent un fichier de
configuration <em>et</em> que chacun d'eux soit capable de le modifier, il
faut faire ce qui suit&nbsp;:

	    <enumlist compact="compact">
	      <item>
		<p>
L'un des paquets apparentés (le paquet «&nbsp;propriétaire&nbsp;») doit gérer 
le fichier de
configuration avec les scripts du responsable de paquet comme il est décrit
dans les sections précédentes ;</p>
	      </item>
	      <item><p>
le paquet «&nbsp;propriétaire&nbsp;» fournira aussi un programme que les 
autres paquets utiliseront pour modifier le fichier de configuration&nbsp;;</p>
	      </item>
	      <item>
		<p>
les paquets apparentés doivent se servir de ce programme pour faire
les modifications voulues sur le fichier de configuration. Ils dépendront alors
de la garantie donnée quant à la disponibilité de ce programme, 
ou bien ils accepteront avec élégance de ne pouvoir modifier 
le fichier de configuration si ce programme n'est pas disponible. C'est une
addition au fait que le fichier de configuration pourrait même ne pas
exister dans ce dernier scénario.
</p>
	      </item>
	    </enumlist></p>
	  <p>
Quelques fois, il convient de créer un nouveau paquet qui fournit
l'infrastructure de base pour les autres paquets et qui gère les fichiers
de configuration partagés (on peut consulter le paquet <tt>sgml-base</tt>
comme exemple).</p>
	</sect1>

	<sect1>
	  <heading>Les fichiers de configuration de l'utilisateur («&nbsp;dotfiles&nbsp;»)</heading>

	  <p>
Les fichiers dans <file>/etc/skel</file> sont copiés automatiquement dans les 
comptes des nouveaux utilisateurs par <prgn>adduser</prgn>. Aucun programme
ne devra référencer les fichiers dans <file>/etc/skel</file>.
</p>

	  <p>
Ainsi, quand un programme, pour fonctionner correctement, a besoin
qu'un fichier «&nbsp;.fichier&nbsp;» existe par avance dans <tt>$HOME</tt>, 
le paquet installera ce fichier dans <file>/etc/skel</file> et le 
traitera comme un fichier de configuration.
</p>

	  <p>
Cependant, avoir un programme qui, pour fonctionner correctement, a besoin 
de fichiers «&nbsp;.fichier&nbsp;» est une mauvaise idée, à moins que ce 
programme ne crée automatiquement ces fichiers.
	  </p>
<p>L'installation par défaut de Debian
devrait configurer les programmes d'une manière aussi proche que possible de
la configuration originelle par défaut.
</p>
	  <p>
Ainsi, le programme d'un paquet Debian, qui a besoin d'une quelconque
configuration pour fonctionner correctement, sera configuré globalement pour 
le système à l'aide d'un fichier placé dans <file>/etc</file>. C'est 
uniquement 
dans le cas où le programme n'accepte pas de configuration globale au site, 
et si le responsable du paquet n'a pas le temps d'ajouter un fichier de 
configuration par défaut, qu'un tel fichier pourra être placé dans 
<file>/etc/skel</file>.
</p>
	  <p>
<file>/etc/skel</file> sera aussi vide que possible. C'est d'autant plus 
nécessaire qu'il n'existe pas de mécanisme simple (ou même désirable) pour 
s'assurer que les 
fichiers «&nbsp;.fichier&nbsp;» nécessaires sont copiés dans les comptes des 
utilisateurs existants à l'installation du paquet.
</p>

	</sect1>
      </sect>
      
      <sect>
	<heading>Les fichiers-journaux («&nbsp;log file&nbsp;»)</heading>

	<p>
Les fichiers-journaux se nomment habituellement
<tt>/var/log/<var>paquet</var>.log</tt>. Si vous avez de nombreux 
fichiers-journaux ou si vous avez besoin d'un répertoire pour des raisons de 
droits 
(<tt>/var/log</tt> ne peut être modifié que par <tt>root</tt>), vous créerez 
habituellement un répertoire nommé <tt>/var/log/<var>paquet</var></tt> où
vous mettrez ces fichiers.
</p>
	<p>
Une rotation des fichiers-journaux doit être assurée de manière qu'ils
ne grandissent pas indéfiniment&nbsp;;
la meilleure façon de procéder est de mettre un fichier de configuration pour 
la rotation des fichiers dans le répertoire <tt>/etc/logrotate.d</tt> et 
d'utiliser les facilités apportées par <em>logrotate</em> <footnote>
<p>
L'approche traditionnelle pour les fichiers-journaux était d'utiliser 
«&nbsp;cron&nbsp;» et de simples scripts shell pour monter des combines 
<em>ad hoc</em> pour la rotation des fichiers. Cette 
approche, grandement paramétrable, demandait beaucoup de travail à
l'administrateur système. Bien que le premier système Debian ait apporté une 
aide en installant automatiquement un système qui pouvait être pris 
comme modèle, cela ne fut pas considéré comme suffisant.
</p>  
	<p>
Une meilleure idée est d'utiliser <prgn>logrotate</prgn>, un programme 
développé par Red Hat, qui centralise la gestion des fichiers-journaux. Il 
possède à la fois un fichier de configuration 
(<tt>/etc/logrotate.conf</tt>) et un répertoire où les paquets peuvent 
déposer leurs configurations pour la rotation des fichiers, 
(<tt>/etc/logrotate.d</tt>).
        </p>
</footnote>.
Voici un bon exemple de fichier de configuration de «&nbsp;logrotate&nbsp;» 
(pour plus de renseignements voir <manref name="logrotate " section="8">)&nbsp;:
	  <example compact="compact">
/var/log/foo/*.log {
rotate 12
weekly
compress
postrotate
/etc/init.d/foo force-reload
endscript
}
	  </example> 	  
	  Cela fait tourner tous les fichiers sous <tt>/var/log/foo</tt>, 
sauve 12 compressions, et demande au démon de recharger ses informations de
configuration après la rotation des fichiers.
	</p>
	
	<p>
Les fichiers-journaux seront supprimés quand le paquet est 
«&nbsp;purgé&nbsp;» (mais pas quand le paquet est simplement supprimé). Ce
sera fait par le script <prgn>postrm</prgn> quand il sera appelé avec 
l'argument <tt>purge</tt> (voir <ref id="removedetails">). 
	</p>
      </sect>
     	    
	<sect>
	  <heading>Permissions et propriétaires</heading>
	    
	  <p>
Les règles de cette section sont des directives pour une utilisation 
élémentaire. Quand c'est nécessaire, vous pouvez vous écarter de certains 
détails. Cependant, dans ce cas, sécurisez ce que vous
faites et restez aussi cohérent que possible avec le système. Vous devriez
probablement en discuter aussi dans <prgn>debian-devel</prgn>.
</p>
	  <p>
Les fichiers appartiendront à <tt>root.root</tt>. Ils seront
modifiables uniquement par le propriétaire et seront lisibles 
par tous (exécutables si nécessaire) c'est-à-dire 644 ou 755.
</p>
	  <p>
Les répertoires auront le mode 755 ou, pour ceux qui doivent être 
modifiables par un groupe, le mode 2775. La propriété du répertoire sera 
cohérente avec le mode -- si le répertoire a comme mode 2775, il 
appartiendra au groupe qui a besoin d'y accéder.<footnote>
            <p>
Quand un paquet est mis à jour et que le propriétaire ou les permissions d'un
fichier inclus dans le paquet a changé, dpkg s'arrange pour que le propriétaire
et les permissions soient positionnées correctement lors de
l'installation. Cependant, cela ne s'étend pas aux répertoires&nbsp;; les
permissions et le propriétaire des répertoires déjà présents sur le système ne
changent pas lors d'une installation ou d'une mise à jour de paquet. Cela est
logique car, sinon, des répertoires communs comme <tt>/usr</tt> serait toujours
en flux. Pour changer correctement les permissions d'un répertoire appartenant à
un paquet, une action explicite est nécessaire, habituellement dans le script
<tt>postinst</tt>. Dans ce cas, une attention particulière doit être prise pour
gérer également les mises à jour vers une version antérieure.
            </p>
          </footnote>
	  </p>
	    
	  <p>
Les exécutables qui sont «&nbsp;setuid&nbsp;» et «&nbsp;setgid&nbsp;» auront 
respectivement les modes 4755 et 2755, et ils appartiendront à l'utilisateur 
ou au groupe approprié. On n'interdira pas leur lecture (par des modes 
comme 4711 ou 2711 ou même 4111)&nbsp;; en effet cela n'apporte aucun gain de 
sécurité puisque n'importe qui peut obtenir les binaires dans les paquets 
Debian qui sont librement disponibles&nbsp;; c'est simplement gênant. Pour la même 
raison vous ne restreindrez pas les droits en lecture ou en exécution 
des exécutables «&nbsp;non-set-id&nbsp;».
</p>
	  <p> 
Certains programmes «&nbsp;setuid&nbsp;» doivent être restreints à certains 
groupes d'utilisateurs en se servant des permissions sur les fichiers. Dans 
ce cas, ils appartiendront à l'«&nbsp;uid&nbsp;» pour lesquels ils sont 
«&nbsp;set-id&nbsp;» et au groupe qui aura des droits d'exécution. Ils auront
le mode 4754&nbsp;; cela ne sert à rien d'empêcher leur lecture aux 
utilisateurs qui n'ont pas les droits d'exécution.
</p>
	  <p>
On peut permettre que, pour suivre sa politique locale de sécurité, un 
administrateur système puisse reconfigurer un paquet en changeant
les permissions des fichiers binaires&nbsp;: il peut utiliser 
<prgn>dpkg-statoverride</prgn> pour cela, comme c'est décrit plus bas
<footnote>
<p>
Les fichiers ordinaires (à l'exception des <tt>conffile</tt>s et d'autres
fichiers similaires) installés par <prgn>dpkg</prgn> ont normalement
leurs droits réinitialisés avec les droits de la distribution lors de la 
réinstallation d'un paquet. Cependant, l'utilisation du programme 
<prgn>dpkg-statoverride</prgn> annule ce comportement par défaut. Si vous
utilisez cette méthode, vous penserez à décrire ce programme dans la
documentation du paquet&nbsp;; en tant qu'apport relativement récent à
Debian, il est probablement peu connu.
	</p></footnote>.
Une autre méthode est de créer un groupe comprenant les utilisateurs autorisés
à utiliser le programme et de rendre tous les exécutables <em>setuid</em>
exécutables seulement par ce groupe.
        </p>

	  <p>
Si vous avez besoin d'un nouvel utilisateur ou groupe pour votre paquet, vous 
avez deux possibilités. La première est de rendre cet utilisateur ou ce 
groupe propriétaire d'un ou plusieurs fichiers de votre paquet. La deuxième
est de compiler l'identifiant (plutôt que le nom) d'utilisateur ou de groupe 
dans le binaire. Dans ce cas vous avez besoin d'un identifiant attribué de 
façon fixe.
</p>
	  <p>
Si vous avez besoin d'un identifiant attribué de façon fixe, vous devez alors 
demander un identifiant d'utilisateur ou de groupe au 
responsable du système de base, <tt>base-passwd</tt> et vous ne devez pas 
livrer votre paquet avant d'avoir reçu un tel identifiant. Quand vous l'avez 
reçu, vous devez faire dépendre votre paquet d'une version du système de base 
dans laquelle l'identifiant est présent dans <tt>/etc/passwd</tt> ou dans 
<tt>/etc/group</tt>. Alternativement, vous pouvez modifier votre paquet pour 
qu'il crée lui-même l'utilisateur ou le groupe avec le bon identifiant 
(en utilisant <tt>adduser</tt>) dans les scripts <prgn>preinst</prgn> ou
<prgn>postinst</prgn>. (Utiliser <prgn>postinst</prgn> est préférable si c'est
possible&nbsp;; sinon, il faudra une pré-dépendance envers le paquet
<tt>adduser</tt>.)
</p>
	    
	  <p>
D'un autre côté, un programme peut être capable, en fonctionnement, de 
déterminer l'«&nbsp;uid&nbsp;» ou le «&nbsp;gid&nbsp;» à partir du nom d'un 
groupe de façon à utiliser un identifiant attribué de façon dynamique. Dans 
ce cas vous choisirez un nom d'utilisateur ou de groupe approprié, vous en 
discuterez dans <prgn>debian-devel</prgn>, vous vérifierez avec le responsable
du paquet <package>base-passwd</package> que ce nom est unique et vous vous 
assurerez qu'ils 
(la liste <prgn>debian-devel</prgn>) ne préfèrent pas un identifiant attribué 
de manière fixe. Quand tout cela a été vérifié, vous devez modifier votre 
paquet pour qu'il crée, si nécessaire, l'utilisateur ou le groupe avec 
<prgn>adduser</prgn> dans les scripts <prgn>preinst</prgn> ou
<prgn>postinst</prgn> (à nouveau, ces derniers sont préférables si c'est 
possible).
</p>	   
	  <p>
Il faut noter que changer la valeur numérique d'un identifiant associé
à un nom est une opération très difficile. Elle implique de rechercher
dans le système de fichier tous les fichiers concernés. Réfléchissez
sérieusement au meilleur choix entre «&nbsp;id&nbsp;» statique ou dynamique,
car modifier votre choix ultérieurement posera des problèmes.
</p>

<sect1><heading>L'utilisation du programme <prgn>dpkg-statoverride</prgn></heading>
<p>
Cette section ne se veut pas normative&nbsp;: c'est une description de
l'utilisation du programme <prgn>dpkg-statoverride</prgn>.
	  </p>
<p>
Le programme <prgn>dpkg-statoverride</prgn> remplace le paquet
<tt>suidmanager</tt>. Les paquets qui utilisaient <tt>suidmanager</tt>
auront un champ <tt>Conflicts: suidmanager (&lt;&lt;0.50)</tt> et les appels à
<tt>suidregister</tt> et à <tt>suidunregister</tt> seront simplement
supprimés des scripts des responsables de paquet.
	  </p>
<p>
Quand un administrateur système souhaite installer un fichier (un répertoire,
etc.) avec un système de permissions différent de celui du paquet Debian
distribué, il peut se servir de <prgn>dpkg-statoverride</prgn> pour dire
à <prgn>dpkg</prgn> d'utiliser un système particulier à chaque installation
du fichier. Ainsi, le responsable du paquet distribuera les fichiers avec
un système de permissions normal et laissera faire
ses modifications. Par exemple, un démon, qui est normalement 
<em>setuid root</em> mais qui pourrait parfois être utilisé sans être
<em>setuid</em>, sera installé <em>setuid</em> dans le fichier <tt>.deb</tt>.
Puis, l'administrateur système local changera cela s'il le souhaite. Quand il
y a deux façons de faire, le responsable de paquet peut utiliser
<tt>debconf</tt> pour trouver la préférée, et appeler 
<prgn>dpkg-statoverride</prgn> dans ses scripts pour prendre en compte les
choix de l'administrateur système. Une attention particulière doit être prise
pendant les mises à jour pour ne pas supprimer un paramétrage existant.
	  </p>
<p>
Le programme <prgn>dpkg-statoverride</prgn> est donc essentiellement un
outil pour administrateur système et les scripts de responsable de paquet
ne devraient pas en avoir besoin. Il y a cependant une situation où des
appels à <prgn>dpkg-statoverride</prgn> peuvent être nécessaires dans ces
scripts&nbsp;; il s'agit des paquets qui se servent d'identifiants 
d'utilisateur ou de groupe attribués dynamiquement. Dans cette situation, où
<tt>sysuser</tt> est un identifiant dynamiquement attribué, il peut être
utile de se servir, dans le <prgn>postinst</prgn> du paquet, de quelque chose
comme&nbsp;:
           <example>
for i in /usr/bin/foo /usr/sbin/bar
do
  # ne faire quelque chose que si aucun paramétrage n'existe
  if ! dpkg-statoverride --list $i >/dev/null
  then
    #inclus : traitement debconf, question à propos de foo et bar
    if [ "$RET" = "true" ] ; then
      dpkg-statoverride --update --add sysuser root 4755 $i
    fi
  fi
done
           </example>
Quand le paquet est <em>purgé</em>, on peut faire sans condition les appels 
correspondants <tt>dpkg-statoverride --remove</tt>.
	  </p>
	</sect1>
      </sect>
    </chapt>

    <chapt id="customized-programs">
       <heading>Programmes personnalisés</heading>
	
      <sect id="arch-spec">
	<heading>Les chaînes de spécification d'architecture</heading>
	  
	<p>
Quand un programme doit fournir une <em>chaîne de spécification
d'architecture</em>, il devra choisir l'une des chaînes fournies par
<tt>dpkg-architecture -L</tt>. Les chaînes sont au format&nbsp;:
<tt><var>os</var>-<var>arch</var></tt>, bien que la partie OS soit parfois omise
quand l'OS est Linux.<footnote>
            <p>
	      Actuellement, les chaînes sont&nbsp;:
              i386 ia64 alpha amd64 armeb arm hppa m32r m68k mips
              mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb
              sparc darwin-i386 darwin-ia64 darwin-alpha darwin-amd64
              darwin-armeb darwin-arm darwin-hppa darwin-m32r
              darwin-m68k darwin-mips darwin-mipsel darwin-powerpc
              darwin-ppc64 darwin-s390 darwin-s390x darwin-sh3
              darwin-sh3eb darwin-sh4 darwin-sh4eb darwin-sparc
              freebsd-i386 freebsd-ia64 freebsd-alpha freebsd-amd64
              freebsd-armeb freebsd-arm freebsd-hppa freebsd-m32r
              freebsd-m68k freebsd-mips freebsd-mipsel freebsd-powerpc
              freebsd-ppc64 freebsd-s390 freebsd-s390x freebsd-sh3
              freebsd-sh3eb freebsd-sh4 freebsd-sh4eb freebsd-sparc
              kfreebsd-i386 kfreebsd-ia64 kfreebsd-alpha
              kfreebsd-amd64 kfreebsd-armeb kfreebsd-arm kfreebsd-hppa
              kfreebsd-m32r kfreebsd-m68k kfreebsd-mips
              kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64
              kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb
              kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc knetbsd-i386
              knetbsd-ia64 knetbsd-alpha knetbsd-amd64 knetbsd-armeb
              knetbsd-arm knetbsd-hppa knetbsd-m32r knetbsd-m68k
              knetbsd-mips knetbsd-mipsel knetbsd-powerpc
              knetbsd-ppc64 knetbsd-s390 knetbsd-s390x knetbsd-sh3
              knetbsd-sh3eb knetbsd-sh4 knetbsd-sh4eb knetbsd-sparc
              netbsd-i386 netbsd-ia64 netbsd-alpha netbsd-amd64
              netbsd-armeb netbsd-arm netbsd-hppa netbsd-m32r
              netbsd-m68k netbsd-mips netbsd-mipsel netbsd-powerpc
              netbsd-ppc64 netbsd-s390 netbsd-s390x netbsd-sh3
              netbsd-sh3eb netbsd-sh4 netbsd-sh4eb netbsd-sparc
              openbsd-i386 openbsd-ia64 openbsd-alpha openbsd-amd64
              openbsd-armeb openbsd-arm openbsd-hppa openbsd-m32r
              openbsd-m68k openbsd-mips openbsd-mipsel openbsd-powerpc
              openbsd-ppc64 openbsd-s390 openbsd-s390x openbsd-sh3
              openbsd-sh3eb openbsd-sh4 openbsd-sh4eb openbsd-sparc
              hurd-i386 hurd-ia64 hurd-alpha hurd-amd64 hurd-armeb
              hurd-arm hurd-hppa hurd-m32r hurd-m68k hurd-mips
              hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x
              hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc
            </p>
	  </footnote>
	</p>

	<p>
On remarquera que nous ne voulons pas utiliser 
<tt><var>arch</var>-debian-linux</tt> dans la chaîne  
<tt><var>architecture</var>-<var>vendor</var>-<var>os</var></tt>
car cela rendrait nos programmes incompatibles avec les autres distributions 
Linux. Notez aussi que nous n'utilisons pas 
<tt><var>arch</var>-unknown-linux</tt>, car <tt>unknown</tt> ne sonne pas 
très bien.
</p>
</sect>
	  
	  
      <sect>
	<heading>Les «&nbsp;démons&nbsp;»</heading>
	  
	<p>
Les fichiers de configuration <file>/etc/services</file>,
<file>/etc/protocols</file> et <file>/etc/rpc</file> sont gérés par le paquet
<prgn>netbase</prgn> et ne doivent pas être modifiés par d'autres paquets.
</p>
	  
	<p>
Quand un paquet a besoin d'une nouvelle entrée dans l'un de ces fichiers,
son responsable contactera le responsable du paquet <prgn>netbase</prgn>,
qui ajoutera cette entrée et produira une nouvelle version du paquet
<prgn>netbase</prgn>.
</p>
	  
	<p>
Le fichier de configuration <file>/etc/inetd.conf</file> ne doit pas être 
modifié par les scripts d'un paquet sauf si c'est <em>via</em> le script 
<prgn>update-inetd</prgn> ou le module Perl <file>DebianNet.pm</file>. Voir la
documentation pour savoir comment ajouter des entrées.
</p>
	<p>
Quand un paquet veut ajouter un exemple d'entrée dans
<file>/etc/inetd.conf</file>, cette entrée doit être précédée par un seul
caractère «&nbsp;#&nbsp;». De telles lignes sont traitées comme des
commentaires de l'utilisateur  par le script <prgn>update-inetd</prgn> et
ne seront pas modifiées ou activées lors des mises à jour des paquets.
</p>
</sect>
	  
      <sect>
<heading>L'utilisation des pseudo-ttys et la modification de «&nbsp;wtmp&nbsp;», 
«&nbsp;utmp&nbsp;» et «&nbsp;lastlog&nbsp;»</heading>
	  
	<p>
Certains programmes ont besoin de créer des pseudo-ttys.
On doit le faire avec les «&nbsp;Unix98&nbsp;» ptys si la bibliothèque 
«&nbsp;C&nbsp;» le permet. Le programme résultant ne doit pas être installé 
«&nbsp;setuid root&nbsp;», à moins que d'autres fonctions ne le demandent.</p>
	
	<p>
Les fichiers <tt>/var/run/utmp</tt>, <tt>/var/log/wtmp</tt> et
<tt>/var/log/lastlog</tt> doivent être modifiables par le groupe 
<tt>utmp</tt>. Les programmes qui ont besoin de modifier ces fichiers 
doivent appartenir au groupe <tt>utmp</tt>.
	</p>
      </sect>

      <sect>
	<heading>Les éditeurs de texte et les pagineurs</heading>
	  
	<p>
Certains programmes peuvent appeler un éditeur ou un pagineur pour modifier
ou afficher un document texte. Comme de nombreux éditeurs et pagineurs sont
disponibles dans la distribution Debian, l'administrateur système et les
utilisateurs pourront choisir leur éditeur ou leur pagineur préféré.
</p>
	<p>
De plus, chaque programme choisira un éditeur ou un pagineur 
par défaut si l'utilisateur ou l'administrateur système n'en a pas choisi un.
</p>
	  
	<p>
Ainsi chaque programme qui appelle un éditeur ou un pagineur doit
utiliser les variables d'environnement EDITOR ou PAGER pour déterminer
l'éditeur ou le pagineur que l'utilisateur souhaite employer. Si ces
variables ne sont pas définies, les programmes <tt>/usr/bin/editor</tt>
et <tt>/usr/bin/pager</tt> seront, respectivement, utilisés.
</p>
	<p>
Ces deux fichiers sont gérés par l'outil de <prgn>dpkg</prgn>, 
«&nbsp;alternatives&nbsp;». Tout paquet,
fournissant un éditeur ou un pagineur, doit employer le script
«&nbsp;update-alternatives&nbsp;» pour déclarer ces programmes.
</p>
	  
	<p>
Lorsqu'il est très difficile d'adapter un programme pour qu'il utilise
les variables EDITOR et PAGER, ce programme peut être configuré
pour utiliser respectivement <tt>/usr/bin/sensible-editor</tt> et
<tt>/usr/bin/sensible-pager</tt> comme éditeur ou pagineur. Ce sont
deux scripts fournis par le système Debian de base qui testent les
variables EDITOR ou PAGER et lancent les programmes appropriés ou bien
exécutent par défaut <tt>/usr/bin/editor</tt> ou <tt>/usr/bin/pager</tt>
quand la variable n'est pas définie.
</p>
	<p>
Un programme peut aussi se servir de la variable d'environnement VISUAL
pour connaître l'éditeur choisi par l'utilisateur. Si elle existe, elle
prend le pas sur la variable EDITOR. Et c'est ce que fait
<tt>/usr/bin/sensible-editor</tt>.</p>


	<p>
Un paquet n'a pas besoin de dépendre d'<tt>editor</tt> ou de <tt>pager</tt>,
et il n'y a pas besoin de paquets virtuels pour cela
<footnote>
<p>
Le système Debian de base fournit déjà un éditeur et
un pagineur.</p>
	  </footnote>.
</p>
  </sect>
      <sect id="web-appl">
	<heading>Serveurs et applications Web</heading>
	  
	<p>
Cette section décrit les emplacements et les «&nbsp;URL&nbsp;» qui seront
employés par tous les serveurs et applications Web dans le système Debian.
</p>
	  
	<p>
	  <enumlist>
	    <item>
<p>Les fichiers exécutables cgi-bin sont installés dans le répertoire
		<example compact="compact">
/usr/lib/cgi-bin/<var>cgi-bin-name</var>
		</example>
et seront référencés par
		<example compact="compact">
http://localhost/cgi-bin/<var>cgi-bin-name</var>
		</example></p></item>
		
		
	    <item><p>L'accès aux documents HTML</p>
		
	      <p>
Les documents HTML d'un paquet sont conservés dans 
<tt>/usr/share/doc/<var>package</var></tt> et peuvent être référencés par
		<example compact="compact">
http://localhost/doc/<var>paquet</var>/<var>nom-de-fichier</var>
		</example></p>
<p>
Le serveur web restreindra l'accès à l'arborescence des documents pour que
seuls les clients appartenant à cette machine puissent consulter ces documents.
Quand le serveur ne peut contrôler les accès, il ne fournira aucun accès, ou
questionnera, pendant l'installation, au sujet d'un tel accès.
</p>
</item>

            <item>
              <p>L'accés au images</p>
              <p>
Il est recommandé de mettre les images d'un paquet dans
<tt>/usr/share/images/<var>paquet</var></tt> et de les référencer par un alias
comme dans cet exemple&nbsp;:
                <example>
                  http://localhost/images/&lt;package&gt;/&lt;filename&gt;     
                </example>
                
              </p>
            </item>

		
		
	    <item><p>La racine des documents Web</p>
		
	      <p>
Les applications Web éviteront de conserver des fichiers dans la racine
des documents Web. Il faut utiliser, à la place, le répertoire
/usr/share/doc/<var>paquet</var> pour les documents et déclarer
l'application Web <em>via</em> le paquet <package>doc-base</package>. 
Si l'accès à la racine des documents Web est inévitable alors il faut utiliser
		<example compact="compact">
/var/www
		</example> 
comme racine des documents. Cela peut être juste un lien symbolique
vers l'emplacement où l'administrateur a mis la véritable racine
des documents.
 </p>
</item>
	    <item><p>Fournir httpd et/ou httpd-cgi</p>
	      <p>
Tous les serveurs web devraient fournir le paquet virtuel <tt>httpd</tt>. Si un
serveur intègre une gestion des CGI, il devrait de plus fournir
<tt>httpd-cgi</tt>.
	      </p>
	      <p>
Toutes les applications web ne contenant pas de scripts CGI devraient dépendre
de <tt>httpd</tt>, toutes les applications web <tt>contenant</tt> des scripts
CGI, devraient dépendre de <tt>httpd-cgi</tt>.
	      </p>
	    </item>
</enumlist>
</p>
</sect>
	  
	  
      <sect id="mail-transport-agents">
	<heading>Le courrier : transport, distribution et lecture des messages.</heading>
	  
	<p>
Les paquets Debian qui traitent le courrier électronique, que ce soient les 
agents utilisateurs (<em>MUA: Mail User Agents</em>) ou les agents de 
transport (<em>MTA: Mail Transport Agent</em>), doivent respecter les 
directives de configuration qui suivent. Le non-respect de celles-ci peut 
entraîner la perte de messages, la présence de lignes <tt>From:</tt> 
incorrectes et d'autres dommages sérieux&nbsp;!
</p>
	  
	<p>
Le répertoire pour le courrier est <tt>/var/mail</tt> et l'interface 
pour envoyer des courriers est <tt>/usr/sbin/sendmail</tt> (conformément au 
FHS). Sur des systèmes plus anciens, le répertoire du courrier peut être
physiquement situé dans <tt>/var/spool/mail</tt> mais les accès à ce répertoire
se feront par le lien symbolique <tt>/var/mail</tt>. Le répertoire pour le 
courrier fait partie du système de base et n'appartient pas au paquet MTA.
</p>
	  
<p>
Dans le système Debian, tous les MUA, MTA, MDA et autres programmes de 
gestions des boîtes aux lettres (comme les démons IMAP) doivent verrouiller
les boîtes aux lettres de façon à permettre l'usage de NFS. Cela signifie
que le verrouillage de type <tt>fcntl()</tt> doit être associé avec celui
de type point («&nbsp;dot locking&nbsp;»). Pour éviter les situations inextricables, un programme utilisera d'abord <tt>fcntl()</tt> et ensuite le
verrouillage «&nbsp;point&nbsp;» ou bien implantera si possible les deux 
méthodes à la fois<footnote><p>Quand il n'est pas possible d'établir les deux 
modes de verrouillage, le système ne doit pas attendre que le second mode soit
mis en place, mais doit enlever le premier mode, attendre un certain temps
et recommencer le verrouillage.</p></footnote>. Pour faire cela, il est
conseillé d'employer les fonctions <tt>maillock</tt> et <tt>mailunlock</tt> 
présentes dans le paquet <tt>liblockfile*</tt><footnote>
            <p>
Pour utiliser ces fonctions, il faut avoir une dépendance envers 
<tt>liblockfile</tt> version &gt;&gt;1.01.</p>
          </footnote>.
        </p>


	<p>
Les boîtes aux lettres ont généralement le mode 660
<tt><var>utilisateur</var>.mail</tt> à moins que l'administrateur système n'en
ait décidé autrement. Un MUA peut supprimer une boîte aux lettres (sauf
si elle n'a pas les permissions standards). Dans ce cas, le MTA ou
un autre MUA doit la recréer au besoin. Le groupe <tt>mail</tt> doit 
pouvoir modifier les boîtes aux lettres.
</p>
	<p>
La file d'attente du courrier a le mode 2775
<tt>root.mail</tt> et les MUA doivent appartenir au groupe <tt>mail</tt> 
pour effectuer le verrouillage mentionné précédemment (et doivent évidemment
s'interdire l'accès aux boîtes aux lettres des autres utilisateurs
en employant ce privilège).
</p>
	<p>
<file>/etc/aliases</file> est le fichier contenant les alias du système
de messagerie (par exemple postmaster, usenet, etc.)&nbsp;&mdash; c'est l'un des
fichiers que l'administrateur système et les scripts <prgn>postinst</prgn>
peuvent modifier. Après avoir modifié <file>/etc/aliases</file>, le programme
ou l'administrateur doit exécuter <prgn>newaliases</prgn>. Tous les
paquets MTA doivent contenir un programme <prgn>newaliases</prgn>,
même s'il ne fait rien. Cependant les anciens paquets MTA ne le
faisant pas, les programmes ne doivent pas échouer si
<prgn>newaliases</prgn> ne peut être trouvé. À cause de cela, tous les
MTA doivent posséder les champs <tt>Provides</tt>, <tt>Conflicts</tt> et
<tt>Replaces: mail-transport-agent</tt> dans leur fichier de contrôle.
</p>
	  
	<p>
La convention consistant à écrire <tt>forward to <var>adresse</var></tt>
dans la boîte aux lettres elle-même n'est pas supportée. Utilisez
un fichier <tt>.forward</tt> à la place.
</p>
	<p>
L'emplacement du programme <prgn>rmail</prgn> utilisé par UUCP pour
les messages entrants sera <tt>/usr/sbin/rmail</tt>.
De même le programme <prgn>rsmtp</prgn>, qui reçoit des lots SMTP via UUCP,
sera placé dans <tt>/usr/sbin/rsmtp</tt> s'il est supporté.
</p>
	<p>
Quand un programme veut savoir quel nom d'hôte employer, par exemple, pour les
messages sortants (courrier et nouvelles) qui sont créés localement,
il utilisera le fichier <tt>/etc/mailname</tt>. Il contient
la partie située après le nom d'utilisateur et le signe <tt>@</tt> (at)
des adresses électroniques des utilisateurs de la machine (suivi
par un retour à la ligne).
</p>
	  
	<p>
Un tel programme s'assurera de l'existence de ce fichier. S'il existe,
il sera employé sans commentaire (le script de configuration
d'un MTA peut vouloir interroger l'utilisateur même s'il trouve
ce fichier). S'il n'existe pas, il demandera une valeur à
l'utilisateur (en utilisant de préférence <prgn>debconf</prgn>) et la 
stockera dans <tt>/etc/mailname</tt> puis
l'emploiera pour la configuration du paquet. Le message d'invite
sera explicite afin d'indiquer que ce nom ne sera pas utilisé
seulement par ce paquet. Par exemple dans cette situation, le paquet 
<tt>INN</tt> pourrait dire&nbsp;:
	  <example compact="compact">
Please enter the "mail name" of your system.  This is the
hostname portion of the address to be shown on outgoing
news and mail messages.  The default is
<var>syshostname</var>, your system's host name.  Mail
name ["<var>syshostname</var>">']:
	  </example>
	  où <var>syshostname</var> est la sortie de  <tt>hostname
	    --fqdn</tt>.
</p>
</sect> 
	  
	  
      <sect>
	<heading>La configuration du système de «&nbsp;Nouvelles&nbsp;»</heading>
	  
	<p>
Tous les fichiers de configuration relatifs aux serveurs et aux
clients NNTP (nouvelles) seront placés dans le répertoire <file>/etc/news</file>.
</p>
	  
	<p>
Quelques points de configuration s'appliquent à de nombreux paquets
concernant les nouvelles (clients et serveurs) sur la machine&nbsp;:

	  <taglist>
	    <tag><tt>/etc/news/organization</tt></tag>
	    <item><p>c'est une chaîne qui apparaîtra dans le champ 
organisation de l'en-tête de chaque
message posté par les clients NNTP de la machine.
 </p>
</item>
		
	    <tag><tt>/etc/news/server</tt></tag>
	    <item><p>contient soit le FQDN du serveur NNTP principal soit
localhost si la machine locale est un serveur NNTP.
 </p>
</item>
	  </taglist>
	  </p>
<p>
D'autres fichiers de portée générale peuvent être ajoutés s'ils sont requis 
pour la configuration commune à plusieurs paquets concernant les nouvelles.
</p>
</sect>
	  
      <sect>
	<heading>Les programmes pour le système X Window</heading>
	  
        <sect1>
          <heading>X et la priorité des paquets</heading>

	<p>
On doit configurer pour le système X Window les programmes qui peuvent l'être,
et on doit déclarer toutes les dépendances nécessaires à leur fonctionnement
sous «&nbsp;X&nbsp;». Quand ces dépendances sont pour un paquet
dont la priorité est une priorité supérieure à celles des paquets X dont il
dépend, les binaires spécifiques à «&nbsp;X&nbsp;» peuvent être mis dans un
paquet distinct, ou bien des versions alternatives du paquet avec support de
«&nbsp;X&nbsp;» peuvent être fournies, ou bien encore la priorité du paquet
peut être abaissée.
</p>
	</sect1>

<sect1><heading> Les paquets fournissant un serveur X</heading>

<p>
<em>Les paquets qui fournissent un serveur «&nbsp;X&nbsp;» </em> et qui,
directement ou indirectement, communiquent avec le matériel d'entrée et
d'affichage, déclareront dans leurs données de contrôle qu'ils fournissent
le paquet virtuel <tt>xserver</tt>
          <footnote>
            <p>
Cela met en ½uvre la pratique actuelle et offre une
vraie politique pour l'utilisation du paquet virtuel <tt>xserver</tt>,
lequel apparaît dans la liste des paquets virtuels. En résumé, les serveurs
«&nbsp;X&nbsp;» qui communiquent directement avec le matériel d'entrée et 
d'affichage ou via un autre sous-système (p. ex. GGI) fourniront
<tt>xserver</tt>. Des choses comme <tt>Xvfb</tt>, <tt>Xnest</tt> et
<tt>Xprt</tt> ne doivent pas le faire.
	    </p>
	  </footnote>.
	  </p>
	</sect1>
<sect1>
<heading>Les paquets fournissant un émulateur de terminal</heading>

<p>

Les paquets qui fournissent un émulateur de terminal pour le
système X Window et qui correspondent aux critères énumérés plus bas,
déclareront dans leurs données de contrôle qu'ils fournissent le paquet
virtuel <tt>x-terminal-emulator</tt>. Ils se déclareront comme une
alternative pour <file>/usr/bin/x-terminal-emulator</file>, avec une priorité
égale à 20.
</p>
<p>
Pour être un <tt>x-terminal-emulator</tt>, un programme doit&nbsp;:
<list compact="compact">
<item><p>
se comporter comme un terminal DEC VT100 ou un terminal compatible&nbsp;;
</p></item>
<item><p>
accepter l'option de ligne de commande <tt>-e <var>commande</var></tt> qui
crée une nouvelle fenêtre de terminal<footnote>
Une nouvelle fenêtre de terminal ne signifie pas nécessairement une nouvelle
fenêtre X de plus haut niveau directement liée au gestionnaire de 
fenêtres&nbsp;; elle pourrait être, si l'application qui émule le terminal
était codée ainsi, une nouvelle «&nbsp;vue&nbsp;» dans une interface pour
plusieurs documents (MDI, multiple-document interface).
		  </footnote>
et exécuter la <var>commande</var> spécifiée, en interprétant tout le reste de 
la ligne de commande comme une commande à donner directement à exec, à la 
manière de <tt>xterm</tt>&nbsp;;
</p></item>
<item><p>
accepter l'option de ligne de commande <tt>-T <var>titre</var></tt> qui
crée une nouvelle fenêtre de terminal avec comme titre <var>titre</var>.
</p></item>
</list>
</p>
</sect1>

<sect1><heading>Les paquets fournissant des gestionnaires de fenêtres</heading>

<p>
Les paquets qui fournissent des gestionnaires de fenêtres déclareront dans 
leurs données de contrôle qu'ils fournissent le paquet virtuel 
<tt>x-window-manager</tt>. Ils se déclareront comme une alternative pour 
<tt>/usr/bin/x-window-manager</tt>, avec une priorité qu'on calculera ainsi&nbsp;:
<list compact="compact">
            <item><p>Commencez avec une priorité égale à 20.</p></item>
            <item>
<p>
Si le gestionnaire de fenêtres permet le système des menus de Debian, on
ajoutera 20 points si cela se fait avec la configuration par défaut du
paquet (c.-à-d. qu'il n'y a pas besoin, pour obtenir cette fonctionnalité,
de modifier des fichiers de configuration appartenant au système ou à 
l'utilisateur)&nbsp;; si l'on doit modifier des fichiers de configuration, on
ajoutera seulement 10 points.</p>
</item>
              <item>
                <p>
Si le gestionnaire de fenêtres est conforme au 
<url id="http://www.freedesktop.org/standards/wm-spec"
                    name="Projet pour la spécification des gestionnaires de fenêtres (The Window Manager Specification Project)">, écrit par le 
                  <url id="http://www.freedesktop.org"
                    name="Free Desktop Group">, on ajoutera 20 points.
                </p>
              </item>

<item>
<p>
Si le gestionnaire de fenêtres autorise, dans sa configuration par défaut, le 
redémarrage d'une session X avec un <em>nouveau</em> gestionnaire de fenêtres 
(sans tuer le serveur X), on ajoutera 10 points&nbsp;; sinon, rien.
</p>
</item>
</list>
	  </p>
	</sect1>

<sect1>
<heading>Les paquets fournissant des polices</heading>
<p>
Les paquets qui fournissent des polices pour le système X Window
<footnote>
<p>
Dans le cadre de cette charte, une «&nbsp;police pour le système X Window&nbsp;»
est une police accessible par des requêtes utilisant le protocole X. Les
polices pour la console Linux, pour les formateurs PostScript, etc., ne
rentrent pas dans cette catégorie. Tous les outils qui rendent disponibles de
telles polices pour le système X Window doivent cependant se conformer à cette
règle.</p>
	    </footnote>
doivent faire un certain nombre de choses pour s'assurer à la fois qu'ils 
sont disponibles sans avoir à modifier la configuration du serveur 
X ou du serveur de polices, et qu'ils n'abîment pas les fichiers utilisés
par d'autres paquets pour déclarer les renseignements qui les concernent.
<enumlist>
           <item>
<p>
Les polices de tout type offertes pour le système X Window doivent être dans des
paquets distincts des binaires, bibliothèques ou de la documentation (sauf
celle liée à la police fournie, par exemple leur licence). Quand une ou
plusieurs polices sont nécessaires à l'exploitation correcte du paquet auquel
elles sont associées, le paquet qui les contient peut être placé dans un 
champ <em>Recommends</em>&nbsp;; si elles n'apportent que des améliorations,
on peut utiliser un champ <em>Suggests</em>. Les paquets ne doivent pas
dépendre de paquets contenants des polices<footnote>
<p>
Le serveur X peut en effet récupérer des polices sur le système de fichiers
local ou, à travers le réseau, sur un serveur de polices pour X&nbsp;; le
système Debian des paquets ne permet que l'utilisation du système de fichiers
local.
</p>
</footnote>.
		</p>
	      </item>
<item>
<p>
Les polices BDF seront converties en polices PCF avec le programme
<prgn>bdftopcf</prgn> (disponible dans le paquet <tt>xfonts-utils</tt>),
<prgn>gzip</prgn>ées, et placées dans un répertoire qui correspond à leur
définition&nbsp;: 
<list compact="compact">
                  <item><p>
                      Les polices à 100 dpi seront mises dans
		      <tt>/usr/share/fonts/X11/100dpi/</tt>&nbsp;;
		      </p></item>
                  <item><p>
                      Les polices à 75 dpi seront mises dans
                      <tt>/usr/share/fonts/X11/75dpi/</tt>&nbsp;;
                  </p></item>
                  <item><p>
Les polices à chasse fixe, les polices pour le curseur, ainsi que
d'autres polices de faible définition seront mises dans
                      <tt>/usr/share/fonts/X11/misc/</tt>.
		      </p></item>
                </list>
            </p>
</item>
            <item><p>
les polices «&nbsp;Speedo&nbsp;» seront mises dans
<tt>/usr/share/fonts/X11/Speedo/</tt>.
           </p> </item>
<item><p>
les polices «&nbsp;Type 1&nbsp;» seront mises dans
                <tt>/usr/share/fonts/X11/Type1/</tt>.
Si des fichiers de métrique sont disponibles, ils peuvent aussi être placés 
là.
         </p>   </item>
            <item><p>
On ne doit pas créer ni utiliser d'autres répertoires dans 
<tt>/usr/share/fonts/X11/</tt> que ceux répertoriés dans la liste qui 
précède. Les répertoires <tt>PEX</tt>, <tt>CID</tt> et <tt>cyrillic</tt> 
font exception pour des raisons historiques, mais l'installation de fichiers 
dans ces répertoires reste déconseillée.
</p>
</item>
            <item>
<p>
Au lieu de mettre directement des fichiers dans les répertoires cités dans
la liste qui précède, les paquets peuvent fournir des liens symboliques 
dans le répertoire des polices pointant vers l'emplacement réel des fichiers 
dans l'arborescence. Un tel emplacement doit se conformer au «&nbsp;FHS&nbsp;».
		</p></item>
            <item><p>
Les paquets ne contiendront pas à la fois les versions à 75 dpi et les versions
à 100 dpi d'une police. Si les deux sont disponibles, elles seront fournies
dans des paquets distincts dont les noms seront étiquetés <tt>-75dpi</tt>
ou <tt>-100dpi</tt>.</p></item>
            <item><p>
Les polices destinées au répertoire <tt>misc</tt> ne doivent pas être mises
dans les mêmes paquets que ceux des polices à 75 dpi ou 100 dpi mais elles 
seront fournies dans un paquet distinct étiqueté <tt>-misc</tt>.
</p>
</item>
            <item>
<p>
Les paquets ne doivent pas fournir les fichiers <tt>fonts.dir</tt>,
<tt>fonts.alias</tt>  ou <tt>fonts.scale</tt> dans un répertoire de polices.
<list compact="compact">
                  <item><p>
les fichiers <tt>fonts.dir</tt> ne doivent en aucun cas être fournis&nbsp;;
                  </p></item>
                  <item><p>
si besoin est, les fichiers <tt>fonts.alias</tt> et <tt>fonts.scale</tt>
seront fournis dans le répertoire
<tt>/etc/X11/fonts/<var>fontdir</var>/<var>paquet</var>.<var>extension</var></tt>
où <var>fontdir</var> est le nom du répertoire de
<tt>/usr/share/fonts/X11/</tt> dans lequel sont conservées les polices
du paquet correspondant (p. ex. <tt>75dpi</tt> ou <tt>misc</tt>), où
<var>paquet</var> est le nom du paquet qui fournit ces polices, et où
<var>extension</var> correspond au contenu du fichier, soit <tt>scale</tt>
soit <tt>alias</tt>.
</p>
</item>
                </list>
		</p>
            </item>
            <item>
<p>
Les paquets doivent déclarer une dépendance envers le paquet 
<tt>xfonts-utils</tt> dans leurs données de contrôle.
		</p>
	      </item>
<item><p>
Les paquets qui fournissent un ou plusieurs fichiers <tt>fonts.scale</tt> tels
qu'ils sont décrits plus haut, doivent appeler le programme
<prgn>update-fonts-scale</prgn>, pour chaque répertoire où est installée une 
police, <em>avant</em> d'appeler le programme <prgn>update-fonts-dir</prgn>
pour ce répertoire. Cet appel doit se faire à la fois dans le script
<prgn>postinst</prgn> (pour tous les arguments) et dans le script
<prgn>postrm</prgn> (pour tous les arguments sauf <tt>upgrade</tt>).
	  </p>
</item>
            <item>
<p>
Les paquets qui fournissent un ou plusieurs de ces fichiers
<tt>fonts.alias</tt> dont on vient de parler, doivent appeler le programme
<prgn>update-fonts-alias</prgn> pour chaque répertoire où ils installent des 
polices. Cet appel doit se faire à la fois dans le script
<prgn>postinst</prgn> (pour tous les arguments) et dans le script
<prgn>postrm</prgn> (pour tous les arguments sauf <tt>upgrade</tt>).
          </p>
</item>


            <item>
<p>
Les paquets doivent appeler le programme <prgn>update-fonts-dir</prgn>
pour chaque répertoire où ils installent des
polices. Cet appel doit se faire à la fois dans le script
<prgn>postinst</prgn> (pour tous les arguments) et dans le script
<prgn>postrm</prgn> (pour tous les arguments sauf <tt>upgrade</tt>).
          </p>
</item>
<item>
<p>
Les paquets ne doivent pas proposer, pour les noms des polices qu'ils
fournissent, des alias qui entrent en conflit avec les alias déjà utilisés
par des polices d'autres paquets.
</p></item>
<item>
<p>
Les paquets ne doivent pas fournir des polices qui ont le même nom pour
l'enregistrement XLFD que celui donné par une police déjà en usage.
</p>
</item>
          </enumlist>
        </p>
	</sect1>

<sect1>
<heading>Les fichiers « défaut » des applications</heading>
<p>
Les fichiers « défaut » des applications doivent être 
installés dans le répertoire <tt>/etc/X11/app-defaults/</tt> 
(on peut utiliser un répertoire particulier dans <file>/etc/X11/</file>
comme l'indique le manuel 
<em>X Toolkit Intrinsics - C Language Interface</em>).
On ne les déclarera pas comme des <tt>conffile</tt>s et on ne les
traitera pas non plus comme des fichiers de configuration. Les paquets ne
doivent pas fournir le répertoire <tt>/usr/X11R6/lib/X11/app-defaults/</tt>.
	  </p>
<p>
Le paramétrage des ressources X des programmes peut aussi se faire par
l'intermédiaire d'un fichier portant le même nom que celui du paquet mis
dans le répertoire <tt>/etc/X11/Xresources/</tt> et qui doit être
enregistré comme <tt>conffile</tt> ou traité comme un fichier de configuration
<footnote>
<p>
Ce mécanisme n'est pas identique à celui d'<em>app-defaults</em>&nbsp;; les
fichiers <em>app-defaults</em> sont liés au binaire client du système de
fichiers local, alors que les ressources X sont stockées dans le serveur X
et influencent tous les clients qui se connectent.
	      </p>
	    </footnote>.

<em>Important :</em> les paquets 
qui installent des fichiers dans le répertoire <tt>/etc/X11/Xresources/</tt> 
doivent déclarer un conflit avec le paquet <tt>xbase 
(&lt;&lt;3.3.2.3a-2)</tt>&nbsp;; si ce n'est pas fait, le paquet peut détruire un 
<em>fichier</em> <tt>/etc/X11/Xresources</tt> préexistant qui a pu être
paramétré par l'administrateur système.
       </p>
	</sect1>
<sect1>
<heading>Questions concernant le répertoire d'installation</heading>

<p>
Les paquets qui utilisent le système X Window ne seront pas configurés pour
installer des fichiers sous le répertoire <tt>/usr/X11R6/</tt>. La hiérarchie du
répertoire <tt>/usr/X11R6/</tt> sera tenue comme obsolète.
	  </p>

	  <p>
Les programmes qui utilisent les programmes GNU <prgn>autoconf</prgn> et
<prgn>automake</prgn> sont facilement configurés au moment de la compilation
pour utiliser <file>/usr/</file> au lieu de <file>/usr/X11R6/</file>, et cela 
sera fait à chaque fois que c'est possible. On placera les fichiers de 
configuration des gestionnaires de fenêtres et des gestionnaires d'affichage 
dans un sous-répertoire de <file>/etc/X11/</file> correspondant au nom du 
paquet&nbsp;; cela est dû à l'interpénétration étroite de ces programmes et 
du mécanisme du système X Window. Les programmes applicatifs utiliseront le 
répertoire <file>/etc/</file> sauf si cette charte impose autre chose. 
	  </p>
<p>
L'installation de fichiers dans des 
sous-répertoires de <file>/usr/X11R6/include/X11/</file> et de 
<file>/usr/X11R6/lib/X11/</file> est maintenant interdite&nbsp;; les 
responsables de paquet détermineront s'ils peuvent utiliser des 
sous-répertoires de <file>/usr/lib/</file> et de <file>/usr/share/</file>. 
	  </p>
<p>
Les paquets devraient installer tout fichier pertinent dans les répertoires
<file>/usr/include/X11/</file> et <file>/usr/lib/X11/</file>, mais s'ils le
font, ils doivent avoir une pré-dépendance sur <tt>x11-common (&gt;=
1:7.0.0)</tt>.<footnote>
              <p>
                Ces bibliothèques étaient auparavant des liens
                symboliques. Cependant, avec <tt>X11R7</tt>,
                <tt>/usr/include/X11</tt> et <tt>/usr/lib/X11</tt>
                sont maintenant des vrais répertoires et les paquets
                <strong>devraient</strong> placer leur fichiers à cet endroit
                plutôt que dans <tt>/usr/X11R6/{include,lib}/X11</tt>.
                <tt>x11-common (&gt;= 1:7.0.0) </tt> est le paquet responsable
                de la conversion de ces liens symboliques en répertoires.
              </p>
            </footnote>
</p>
	</sect1>
<sect1>
<heading>Les bibliothèques <em>OSF/Motif</em> et <em>OpenMotif</em></heading>
 
	<p>
Les programmes qui demandent les bibliothèque <em>OSF-Motif</em> et 
<em>OpenMotif</em><footnote>
<p>
Dans ce document, on regroupe les deux termes sous le nom de «&nbsp;Motif&nbsp;».</p>
	    </footnote>, 
bibliothèques non conformes aux «&nbsp;DFSG&nbsp;», seront compilés et 
testés avec «&nbsp;LessTif&nbsp;» (une libre ré-implémentation de 
«&nbsp;Motif&nbsp;»). Quand le responsable du paquet juge que 
le programme ne fonctionne pas suffisamment bien avec «&nbsp;LessTif&nbsp;»
pour être distribué et supporté, mais qu'il fonctionne correctement quand
il est compilé avec «&nbsp;Motif&nbsp;», il créera alors deux versions du
paquet&nbsp;; l'une qui sera liée de façon statique à «&nbsp;Motif&nbsp;» et
dont le nom sera étiqueté «&nbsp;-smotif&nbsp;», et l'autre qui sera liée
de façon dynamique à «&nbsp;Motif&nbsp;» et dont le nom sera étiqueté 
«&nbsp;-dmotif&nbsp;». 
	  </p>
<p>
Les deux versions liées à «&nbsp;Motif&nbsp;» sont
dépendantes de logiciels non conformes aux «&nbsp;DFSG&nbsp;» et donc ne
peuvent être mises dans la section «&nbsp;main&nbsp;» de la 
distribution&nbsp;; si 
le logiciel lui-même est conforme aux «&nbsp;DFSG&nbsp;»  il peut être mis 
dans la section «&nbsp;contrib&nbsp;». Toutes les versions connues de
«&nbsp;OSF-Motif&nbsp;» autorisent la redistribution sans restriction de 
binaires liés de façon statique ou dynamique à cette bibliothèque, mais 
c'est au responsable de paquet de déterminer si la licence  
de la version de «&nbsp;Motif&nbsp;» qu'il possède le permet.
	</p>
	</sect1>
      </sect>
	  
	  
<sect id="perl">
<heading>Les programmes et modules Perl</heading>
<p>
Les programmes et modules Perl suivront les règles concernant Perl.
	</p>
<p>
On peut trouver ces règles dans le fichier <tt>perl-policy</tt> du paquet
<tt>debian-policy</tt>. Elles sont aussi disponibles sur les miroirs web de
Debian, 
          <tt><url name="/doc/packaging-manuals/perl-policy/"
          id="https://www.debian.org/doc/packaging-manuals/perl-policy/"></tt>.
        </p>

      </sect>
     <sect id="emacs">
	<heading>Les programmes emacs lisp</heading>
	  
	<p>
Veuillez consulter le «&nbsp;Debian Emacs Policy&nbsp;» pour les détails 
concernant la création de paquets de programmes emacs lisp.
</p>
       <p>
On peut trouver les règles concernant Emacs dans le fichier 
<file>debian-emacs-policy.gz</file> du paquet 
<package>emacsen-common</package> package. Elles sont aussi disponibles
sur les miroirs web de Debian, 
<tt><url name="/doc/packaging-manuals/debian-emacs-policy" id="https://www.debian.org/doc/packaging-manuals/debian-emacs-policy"></tt>.
       </p>

</sect>
	  
	  
      <sect>
	<heading>Les jeux</heading>
	  
	<p>
Les permissions de <tt>/var/lib/games</tt> sont 755 , propriétaire 
<tt>root</tt> et groupe <tt>root</tt>.
</p>
	  
	<p>
Chaque jeu décide de ses propres règles de sécurité.
</p>
	  
	<p>
Les jeux qui demandent des accès privilégiés et protégés à des
fichiers de scores, de sauvegardes de parties, etc., peuvent appartenir
à <tt>root.games</tt> et être exécutables par le groupe <tt>games</tt> 
(mode 2755) et doivent utiliser des fichiers et des répertoires avec
des permissions appropriées (770 <tt>root.games</tt> par exemple).
Ils ne doivent pas être exécutable par un utilisateur (set-user-id),
car cela entraîne des problèmes de sécurité. Si un attaquant arrive
à corrompre un jeu «&nbsp;set-user-id&nbsp;», il peut alors remplacer 
l'exécutable d'autres utilisateurs, forçant les autres joueurs de ces jeux à 
exécuter un cheval de Troie. Avec un programme «&nbsp;set-group-id&nbsp;»,
l'attaquant n'a accès qu'à des données de jeu moins 
importantes. S'il veut accéder aux comptes des autres joueurs, cela lui 
demandera des efforts beaucoup plus importants.
</p>
	  
	<p>
Certains paquets, comme les programmes «&nbsp;fortune&nbsp;», sont configurés
par leurs auteurs originaux pour interdire la lecture de leurs fichiers
de données ou d'autres informations statiques,
de manière qu'ils ne puissent être accessibles que par les programmes 
«&nbsp;set-id&nbsp;» fournis. Vous ne ferez pas de même dans un paquet 
Debian&nbsp;: n'importe qui peut télécharger le fichier <tt>.deb</tt> et y lire 
les données, cela n'a donc pas de sens d'avoir des fichiers non lisibles. 
Créer des fichiers accessibles en lecture implique aussi que vous n'avez pas 
à construire des programmes «&nbsp;set-id&nbsp;», ce qui réduit le risque de 
failles de sécurité.
</p>
	<p>
	  Conformément au «&nbsp;FHS&nbsp;», les binaires des jeux seront
installés dans le répertoire <file>/usr/games</file>. Cela s'applique
aussi aux jeux utilisant le système <em>X Window</em>. On installera les 
pages de manuel des jeux («&nbsp;X&nbsp;» et «&nbsp;non-X&nbsp;») dans
<file>/usr/share/man/man6</file>.
</p>
</sect>
</chapt>
      
    <chapt id="docs">
<heading>La documentation</heading>
	
      
      <sect>
	<heading>Les pages du manuel</heading>
	  
	<p>
On installera les pages de manuel sous la forme d'un source
<prgn>nroff</prgn>, à l'emplacement approprié dans <file>/usr/share/man</file>.
Vous utiliserez uniquement les sections 1 à 9 (voir le FHS pour
plus de détails). Vous ne devez pas installer de
pages «&nbsp;cat&nbsp;» préformatées.
</p>
<p>
Chaque programme, utilitaire ou fonction aura une page de manuel associée
dans le même paquet. On suggère aussi que chaque fichier de configuration
ait une page de manuel associée. Pour des protocoles ou des programmes
secondaires, les pages de manuel sont facultatives.
</p>	  
	<p>
L'absence de page de manuel est considérée comme un bogue et un rapport sera 
envoyé au système Debian de suivi de bogues (le responsable du paquet peut
écrire lui-même ce rapport, s'il le souhaite). On ne doit pas fermer le
rapport tant que la page de manuel n'est pas disponible <footnote>
<p>
Ce n'est pas très difficile d'écrire une page de manuel. Voyez le
<url id="http://www.schweikhardt.net/man_page_howto.html" 
name="Man-Page-HOWTO">, la page <manref name="man" section="7">, les exemples
créés par <prgn>debmake</prgn> ou par <prgn>dh_make</prgn>, les programmes
d'aide <prgn>help2man</prgn>, ou les exemples dans le répertoire
<file>/usr/share/doc/man-db/examples</file>.
	    </p>
	  </footnote>.
</p>
	  
	<p>
Vous pouvez faire suivre une plainte concernant l'absence d'une page du manuel
aux auteurs originaux, et signaler qu'un rapport de bogue a été envoyé au 
système Debian de suivi des bogues. Même si le projet GNU ne considère pas en
général l'absence d'une page du manuel comme un bogue, nous oui. S'ils vous
répondent qu'ils ne considèrent pas cela comme un bogue, laissez quand même 
le bogue ouvert dans notre système de suivi.
</p>
	  
	<p>
Les pages de manuel seront installées comprimées avec <tt>gzip -9</tt>.
</p>
	<p>
Si une page de manuel doit être accessible via différents noms, il est
préférable d'utiliser un lien symbolique plutôt que la fonctionnalité
<tt>.so</tt>, mais il est inutile de bricoler les parties
incriminées dans les sources originaux pour changer les <tt>.so</tt>
en liens symboliques (à moins que ce soit trivial).
Ne créez pas de lien physique dans les répertoires des pages du manuel
et ne mettez pas de chemin absolu dans les directives <tt>.so</tt>.
Le nom du fichier dans le <tt>.so</tt> d'une page du manuel sera
relatif à la racine des pages (habituellement <tt>/usr/share/man</tt>).
Si l'on ne crée pas de liens (liens symboliques, liens «&nbsp;en dur&nbsp;» 
ou des directives <tt>.so</tt>) dans le système de fichiers pour les autres 
noms de cette page, on ne comptera pas sur <prgn>man</prgn> pour trouver la
page de manuel sous ces noms à partir des seuls renseignements contenus dans
l'en-tête de la page<footnote>
<p>
Cette faculté demande à <prgn>man</prgn> un temps de calcul déraisonnable
pour trouver une page de manuel, rapporter qu'elle n'existe pas et
transférer dans sa base de données une information qui devrait rester dans le
système de fichier. Elle est déconseillée et cessera d'exister à l'avenir.
	    </p>
	  </footnote>.
</p>
</sect>
	  
      <sect>
	<heading>Les documents «&nbsp;Info&nbsp;»</heading>
	  
	<p>

On installera les documents «&nbsp;Info&nbsp;» dans <tt>/usr/share/info</tt>.
Ils seront comprimés avec <tt>gzip -9</tt>.
</p>
	<p>
Votre paquet appellera <prgn>install-info</prgn>, dans le script 
<prgn>postinst</prgn>, appelé par exemple avec un argument <tt>configure</tt>,
pour mettre à jour le fichier <tt>dir</tt> de «&nbsp;Info&nbsp;»&nbsp;:
	  <example compact="compact">
install-info --quiet --section Development Development \
/usr/share/info/foobar.info
	  </example></p>
	  
	<p>
Il est judicieux de spécifier une section pour l'emplacement de votre
programme&nbsp;; cela se fait avec l'option <tt>--section</tt>.
Pour déterminer la section à utiliser, vous devez consulter
<tt>/usr/share/info/dir</tt> sur votre système et choisir la plus adéquate
(ou créer une nouvelle section si aucune des sections actuelles n'est
adaptée). Notez que l'option <tt>--section</tt> prend deux arguments&nbsp;;
le premier est une expression régulière pour rechercher une section
existante (indépendamment de la casse), le second est utilisé pour la création
d'une nouvelle section.
</p>
	<p>
Vous retirerez les entrées dans le script <prgn>prerm</prgn> appelé avec un
argument <tt>remove</tt>&nbsp;:
	  <example compact="compact">
install-info --quiet --remove /usr/share/info/foobar.info
	  </example></p>
	  
	<p>
Si <prgn>install-info</prgn> ne trouve pas une entrée descriptive dans
le fichier Info, vous devrez en fournir une. Voir
<manref name="install-info" section="8"> pour des précisions.
</p>
</sect>
      
      <sect>
	<heading>Documentations supplémentaires</heading>
	
	<p>
Le responsable d'un paquet peut installer toute documentation supplémentaire 
qui vient avec ce paquet. Les documents texte seront placés dans le 
répertoire <tt>/usr/share/doc/<var>paquet</var></tt>,
et comprimés avec <tt>gzip -9</tt> à moins qu'ils soient petits.
</p>
	
	<p>
Si un paquet contient une importante documentation dont la majorité des
utilisateurs du paquet n'a pas besoin, vous la mettrez dans un paquet binaire
distinct. Ainsi elle ne prendra pas d'espace disque sur
les machines des utilisateurs qui n'en ont pas besoin ou qui ne veulent
pas l'installer.
</p>

	
	<p>
Il est souvent judicieux de mettre les fichiers d'informations
(<tt>README</tt>, changelogs, etc.) provenant du paquet source
dans <tt>/usr/share/doc/<var>paquet</var></tt> au sein des paquets binaires.
Bien entendu, vous n'avez pas besoin de fournir les instructions
de compilation et d'installation.
</p>

<p>
Aucun programme ne demandera, pour son fonctionnement, que des fichiers 
existent dans <tt>/usr/share/doc</tt> <footnote>
<p>
L'administrateur système pourra supprimer tout fichier dans 
<file>/usr/share/doc/</file> sans craindre de <em>planter</em>
un programme. 
	    </p>
	  </footnote>.
Tout fichier référencé par un programme et qui est utile
en tant que documentation indépendante sera installé dans 
<file>/usr/share/<var>paquet</var>/</file> et lié symboliquement avec
<file>/usr/share/doc/<var>paquet</var>/</file>.
	</p>
<p>
<file>/usr/share/doc/<var>paquet</var></file> peut être un lien symbolique
vers un autre répertoire de <file>/usr/share/doc</file> seulement si
les deux paquets proviennent de la même source et si le premier paquet
dépend du second. <footnote>
            <p>

Il faut remarquer que cela n'annule pas la section dans les fichiers
changelog et le fichier <file>/usr/share/<var>package</var>/changelog.Debian.gz</file>
doit se référer au changelog de la version courante du <var>paquet</var>
en question. En pratique, cela signifie que la source de la cible
et la destination du lien symbolique doivent être identiques 
(même paquet source et même version).
            </p>
          </footnote>
</p>
       <p>
Les précédentes versions de Debian plaçaient toute la documentation 
supplémentaire dans <file>/usr/doc/<var>paquet</var></file>. C'est maintenant
<file>/usr/share/doc/<var>paquet</var></file>, et les paquets ne doivent pas
mettre de la documentation dans le répertoire 
<file>/usr/doc/<var>paquet</var></file> <footnote>
<p>
À ce moment de la transition, nous n'avons plus besoin d'un lien symbolique
vers <file>/usr/doc/</file>. Plus tard, la charte transformera ces liens
symboliques en bogues.</p>
	  </footnote>.
	</p>
      </sect>
     
    
  <sect>
	<heading>Les formats préférés pour la documentation </heading>
	
	<p>
L'unification de la documentation Debian se fait autour du format HTML.
</p>
	
	<p>
Si votre paquet comprend une importante documentation dans un format balisé
qui peut être converti en d'autres formats, vous livrerez
si possible la version HTML dans le paquet binaire, dans le répertoire
<tt>/usr/share/doc/<var>paquet-approprié</var></tt> ou l'un de ses 
sous-répertoires
<footnote>
 <p> 
 Le raisonnement&nbsp;: ce qui importe ici, c'est que les documents HTML 
 soient disponibles dans <em>certains</em> paquets, et pas
 nécessairement dans le paquet binaire principal.
 </p>
</footnote>.

</p>
	<p>
Le responsable de paquet peut fournir à sa guise d'autres formats, comme 
PostScript.
</p>
</sect>
      
      <sect id="copyrightfile">
	<heading>Les informations de copyright</heading>
	
	<p>
Chaque paquet doit être accompagné d'une copie <em>verbatim</em> de son 
copyright ainsi que de sa licence de distribution dans le fichier
<tt>/usr/share/doc/<var>paquet</var>/copyright</tt>. Ce fichier ne doit 
pas être comprimé ni être un lien symbolique.
</p>
	<p>
De plus, le fichier de copyright doit préciser où ont été obtenus
les fichiers sources originaux (s'ils existent). Il nommera les auteurs 
originaux  et le(s) responsable(s) Debian qui ont ½uvré à la création 
du paquet.
</p>

<p>
Une copie du fichier installé dans 
<file>/usr/share/doc/<var>paquet</var>/copyright</file> sera faite dans le
<file>debian/copyright</file> du paquet source.</p>

	<p>
<file>/usr/share/doc/<var>paquet</var></file> peut être un lien symbolique 
vers un répertoire de <file>/usr/share/doc</file> seulement si, de deux 
paquets 
provenant tous les deux de la même source, le premier possède une relation 
«&nbsp;Depends&nbsp;» avec le second. Ces règles sont importantes car 
on doit pouvoir extraire les copyrights par des moyens automatiques.
</p>
	<p>
Les paquets distribués sous la licence «&nbsp;UCB BSD&nbsp;», la licence 
«&nbsp;Artistic&nbsp;», la licence «&nbsp;GNU GPL&nbsp;» ou la licence 
«&nbsp;GNU LGPL&nbsp;» feront respectivement référence aux fichiers
correspondants sous <file>/usr/share/common-licenses</file>,<footnote>
            <p>
              Par exemple,
              <file>/usr/share/common-licenses/Artistic</file>,
              <file>/usr/share/common-licenses/BSD</file>,
              <file>/usr/share/common-licenses/GPL</file>,
              <file>/usr/share/common-licenses/LGPL</file>,
              <file>/usr/share/common-licenses/GFDL</file>,
              <file>/usr/share/common-licenses/GPL-2</file> et
              <file>/usr/share/common-licenses/LGPL-2.1</file> et ainsi de
              suite. Notez que la GFDL est nouvelle ici et que le fichier de
              licence peut ne pas être encore en place dans
              <file>/usr/share/common-licenses/GFDL</file>. 
            </p>
          </footnote>
plutôt que de les citer dans le fichier de copyright. 
</p>
	
	<p>
Vous ne devez pas utiliser le fichier copyright comme un fichier 
<file>README</file> général. Si votre paquet possède un tel fichier, vous 
l'installerez dans <file>/usr/share/doc/<var>paquet</var>/README</file> ou 
<file>README.Debian</file> ou dans un autre endroit approprié.
</p>
</sect>

<sect>
<heading>Exemples</heading>

<p>
On installera tous les exemples (configuration, fichiers source, autres) dans 
un répertoire <file>/usr/share/doc/<var>paquet</var>/examples</file>.
Ces fichiers ne seront pas utilisés par un quelconque programme.
Ils ne sont là qu'en tant que documentation, et pour le seul bénéfice de 
l'administrateur système et des utilisateurs.
On installera les exemples concernant une architecture particulière dans un 
répertoire <file>/usr/lib/<var>paquet</var>/examples</file> et les fichiers 
dans <file>/usr/share/doc/<var>paquet</var>/examples</file> seront des liens 
symboliques. Ou bien, ce dernier répertoire sera un lien vers le premier.
</p>
       <p>
Si le but d'un paquet est de fournir des exemples, les fichiers d'exemples
peuvent être installés dans <file>/usr/share/doc/<var>paquet</var></file>.
       </p>

</sect>

<sect id="changelogs">
<heading>Les fichiers «&nbsp;Changelog&nbsp;»</heading>
<p>
Les paquets qui ne sont pas originaires de Debian doivent contenir,
dans <file>/usr/share/doc/<var>paquet</var></file>, une copie compressée nommée
<file>changelog.Debian.gz</file> du fichier <file>debian/changelog</file> qui 
est dans l'arborescence des sources.
	</p>
<p>
S'il existe un «&nbsp;changelog&nbsp;» original, il sera accessible comme un 
fichier texte, <file>/usr/share/doc/<var>paquet</var>/changelog.gz</file>.
Si le «&nbsp;changelog&nbsp;» original est distribué comme un fichier HTML,
il sera rendu disponible en tant que
<file>/usr/share/doc/<var>paquet</var>/changelog.html.gz</file> et le
<file>changelog.gz</file> sera produit en utilisant p. ex.
<tt>lynx -dump -nolist</tt>.
Si le changelog original n'est pas déjà conforme 
à cette convention, alors cela peut être réalisé soit en renommant ce fichier 
soit en créant un lien symbolique, c'est à la convenance du responsable
du paquet<footnote><p> Argument : on n'a pas à chercher dans deux endroits
les «&nbsp;changelogs&nbsp;» originaux simplement parce qu'ils ont des noms
différents ou parce qu'ils sont dans un format HTML.</p></footnote>.
</p>

<p>
Ces fichiers seront installés comprimés par <tt>gzip -9</tt>, car 
ils grossissent avec le temps même s'ils commencent petitement.
</p>

<p>
Quand un paquet a un seul changelog, utilisé à la fois comme
changelog Debian et changelog original car le responsable principal est le même
que le responsable Debian, on appellera simplement ce changelog&nbsp;:
<file>/usr/share/doc/<var>paquet</var>/changelog.gz</file>. S'il y a un 
responsable principal mais pas de changelog source, on appellera toujours le 
changelog Debian&nbsp;: <file>changelog.Debian.gz</file>.
</p>
       <p>
Pour des précisions sur le format et le contenu d'un fichier changelog de 
Debian, voyez <ref id="dpkgchangelog">.
        </p>

</sect>
</chapt>

<appendix id="pkg-scope">
<heading>Introduction : la portée des ces annexes</heading>

<p>
Ces annexes sont tirées essentiellement <em>verbatim</em> du 
<em>Packaging Manual</em>, version 3.2.1.0, dont l'usage est maintenant 
déconseillé. Elles contiennent les chapitres qui peuvent aider les 
responsables de paquet et qui n'ont pas été inclus dans la Charte elle-même. 
La plupart de ces sections ne sont sans doute pas pertinentes pour une
charte&nbsp;; elles seront vues comme une documentation du système 
d'empaquetage.
Veuillez remarquer que ces annexes ont été incluses pour leur utilité et
pour des raisons historiques&nbsp;: elles faisaient partie du paquet 
«&nbsp;policy&nbsp;» et n'ont pas encore intégré la documentation de
<prgn>dpkg</prgn>. Cependant, elles sont utiles et sont donc présentées ici.
      </p>
<p>
On ne s'est pas assuré qu'elles étaient compatibles avec le contenu de la 
Charte&nbsp;; s'il y a contradiction, la version de la Charte prime. On ne 
s'est pas assuré non plus qu'aucune partie des chapitres restants du vieux 
<em>Packaging Manual</em> n'a été oubliée. Ces deux choses seront faites en 
temps et en heure.
      </p>
      <p>
Des parties du <em>Packaging Manual</em> ont été intégrées dans la Charte et
supprimées de ces annexes. Des liens renvoient de l'ancienne place à la
nouvelle.
      </p>

<p>
<prgn>dpkg</prgn> est un ensemble de programmes servant à la création, 
l'installation et la suppression des fichiers des paquets binaires sur les 
systèmes Unix
<footnote><p><prgn>dpkg</prgn> est conçu d'abord pour Debian GNU/Linux, mais
peut fonctionner sur, ou être porté vers, d'autres systèmes.</p></footnote>.
      </p>
<p>
Les paquets binaires sont conçus pour la gestion des programmes exécutables
installés (habituellement des binaires compilés) et de leurs données 
associées, bien que les exemples de code source et la documentation fassent 
partie de certains paquets.
      </p>
<p>
Ce manuel décrit les aspects techniques de la création des paquets binaires 
Debian (fichiers <tt>.deb</tt>). Il documente le comportement des
programmes de gestion des paquets <prgn>dpkg</prgn>, 
<prgn>dselect</prgn> et al., et la manière dont ils interagissent avec les 
paquets.
      </p>
<p>
Il précise aussi les interactions entre le c½ur de <prgn>dselect</prgn> et les
méthodes d'accès qu'il utilise pour installer réellement les paquets
sélectionnés, et décrit comment créer une nouvelle méthode d'accès.
      </p>
<p>
Ce manuel ne détaille pas les options et l'utilisation des outils de création
et d'installation des paquets. Il est donc souhaitable de le lire
conjointement avec les pages de manuel de ces programmes.
      </p>
<p>
Les utilitaires qui sont fournis avec <prgn>dpkg</prgn> pour gérer
les problèmes de configuration des différents systèmes, tels
que <prgn>update-rc.d</prgn> et <prgn>install-info</prgn> ne sont pas non 
plus décrits en détail, voyez leurs pages de manuel.
      </p>
<p>
On supposera que le lecteur est familier avec le manuel de
l'administrateur système <prgn>dpkg</prgn>. Malheureusement ce document n'existe pas encore.

      </p>
<p>
La version Debian du programme GNU <prgn>hello</prgn> de la <em>FSF</em> est 
proposé comme exemple aux personnes qui souhaitent créer des paquets Debian. 
Le paquet Debian <prgn>debmake</prgn> est un outil recommandé pour la 
création et
la maintenance des paquets Debian. Bien qu'utiles, ces outils et les
exemples ne peuvent cependant dispenser de la lecture de la Charte.
      </p>
    </appendix>

<appendix id="pkg-binarypkg">
<heading>Les paquets binaires (annexe tirée de l'ancien <em>Packaging Manual</em>)</heading>
<p>
Un paquet binaire comporte deux parties principales. La première comprend 
divers fichiers d'information de contrôle et des scripts utilisés
par <prgn>dpkg</prgn> lors de l'installation ou de la dés-installation. Voir
<ref id="pkg-controlarea">.
      </p>
<p>
La deuxième partie est une archive contenant les fichiers et les
répertoires à installer.
      </p>
<p>
À l'avenir les paquets binaires pourront contenir d'autres composants,
comme des sommes de contrôle ou des signatures numériques. Le format
de l'archive est décrit dans la page de manuel de <tt>deb(5)</tt>.
      </p>

<sect id="pkg-bincreating"><heading>Comment créer les fichiers d'un paquet&nbsp;? -- <prgn>dpkg-deb</prgn></heading>
<p>
Toutes les manipulations des fichiers d'un paquet binaire se font avec 
<prgn>dpkg-deb</prgn>&nbsp;; c'est le seul programme qui connaisse le format. 
<prgn>dpkg-deb</prgn> peut être appelé par <prgn>dpkg</prgn>, car 
<prgn>dpkg</prgn> reconnaît que les options qui lui sont données appartiennent
à <prgn>dpkg-deb</prgn> et l'appelle avec ces arguments.
	</p>
<p>
Pour créer un paquet binaire, on doit créer une arborescence qui
contient tous les fichiers et répertoires destinés à la partie « données »
du système de fichiers du paquet. Dans les paquets Debian au format
source, ce répertoire, <tt>debian/tmp</tt>, est habituellement relatif à la
racine de l'arborescence du paquet source.
	</p>
<p>
Ces fichiers auront l'adresse (relativement à la racine de l'arborescence
que l'on construit) et le système de propriété et de permissions que l'on
veut leur donner sur le système où ils seront installés.
</p> 
<p>
Avec les versions actuelles de <prgn>dpkg</prgn>, les identifiants <em>uid</em>
(utilisateur) et les identifiants <em>gid</em> (groupe) utilisés seront les
mêmes pour le système <em>sur</em> lequel on construit que pour le système 
<em>pour</em> lequel on construit.
	</p>
<p>
On doit ajouter un répertoire spécial à la racine de la mini
arborescence créée&nbsp;: <prgn>DEBIAN</prgn>. Il contiendra les
fichiers de contrôle, notamment le fichier de contrôle des
paquets binaires (voir <ref id="pkg-controlfile">).
	</p>
<p>
Le répertoire <tt>DEBIAN</tt> n'apparaîtra pas dans l'archive du système
de fichiers du paquet, et ainsi ne sera pas créé par <prgn>dpkg</prgn>
quand le paquet sera installé.
	</p>
<p>
Quand le paquet est prêt, on appellera&nbsp;:
<example>
dpkg --build <var>répertoire</var>
</example>
	</p>
<p>
Le paquet sera construit dans <file><var>répertoire</var>.deb</file>. 
(<prgn>dpkg</prgn> sait que <tt>--build</tt> est une option de
<prgn>dpkg-deb</prgn> et il appelle <prgn>dpkg-deb</prgn> avec ces arguments
pour construire le paquet.)
	</p>
<p>
Voir les pages de manuel <manref name="dpkg-deb" section="8">
pour savoir comment examiner le contenu de ce fichier fraîchement créé.
Les sorties des commandes suivantes peuvent être éclairantes&nbsp;:
<example>
dpkg-deb --info <var>filename</var>.deb
dpkg-deb --contents <var>filename</var>.deb
dpkg --contents <var>filename</var>.deb
</example>
Pour voir le copyright d'un paquet, on peut utiliser cette commande&nbsp;:
<example>
dpkg --fsys-tarfile <var>filename</var>.deb | tar xOf - \*/copyright | pager
</example>
	</p>
      </sect>

<sect id="pkg-controlarea">
<heading>Les fichiers de contrôle d'un paquet</heading>
<p>
La partie contenant les informations de contrôle d'un paquet binaire est une
collection de fichiers dont les noms sont connus par <prgn>dpkg</prgn>.
<prgn>dpkg</prgn> traitera le contenu de ces fichiers d'une manière spéciale -
certains d'entre eux contiennent des informations utilisées pour 
l'installation ou la suppression d'un paquet&nbsp;; les autres sont des
scripts dont le responsable de paquet désire l'exécution.
	</p>
<p>
Il est possible de mettre d'autres fichiers dans la zone de contrôle du
paquet, mais ce n'est pas une bonne idée (de toute façon ils seront ignorés).
	</p>
<p>
Voici une brève liste  des fichiers de contrôle utilisés par
<prgn>dpkg</prgn> et un résumé de ce qu'ils font.
	</p>
<p>
<taglist>
<tag><tt>control</tt></tag>
<item>
<p>
C'est le principal fichier de description utilisé par <prgn>dpkg</prgn>. Il
indique le nom et la version du paquet, donne sa description pour les
utilisateurs, établit les relations avec les autres paquets, etc.
Voir <ref id="sourcecontrolfiles"> et <ref id="binarycontrolfiles">.
	      </p>
<p>
Ce fichier est créé par le programme <prgn>dpkg-gencontrol</prgn>, avec 
l'aide de <prgn>dpkg-shlibdeps</prgn>, à partir des informations
contenues dans le paquet source. Voir <ref id="pkg-sourcetools">.
	      </p>
	</item>
<tag><tt>postinst</tt>, <tt>preinst</tt>, <tt>postrm</tt>, <tt>prerm</tt></tag>
<item>
<p>
Ce sont des fichiers exécutables (habituellement des scripts) que
<prgn>dpkg</prgn> exécute pendant l'installation, la mise à jour ou
la suppression des paquets. Ils permettent de traiter les particularités
d'un paquet ou celles qui nécessitent un traitement plus
compliqué que celui fourni par <prgn>dpkg</prgn>. Quand et comment ils sont 
appelés est indiqué dans <ref id="maintainerscripts">.
	      </p>
<p>
Il est très important de rendre ces scripts idempotents. 
Voyez <ref id="idempotency">.
	      </p>
<p>
Les scripts de maintenance peuvent compter sur un 
terminal de contrôle et peuvent interagir avec l'utilisateur. 
Voyez <ref id="controllingterminal">.
	      </p>
</item>

<tag><tt>conffiles</tt>
</tag>
<item>
<p>
Ce fichier contient une liste des fichiers de configuration qui doivent être 
gérés automatiquement par <prgn>dpkg</prgn> (voir <ref id="pkg-conffiles">).
Il faut remarquer que tous les fichiers de configuration ne sont pas
nécessairement listés là.
	      </p>
	    </item>
<tag><tt>shlibs</tt>
</tag>
<item>
<p>
Ce fichier contient une liste des bibliothèques partagées fournies par
le paquet avec les informations de dépendances pour chacune. Elle est utilisée
par <prgn>dpkg-shlibdeps</prgn> quand il détermine quelles dépendances sont
nécessaires dans un fichier de contrôle de paquet. Le format du fichier
<tt>shlibs</tt> est décrit dans <ref id="shlibs">.
	      </p>
	    </item>
	  </taglist>
</p>
  </sect>

<sect id="pkg-controlfile">
<heading>Le principal fichier d'informations de contrôle : <tt>control</tt></heading>
        <p>
<tt>control</tt> est le plus important des fichiers pour <prgn>dpkg</prgn>.
Il contient toutes les informations vitales d'un paquet.
        </p>

<p>
Les fichiers de contrôle des paquets binaires construits à partir des sources 
Debian sont faits par un outil spécial <prgn>dpkg-gencontrol</prgn> qui lit 
<tt>debian/control</tt> et <tt>debian/changelog</tt> pour trouver les 
informations dont il a besoin. Voir <ref id="pkg-sourcepkg"> pour des 
précisions.
	</p>
<p>
Les champs d'un fichier de contrôle d'un paquet binaire sont listés
dans <ref id="binarycontrolfiles">.
	</p>
        <p>
La description de la syntaxe de ces champs et de leur signification se
trouve dans <ref id="controlfields">.
        </p>

      </sect>

<sect>
<heading>Les cachets de date</heading>
        <p>
          Voyez <ref id="timestamps">.
        </p>
      </sect>
    </appendix>

<appendix id="pkg-sourcepkg">
<heading>Les paquets sources (annexe tirée de l'ancien<em> Packaging Manual</em>)</heading>
<p>
Les paquets binaires de la distribution Debian sont créés à partir des
paquets sources, lesquels sont dans un format spécial pour faciliter la 
construction automatique des binaires.
      </p>

<sect id="pkg-sourcetools">
<heading>Les outils pour gérer les paquets sources</heading>
<p>
De nombreux outils sont fournis pour manipuler les paquets sources.
Ils emballent et déballent les sources, aident à la construction
des paquets binaires et gèrent la distribution des nouvelles versions.
	</p>
<p>
Ils sont présentés ici et leurs usages habituels décrits&nbsp;; pour de plus 
amples informations, voir <manref name="dpkg-source" section="1">.
	</p>
<p>
Le paquet <prgn>hello</prgn> est un exemple de construction de paquet source 
Debian et de la mise en ½uvre des utilitaires qui y sont impliqués.
	</p>
<sect1 id="pkg-dpkg-source">
<heading><prgn>dpkg-source</prgn> - faire et défaire un paquet source Debian</heading>

<p>
Ce programme est fréquemment utilisé sur la ligne de commande&nbsp;; il est
aussi appelé à partir des scripts de construction automatique de paquet, tel 
que <prgn>dpkg-buildpackage</prgn>.
	  </p>
<p>
Il est appelé ainsi pour dépaqueter un paquet&nbsp;:
<example>
dpkg-source -x <var>.../path/to/filename</var>.dsc
</example>
	  </p>
<p>
avec <file><var>filename</var>.tar.gz</file> et <file><var>filename</var>.diff.gz</file> (si c'est utile) dans le même répertoire. Il dépaquette dans
<file><var>package</var>-<var>version</var></file>, et, si c'est utile, 
<file><var>package</var>-<var>version</var>.orig</file>, dans le répertoire
actuel.
	  </p>
<p>
Pour créer un paquet, on utilise :

<example>
    dpkg-source -b <var>paquet</var>-<var>version</var>
</example>
	  </p>
<p>

Les fichiers <file>.dsc</file>, <file>.tar.gz</file> et <file>.diff.gz</file> 
seront
créés (si c'est utile) dans le répertoire courant. <prgn>dpkg-source</prgn> 
n'efface pas l'arborescence des sources. Cela doit être fait séparément, si 
nécessaire.
	  </p>
<p>
Voir aussi <ref id="pkg-sourcearchives">.
	  </p>
	</sect1>

<sect1 id="pkg-dpkg-buildpackage">
<heading><prgn>dpkg-buildpackage</prgn> - script de contrôle pour la 
construction de paquet</heading>
<p>
<prgn>dpkg-buidpackage</prgn> est un script qui fait appel à 
<prgn>dpkg-source</prgn>, aux cibles de <tt>debian/rules</tt>&nbsp;:
<tt>clean</tt>, <tt>build</tt> et <tt>binary</tt>, à
<prgn>dpkg-genchanges</prgn> et à <prgn>pgp</prgn> 
(ou <prgn>pgp</prgn>) pour construire des paquets 
signés, source et binaire, installables sur le serveur.
	  </p>
<p>
Il est généralement utilisé sur la ligne de commande, à la racine du répertoire
source à créer ou à détruire. Il peut être invoqué sans arguments.
Les arguments utiles sont&nbsp;:
<taglist compact="compact">
<tag><tt>-uc</tt>, <tt>-us</tt></tag>
<item>

<p>
ne pas chiffrer, respectivement le fichier <tt>.changes</tt>
et le fichier paquet source <tt>.dsc</tt>.
		</p>
	      </item>
<tag><tt>-p<var>sign-command</var></tt></tag>
<item>
<p>
Invoque la commande <var>sign-command</var>
au lieu de chercher <tt>gpg</tt> ou <tt>pgp</tt> dans la variable 
<tt>PATH</tt>.
<var>sign-command</var> doit avoir le même comportement que 
<prgn>gpg</prgn> ou <tt>pgp</tt>.
		</p>
	      </item>
<tag><tt>-r<var>root-command</var></tt></tag>
<item>
<p>
Quand les privilèges de root sont nécessaires, invoque
la commande <var>root-command</var>. <var>root-command</var> invoquera
son premier argument comme une commande, dans le <tt>PATH</tt> si nécessaire,
et passera son second argument et les autres à la commande qu'il appelle.
Si aucune <var>root-command</var> n'est fournie, 
<prgn>dpkg-buildpackage</prgn> ne fera rien pour obtenir les 
privilèges de root&nbsp;; ainsi, pour la plupart des programmes, il devra être 
appelé par root pour démarrer.
		</p>
	      </item>
<tag><tt>-b</tt>, <tt>-B</tt></tag>
<item>
<p>
Deux types de construction et d'installation pour les binaires,
voir <manref name="dpkg-source" section="1">.
		</p>
	      </item>
	    </taglist></p>
	</sect1>
 <sect1 id="pkg-dpkg-gencontrol">
<heading><prgn>dpkg-gencontrol</prgn> - créer des fichiers de contrôle pour
les paquets binaires</heading>
<p>
Ce programme est habituellement appelé à partir du fichier 
<file>debian/rules</file> (voir <ref id="pkg-sourcetree">) depuis la racine de 
l'arborescence source.
</p>
<p>
On l'appelle juste avant que ne soit établi le système des permissions pour 
les fichiers et les répertoires du répertoire temporaire où le paquet est 
construit et avant la construction du paquet par <prgn>dpkg-deb</prgn>
<footnote><p>Il en est ainsi afin que le fichier de contrôle produit possède 
les bonnes permissions.</p></footnote>.
	  </p>
<p>
<prgn>dpkg-gencontrol</prgn> doit être appelé après que tous les fichiers du
paquet ont été mis en place dans le répertoire temporaire de construction,
afin que le calcul de la taille du paquet installé soit correct.
	  </p>
<p>
Il faut aussi que <prgn>dpkg-gencontrol</prgn> soit exécuté après
<prgn>dpkg-shlibdeps</prgn> afin que les variables de substitutions, créées par
<prgn>dpkg-shlibdeps</prgn> dans le fichier <tt>debian/substvars</tt>, soient
disponibles.
	  </p>
<p>
Un paquet qui crée un seul paquet binaire et qui le construit
dans le répertoire <tt>debian/tmp</tt> relatif à la racine du paquet
source, appellera simplement&nbsp;: <prgn>dpkg-gencontrol</prgn>.
	  </p>
<p>
Les sources qui construisent plusieurs binaires utiliseront&nbsp;:
<example>
dpkg-gencontrol -Pdebian/tmp-<var>pkg</var> -p<var>paquet</var>
</example>
L'argument <tt>P</tt> indique à <prgn>dpkg-gencontrol</prgn> que le paquet est
en train de se construire dans un répertoire différent de celui par défaut
et l'argument <tt>-p</tt> indique le fichier de contrôle qui sera créé.
	  </p>
<p>
<prgn>dpkg-gencontrol</prgn> ajoute aussi des informations à la liste des 
fichiers dans <tt>debian/files</tt>&nbsp;; cela peut servir à un prochain appel à
<prgn>dpkg-genchanges</prgn>.
	  </p>
	</sect1>
<sect1 id="pkg-dpkg-shlibdeps">
<heading><prgn>dpkg-shlibdeps</prgn> - les dépendances des bibliothèques partagées</heading>
<p>
Ce programme est habituellement appelé à partir du fichier 
<file>debian/rules</file>,
juste avant <prgn>dpkg-gencontrol</prgn> (voir <ref id="pkg-sourcetree">),
à la racine de l'arborescence source.
	  </p>
<p>
Les arguments sont des exécutables <footnote>
<p>
Dans une prochaine version de dpkg, <prgn>dpkg-shlibdeps</prgn> serait aussi
appelé pour les bibliothèques partagées.
</p>
<p>
Ils peuvent être spécifiés soit dans les emplacements de l'arborescence source
où ils sont créés soit dans les emplacements de l'arborescence temporaire de 
construction où ils sont installés avant la création du paquet binaire.
	      </p>
	    </footnote> pour lesquels les dépendances des bibliothèques
partagées seront incluses dans le fichier de contrôle du paquet.
	  </p>
<p>
Si certaines bibliothèques partagées doivent seulement justifier d'un
<tt>Recommends</tt> ou d'un <tt>Suggests</tt>, ou si certaines demandent un
<tt>Pre-Depends</tt>, cela peut être réalisé en utilisant l'option
<tt>-d</tt><em>dependency-field</em> avant ces exécutables
(chaque option <tt>-d</tt> prend effet jusqu'au prochain <tt>-d</tt>).
	  </p>
<p>
<prgn>dpkg-shlibdeps</prgn> ne modifie pas directement le fichier de contrôle.
Par défaut, il ajoute au fichier <file>debian/substvars</file> des variables 
comme <tt>shlibs:Depends</tt>. Ces variables doivent être référencées dans les 
champs de dépendance du fichier de contrôle source dans les sections propres 
aux paquets binaires.
	  </p>
<p>
Par exemple, un paquet, avec une partie essentielle qui demande des 
dépendances et des parties facultatives qui ne demandent que des
recommandations, séparerait ces dépendances en deux champs <footnote>
On peut trouver aujourd'hui un exemple avec le paquet 
<package>xmms</package> dont le champ Depends est utilisé pour l'exéutable
xmms, le champ Recommends pour des extensions («&nbsp;plug-ins&nbsp;» et le
champ Suggests par d'autres fonctionnalités fournies par unzip.
	    </footnote>.
Cela peut être indiqué dans le fichier <tt>debian/rules</tt> par&nbsp;:
<example>
  dpkg-shlibdeps -dDepends <var>programme autreprogramme ...</var> \
                 -dRecommends <var>partiefacultative autrepartiefacultative</var>

</example>
et ensuite dans le fichier principal de contrôle <file>debian/control</file>&nbsp;:
<example>
<var>...</var>
Depends: ${shlibs:Pre-Depends}
Recommends: ${shlibs:Recommends}
<var>...</var>
</example>
	  </p>
<p>
Les sources qui produisent plusieurs paquets binaires avec des exigences 
différentes pour les dépendances envers les bibliothèques partagées peuvent 
utiliser l'option <tt>-p<var>varnameprefix</var></tt> pour annuler le préfixe 
<tt>shlibs:</tt> par défaut (un seul appel à <prgn>dpkg-shlibdeps</prgn>
par réglage de cette option). Ils peuvent ainsi produire plusieurs ensembles 
de variables de dépendance, chacune de la forme 
<tt><var>varnameprefix</var>:<var>dependencyfield</var></tt>, auxquelles 
peuvent se référer les parties appropriées des fichiers de contrôle des 
paquets binaires.
	  </p>
	</sect1>

<sect1 id="pkg-dpkg-distaddfile">
<heading><prgn>dpkg-distaddfile</prgn> - ajouter un fichier à <file>debian/files</file></heading>
<p>
Certaines installations de paquets sur le serveur nécessitent d'inclure 
d'autres fichiers que les fichiers des paquets sources et binaires.
	  </p>
<p>
<prgn>dpkg-distaddfile</prgn> ajoute un fichier dans 
<file>debian/files</file> afin
qu'il soit inclus dans le fichier <file>.changes</file> lorsque 
<prgn>dpkg-genchanges</prgn> sera lancé.
	  </p>
<p>
Il est habituellement invoqué à partir de la cible <prgn>binary</prgn> du 
fichier <tt>debian/rules</tt>&nbsp;:
<example>
dpkg-distaddfile <var>fichier</var> <var>section</var> <var>priority</var>
	    </example>
L'argument <var>filename</var> est relatif au répertoire où 
<prgn>dpkg-genchanges</prgn> s'attend à le trouver, généralement au-dessus de 
la racine de l'arborescence source. La règle de <tt>debian/rules</tt> devrait 
placer ce fichier juste avant ou juste après l'appel à 
<prgn>dpkg-distaddfile</prgn>.
	  </p>
<p>
Les arguments <var>section</var> et <var>priority</var> sont placés sans 
modification dans le fichier résultant <file>.changes</file>.
	  </p>
	</sect1>

<sect1 id="pkg-dpkg-genchanges">
<heading><prgn>dpkg-genchanges</prgn> - créer un fichier de contrôle de
l'installation sur le serveur <file>.changes</file></heading>
<p>
Ce programme est généralement appelé par des scripts de construction automatique de paquet tels que <prgn>dpkg-buildpackage</prgn> mais peut être aussi 
appelé sur la ligne de commande.
	  </p>
<p>
Il est habituellement exécuté à la racine de l'arborescence source construite,
et quand il est invoqué sans arguments, il écrira un simple fichier 
<file>.changes</file> basé sur les informations des fichiers de contrôle et 
de changement des paquets sources, et des paquets
sources et binaires qui ont dû être construits.
	  </p>
	</sect1>

<sect1 id="pkg-dpkg-parsechangelog">
<heading><prgn>dpkg-parsechangelog</prgn> - produire une représentation du fichier <tt>changelog</tt></heading>
<p>
Ce programme est utilisé en interne par <prgn>dpkg-source</prgn> et al.
Il peut être aussi occasionnellement utilisé dans <file>debian/rules</file> et 
ailleurs. Il analyse un fichier <em>changelog</em>, par défaut 
<file>debian/changelog</file>, et affiche sur la sortie standard une 
représentation des informations 
contenues faite selon le format d'un fichier de contrôle.
	  </p>
	</sect1>

<sect1 id="pkg-dpkg-architecture">
<heading><prgn>dpkg-architecture</prgn> - informations
sur les systèmes de construction et d'installation</heading>

<p>
On peut utiliser ce programme sur la ligne de commande&nbsp;; mais il est aussi
appelé par <tt>dpkg-buildpackage</tt> ou <file>debian/rules</file> pour
déterminer les variables d'environnement qui indiquent les architectures 
utilisées pour la construction et pour l'installation pendant le processus
de construction du paquet.
	  </p>
	</sect1>
      </sect>

<sect id="pkg-sourcetree"><heading>L'arborescence debianisée</heading>
<p>
La structure de l'archive source, décrite ci-dessous, a été conçue pour 
permettre à une arborescence source debianisée et ses informations de 
contrôle associées d'être facilement dupliquée et transportée. L'arborescence 
source debianisée comprend une version du programme original, certains 
fichiers ajoutés pour le processus de debianisation, ainsi que tous les
changements nécessaires réalisés sur les codes sources et scripts 
d'installation.
	</p>
<p>
Les fichiers supplémentaires créés pour Debian sont dans le répertoire 
<file>debian</file> à la racine de l'arborescence source debianisée. Ils sont 
décrits ci-dessous.
	</p>

<sect1 id="pkg-debianrules">
<heading><file>debian/rules</file> - le script principal de construction</heading> 
          <p>
Voyez <ref id="debianrules">.
          </p>

        <sect1 id="pkg-dpkgchangelog">
          <heading><file>debian/changelog</file></heading>

          <p>
Voyez <ref id="dpkgchangelog">.
          </p>

          <p>
Il est recommandé que tout le fichier changelog soit codé en
<url id="http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2279.html" name="UTF-8">
   de <url id="http://www.unicode.org/" name="Unicode"> <footnote>
              <p>
Il me paraît évident que nous devrons passer au codage UTF-8 pour notre
infrastructure des paquets. C'est réellement le seul codage adéquat à un
environnement international. Mais nous ne pouvons l'utiliser dans les
champs des fichiers de contrôle des paquets tant que dpkg n'accepte pas
ce codage. On peut malgré tout demander aujourd'hui que les fichiers
changelogs soient codés en UTF-8.
              </p>
              <p>
Vérifier la présence de caractères n'appartenant pas à UTF-8 dans les
changelogs est facile. Passer le fichier dans
<example>iconv -f utf-8 -t ucs-4</example>, délaisser la sortie et
vérifier la valeur de retour. Si des chaînes comportent des séquences
qui n'appartiennent pas à UTF-8, iconv s'arrêtera avec un code d'erreur.
Ce sera pareil avec la grande majorité des autres jeux de caractères.
              </p>
            </footnote>
          </p>

          <sect2><heading>Comment définir des formats alternatifs pour le 
fichier <tt>changelog</tt></heading>
<p>
Il est possible d'utiliser un format différent de celui proposé,
en fournissant un analyseur pour le format qu'on veut utiliser.
          </p>
<p>
Pour que <tt>dpkg-parsechangelog</tt> exécute l'analyseur, on inclura une
ligne à l'intérieur des quarante dernières lignes du fichier correspondant à
l'expression rationnelle Perl suivante&nbsp;:
<tt>\schangelog-format:\s+([0-9a-z]+)\W</tt>. La partie entre parenthèses sera
le nom du format. Par exemple, on pourrait dire&nbsp;:
<example>
@@@ changelog-format: joebloggs @@@
</example>
Les noms des formats pour changelog sont des chaînes non vides 
de caractères alphanumériques.
</p>
<p>
Quand une telle ligne existe, <tt>dpkg-parsechangelog</tt> cherche l'analyseur
dans <file>/usr/lib/dpkg/parsechangelog/<var>format-name</var></file> ou dans
<file>/usr/local/lib/dpkg/parsechangelog/<var>format-name</var></file>&nbsp;;
c'est une erreur de ne pas le trouver, ou qu'il ne soit pas exécutable. Le
format changelog par défaut est <tt>dpkg</tt> et un analyseur est fourni
avec le paquet <tt>dpkg</tt>.
            </p>
<p>
L'analyseur sera invoqué, au début du fichier, avec le changelog ouvert sur
l'entrée standard. Il lira le fichier (ou le parcourra avec seek) pour
trouver l'information et la retourner analysée sur la sortie standard sous la
forme d'une série de champ de contrôle dans le format standard. Par défaut,
il retournera seulement les informations les plus récentes du fichier
changelog&nbsp;; il acceptera l'option <tt>-v</tt><em>version</em> pour
retourner les informations de changement de toutes les versions présentes
strictement supérieures à <em>version</em> et ce sera donc une erreur que
<var>version</var> soit absent dans le fichier changelog.
            </p>
             <p>
              Voici les champs :
              <list compact="compact">
                <item><qref id="f-Source"><tt>Source</tt></qref></item>
                <item><qref id="f-Version"><tt>Version</tt></qref> (obligatoire)</item>
                <item><qref id="f-Distribution"><tt>Distribution</tt></qref> (obligatoire)</item>
                <item><qref id="f-Urgency"><tt>Urgency</tt></qref> (obligatoire)</item>
                <item><qref id="f-Maintainer"><tt>Maintainer</tt></qref> (obligatoire)</item>
                <item><qref id="f-Date"><tt>Date</tt></qref></item>
                <item><qref id="f-Changes"><tt>Changes</tt></qref> (obligatoire)</item>
              </list>
            </p>
<p>
Si plusieurs versions sont retournées (à cause de l'utilisation
de l'option <tt>-v</tt>), la valeur <tt>urgency</tt> sera la plus grande
listée par toutes les versions requises et sera suivie par les commentaires
concaténés
(séparés par une espace) de toutes les versions requises&nbsp;; les
champs&nbsp;: maintainer, version, distribution et date proviennent toujours
de la version la plus récente.
            </p>
<p>
Pour le format du champ <tt>Changes</tt> voir <ref id="f-Changes">.
            </p>
<p>
Si le format du fichier <tt>changelog</tt> analysé laisse toujours ou presque
toujours une ligne vide entre les notes de modifications individuelles, ces
lignes vides seront supprimées, pour rendre la sortie résultante plus compacte.
            </p>
<p>
Si le format de changelog ne contient pas de date ou d'information sur le nom
du paquet, ces informations seront omises en sortie. L'analyseur ne doit pas
essayer de les synthétiser ou de les trouver à partir d'autres sources.
            </p>
<p>
Si le fichier changelog n'a pas le format attendu, l'analyseur se terminera
avec un statut différent de zéro, plutôt que d'essayer de se débrouiller tant
bien que mal et créer des sorties incorrectes.
            </p>
<p>
Un analyseur de changelog ne doit pas être interactif.
          </p>
	  </sect2>
	</sect1>


<sect1 id="pkg-srcsubstvars">
<heading><tt>debian/substvars</tt> et les variables de substitution</heading>

          <p>
           Voyez <ref id="substvars">.
          </p>
	</sect1>

<sect1>
<heading><file>debian/files</file></heading>
          <p>
Voyez <ref id="debianfiles">.
          </p>
	</sect1>

<sect1>
<heading><file>debian/tmp</file></heading>

<p>
C'est l'emplacement temporaire, pour la construction des paquets
binaires par la cible <tt>binary</tt>. Le répertoire <tt>tmp</tt> sert
de racine à l'arbre du système de fichier qui est en train de se
construire (par exemple en utilisant la règle d'installation du
<prgn>Makefile</prgn> du paquet original et en le redirigeant dans
<tt>tmp</tt>), et il contient aussi le sous-répertoire <tt>DEBIAN</tt>. Voir
<ref id="pkg-bincreating">.
	  </p>
<p>
Si plusieurs paquets binaires sont créés à partir du même arbre
source, il est habituel d'utiliser plusieurs répertoires
<tt>debian/tmp-truc</tt>, par exemple <tt>tmp-a</tt>
ou <tt>tmp-doc</tt>.
	  </p>
<p>
Quelques soient les répertoires <tt>tmp</tt> créés et utilisés par
<tt>binary</tt>, la cible <tt>clean</tt> doit bien sûr les effacer.
	  </p>
	</sect1>
      </sect>

<sect id="pkg-sourcearchives"><heading>Les paquets sources en tant qu'archive</heading>
<p>
Sur les sites FTP, les paquets sources contiennent trois fichiers reliés
entre eux. On doit avoir les trois bonnes versions pour pouvoir
les utiliser.
	</p>
<p>
<taglist>
<tag>Le fichier de contrôle des sources Debian - <tt>.dsc</tt></tag>
<item>
Ce fichier est un fichier de contrôle utilisé par <prgn>dpkg-source</prgn>
pour extraire un paquet source. Voyez <ref id="debiansourcecontrolfiles">.
	    </item>

<tag>L'archive source originelle - 
<file><var>paquet</var>_<var>version-amont</var>.orig.tar.gz</file></tag>
<item>
<p>C'est un fichier <prgn>tar</prgn> comprimé (avec <prgn>gzip -9</prgn>)
contenant le code source de l'auteur original du programme. 
	      </p>
	    </item>
<tag>fichier <tt>diff</tt> de debianisation - <tt><var>paquet</var>_<var>version_amont-revision</var>.diff.gz</tt></tag>
<item>
<p>
C'est un fichier <tt>diff</tt> unifié (<tt>diff -u</tt>) donnant les
changements requis pour modifier le source original en source Debian.
Ces changements peuvent inclure seulement la modification ou la création de
simples fichiers. Les permissions des fichiers, les cibles des
liens symboliques et les caractéristiques des fichiers spéciaux ou
tubes ne peuvent pas être changés et aucun fichier ne doit être
enlevé ou renommé.
	      </p>
<p>
Tous les répertoires dans le fichier <tt>diff</tt> doivent exister, sauf
le sous-répertoire <tt>debian</tt> à la racine de l'arbre source, qui
sera crée par <prgn>dpkg-source</prgn>, si nécessaire, lors de
l'extraction.
	      </p>
<p>
Le programme <prgn>dpkg-source</prgn> rendra automatiquement exécutable le
fichier <tt>debian/rules</tt> (voir ci-dessous).</p>
	    </item>
	  </taglist>
    </p>
<p>
S'il n'y a pas de code source original, par exemple, si le paquet a été
spécialement préparé pour Debian ou si le responsable Debian est le
même que le responsable original, le format est alors légèrement
différent&nbsp;: il n'y pas de fichier <tt>diff</tt> et le fichier
<prgn>tar</prgn> est nommé <em>paquet-version</em><tt>.tar.gz</tt> et
contient de préférence un répertoire nommé <em>paquet-version</em>.
	</p>
      </sect>

<sect><heading>Comment dépaqueter un paquet source Debian sans <prgn>dpkg-source</prgn></heading>

<p>
<prgn>dpkg-source -x</prgn> est la manière recommandée pour dépaqueter un
paquet source Debian. Cependant, si le programme n'est pas disponible,
il est possible de faire comme suit&nbsp;:

<enumlist compact="compact">
<item>
<p>
<em>Déballer</em> le fichier <tt>tar</tt>, pour créer un répertoire
<tt>.orig</tt>.</p>
	    </item>
<item>
<p>
Changer le nom du répertoire <tt>.orig</tt> en <tt><var>package</var>-<var>version</var></tt>.</p>
	    </item>
<item>
<p>
Créer le sous-répertoire <tt>Debian</tt> à la racine de l'arborescence source.
	      </p>
	    </item>
<item>
<p>
Appliquer le fichier <tt>diff</tt> en utilisant <tt>patch -p0</tt>.
	      </p>
	    </item>
<item>
<p>
<em>Déballer</em> le fichier <tt>tar</tt> de nouveau, si l'on veut une copie du
code source original à côté de la version debianisée.
	      </p>
	    </item>
	  </enumlist>
    </p>
<p>
Il n'est pas possible de créer une archive source Debian valide sans
utiliser <prgn>dpkg-source</prgn>. En particulier, essayer d'utiliser
<prgn>diff</prgn> directement pour créer le fichier <tt>.diff.gz</tt> ne
fonctionnera pas.
	</p>
      </sect>
    </appendix>


 <appendix id="pkg-controlfields"><heading>Les fichiers de contrôle et leurs
champs (annexe tirée de l'ancien <em>Packaging Manual</em>)</heading>

<p>
Beaucoup d'outils de la suite <tt>dpkg</tt> manipulent les données dans
un format commun, connu sous le nom de fichiers de contrôle.
Les paquets source et binaire ont des données de contrôle comme les
fichiers <tt>.changes</tt> qui contrôlent l'installation des fichiers sur le
serveur, et les bases de données internes à <tt>dpkg</tt> sont dans
un format similaire.
      </p>

 <sect><heading>La syntaxe des fichiers de contrôle</heading>

        <p>
Voyez <ref id="controlsyntax">.
        </p>
<p>
Il est important de noter que plusieurs champs sont facultatifs
pour ce qui concerne <prgn>dpkg</prgn> et ses outils associés&nbsp;; mais ils
doivent apparaître dans chaque paquet Debian, et leur omission peut
entraîner des problèmes.
</p>
      </sect>

<sect><heading>La liste des champs</heading>
        <p>
Voyez <ref id="controlfieldslist">.
        </p>
        <p>
Cette section ne contient plus que les champs qui n'appartiennent pas à la
charte Debian.
        </p>

<sect1 id="pkg-f-Filename">
<heading><tt>Filename</tt> et <tt>MSDOS-Filename</tt></heading>
<p>
Ces champs dans les fichiers <tt>Packages</tt> donnent les noms de
fichiers d'un paquet dans une distribution, par rapport à la racine de
la hiérarchie Debian. Si le paquet a été découpé en plusieurs morceaux,
les parties sont toutes listées dans l'ordre, séparées par des espaces.
	  </p>
	</sect1>

<sect1 id="pkg-f-Size">
<heading><tt>Size</tt> et <tt>MD5sum</tt></heading>
<p>
Ces champs dans les fichiers <tt>Packages</tt> donnent la taille (en
octets, exprimée en décimal) et la somme de contrôle MD5 du ou des
fichiers qui composent le paquet de la distribution. Si le paquet est
découpé en plusieurs parties, les valeurs pour ces parties sont listées
dans l'ordre, séparées par des espaces.
	  </p>
	</sect1>

<sect1 id="pkg-f-Status">
<heading><tt>Status</tt></heading>
<p>
Ce champ dans le fichier status de <prgn>dpkg</prgn> enregistre si
l'utilisateur veut un paquet installé, enlevé ou laissé tout seul, s'il
est défectueux (nécessite une réinstallation) ou non et son état actuel
sur le système. Chaque partie de ces informations est un simple mot.
	  </p>
	</sect1>

<sect1 id="pkg-f-Config-Version">
<heading><tt>Config-Version</tt></heading>
<p>
Si un paquet n'est pas installé, ou non configuré, ce champ dans le
fichier status de <prgn>dpkg</prgn> enregistre la dernière version de ce
paquet qui a été configurée avec succès.
	  </p>
	</sect1>

<sect1 id="pkg-f-Conffiles">
<heading><tt>Conffiles</tt></heading>
<p>
Ce champ dans le fichier status de <tt>dpkg</tt> contient des informations
sur les fichiers de configuration automatiquement gérés et maintenus par un
paquet. Ce champ <em>ne doit pas</em> apparaître n'importe où dans un
paquet&nbsp;!
</p>
	</sect1>

<sect1><heading>Champs obsolètes</heading>
<p>
Ils sont toujours reconnus par <prgn>dpkg</prgn> mais ne doivent plus
apparaître n'importe où.
<taglist compact="compact">
<tag><tt>Revision</tt></tag>
<tag><tt>Package-Revision</tt></tag>
<tag><tt>Package_Revision</tt></tag>
<item>
<p>La partie revision Debian d'une version de paquet a été dans un champ de 
fichier de contrôle séparé. Ce champ était présent à travers plusieurs noms.
		</p>
	      </item>
<tag><tt>Recommended</tt></tag>
<item><p>ancien nom de <tt>Recommends</tt></p>
	      </item>
<tag><tt>Optional</tt></tag>
<item><p>ancien nom de <tt>Suggests</tt>.</p>
	      </item>
<tag><tt>Class</tt></tag><item><p>ancien nom de <tt>Priority</tt>.</p>
	      </item>
	    </taglist>
</p>
	</sect1>
      </sect>
    </appendix>

<appendix id="pkg-conffiles">
<heading>La gestion des fichiers de configuration (annexe tirée de l'ancien <em>Packaging Manual</em>)</heading>

<p>
<prgn>dpkg</prgn> peut faire de la gestion automatique de fichiers de 
configuration des paquets.
      </p>
<p>

Que ce mécanisme soit adéquat, dépend d'un certain nombre de facteurs&nbsp;;
mais fondamentalement, pour tout fichier de configuration, il y a deux 
approches.
      </p>
<p>

Une méthode simple est de mettre la meilleure configuration possible
dans le paquet et d'utiliser le mécanisme des <em>conffile</em> de
<prgn>dpkg</prgn> pour faire les mises à jour.
Il est peu probable que l'utilisateur veuille modifier le fichier, mais il 
faut que cela soit possible sans perdre les modifications&nbsp;;
et un nouveau paquet avec une version modifiée du fichier est 
mis à jour rarement&nbsp;; c'est la meilleure approche.
      </p>
<p>

La méthode radicale est de construire le fichier de configuration à partir
du script <prgn>postinst</prgn>, et de prendre la responsabilité de résoudre
automatiquement les erreurs des versions précédentes du paquet. C'est
justifié si le fichier est nécessairement différent sur chaque système.
      </p>

<sect><heading> <prgn>Dpkg</prgn> et la gestion automatique des fichiers de
configuration.</heading>

<p>
Un paquet peut contenir un fichier dans la zone de contrôle appelé
<tt>conffiles</tt>. Ce fichier doit être une liste de noms de fichier de
configuration nécessitant une gestion automatique&nbsp;; les noms sont séparés par 
un retour chariot. Les noms de fichiers seront des noms absolus,
et les fichiers référencés doivent réellement exister dans le
paquet.
	</p>
<p>

Quand un paquet est mis à jour, <prgn>dpkg</prgn> traitera les fichiers de
configuration pendant l'étape de configuration, juste avant d'exécuter
le script <tt>postinst</tt> du paquet.
	</p>
<p>

Pour chaque fichier, il vérifie si la version du fichier inclus dans le
paquet est la même que celle du fichier inclus dans la dernière version du
paquet (celui à partir duquel on fait la mise à jour). <prgn>dpkg</prgn>
compare aussi la version actuellement installée sur le système avec celle
donnée dans la dernière version du paquet.
    </p>
<p>

Quand ni l'utilisateur ni le responsable du paquet n'ont changé le fichier,
il est laissé tel quel. Si l'un ou l'autre l'ont modifié, les nouvelles 
versions sont prises en compte&nbsp;: si l'utilisateur modifie son fichier, mais 
le responsable ne donne pas de nouvelle version, les modifications de 
l'utilisateur sont conservées (silencieusement)&nbsp;; si le 
responsable donne une nouvelle version et l'utilisateur n'a pas modifié son 
fichier, la nouvelle version sera installée (avec un message d'avertissement).
Si les deux ont modifié le fichier, l'utilisateur est averti du problème et 
doit résoudre les différences lui-même.
	</p>
<p>

La comparaison est faite en calculant le MD5 des fichiers et en stockant
ce MD5 comme s'il était inclus dans la plus récente version du
paquet.
	</p>
<p>

Quand un paquet est installé pour la première fois, <prgn>dpkg</prgn>
installera le fichier qui l'accompagne, à moins que cela ne
signifie le remplacement d'un fichier existant sur le système de
fichiers.
	</p>
<p>

Cependant, notons que <prgn>dpkg</prgn> ne remplacera pas un conffile qui a 
été supprimé par l'utilisateur (ou par un script).
C'est nécessaire parce qu'avec certains programmes, un fichier
manquant produit un effet difficile ou impossible à réaliser d'une autre
manière&nbsp;; un fichier manquant ne sera pas remplacé
si l'utilisateur en a décidé ainsi.
    </p>
<p>

Notons qu'un paquet ne doit pas modifier un conffile géré par 
<prgn>dpkg</prgn> dans ses scripts de maintenance. Faire cela amènera 
<prgn>dpkg</prgn> à donner à l'utilisateur des options confuses ou
dangereuses pour la mise à jour des fichiers de configuration quand le
paquet est mis à niveau.
	</p>
      </sect>

<sect><heading>La gestion de la configuration entièrement faite par les
scripts du responsable de paquet.</heading>

<p>
Pour les fichiers qui contiennent des informations spécifiques telles
que le nom de l'hôte, les informations sur le réseau, il est
préférable de créer le fichier dans le script <prgn>postinst</prgn> du
paquet.
	</p>
<p>

Ceci impliquera l'examen de l'état du reste du système pour
déterminer valeurs et autres informations, et peut aussi impliquer
de demander à l'utilisateur des informations qui n'ont pas pu être
obtenues autrement.
	</p>
<p>

Quand on utilise cette méthode, il y a un nombre important de problèmes à
considérer&nbsp;:
	</p>
<p>

Si l'on découvre une erreur dans le programme qui crée le fichier de
configuration, ou si le format d'un fichier change d'une version à la
suivante, on devra modifier le script <tt>postinst</tt> pour le
corriger&nbsp;; habituellement cela veut dire, éditer le fichier de
configuration installé et enlever le problème ou changer la syntaxe. On
devra faire ça avec soin&nbsp;: l'utilisateur peut avoir
changé le fichier, peut-être pour fixer le problème que le script est
en train de traiter&nbsp;; on devra détecter ces situations et les traiter
correctement.
    </p>
<p>
Si l'on choisit cette voie, c'est alors une bonne idée de mettre le
programme qui crée le fichier de configuration dans un programme séparé
dans <tt>/usr/sbin</tt>, appelé par convention
<tt><var>package</var>config</tt> et de l'exécuter si nécessaire, à partir du
script de post-installation. Le programme <tt><var>package</var>config</tt>
ne doit pas écraser une configuration existante - si son mode opératoire
s'applique à une première installation (non pas une reconfiguration
arbitraire ultérieure), on doit vérifier si une configuration existe déjà, et 
utiliser l'option <tt>--force</tt> pour la remplacer.
	</p>
      </sect>
    </appendix>


<appendix id="pkg-alternatives"><heading>Versions alternatives d'une interface
- <prgn>update-alternatives</prgn> (annexe tirée de l'ancien <em>Packaging Manual</em>)</heading>

<p>
Quand plusieurs paquets fournissent tous des versions différentes du
même programme ou fichier, il est utile que le système en sélectionne un
par défaut, tout en autorisant l'administrateur système à le changer et à 
faire respecter ses décisions.
</p>
<p>

Par exemple, il y a plusieurs versions de l'éditeur <prgn>vi</prgn>, et il n'y
a aucune raison d'empêcher leur installation, chacun
sous son propre nom (<prgn>nvi</prgn>, <prgn>vim</prgn>, etc.). Néanmoins, il 
est souhaitable que le nom <tt>vi</tt> se réfère à quelque chose, au
moins par défaut.
</p>
<p>
Si tous les paquets impliqués coopèrent, ceci peut être fait par
<prgn>update-alternatives</prgn>.
      </p>
<p>

Chaque paquet fournit sa propre version sous son propre nom, et appelle
<prgn>update-alternatives</prgn> dans le script <prgn>postinst</prgn> pour 
enregistrer sa version (et dans le script <prgn>prerm</prgn> pour l'enlever).
      </p>
<p>

Voir le manuel en page <manref name="update-alternatives" section="8">
pour des précisions.
      </p>
<p>

Si <prgn>update-alternatives</prgn> ne semble pas approprié, on peut essayer
d'utiliser les déviations.</p>
    </appendix>

<appendix id="pkg-diversions"><heading>Les déviations - remplacer la version 
d'un fichier contenue dans un paquet.</heading>

<p>
Quand <prgn>dpkg</prgn> réinstalle un paquet, on peut faire que tel ancien 
fichier ne soit pas remplacé et que le nouveau fichier correspondant soit mis 
ailleurs.
      </p>
<p>
Une utilisation locale de cette technique peut être de remplacer la version
d'un fichier contenue dans un paquet&nbsp;; un paquet peut aussi s'en servir pour
remplacer tel fichier d'un autre paquet ou bien pour mettre à sa place un
«&nbsp;wrapper&nbsp;».
      </p>
<p>
Avant de décider de l'utilisation d'une déviation, lire 
<ref id="pkg-alternatives">, pour savoir si on veut vraiment une déviation
plutôt que plusieurs versions différentes d'un même programme.
      </p>
<p>

Il y a une liste des déviations qui est lue par <prgn>dpkg</prgn> et mise à
jour par un programme spécial <prgn>dpkg-divert</prgn>. Voir
<manref name="dpkg-divert" section="8">
pour plus de renseignements sur ses arguments.
      </p>
<p>
Quand un paquet souhaite remplacer un fichier par un autre, il doit
appeler <prgn>dpkg-divert</prgn> dans son fichier «&nbsp;preinst&nbsp;» pour ajouter la
déviation et changer le nom du fichier existant. Par exemple, supposons qu'un
paquet <prgn>smailwrapper</prgn> souhaite installer un «&nbsp;wrapper&nbsp;» pour
<tt>/usr/sbin/smail</tt>&nbsp;:

<example>
   if [ install = "$1"  ]; then
       dpkg-divert --package smailwrapper --add --rename \
                   --divert /usr/sbin/smail.real /usr/sbin/smail
   fi
</example>
Le test de <tt>$1</tt> est nécessaire afin que le script n'essaye pas
d'ajouter encore la déviation quand <prgn>smailwrapper</prgn> est mis à
jour. L'option <tt>--package smailwrapper</tt> assure que la copie du fichier
<prgn>/usr/sbin/smail</prgn> contenue dans le paquet <tt>smailwrapper</tt>
évitera la déviation et s'installera comme la vraie version.
  </p>
<p>
Le <tt>postrm</tt> fait l'inverse :
<example>
   if [ remove = "$1" ]; then
       dpkg-divert --package smailwrapper --remove --rename \
                   --divert /usr/sbin/smail.real /usr/sbin/smail
   fi
</example>
Il ne faut pas essayer de remplacer un fichier vital pour la marche
du système. Il y a en effet un moment, quand on utilise <tt>dpkg</tt>, après
que le fichier a été dévié, mais avant que <tt>dpkg</tt> ait installé
la nouvelle version, où le fichier n'existe pas.
</p>
    </appendix>
</book>
</debiandoc>


<!--  LocalWords:  NNTP
 -->