Indeling van de spiegelserverlijst¶

Een spiegelserverlijst bestaat uit één of meer regels met een URI van een spiegelserver. Lege regels en regels die beginnen met een hekje (#) worden genegeerd. Een URI begint steeds meet een URI-methode die de transportmethode vaststelt die voor die spiegelserver gebruikt wordt. Indien de URI bijvoorbeeld met http: begint, is de bevoegde transportmethode apt-transport-http(1), welke specifieke eisen kan stellen aan de indeling van het resterende deel van de URI.

Metadata over een spiegelserver kunnen op dezelfde regel opgegeven worden, gescheiden van de URI met een tab. Verschillende metadata-elementen kunnen onderling gescheiden worden door tabs of spaties. (Dit is een gespecialiseerde functionaliteit die enkel beschikbaar is in apt >= 1.6. Eerdere versies van apt zullen er niet in slagen spiegelserverlijsten met deze functionaliteit te ontleden.)

Vanaf apt 1.6 wordt ook het gebruik van gecomprimeerde spiegelserverlijsten ondersteund. Merk op dat de bestandsnaam van de spiegelserverlijst moet aangeven welk compressiealgoritme gebruikt wordt. Er gebeurt geen autodetectie op basis van de inhoud van het bestand.

Spiegelserverselectie op basis van metadata¶

Zoals aangegeven bij de indeling, kunnen metadata toegevoegd worden aan een spiegelserver om te voorkomen dat een spiegelserver geselecteerd zou worden voor het bekomen van een bestand dat niet overeenkomt met deze metadata. Daardoor kan de spiegelserverlijst bijvoorbeeld partiële spiegelservers bevatten die enkel bepaalde architecturen bedienen en zal APT automatisch een andere spiegelserver kiezen voor bestanden die voor een niet vermelde architectuur bedoeld zijn. Worden ondersteund: beperkingen op het gebied van architectuur (arch), de codenaam van de release (codename), de component van de pakketbron waarin het bestand zich bevindt (component), de taal waarvoor het bestand moet dienen (lang), de suitenaam van de release (suite) en het bestandstype (type).

Volgorde waarin het teruggevallen op spiegelservers gebeurt¶

Indien voor een spiegelserver geen volgorde opgegeven is via de metadatasleutel priority, is de volgorde waarin spiegelservers gecontacteerd worden toevallig. Indien een bepaalde groep spiegelservers eerst uitgeprobeerd moet worden vooraleer eventuele andere groepen aangesproken worden, kan expliciet een prioriteit ingesteld worden. De spiegelservers met het laagste getal worden eerst uitgeprobeerd. Spiegelservers waarvoor geen uitdrukkelijke prioriteit ingesteld werd, hebben standaard het hoogst mogelijke getal en worden daardoor laatst uitgeprobeerd. De keuze tussen spiegelservers met dezelfde prioriteit gebeurt opnieuw op basis van toeval.

Toegestane transportmethodes in een spiegelserverlijst¶

De beschikbaarheid en de keuzemogelijkheden van transportmethodes in een spiegelserverlijst wordt beperkt door hoe de APT-cliënt de spiegelserverlijst benadert. Indien een lokale transportmethode, zoals file of copy gebruikt wordt, kan de spiegelserverlijst ook lokale bronnen bevatten, terwijl een spiegelserverlijst die benaderd wordt via http dat niet kan. Bovendien kan een spiegelserverlijst niet zelf een spiegelserverlijst bevatten of geen andere transportmethodewikkels (zoals apt-transport-tor). Zie de documentatie bij deze transportmethodes over hoe u ze met de spiegelservermethode kunt gebruiken.

Merk op dat versies van apt voorafgaand aan 1.6 geen enkele andere transportmethode dan http ondersteunen.

Basaal voorbeeld¶

Een basaal voorbeeld van een spiegelserverlijst die door alle versies van apt met een spiegelservermethode (>= 0.7.24) ondersteund wordt, waarbij de cliënt om het even welke van de drie spiegelservers zal kiezen:

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

In de veronderstelling dat een bestand met deze inhoud op uw computer opgeslagen werd als /etc/apt/mirrorlist.txt, kan het op de volgende manier gebruikt worden in sources.list(5) (sinds apt 1.6):

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

Alle versies van de spiegelservermethode ondersteunen een spiegelserverlijst die via HTTP benaderd kan worden. In de veronderstelling dat het beschikbaar is op http://apt.example.org/mirror.lst, kan het element uit de bovenstaande sources.list ook als volgt geschreven worden:

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

Merk op dat met het oog op uniformiteit vanaf apt 1.6 het gebruik van mirror+http de voorkeur zou moeten genieten boven mirror. De functionaliteit blijft dezelfde.

Voorbeeld van een met metadata verrijkte spiegelserverselectie¶

Zoals bij de definiëring van de indeling uitgelegd werd, ondersteunen versies van apt voorafgaand aan 1.6 dit niet. Ze zullen dus de spiegelserverlijst niet kunnen ontleden. De voorbeeldspiegelserverlijst is met opzet gecompliceerd gemaakt om een aantal aspecten van het selectieproces te illustreren. Er wordt uitgegaan van de volgende opstelling: de eerste spiegelserver is een lokale spiegelserver die via de methode file kan benaderd worden, maar mogelijk is deze onvolledig. De tweede spiegelserver heeft een zeer goede verbinding, maar het is een gedeeltelijke spiegelserver in die zin dat hij enkel bestanden bevat bedoeld voor de architecturen amd64 en all. De overige spiegelservers zijn doorsneespiegelservers die enkel gecontacteerd moeten worden als de voorgaande niet werken.

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/

In deze opstelling met deze spiegelserverlijst, zal de eerste spiegelserver gebruikt worden om alle indexbestanden te downloaden, in de veronderstelling dat de spiegelserverlijst zelf benaderd wordt via een lokale transportmethode zoals file. Indien dit niet het geval is, of indien de spiegelserver om een andere reden niet bereikbaar is, of indien hij het gevraagde bestand niet ter beschikking heeft, zal een andere spiegelserver gebruikt worden om het bestand te bekomen, en die zal gekozen worden op basis van het type bestand: een indexbestand zal door de laatste server uit de lijst aangeleverd worden, terwijl een pakket voor de architectuur amd64 aangeleverd wordt door de tweede en die voor bijv. de architectuur i386 door een van de drie laatste.