Merci à Cyril pour la relecture
Eric
<!-- CVS revision of original english document "1.47" -->
<chapt id="ftparchives">Les archives FTP de Debian
<sect id="dirtree">Quels sont tous ces répertoires dans les archives FTP de
Debian ?
<p>Le logiciel empaqueté pour &debian; est disponible dans un des nombreux
répertoires
présent sur chaque site miroir de Debian.
<p>Le répertoire <tt>dists</tt> est une abréviation pour
« distributions »
et c'est la manière canonique pour accéder à la version (et pré-versions) Debian
actuellement disponible.
<p>Le répertoire <tt>pool</tt> contient les paquets actuels, voir
<ref id="pools">.
<p>On trouve aussi les répertoires supplémentaires suivant :
<taglist>
<tag><em>/tools/</em> :
<item>Utilitaire DOS pour la création de disque de démarrage, pour le
partitionnement
de votre disque, pour la compression et la décompression de fichiers et
pour le
démarrage de Linux.
<tag><em>/doc/</em> :
<item>La documentation de base de Debian, comme la FAQ, les instructions
pour le système de
rapport de bogues, etc.
<tag><em>/indices/</em> :
<item>Le fichier Maintainers et les fichiers override.
<tag><em>/project/</em> :
<item>Principalement des ressources pour les développeurs, comme :
<taglist>
<tag><em>project/experimental/</em> :
<item>Ce répertoire contient des paquets et des outils qui sont encore
en
développement et sont encore en état de test alpha. Les
utilisateurs
ne devraient pas utiliser ces paquets parce qu'ils peuvent être
dangereux
même pour les personnes les plus expérimentées.
</taglist>
</taglist>
<sect id="dists">Combien de distributions de Debian y a-t-il dans le répertoire
<tt>dists</tt> ?
<p>Il y a trois distributions, la distribution « stable », la
distribution
« testing », et la distribution « unstable ». La
distribution
« testing » est quelque fois gelée (« frozen ») (voyez <ref
id="frozen">).
<sect id="codenames">À quoi correspondent tous les noms comme slink, potato,
etc. ?
<p>Ce sont justes des noms de code. Quand une distribution Debian est en cours
de développement,
elle n'a aucun numéro de version mais un nom de code. Le but de ces noms de
code est de faciliter
la copie sur les miroirs des distributions Debian (si un véritable répertoire
comme <tt>unstable</tt> est
soudainement renommé en <tt>stable</tt>, beaucoup de choses devraient être
inutilement téléchargées).
<p>Actuellement, la version <tt>stable</tt> est un lien symbolique vers
<tt>&releasename;</tt>
(c.-à-d. Debian GNU/Linux 3.1) et la version <tt>testing</tt> est un lien
symbolique vers
<tt>&testingreleasename;</tt>. Ceci signifie que <tt>&releasename;</tt> est la
distribution
« stable » actuelle et <tt>&testingreleasename;</tt> est la
distribution « testing » actuelle.
<p><tt>Unstable</tt> est un lien symbolique permanent vers <tt>sid</tt>, car
<tt>sid</tt>
est toujours la distribution « unstable ».
<sect1 id="oldcodenames">Quels noms de code ont déjà été utilisés ?
<p>Les autres noms de code qui ont déjà été employés sont : <tt>buzz</tt>
pour la version 1.1,
<tt>rex</tt> pour la version 1.2, <tt>bo</tt> pour les versions 1.3.x,
<tt>hamm</tt> pour la version 2.0,
<tt>slink</tt> pour la version 2.1, <tt>potato</tt> pour la version 2.2 et
<tt>woody</tt> pour la version 3.0.
<sect1 id="sourceforcodenames">D'où proviennent les noms de code ?
<p>Jusqu'ici les noms de code proviennent des personnages du film « Toy
Story » par Pixar.
<list>
<item><em>buzz</em> (Buzz Lightyear) est le cosmonaute,
<item><em>rex</em> est le tyrannosaure,
<item><em>bo</em> (Bo Peep) est la bergère,
<item><em>hamm</em> est la tirelire en forme de cochon,
<item><em>slink</em> (Slinky Dog ®) est le chien,
<item><em>potato</em> est bien sûr, Mr. Patate ®,
<item><em>woody</em> est le cowboy,
<item><em>sarge</em> est le sergent de l'armée de plastique vert,
<item><em>etch</em> est l'ardoise magique (Etch-a-Sketch ®),
<!-- SID should be the last line always -->
<item><em>sid</em> est le garçon des voisins qui détruit les jouets.
</list>
<!-- Q: Should we add the trademark info here? Maybe as a footnote
Mr. Potato is a Registered Trademark of Playskool, Inc.,
Pawtucket, R.I., a division of Hasbro Inc.
Slinky Dog is a trademark of Poof Products of Plymouth, Mich.,
Etch-a-Sketch is a trademark of The Ohio Art Company,
other characters might also be registered trademarks...
(jfs)
-->
<!--
more info in http://www.pixar.com/featurefilms/ts/
and http://www.pixar.com/featurefilms/ts2/
or better yet http://us.imdb.com/M/title-exact?Toy%20Story%20(1995)
or actually:
http://us.imdb.com/Title?0114709 for TS1
http://us.imdb.com/Title?0120363 for TS2
we shouldn't put the links in, Pixar needs no additional propaganda
-->
<!--
characters not used from Toy Story (yet):
- Andy (the kid)
- Snake
- Robot
- Scud (Sid's dog)
- Lenny the Binoculars
- Three Eyed Alien
- Rocky (the wrestling figure)
- Roller Bob (the remote control car)
- Legs (one of sid's mutant toys)
- Hand-in-the-box (one of sid's mutant toys)
- Duckie (one of sid's mutant toys)
and additional characters from Toy Story 2, also not yet used:
- Al (the propietor of Al's Toy Farm)
- Jessie (the Yodelling Cowgirl)
- Bullseye (Woody's toy horse)
- Zurg (the Evil Emperor)
- Wheezy (the penguin)
- Hannah (owner of Jessie)
- Stinky Pete the Prospector (the old fat guy)
- Mrs. Davis (Andy's Mom)
- Barbie (the Tour Guide, probably under (c))
- Mrs. Potato Head
- Heimlich the Caterpillar
-->
<!-- (jfs) Just in case somebody misses the "What do we do when we finish
with Toy Story characters" thread see:
http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg01133.html
I, suggested we followed with either Monster's Inc or "A Bug's life" :)
-->
<sect id="sid">Que dire de « sid » ?
<p><em>Sid</em> ou <em>« unstable »</em> est le lieu où la plupart
des paquets sont
initialement téléchargés. Elle ne sera jamais directement publiée, parce que
les
paquets devront d'abord être inclus dans <em>« testing »</em>, afin
d'être publiés
dans <em>« stable »</em> plus tard. Sid contient des paquets pour
l'ensemble des
architectures publiées ou non.
<p>Le nom « sid » vient aussi du film d'animation Toy Story :
Sid est le garçon des voisins qui détruit les jouets.
<p><footnote>
<p>Quand la sid n'existait pas, l'organisation du site FTP avait un défaut
majeur.
On supposait que quand une architecture était créée dans la distribution
« unstable » actuel, elle serait publiée quand la distribution
deviendrait la nouvelle distribution « stable ». Pour beaucoup
d'architectures
ce n'était pas le cas, ce qui obligeait à déplacer ces répertoires lors de la
sortie d'une
version. Ce n'était pas pratique parce que le déplacement aurait consommé
beaucoup de bande
passante.
<p>Les administrateurs ont évité le problème pendant plusieurs années en
plaçant
les binaires pour les architectures non publiées dans un répertoire particulier
nommé « sid ». Pour les architectures non encore publiées, lors de
leurs
sorties, un lien entre la stable courante et sid était créé et à partir de là
elles
étaient créées normalement dans l'arborescence « unstable ». Cette
disposition
était légèrement déconcertante pour les utilisateurs.
<p>Avec l'arrivée des répertoires communs (voir <ref id="pools">), les paquets
ont commencé à être placés dans un endroit standard dans le pool, quelle que
soit
la distribution, donc la publication d'une distribution n'entraîne plus de
consommation
excessive de bande passante sur les miroirs (mais il y a cependant une
consommation
graduelle de la bande passante pendant le processus de développement).
</footnote>
<sect id="stable">Que contient le répertoire stable ?
<p><list>
<item>stable/main/ :
Ce répertoire contient les paquets qui constituent la version la plus
récente
du système &debian;.
<p>Ces paquets sont tous conformes aux <url name="principes du logiciel libre
selon Debian"
id="http://www.debian.org/social_contract#guidelines";> (Debian Free Software
Guidelines,
DFSG) et sont tous librements utilisables et librements distribuables.
<item>stable/non-free/ : Ce répertoire contient les paquets de la
distribution ayant certaines
restrictions, ce qui oblige que les distributeurs doivent tenir compte
soigneusement des conditions
définies dans les copyright.
<p>Par exemple, certains paquets ont une licence avec une clause interdisant
une distribution commerciale. D'autres peuvent être redistribués mais sont en
fait
des partagiciels (shareware) et non des graticiels (freeware). La licence de
chaque paquet doit être étudiée,
et probablement négociée, avant qu'ils ne soient inclus dans toutes
distributions
(par exemple sur un cédérom).
<item>stable/contrib/ : Ce répertoire contient les paquets qui sont
conformes aux DFSG et
<em>librement distribuables</em>, mais dépendent d'une façon ou d'une d'autre
d'un paquet qui
<em/n'est pas/ librement distributable et ainsi disponible seulement dans la
section non-free.
</list>
<sect id="testing">Que contient le répertoire testing ?
<p>Des paquets sont installés dans le répertoire « testing » après
qu'ils aient subi
un certain nombre de tests dans « <qref
id="unstable">unstable</qref> ».
<p>Ils doivent être synchronisés sur toutes les architectures où ils ont été
construits
et ne doivent pas avoir de dépendances qui empêcheraient leur
installation ; ils doivent
également avoir moins de bogues critiques que les versions actuellement dans
« testing ».
De cette façon, nous espérons que « testing » soit une version
toujours prête à la publication.
<p>Plus d'informations sur l'état de « testing » en général et sur
les différents paquets
sont disponibles à <url id="http://www.debian.org/devel/testing";>.
<sect1 id="frozen">Que dire de « testing » ? Comment est-elle
gelée (« frozen ») ?
<p>Quand la distribution « testing » est suffisamment mature, le
gestionnaire
de version commence à geler la distribution. Le temps de propagation des
paquets entre les
distribution est augmenté pour s'assurer que le moins possible de bogues passe
de la distribution
« unstable » dans « testing ».
<p>Après un moment, la distribution « testing » devient vraiment
gelée.
Ceci signifie que tous les nouveaux paquets qui devait entrer dans
« testing »
sont bloqués, à moins qu'il ne corrige un bogue critique (release critical).
La distribution « testing » peut également demeurer dans un gel
profond pendant
les cycles d'essai, quand la publication est imminente.
<p>Nous conservons un enregistrement des bogues de la distribution
« testing »
qui peuvent empêcher un paquet d'être publié, ou retarder la publication de la
distribution. Pour plus de détails, veuillez-vous reporter aux <url
name="informations
sur la version testing actuelle" id="http://www.debian.org/releases/testing/";>.
<p>Une fois que le nombre de bogues a atteint une valeur maximale acceptable,
la distribution « testing » gelée est déclarée « stable »
et publiée avec un numéro de version.
<p>Avec chaque nouvelle version, l'ancienne distribution « stable »
devient
obsolète et est déplacée de l'archive. pour plus d'informations, reportez-vous à
<url name="Debian archive" id="http://www.debian.org/distrib/archive";>.
<sect id="unstable">Que contient le répertoire unstable ?
<p>Le répertoire « unstable » contient une image du système en cours
de
développement. Les utilisateurs sont les bienvenus pour utiliser et tester ces
paquets, mais soyez averti au sujet de leur état. L'avantage d'utiliser la
distribution « unstable » est que votre système est toujours à jour
avec la dernière version des logiciels GNU/Linux, mais s'il y a un problème,
vous en découvrirez les mauvais côtés.
<p>Il y a aussi dans « unstable » des sous-répertoires main, contrib
et
non-free remplis avec les mêmes critères que dans « stable ».
<sect id="archsections">Que sont tous ces répertoires dans
<tt>dists/stable/main</tt> ?
<p>Dans chacune des arborescences des répertoires majeurs
<footnote>
<tt>dists/stable/main</tt>, <tt>dists/stable/contrib</tt>,
<tt>dists/stable/non-free</tt> et <tt>dists/unstable/main/</tt>, etc.
</footnote>, il y a trois ensembles de sous-répertoires contenant les fichiers
catalogues.
<p>Il y a un ensemble de sous-répertoires
<tt>binary-<var>quelquechose</var></tt>
contenant les fichiers catalogues pour les paquets binaires de chaque
architecture
disponible. Par exemple, <tt/binary-i386/ pour les paquets s'exécutant sur les
machines
Intel x86 ou <tt/binary-sparc/ pour les paquets s'exécutant sur les
SPARCStations Sun.
<p>La liste complète de toutes les architectures disponibles pour chaque
version est
accessible à l'adresse <url name="the release's web page"
id="http://www.debian.org/releases/";>.
Pour la version en cours, veuillez-vous reporter à <ref id="arches">.
<p>Les fichiers catalogues dans les répertoires <tt>binary-*</tt> sont nommés
Packages(.gz) et fournissent un résumé de chaque paquets binaires présents dans
la distribution. Les paquets binaires (pour <em/woody/ et les versions
suivantes)
se trouvent à la racine du <qref id="pools">répertoire <tt/pool/</qref>.
<p>De plus, il y existe un sous-répertoire nommé <tt>source/</tt> contenant les
fichiers
catalogues pour les paquets sources contenus dans la distribution.
Le fichier catalogue est nommé Sources(.gz).
<p>Le dernier mais non des moindre, est un ensemble de sous-répertoires utilisé
pour les
fichiers catalogues du système d'installation. Pour la version <em>woody</em>
ils sont
nommés <tt>disks-<var>architecture</var></tt> et pour <em>sarge</em> c'est
<tt>debian-installer/binary-<var>architecture</var></tt>.
<sect id="source">Où trouve-t-on le code source ?
<p>Le code source est inclus pour tout le système Debian. De plus, les termes
de la licence de la plupart des programmes du système <em>requièrent</em> que
le code source soit distribué avec le programme, ou qu'un moyen de récupérer
ce code accompagne le programme.
<p>Le code source est distribué dans le répertoire <tt>pool</tt> (voir <ref
id="pools">)
avec les binaires de toutes les architectures. Pour récupérer le code source
sans être
familier avec la structure de l'archive FTP, exécutez une commande
comme <tt>apt-get source monpaquet</tt>.
<p>Certains paquets sont seulement distribués sous forme de code source à cause
de restriction de leur licence. Notamment, l'un de ces paquets est
<tt>pine</tt>,
voir <ref id="pine"> pour plus d'informations.
<p>Le code source peut ou non être disponible pour les paquets dans les sections
« contrib » et « non-free », qui ne font pas formellement
partie du système Debian.
<sect id="pools">Que trouve-t-on dans le répertoire <tt>pool</tt> ?
<p>Les paquets sont gardés dans un répertoire commun (« pool »),
structuré selon
le nom des paquets sources. Pour rendre cela gérable, le répertoire est divisé
par section
(« main », « contrib » et « non-free ») et dans
chaque section
par la première lettre du nom des paquets sources. Ces répertoires contiennent
plusieurs
fichiers : les paquets binaires pour chaque architecture et les paquets
sources à partir
desquels sont construits les paquets binaires.
<p>Vous pouvez voir où chaque paquet est conservé en exécutant la commande
<tt>apt-cache showsrc monpaquet</tt> et en regardant la ligne
« Directory: ».
Par exemple, les paquets <tt>apache</tt> sont conservés dans
<tt>pool/main/a/apache/</tt>.
<p>De plus, comme il existe de nombreux paquets de bibliothèque <tt>lib*</tt>,
ceux-ci
sont traités différemment. Par exemple, le paquet <tt>libpaper</tt> est placé
dans le
répertoire <tt>pool/main/libp/libpaper/</tt>.
<!-- joeyh doesn't want to maintain it so it's dead; need to integrate it
If you want more information, see the
<url id="http://people.debian.org/~joeyh/poolfaq";
name="Debian Package Pools FAQ">.
-->
<p><footnote>
<p>Historiquement, les paquets étaient conservés dans le sous-répertoire
<tt>dists</tt>
correspondant aux distributions. Ceci s'est avéré poser certains problèmes,
comme une grande consommation de bande passante sur des miroirs lors de
changements
majeurs. Ces problèmes ont été résolus avec l'introduction du répertoire pool.
<p>Le répertoire <tt>dists</tt> est encore utilisé pour les fichiers catalogues
servant à des programmes comme <tt>apt</tt>. Vous pouvez également voir les
chemins
<tt>dists/potato</tt> ou <tt>dists/woody</tt> dans les champs des entêtes de
fichier
de certains anciens paquets.
</footnote>
<sect id="incoming">Qu'est-ce que le répertoire incoming ?
<p>Après qu'un développeur a envoyé un paquet, il est conservé dans le
répertoire « incoming » avant de vérifier son origine et de
l'autoriser
dans l'archive.
<p>Généralement personne ne devrait installer des paquets provenant de ce
répertoire. Cependant, dans certains rares cas d'urgence le répertoire
« incoming »
est disponible à <url id="http://incoming.debian.org/";>. Vous devrez
télécharger manuellement les paquets, vérifier les signatures GPG et les
sommes MD5 dans les fichiers .changes et .dsc et après les installer.
<sect id="ownrepository">Comment configurer mon propre référentiel pour
apt ?
<p> Si vous avez construit vos paquets Debian et que vous souhaitez les
installer en utilisant
les outils de gestion de paquets Debian, vous devez configurer votre propre
archive de
paquets. Ceci peut-être aussi utile si vous désirez partager vos paquets Debian
alors que ceux-ci
ne sont pas encore officiellement distribués par le projet Debian.
Reportez-vous aux instructions
fournies dans le <url name="Guide pratique des référentiels Debian"
id="http://www.debian.org/doc/manuals/repository-howto/repository-howto";>.
