| Chapitre 6. The Debian archives | ||
|---|---|---|
 |  | |
| Chapitre 6. The Debian archives | ||
|---|---|---|
| | | |
Table des matières
dists/stable/main ?pool ?Il y a trois distributions majeures : la distribution « stable », la distribution « testing » et la distribution « unstable ». La distribution « testing » est quelque fois gelée (« frozen ») (voyez Section 6.5.1, « Que dire de « testing » ? Comment est-elle gelée (« frozen ») ? »). À côté de celles-là, on trouve également la distribution « oldstable » (celle qui précédait la « stable ») ainsi que la distribution « experimental ».
Experimental est utilisée pour les paquets encore en cours de développement qui comportent des risques importants pour le fonctionnement de votre système. Elle est utilisée par les développeurs qui veulent étudier et tester les versions les plus récentes des logiciels. Les utilisateurs ne devraient pas utiliser ces paquets-là, car ils peuvent être dangereux et endommager les systèmes des utilisateurs même les plus expérimentés.
Consultez Chapitre 3, Choisir une distribution de Debian pour de l'aide sur le choix d'une distribution Debian.
Ce sont juste 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
unstable est soudainement renommé en
stable, beaucoup de choses devraient être inutilement
téléchargées).
Actuellement, la version stable est un lien symbolique
vers bookworm (c'est-à-dire Debian GNU/Linux 12) et
la version testing est un lien symbolique vers
trixie. Ceci signifie que
bookworm est la distribution « stable »
actuelle et trixie est la distribution
« testing » actuelle.
Unstable est un lien symbolique permanent vers
sid, car sid est toujours la
distribution « unstable ».
Aside bookworm and
trixie, other codenames that have been already
used are: buzz for release 1.1, rex
for release 1.2, bo for releases 1.3.x,
hamm for release 2.0, slink for
release 2.1, potato for release 2.2,
woody for release 3.0, sarge for
release 3.1, etch for release 4.0,
lenny for release 5.0, squeeze for
release 6.0, wheezy for release 7,
jessie for release 8, stretch for
release 9, buster for release 10,
bullseye for release 11, bookworm for
release 12.
Jusqu'ici les noms de code proviennent des personnages des films « Toy Story » par Pixar.
buzz (Debian 1.1) est le cosmonaute Buzz Lightyear,
rex (Debian 1.2) est le tyrannosaure,
bo (Debian 1.3) est Bo Peep, la bergère,
hamm (Debian 2.0) est la tirelire en forme de cochon,
slink (Debian 2.1) est Slinky Dog, le chien,
potato (Debian 2.2) est bien sûr, Mr. Patate,
woody (Debian 3.0) est le cowboy,
sarge (Debian 3.1) est le sergent de l'armée de plastique vert,
etch (Debian 4.0) est l'ardoise magique (Etch-a-Sketch),
lenny (Debian 5.0) est la paire de jumelles,
squeeze (Debian 6) est le nom des extraterrestres à 3 yeux,
wheezy (Debian 7) est le nom du manchot au nœud papillon rouge,
jessie (Debian 8) est l'écuyère,
stretch (Debian 9) est le nom de la pieuvre avec des ventouses sur ses tentacules.
buster (Debian 10) était le chien de compagnie d'Andy.
bullseye (Debian 11) était le cheval de bois de Woody.
bookworm (Debian 12) était un ver de terre vert équipé d'un flash et qui adore lire des livres.
trixie (Debian 13) was a blue plastic triceratops.
sid est le garçon des voisins qui casse tous les jouets.
La décision d'utiliser des noms provenant de Toy Story a été prise par Bruce Perens qui était, à l'époque, responsable du projet Debian et travaillait chez Pixar, la société qui a produit les films.
Sid ou « unstable » est le lieu où la plupart des paquets sont initialement envoyés. Elle ne sera jamais directement publiée, parce que les paquets devront d'abord être inclus dans « testing », afin d'être publiés dans « stable » plus tard. Sid contient des paquets pour l'ensemble des architectures publiées ou non.
Le nom « sid » vient aussi du film d'animation Toy Story : Sid est le garçon des voisins qui détruit les jouets.
stable/main/ : Ce répertoire contient les paquets qui constituent la version la plus récente du système Debian GNU/Linux.
Ces paquets sont tous conformes aux principes du logiciel libre selon Debian (Debian Free Software Guidelines, DFSG) et sont tous librement utilisables et librement distribuables.
stable/non-free/ : Ce répertoire contient les paquets de la distribution ayant certaines restrictions, ce qui oblige les distributeurs à tenir compte soigneusement des conditions définies dans les copyright.
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 pas des logiciels libres (free software). 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 CD-ROM).
stable/contrib/ : Ce répertoire contient les paquets qui sont conformes aux DFSG et librement distribuables, mais dépendent d'une façon ou d'une autre d'un paquet qui n'est pas librement distribuable et ainsi disponible seulement dans la section non-free.
Les paquets sont installés dans le répertoire « testing » après qu'ils aient subi un certain nombre de tests dans « unstable ».
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 unstable. De cette façon, nous espérons que « testing » soit une version toujours prête à la publication.
Plus d'informations sur l'état de « testing » en général et sur les différents paquets sont disponibles à https://www.debian.org/devel/testing.
Quand la distribution « testing » est suffisamment mature, le responsable de la publication commence à la « geler ». Le temps de propagation des paquets entre les distributions est augmenté pour s'assurer que le moins possible de bogues passe de la distribution « unstable » dans « testing ».
Après un moment, la distribution « testing » devient vraiment gelée. Cela signifie que tous les nouveaux paquets qui devaient entrer dans « testing » sont bloqués, à moins qu'ils ne corrigent 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.
Lorsque la distribution « testing » est « gelée », « unstable » a tendance à geler également. En effet, les développeurs sont réticents à envoyer des logiciels complètement nouveaux dans l'archive : cela compliquerait le processus de correction dans le cas où un logiciel dans « testing » doit être corrigé, suite à un bogue mineur voire critique pour la publication.
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 informations sur la version testing actuelle.
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.
Le décompte de bogues le plus important est celui des bogues critiques pour la publication (« Release Critical »). Un objectif courant pour la publication est de réduire à zéro le nombre de bogues critiques, graves ou sérieux (NoRCBugs). La liste complète des problèmes considérés critiques est disponible dans le document de politique des bogues RC.
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 à l'archive Debian.
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.
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 ».
Le logiciel empaqueté pour Debian GNU/Linux est disponible dans un des nombreux répertoires présents sur chaque site miroir de Debian.
Le répertoire dists est une abréviation pour
« distributions » et c'est la manière canonique pour accéder à la
version (et pré-versions) de Debian actuellement disponible.
Le répertoire pool contient les paquets réels, voir Section 6.10, « Que trouve-t-on dans le répertoire pool ? ».
On trouve aussi les répertoires supplémentaires suivants :
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.
La documentation de base de Debian, comme cette FAQ, les instructions pour le système de rapport de bogues, etc.
Différents fichiers d'index (comme le fichier Maintainers et les fichiers override).
Principalement des ressources pour les développeurs et divers fichiers.
Within each of the major directory trees[3], there are three sets of subdirectories containing index files.
Il y a un ensemble de sous-répertoires
binary- contenant
les fichiers catalogues pour les paquets binaires de chaque architecture
disponible. Par exemple, quelquechosebinary-i386 pour les paquets
s'exécutant sur les machines Intel x86 ou binary-sparc
pour les paquets s'exécutant sur les SPARCStations Sun.
La liste complète de toutes les architectures disponibles pour chaque version est accessible à l'adresse the release's web page. Pour la version en cours, veuillez-vous reporter à Section 4.1, « Sur quelle architecture matérielle fonctionne Debian GNU/Linux ? ».
Les fichiers catalogues dans les répertoires binary-*
sont nommés Packages(.gz, .bz2) et fournissent un résumé de chaque paquet
binaire présent dans la distribution. Les paquets binaires se trouvent à la
racine du répertoire pool.
De plus, il y existe un sous-répertoire nommé source/
contenant les fichiers catalogues pour les paquets sources contenus dans la
distribution. Le fichier catalogue est nommé Sources(.gz, .bz2).
Le dernier, mais non des moindres, est un ensemble de sous-répertoires
utilisé pour les fichiers catalogues du système d'installation. Ils sont
présents dans un répertoire
debian-installer/binary-.
architecture
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 requièrent que le code source soit distribué avec le programme, ou qu'un moyen de récupérer ce code accompagne le programme.
The source code is distributed in the pool directory (see
Section 6.10, « Que trouve-t-on dans le répertoire pool ? ») together with all the architecture-specific binary
directories. To retrieve the source code without having to be familiar with
the structure of the archive, try a command like apt-get source
mypackagename.
Suite à des restrictions de licence, le code source de paquets dans les
sections « contrib » et « non-free » peut être disponible ou non, ils ne
font pas partie formellement du système Debian. Dans certains cas, seuls les
« binary blobs » sans code source peuvent être distribués (voir par exemple
firmware-misc-nonfree) ; parfois la licence interdit la
distribution de binaires précompilés mais elle autorise des paquets sources
compilables par les utilisateurs sur leur machine (voir
broadcom-sta-dkms).
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.
Vous pouvez voir où chaque paquet est conservé en exécutant la commande
apt-cache showsrc monpaquet et en regardant la ligne
« Directory: ». Par exemple, les paquets apache
sont conservés dans pool/main/a/apache/.
De plus, comme il existe de nombreux paquets de bibliothèque
lib*, ceux-ci sont traités différemment. Par exemple, le
paquet libpaper est placé dans le répertoire
pool/main/libp/libpaper/.
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.
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 à https://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 les installer ensuite.
Old releases are removed from the main archive and mirrors, which only keep the content of the releases up to "oldstable" (the stable release before the current one). If you are interested in obtaining older versions of packages, go to https://snapshot.debian.org/.
The snapshot archive is a wayback machine that allows access to old packages based on dates and version numbers. It consists of all past and current packages the Debian archive provides. It provides a valuable valuable resource for tracking down when regressions were introduced, or for providing a specific environment that a particular application may require to run. The snapshot archive is accessible like any normal apt repository, allowing it to be easily used by all.
Si vous avez construit quelques paquets Debian personnels que vous voudriez pouvoir installer en utilisant les outils de gestion de paquets de Debian, vous pouvez mettre en place votre propre archive de paquets pour apt. C'est également utile si vous voulez partager vos paquets Debian tant qu'ils ne sont pas distribués par le projet Debian. Les instructions de mise en œuvre sont données sur le Wiki Debian.
[2] When the present-day sid did not exist, the FTP site organization had one major flaw: there was an assumption that when an architecture is created in the current unstable, it will be released when that distribution becomes the new stable. For many architectures that isn't the case, with the result that those directories had to be moved at release time. This was impractical because the move would chew up lots of bandwidth.
The archive administrators worked around this problem for several years by placing binaries for unreleased architectures in a special directory called "sid". For those architectures not yet released, the first time they were released there was a link from the current stable to sid, and from then on they were created inside the unstable tree as normal. This layout was somewhat confusing to users.
With the advent of package pools (see Section 6.10, « Que trouve-t-on dans le répertoire pool ? »), binary
packages began to be stored in a canonical location in the pool, regardless
of the distribution, so releasing a distribution no longer causes large
bandwidth consumption on the mirrors (there is, however, a lot of gradual
bandwidth consumption throughout the development process).
[3]
dists/stable/main,
dists/stable/contrib,
dists/stable/non-free, and
dists/unstable/main/, etc.
[4] Historically, packages were kept in the subdirectory of
dists corresponding to which distribution contained
them. This turned out to cause various problems, such as large bandwidth
consumption on mirrors when major changes were made. This was fixed with
the introduction of the package pool.
The dists directories are still used for the index files
used by programs like apt.
| | | |
| Chapitre 5. Logiciels disponibles sur un système Debian |  | Chapitre 7. Les bases du système de gestion des paquets Debian |