DNF5-CACHING(7)

📦
version 5.4.6.0 · 10 versions
, in fedora 44

✨ DNF5-CACHING(7) ✨

okay bestie, welcome to dnf5-caching — the manual page for dnf5 that's all about caching 💾✨ (yes, the manual name is right there in the title, we're already iconic)

🌸 NAME 🌸

dnf5-caching — Caching 💅

💖 DESCRIPTION 💖

So like, this page is here to give you the whole ~tour~ of the different instruments DNF5 has for messing with cached data, plus the scenarios where you'd actually use them. We're talking configuration options, command-line parameters, and commands, all of it 🫶

🎀 CACHED DATA LOCATION 🎀

here's the vibe of a typical DNF5 cache directory, bestie:

/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

The default root cache directory is /var/cache/libdnf5, periodt. But — plot twist — when DNF5 runs as another user, it pulls the cache from ~/.cache/libdnf5 instead, same structure and everything. And if you wanna change things up? The root cache directory can be redefined with the system_cachedir configuration option, and the user cachedir with the cachedir option. slay 💅

Inside that cache directory there are subdirectories for each configured repository, like fedora-* and updates-*. Those hold metadata files in the repodata directory, and solver-generated cached files in the solv directory. Those solver files? They're there to make resolving package dependencies (or running queries) way faster 🔥 and you can turn them on or off per repository with the build_cache configuration option. The packages directory may store downloaded packages from a repository, and a metalink or mirrorlist file tells you where the remote locations of the repository data are.

Oh and also — the root cache directory has a temporary_files.toml file in it, which is all about temporarily stored packages on the system 👀

🦋 METADATA TYPES 🦋

There are several types of metadata that get downloaded from remote locations and processed in DNF5, bestie. Let's break it down 💫

Some metadata is mandatory and always considered. The main repository metadata file, repomd.xml, holds info about specific metadata type files related to a repository — checksums, file sizes, and where they live in the metadata hierarchy. Another mandatory file is the primary metadata file, which gives you the detailed tea on available packages: package names, versions, dependencies, etc. And modules metadata is also downloaded and processed. no skips 💅

Other metadata types are optional and can be loaded into DNF5 in these ways:

  • Explicit user request, by adding the requested type to the optional_metadata_types configuration option
  • Automatically during runtime, depending on the CLI command used
  • For filelists metadata, when the user passes any filepath argument

Here's the list of supported optional metadata types, in all their glory:

  • comps: Metadata containing package groups and environment descriptions
  • filelists: Information about all files provided by packages
  • updateinfo: Security-related updates and advisories information
  • presto: Information related to delta RPMs
  • other: Additional metadata, such as changelogs

And if the required metadata isn't present on the system? That can lead to different scenarios — like returning an empty query, an error output for no match for an argument, or an error when resolving a transaction 😭 fair warning fr fr

🍓 CACHING PACKAGES 🍓

By default, DNF5 does not cache downloaded package data, because the keepcache option is set to False. With that setting, every single time DNF5 downloads a package from a remote location, it tracks it inside temporary_files.toml in the repository cache directory. Then, after the next successful transaction run, all those files get removed based on that list. This only happens when the transaction contains any inbound action — otherwise, packages are retained, because potential use cases, yk? 🙈

When keepcache is set to True, downloaded files are not tracked, and they could be removed later — either manually or by running the clean command, for example, dnf5 clean packages.

Also important bestie: packages are always retained when downloaded using the download command. no takebacks 💖

🧚 SHARING ROOT CACHE AMONG USERS 🧚

Typically DNF5 is run with superuser privileges so it can make system changes. But there are scenarios where just running queries without elevated privileges is enough. In those cases, we might need to download the entire repository metadata for the user account from the remote — even if there's already existing data in the root's cache. awkward 😭

So here's what DNF5 does: when checking for empty, expired, or invalid repository metadata while running under a non-root account, it first examines the root's location. If metadata is present there, it gets copied over to the user cache location. And ngl, this cloning of metadata is optimized when copy-on-write functionality is present on the filesystem — like with btrfs. ate ✨

💀 CACHEONLY OPTION VS PARAMETER 💀

To tell DNF5 to operate exclusively with cached data and avoid downloads from remote locations, you've got two instruments available, bestie:

  1. The cacheonly configuration option — where you can specify either metadata (use only repository metadata from the cache) or all (include the entire cache, disallowing any package downloads).
  2. The --cacheonly parameter — when this is employed, it automatically sets the configuration option to all, resulting in a fully cache-driven operation.

Using the metadata value for the cacheonly configuration can be a whole advantage when optional repositories are temporarily unavailable, or when we already know they're unnecessary for our current use case. It's also useful when cached metadata isn't the latest or has expired — but is still functional. lowkey the move 💅

🌈 DELETE, CREATE, UPDATE 🌈

These commands are the ones you want for manual cache deletion and creation:

And to force a metadata update before executing a command, just use the --refresh parameter. main character energy 🔥

👑 Author 👑

See AUTHORS.md in dnf5 source distribution.

Contributors to the dnf5 project.

okay that's the whole page bestie, you're officially a caching expert 🎀 and if you wanna know where all this came from: this is dnf5 source/version DNF5-CACHING(7), dated Sep 24, 2026 — mwah, go forth and cache responsibly 💖✨🦋

📦 where this page comes from