Format de la liste de miroirs¶

Une liste de miroirs contient une ou plusieurs lignes qui spécifient chacune l'URI d'un miroir. Les lignes vides et celles commençant par un caractère dièse (#) sont ignorées. Un URI débute toujours par un schème d'URI qui définit le transport utilisé pour ce miroir. Si, par exemple, l'URI débute par http:, le transport responsable est apt-transport-http(1) qui pourrait avoir des exigences particulières pour le format du reste de l'URI.

Les métadonnées d'un miroir peuvent être placées sur la même ligne, séparées de l'URI par une tabulation. De multiples éléments de métadonnées peuvent être eux-mêmes séparés par des tabulations ou des espaces. (C'est une fonctionnalité avancée seulement disponible avec apt >= 1.6. Les versions d'APT antérieures échoueront à analyser les listes de miroirs utilisant cette fonctionnalité.)

Depuis apt 1.6, l'utilisation de listes de miroirs compressées est aussi gérée. Veuillez noter que le nom de fichier de la liste de miroirs doit spécifier l'algorithme de compression utilisé ; il n'y a pas d'auto-détection basée sur le contenu du fichier.

Sélection du miroir par les métadonnées¶

Comme cela est spécifié dans le format, un miroir peut avoir des métadonnées supplémentaires attachées pour éviter qu'il soit sélectionné pour la récupération d'un fichier qui ne correspond pas à ces métadonnées. De cette façon, la liste de miroirs peut contenir par exemple des miroirs partiels fournissant seulement certaines architectures et APT choisira automatiquement un autre miroir pour les fichiers requérant une architecture non listée. Sont prises en charge les limites liées à l'architecture (arch), au nom de code de la version (codename), aux composants du dépôt où se trouve le fichier (component), à la langue à laquelle le fichier s'applique (lang), au nom de la suite de la version suite) et au type du fichier (type).

Ordre de repli pour les miroirs¶

Si aucune priorité n'est donnée à un miroir par la clé de métadonnée priority, l'ordre de contact des miroirs est aléatoire. Si un ensemble particulier de miroirs doit être essayé avant que n'importe lequel des autres ensembles ne le soit, une priorité peut être spécifiée explicitement. Les miroirs avec les numéros les plus bas sont essayés en premier. Les miroirs qui n'ont pas de priorité explicite portent par défaut le numéro le plus élevé possible, et donc, sont essayés en dernier. Le choix entre les miroirs de même priorité est aussi aléatoire.

Transports permis dans une liste de miroir¶

La disponibilité et le choix des transports dans une liste de miroirs sont limités par la manière dont le client APT accède à la liste des miroirs. Si un transport local comme file ou copy est utilisé, la liste de miroirs peut aussi inclure des sources locales, alors qu'une liste de miroirs atteinte par http ne le peut pas. Par ailleurs, une liste de miroirs ne peut pas contenir une liste de miroirs ou d'autres transports enveloppants (comme apt-transport-tor). Voir la documentation sur ces transports pour connaître la manière de les utiliser avec la méthode miroir.

Veuillez noter que les versions d'APT antérieures à 1.6 ne prennent pas en charge d'autres transports que http.

Exemple basique¶

Voici un exemple basique de liste de miroirs prise en charge par toutes les versions d'APT avec une méthode de miroir (>= 0.7.24) dans lequel le client choisira n'importe lequel des trois miroirs :

http://ftp.de.debian.org/debian/
http://ftp.us.debian.org/debian/
http://deb.debian.org/debian/

Si un fichier avec ce contenu est stocké sur la machine sous le nom de /etc/apt/mirrorlist.txt, il peut être utilisé comme cela dans sources.list(5) (à partir d'apt 1.6) :

deb mirror+file:/etc/apt/mirrorlist.txt bookworm main

Toutes les versions de la méthode miroir prennent en charge une liste de miroirs accessible par HTTP, aussi, dans la mesure où elle est disponible à l'adresse http://apt.example.org/mirror.lst, l'entrée de sources.list ci-dessus peut être écrite plutôt ainsi :

deb mirror://apt.example.org/mirror.lst bookworm main

Veuillez noter que depuis apt 1.6, l'utilisation de mirror+http est préférable à mirror pour uniformiser. La fonctionnalité est la même.

Exemple de sélection du miroir avec des métadonnées améliorées¶

Comme cela est expliqué dans la définition de format, les versions d'APT antérieures à 1.6 ne prennent pas cela en charge et échoueront à analyser la liste de miroirs. L'exemple de liste de miroirs est complexe intentionnellement pour montrer certains aspects de la sélection. La configuration suivante est supposée : le premier miroir est un miroir local accessible par la méthode « file », mais possiblement incomplet ; le second miroir possède une excellente connexion, c'est un miroir partiel dans la mesure où il ne contient que des fichiers liés aux architectures amd64 et all. Les miroirs restants sont des miroirs ordinaires qui devraient être contactés seulement si les précédents ne fonctionnent pas.

file:/srv/local/debian/mirror/	priority:1 type:index
http://partial.example.org/mirror/	priority:2 arch:amd64 arch:all type:deb
http://ftp.us.debian.org/debian/	type:deb
http://ftp.de.debian.org/debian/	type:deb
https://deb.debian.org/debian/

Dans une configuration avec cette liste de miroirs, le premier miroir sera utilisé pour télécharger tous les fichiers d'index en supposant que la liste de miroirs elle-même est atteinte par un transport local comme file. Si ce n'est pas le cas, si le miroir est inaccessible ou s'il ne contient pas le fichier requis, un autre miroir sera utilisé pour récupérer le fichier, choisi selon le type du fichier : un fichier d'index sera servi par le dernier miroir de la liste, tandis qu'un paquet de l'architecture amd64 est servi par le second et ceux, par exemple, de l'architecture i386 par un des trois derniers.