-&debian-formal; 1.3 est disponible uniquement pour <em>i386</em>. Debian 2.0
-supporte les architectures <em>i386</em> et <em>m68k</em>. Debian 2.1
-supporte les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et
-<em>sparc</em>. Debian 2.2 ajoute le support de l'architecture
-<em>powerpc</em>.
-
-<p>
-Vous trouverez des informations destinées aux développeurs à propos d'un
-portage particulier sur la page <url id="&url-debian-ports;" name="Portage
-Debian">.
-
-
-
-
- <sect>Les sous-sections
-
-<p>
-Les sections <em>main</em>, <em>contrib</em> et <em>non-free</em> sont
-divisées en sous-sections pour simplifier le processus d'installation et la
-maintenance de l'archive Debian. Ces sous-sections ne sont pas définies
-formellement, à l'exception peut-être de la sous-section <em>base</em>.
-Elles existent pour simplifier l'organisation des paquets et la navigation
-dans la liste des paquets disponibles. Reportez-vous à la distribution
-courante pour connaître la liste des sous-sections disponibles.
-
-<p>
-Notez qu'avec l'introduction de la nouvelle organisation de l'archive (voir le
-répertoire racine <em>pool/</em>), les sous-sections matérialisées par des
-répertoires pourraient disparaître à l'avenir. Elles seront cependant
-conservées dans le champ <tt>Section</tt> de l'en-tête des paquets.
-
-
-
-
- <sect>Les paquets
-
-<p>
-Il existe deux types de paquets Debian : les paquets sources et les
-paquets binaires.
-
-<p>
-Les paquets sources sont constitués de deux ou trois fichiers :
-
- <list compact>
- <item>
- un fichier <tt>.dsc</tt> et un fichier <tt>.tar.gz</tt> ou,
-
- <item>
- un fichier <tt>.dsc</tt>, un fichier <tt>.orig.tar.gz</tt> et un
- fichier <tt>.diff.gz</tt>.
-
- </list>
-
-<p>
-Si un paquet est développé spécifiquement pour le projet Debian et n'est pas
-distribué en dehors de Debian, il n'y a qu'un fichier <tt>.tar.gz</tt> qui
-contient les sources du programme. Si un paquet est distribué ailleurs, le
-fichier <tt>.orig.tar.gz</tt> contient ce que l'on appelle <em>code source
-amont</em>, c'est-à-dire le code source distribué par le <em>mainteneur
-amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le
-fichier <tt>.diff.gz</tt> contient les modifications faites par le responsable
-Debian.
-
-<p>
-Le fichier <tt>.dsc</tt> liste tous les fichiers sources avec leurs sommes de
-contrôle (<prgn>md5sums</prgn>) et quelques informations supplémentaires
-concernant le paquet (responsable, version, etc).
-
-
-
-
- <sect>Les répertoires des distributions
-
-<p>
-L'organisation des répertoires présentée précédemment est elle-même englobée
-par les <em>répertoires des distributions</em>. Chaque distribution est
-incluse dans le répertoire <tt>pool</tt> à la racine de l'archive Debian.
-
-<p>
-En résumant, une archive Debian a un répertoire racine sur un serveur FTP. Par
-exemple, sur le site miroir <ftpsite>ftp.us.debian.org</ftpsite>, l'archive
-Debian se trouve dans <ftppath>/debian</ftppath> ce qui est un emplacement
-courant. Un autre emplacement courant est <tt>/pub/debian</tt>.
-
-<p>
-Une distribution est composée de paquets Debian sources et binaires et des
-fichiers <tt>Sources</tt> et <tt>Packages</tt> correspondants. Ces derniers
-contiennent la description de tous les paquets. Les premiers sont
-conservés dans le répertoire <tt>pool/</tt> tandis que les seconds sont
-conservés dans le répertoire <tt>dists/</tt> de l'archive (pour des questions
-de compatibilité descendante)
-
-
-
-
- <sect1 id="sec-dists"><em>Stable</em>, <em>testing</em> et
- <em>unstable</em>
-
-<p>
-Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire
-<tt>dists/stable</tt>), une distribution appelée <em>testing</em> (dans le
-répertoire <tt>dists/testing</tt>) et une distribution appelée
-<em>unstable</em> (dans le répertoire <tt>dists/unstable</tt>). Ceci reflète
-le processus de développement du projet Debian.
-
-<p>
-Les développements se font sur la distribution <em>unstable</em><footnote>
-<em>unstable</em> signifie « instable »</footnote> (c'est pourquoi
-elle est aussi appelée <em>distribution de développement</em>). Chaque
-développeur Debian peut modifier ses paquets à tout moment dans cette
-distribution. Ainsi son contenu change tous les jours. Comme aucun effort
-particulier n'est fait pour s'assurer que tout fonctionne correctement dans
-cette distribution, elle est parfois <em>instable</em>.
-
-<p>
-Les paquets sont copiés de <em>unstable</em> vers <em>testing</em> s'ils
-satisfont certains critères. Pour entrer dans la distribution <em>testing</em>
-un paquet doit faire partie de l'archive depuis deux semaines et ne doit pas
-avoir de bogue bloquant pour la distribution (<em>RC bug</em>). Passé cette
-période, le paquet sera installé dans <em>testing</em> dès que les paquets
-dont il dépend y seront. Ce processus est automatique. Vous pouvez consulter
-quelques notes sur ce système ainsi que les <tt>update_excuses</tt> (qui
-indiquent quels paquets sont candidats, lesquels ne le sont pas et pourquoi) à
-l'adresse <url id="&url-testing-maint;">.
-
-<p>
-Après une période de développement, quand le responsable de
-distribution<footnote><em>Release manager</em></footnote> le juge opportun, la
-distribution <em>testing</em> est gelée, ce qui signifie que les conditions à
-remplir pour qu'un paquet passe de <em>unstable</em> à <em>testing</em> sont
-durcies. Les paquets trop bogués sont supprimés et les seules mises à jours
-autorisées concernent les corrections de bogues. Après quelques temps,
-selon l'avancement, la distribution entre dans une phase de
-« gel complet » où les seules modifications acceptées concernent la
-procédure d'installation. Cette phase s'appelle un « cycle de test »
-et cela peut durer jusqu'à deux semaines. Il peut y avoir plusieurs cycles de
-tests avant que le responsable de distribution ne la déclare prête pour la
-diffusion. À la fin du dernier cycle de test, la distribution <em>frozen</em>
-est renommée <em>stable</em>, remplaçant l'ancienne distribution <em>stable</em> qui
-est enlevée à cette occasion (elle peut être retrouvée à l'adresse
-<tt>&archive-host;</tt>).
-
-<p>
-Ce cycle de développement est basé sur l'idée que la distribution
-<em>instable</em> devient <em>stable</em> après une période de test
-(<em>testing</em>). Une distribution contient inévitablement des
-bogues, même si elle est classée stable. C'est pourquoi les distributions
-stables sont mises à jour de temps en temps. Les corrections introduites sont
-testées avec une grande attention et ajoutées individuellement à l'archive
-pour diminuer les risques d'introduire de nouveaux bogues. Vous pouvez trouver
-des paquets proposés pour les mises à jour de <em>stable</em> dans le
-répertoire <tt>proposed-updates</tt>. De temps en temps, les paquets de ce
-répertoire qui ne présentent pas de problème sont installés dans la
-distribution <em>stable</em> et le numéro de révision de cette distribution
-est incrémenté (« 1.3 » devient « 1.3r1 »,
-« 2.0r2 » devient « 2.0r3 » et ainsi de suite).
-
-<p>
-Notez que pendant la période de gel les développements continuent sur la
-distribution instable car cette distribution reste en place.
-
-
- <sect1><em>Experimental</em>
-
-<p>
-La distribution <em>experimental</em> est une distribution particulière. Ce
-n'est pas une distribution à part entière comme le sont <em>stable</em> et
-<em>unstable</em>. Elle est prévue pour servir de plate-forme de développement
-pour les projets expérimentaux qui ont de grandes chances de détruire le
-système ou bien pour des logiciels qui sont vraiment trop instables pour être
-inclus dans la distribution <em>unstable</em> (mais pour qui une mise en
-paquet est justifiée). Les utilisateurs qui téléchargent et
-installent des paquets depuis
-<em>experimental</em> sont prévenus : on ne peut pas faire confiance à la
-distribution <em>experimental</em>.
-
-<p>
-Si un logiciel risque de causer des dégats importants, il sera
-sûrement préférable de le mettre dans la distribution <em>experimental</em>.
-Un système de fichier compressé, par exemple, devrait probablement aller dans
-<em>experimental</em>.
-
-<p>
-Une nouvelle version amont qui ajoute de nouvelles fonctions tout en
-supprimant de nombreuses autres ne devra pas être téléchargée dans l'archive
-Debian, elle pourra cependant être téléchargée dans <em>experimental</em>. Une
-nouvelle version non finalisée d'un logiciel qui utilise une méthode de
-configuration complètement différente pourrait aller dans
-<em>experimental</em> au gré du responsable. Si vous travaillez sur
-un cas de mise à jour complexe ou incompatible vous pouvez aussi utiliser
-<em>experimental</em> comme plate-forme d'intégration et ainsi fournir un
-accès aux testeurs.
-
-<p>
-Quelques logiciels expérimentaux peuvent aller dans <em>unstable</em>, avec un
-avertissement dans la description mais ce n'est pas recommandé car les paquets
-de <em>unstable</em> se propagent dans <em>testing</em> et aboutissent dans
-<em>stable</em>.
-
-<p>
-Un nouveau logiciel qui ne risque pas d'endommager le système ira
-directement dans <em>unstable</em>.
-
-<p>
-Une alternative à <em>experimental</em> consiste à utiliser vos pages
-personnelles sur le serveur <tt>people.debian.org</tt>
-(<tt>klecker.debian.org</tt>).
-
- <sect id="codenames">Les noms de distribution
-
-<p>
-Chaque distribution Debian diffusée a un nom : Debian 1.1 s'appelle
-« buz » ; Debian 1.2, « rex » ; Debian 1.3 « bo » ;
-Debian 2.0, « hamm » ; Debian 2.1, « slink »; Debian 2.2
-« potato » et Debian 3.0 « woody ». Il y a aussi une pseudo-distribution nommée
-« sid », il s'agit de la distribution <em>unstable</em> ; comme les
-paquets vont de <em>unstable</em> à <em>testing</em> quand ils approchent de
-la stabilité, la distribution « sid » n'est jamais diffusée. En plus
-du contenu habituel d'une distribution Debian, « sid » contient des
-paquets pour des architectures qui ne sont pas encore officiellement
-supportées ou pour lesquelles la distribution n'a pas encore été diffusée. Ces
-architectures doivent rejoindre les architectures supportées à une date
-future.
-
-<p>
-Comme Debian est un projet de développement ouvert (i.e. tout le monde peut
-participer et suivre les développements) même les distributions
-<em>unstable</em> et <em>testing</em> sont disponibles sur les serveurs HTTP
-et FTP de Debian.
-
-<p>
-Si nous avions nommé le répertoire qui contient la prochaine version àc
-diffuser « testing », il aurait fallu le renommer
-« stable » au moment de la diffusion, ce qui aurait forcé les
-miroirs FTP à re-télécharger la distribution complète (qui est plutôt
-volumineuse).
-
-<p>
-D'un autre coté, si une distribution s'appelle <em>Debian-x.y</em> dès le
-départ, des personnes pourraient s'imaginer que la distribution Debian
-<em>x.y</em> est disponible. (Cela s'est produit par le passé, un distributeur
-avait gravé des cédéroms Debian 1.0 en utilisant une version de développement
-pré-1.0. C'est pour cette raison que la première version officielle était la
-version 1.1 et non la 1.0.)
-
-<p>
-En conséquence, les noms de répertoire des distributions dans l'archive sont
-déterminés par leurs noms de code et non par leur statut (exemple : slink). Ces
-noms sont identiques pendant la période de développement et une fois la
-distribution diffusée ; des liens symboliques, qui peuvent être modifiés
-facilement, indiquent la distribution stable actuelle.
-
-<p>
-Tout ceci explique pourquoi les répertoires des distributions sont nommés à
-partir des noms de code des distributions alors que <em>stable</em>,
-<em>testing</em> et <em>unstable</em> sont des liens
-symboliques qui pointent vers les répertoires appropriés.
-
-
-
-
-
- <chapt id="upload">La mise à jour d'un paquet
-
-
- <sect>Nouveaux paquets
-
-<p>
-Si vous voulez créer un nouveau paquet pour la distribution Debian vous
-devriez commencer par consulter la liste des <url id="&url-wnpp;"
-name="paquets en souffrance et paquets souhaités">. Vous pourrez ainsi
-vérifier que personne ne travaille déjà sur ce paquet et éviter un double
-travail. Consultez aussi cette page si vous voulez en savoir plus.
-
-<p>
-Supposons que personne ne travaille sur le paquet que vous visez, vous devez
-alors envoyer un rapport de bogue (voir <ref id="submit-bug">) concernant le
-pseudo-paquet <tt>wnpp</tt>. Ce
-courrier devra décrire le paquet que vous projetez de créer, la licence de ce
-paquet et l'URL à laquelle le source peut être téléchargé. Cette liste n'est
-pas limitative.
-
-<p>
-Le sujet de votre rapport de bogue devra être <ITP<footnote><em>Intent To
-Package</em> : intention de mise en paquet</footnote> :
-<var>NomDuPaquet</var> — <var> courte description </var>>, en remplaçant
-<var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera
-<em>whishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
-&email-debian-devel; en mettant cette adresse dans le champ
-<tt>X-Debbugs-CC:</tt> de l'en-tête du message. N'utilisez pas le champ
-<tt>CC:</tt> car de cette manière le sujet du message ne contiendrait pas le
-numéro du bogue.
-
-<p>
-Il faudra aussi ajouter une entrée
-<tt>Closes: bug#<var>nnnnn</var></tt> dans le fichier <file>changelog</file>
-du nouveau paquet. Cette indication fermera automatiquement le rapport de
-bogue à l'installation du nouveau paquet sur les serveurs d'archivage (voir
-<ref id="upload-bugfix">).
-
-<p>
-Il y a plusieurs raisons qui nous poussent à demander aux responsables d'annoncer
-leurs intentions :
-
- <list compact>
- <item>
- Les responsables ont ainsi la possibilité de puiser dans l'expérience
- des autres responsables et cela leur permet de savoir si une autre personne
- travaille déjà dessus.
-
- <item>
- D'autres personnes qui envisagent de travailler sur le même paquet
- apprendront ainsi qu'il existe déjà un volontaire, l'effort peut alors
- être partagé.
-
- <item>
- Cela permet aux autres responsables d'en savoir plus sur le nouveau
- paquet que ne le permettent la description d'une ligne et l'habituelle
- entrée « <em>Initial release</em> » que l'on trouve dans les
- fichiers <em>changelog</em> qui sont postés sur
- <tt>debian-devel-changes</tt>.
-
- <p>
- C'est une information utile pour les gens qui utilisent la
- distribution <em>unstable</em> et qui sont nos premiers testeurs. Nous
- devons faciliter la tâche de ces gens.
-
- <p>
- Avec ces annonces, les développeurs Debian et toutes les autres personnes
- intéressées peuvent se faire une meilleure idée des évolutions et nouveautés du
- projet.
-
- </list>
-
-
- <sect id="changelog-entries">
- <heading>Ajouter une entrée à debian/changelog</heading>
-
-<p>
-Les modifications que vous apportez au paquet doivent être tracées dans le
-fichier <file>debian/changelog</file>. Ces traces doivent donner une
-description concise des changements, expliquer pourquoi (si ce n'est pas
-clair) et indiquer si des rapports de bogues sont clos. Il faut aussi indiquer
-quand le paquet a été terminé. Ce fichier sera installé dans
-<file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
-<file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un paquet
-natif.
-
-<p>
-Le fichier <file>debian/changelog</file> a une structure précise comportant
-différents champs. Le champ <em>distribution</em> est décrit dans <ref
-id="upload-dist">. Vous trouverez plus d'information sur la structure de ce
-fichier dans le <em>Debian Policy Manual</em> section
-« <file>debian/changelog</file> ».
-
-<p>
-Les entrées du fichier <file>changelog</file> peuvent être utilisées pour
-fermer des rapports de bogue au moment où le paquet est installé dans
-l'archive. Voir la section <ref id="upload-bugfix">.
-
-<p>
-Par convention, l'entrée changelog d'un paquet qui contient une nouvelle
-version amont ressemble à :
-<example>
- * new upstream version
-</example>
-
-<p>
-Quelques outils peuvent vous aider à créer des entrées et finaliser
-<file>changelog</file> pour une livraison — voir les sections <ref
-id="devscripts"> et <ref id="dpkg-dev-el">.
-
- <sect id="upload-checking">Vérifier le paquet avant la mise à jour
-
-<p>
-Avant de mettre à jour votre paquet vous ferez quelques tests de base. Vous
-devrez au moins faire les tests suivants (il vous faut une ancienne version
-du paquet) :
- <list compact>
- <item>
- Installez le paquet et vérifiez que le logiciel fonctionne. Si le
- paquet existait déjà dans une version plus ancienne, faites une mise à
- jour.
-
- <item>
- Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
- <prgn>lintian</prgn> comme suit : <tt>lintian -v
- <var>package-version</var>.changes</tt>. Ce programme fera une
- vérification sur les paquets source et binaire. Si vous ne comprenez
- pas les messages générés par <prgn>lintian</prgn> essayez l'option
- <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
- bavard dans sa description du problème.
- <p>
- En principe, un paquet pour lequel
- <prgn>lintian</prgn> génère des erreurs (elles commencent par
- <tt>E</tt>) <em>ne doit pas</em> être installé dans l'archive.
- <p>
- Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la
- section lintian <ref id="lintian">.
-
- <item>
- Faites régresser le paquet
- vers sa version précédente si elle existe — cela permet de tester les
- scripts <tt>postrm</tt> et <tt>prerm</tt>.
-
- <item>
- Désinstallez le paquet et réinstallez-le.
-
- </list>
-
-
-
- <sect>Générer le fichier « changes »
-<p>
-Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit
-être accompagnée d'un fichier <tt>.changes</tt>. Ce fichier explique à
-l'administrateur de l'archive Debian ce qu'il doit faire du paquet. Il est en
-général créé par <prgn>dpkg-genchanges</prgn> au cours du processus de
-fabrication du paquet.
-
-<p>
-Le fichier <tt>changes</tt> est un fichier de contrôle qui contient les champs
-suivants :
-
-<p>
-&control-file-fields;
-
-<p>
-Tous ces champs sont obligatoires pour une installation sur les serveurs
-Debian. Vous pouvez consulter la liste des champs de contrôle dans le
-<url id="&url-debian-policy;" name="Debian Policy Manual"> pour connaître
-les valeurs que prennent ces champs. Vous pouvez fermer un rapport de bogue
-automatiquement avec le champ <tt>Description</tt> (voir <ref
-id="upload-bugfix">).
-
-
- <sect1>L'archive des sources amonts
-<p>
-La première fois qu'un paquet est installé dans l'archive pour une version
-amont donnée, le fichier <tt>tar</tt> de cette version amont doit être
-téléchargé et mentionné dans le fichier <tt>.changes</tt>. Par la suite, ce
-fichier <tt>tar</tt> sera utilisé pour générer les fichiers <tt>diff</tt> et
-<tt>.dsc</tt> et il ne sera pas nécessaire de le télécharger à nouveau.
-
-<p>
-Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn>
-incluront le fichier <tt>tar</tt> amont si et seulement si le numéro de
-révision du paquet source est 0 ou 1, ce qui indique une nouvelle version
-amont. Ce comportement peut être modifié en utilisant <tt>-sa</tt> pour
-l'inclure systématiquement ou <tt>-sd</tt> pour ne jamais l'inclure.
-
-<p>
-Si la mise à jour ne contient pas le fichier <tt>tar</tt> des sources
-originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
-fichiers <tt>.dsc</tt> et <tt>diff</tt> de la mise à jour, utilisez un fichier
-<tt>tar</tt> identique à l'octet près à celui sur le serveur. Si pour une
-raison ou pour une autre il y a une différence, la nouvelle version de ce
-fichier doit à nouveau être incluse dans la mise à jour (en utilisant l'option
-<tt>-sa</tt> par exemple).
-
-
-
-
- <sect1 id="upload-dist">Choisir une distribution
-
-<p>
-Le champ <tt>Distribution</tt>, qui provient de la première ligne du fichier
-<file>debian/changelog</file>, indique à quelle distribution le paquet est
-destiné.
-
-<p>
-Il y a trois valeurs possibles pour ce champ : <em>stable</em>,
-<em>unstable</em> et <em>experimental</em> . En temps
-normal, les paquets sont téléchargés dans <em>unstable</em>.
-
-<p>
-Vous devriez éviter de combiner <em>stable</em> avec d'autres cibles à cause
-des problèmes potentiels de dépendance de bibliothèque (pour votre paquet et
-pour les paquets fabriqués par le démon de compilation pour les autres
-architectures). Se reporter à <ref id="upload-stable"> pour savoir quand et
-comment faire une mise à jour de <em>stable</em>.
-
-<p>
-Notez bien que combiner <em>experimental</em> avec quelque distribution
-que ce soit n'a pas de sens.
-
-
- <sect2 id="upload-stable">Mettre à jour un paquet de la distribution <em>stable</em>
-
-<p>
-Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
-sera dirigé vers le répertoire <tt>proposed-updates</tt> des archives Debian
-pour y être testé avant d'être effectivement inclus dans <em>stable</em>.
-
-<p>
-Une livraison pour la distribution <em>stable</em> requière des soins
-supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
-que dans les cas suivants :
-
- <list>
- <item>un problème de sécurité (un avis de sécurité
- Debian<footnote>Debian security advisory.</footnote>),
- <item>un probleme fonctionnel vraiment critique,
- <item>un paquet devenu ininstallable,
- <item>un paquet indisponible pour une architecture.
- </list>
-
-<p>
-Il est fortement déconseillé de changer quoi que ce soit si ce n'est pas
-important car même une modification triviale peut causer un bogue plus
-tard. Livrer une nouvelle version amont d'un logiciel pour corriger un
-problème de sécurité est désapprouvé ; dans la plupart des cas la
-bonne solution consiste à prendre la rustine correspondante de la
-nouvelle version amont et à l'appliquer à l'ancienne (faire un
-portage (<em>backport</em>) de la rustine.
-