NAMN¶

dnf5-caching — Cachning

BESKRIVNING¶

Denna sida strävar efter att ge en överblick över de olika instrument, såsom konfigurationsalternativ, kommandoradsparametrar och kommandon, som är tillgängliga i DNF5 för att hantera cachade data och deras tillhörande scenarion.

CACHAD DATAS PLATS¶

Följande katalogstruktur illustrerar en typisk cache-katalog för DNF5:

/var/cache/libdnf5/
├── fedora-*
│   ├── metalink.xml
│   ├── repodata
│   │   ├── *-comps-Everything.x86_64.xml
│   │   ├── *-primary.xml.zck
│   │   └── repomd.xml
│   └── solv
│       ├── fedora-group.solvx
│       └── fedora.solv
├── temporary_files.toml
└── updates-*


    ├── metalink.xml


    ├── packages


    │   └── bash-5.2.21-1.fc38.x86_64.rpm


    ├── repodata


    │   ├── *-primary.xml.zck


    │   ├── *-updateinfo.xml.zck


    │   ├── *-comps-Everything.x86_64.xml.gz


    │   └── repomd.xml


    └── solv


        ├── updates-group.solvx


        ├── updates-updateinfo.solvx


        └── updates.solv

Roots standard-cache-katalog är /var/cache/libdnf5, men när DNF5 kör som en annan användare använder den cachen från ~/.cache/libdnf5 med samma struktur. Roots cache-katalog kan definieras om med konfigurationsalternativet system_cachedir, och användares cache-katalog med alternativet cachedir.

Inom cache-katalogen finns det underkataloger motsvarande varje konfigurerat förråd, såsom fedora-* och updates-*. Dessa innehåller metadatafiler i katalogen repodata och solver-genererade cache-filer i katalogen solv. Solver-filerna, vilka används för att förbättra prestandan när paketberoenden löses upp eller frågor körs, kan aktiveras eller avaktiveras på en förrådsnivå genom konfigurationsalternativet build_cache. Katalogen packages kan lagra hämtade paket från ett förråd, och en fil metalink eller mirrorlist ger information om fjärrplatserna för förrådets data.

Dessutom innehåller roots cache-katalog en fil temporary_files.toml relaterad till tillfälligt lagrade paket på systemet.

METADATATYPER¶

Det finns flera typer av metadata som hämtas från fjärrplatser och bearbetas i DNF5.

En del metadata är obligatorisk och bearbetas alltid. Förrådets huvudfil för metadata, repomd.xml, innehåller information om de specifika typerna av metadatafiler som hör till ett förråd, såsom kontrollsummor, filstorlekar och deras plats i metadatahierarkin. En annan obligatorisk fil är metadatafilen primary vilken ger detaljerad information om tillgängliga paket, inklusive paketnamn, versioner, beroenden, etc. Om DNF5 kompileras med stöd för modularitet hämtas även filen modules och bearbetas.

Andra typer av metadata är valfria och kan laddas in i DNF5 på följande sätt:

Här är listan över valfria metadatatyper som stödjs:

Om den nödvändiga metadatan inte är tillgänglig på systemet kan det resultera i olika scenarier, såsom att svara med en tom fråga, felutskrift när ett argument inte matchas eller ett fel vid upplösning av en transaktion.

CACHNING AV PAKET¶

Som standard cachar inte DNF5 hämtade paketdata, eftersom alternativet keepcache är konfigurerat som False. Med denna inställning spårar DNF5 varje gång den hämtar ett paket från fjärrplatsen paketet i temporary_files.toml i förrådets cache-katalog. Efter nästa lyckade transaktionskörning tas alla filerna bort baserat på denna lista. Denna process sker endast när transaktionen innehåller någon inkommande åtgärd; annar behålls paket, med hänsyn till potentiella användningsfall.

När alternativet keepcache är satt till True spåras inte hämtade filer, och de kan tas bort senare, antingen manuellt eller genom att köra kommandot clean, till exempel, dnf5 clean packages.

Paket behålls alltid när de hämtas med kommandot download.

DELA ROOTS CACHE BLAND ANVÄNDARE¶

Typiskt kör DNF5 med superanvändarens privilegier för att kunna göra systemändringar. Det finns dock scenarier då körning av frågor utan förhöjda privilegier är tillräckligt. I sådana fall kan vi behöva hämta förrådets hela metadata för användarkontot från fjärren, även om det finns befintliga data i roots cache.

När DNF5 kontrollerar om förrådsmetadata är tom, utgången eller ogiltig när den kör under ett annat konto än root, undersöker vi först roots plats. Om det finns metadata där kopieras den till användarens cache-plats. Observera att denna kloning av metadata är optimerad när funktionaliteten kopiera-vid-skrivning är tillgänglig i filsystemet, såsom med btrfs.

ALTERNATIVET OCH PARAMETERN CACHEONLY¶

För att instruera DNF5 till att arbeta uteslutande med cachade data, och undvika att hämta från fjärrplatser, är två verktyg tillgängliga. Först kan vi, genom att använda konfigurationsalternativet cacheonly, ange antingen metadata för att använda endast förrådsmetadata från cachen eller all för att inkludera hela cachen, därmed inte tillåta att några paket hämtas. Alternativt sätts, när parametern --cacheonly ges, konfigurationsalternativet automatiskt till all, vilket resulterar i en helt cache-driven funktion.

Att använda värdet metadata till konfigurationen cacheonly kan vara fördelaktigt när valfria förråd tillfälligt är otillgängliga eller när vi vet att de inte behövs för vårt aktuella fall. Det är även användbart när cachade metadata inte är de senaste eller har gått ut men fortfarande fungerar.

RADERA, SKAPA, UPPDATERA¶

Följande kommandon används för att manuellt radera och skapa cachen:

dnf5-clean(8), Rensningskommando <#clean-command-ref-label>
dnf5-makecache(8), Kommando för att skapa <#makecache-command-ref-label>

För att framtvinga att metadata uppdateras före ett kommando körs, använd parametern --refresh.

Upphovsman¶

Se AUTHORS.md i dnf5 källkodsdistribution.

Copyright¶

Medarbetare i dnf5-projektet.

ÖVERSÄTTNING¶

Den svenska översättningen av denna manualsida skapades av Göran Uddeborg <goeran@uddeborg.se>

Denna översättning är fri dokumentation; läs GNU General Public License Version 3 eller senare för upphovsrättsvillkor. Vi tar INGET ANSVAR.

Om du hittar fel i översättningen av denna manualsida, skicka ett mail till Tp-sv@listor.tp-sv.se.