dnf5-caching - Man Page

This page aims to provide an overview of the various instruments, such as configuration options, command-line parameters, and commands, available in DNF5 for manipulating cached data and their associated scenarios.

Following directory structure illustrates a typical DNF5 cache directory:

/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, but when DNF5 runs as another user, it uses the cache from ~/.cache/libdnf5 with the same structure. The root cache directory can be redefined using the system_cachedir configuration option, and the user cachedir with the cachedir option.

Within the cache directory, there are subdirectories corresponding to each configured repository, such as fedora-* and updates-*. These contain metadata files in the repodata directory and solver-generated cached files in the solv directory. The solver files, used to enhance performance in resolving package dependencies or running queries, can be enabled or disabled on a repository level through the build_cache configuration option. The packages directory may store downloaded packages from a repository, and a metalink or mirrorlist file provides information on the remote locations of the repository data.

Additionally, the root cache directory contains a temporary_files.toml file related to temporarily stored packages in the system.

There are several types of metadata downloaded from remote locations and processed in DNF5.

Some metadata is mandatory and always considered. The main repository metadata file, repomd.xml, contains information about specific metadata type files related to a repository, such as checksums, file sizes, and their locations in the metadata hierarchy. Another mandatory file is the primary metadata file, providing detailed information about available packages, including package names, versions, dependencies, etc. If DNF5 is compiled with modularity support, modules metadata is also downloaded and processed.

Other metadata types are optional and can be loaded into DNF5 in the following 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 is the list of supported optional metadata types:

• 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

If the required metadata is not present in the system, it can result in different scenarios, such as returning an empty query, error output for no match for an argument, or an error when resolving a transaction.

By default, DNF5 does not cache downloaded package data, as the keepcache option is configured to False. With this setting, every time DNF5 downloads a package from the remote location, it tracks it within the temporary_files.toml in the repository cache directory. After the next successful transaction run, all the files are removed based on this list. This process occurs only when the transaction contains any inbound action; otherwise, packages are retained, considering potential use cases.

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

Packages are always retained when downloaded using the download command.

Typically, DNF5 is run with superuser privileges to make system changes. However, there are scenarios where executing queries without elevated privileges is sufficient. In such cases, we may need to download the entire repository metadata for the user account from the remote, even if there is existing data in the root's cache.

In DNF5, when checking for empty, expired, or invalid repository metadata while running under a non-root account, we first examine the root's location. If metadata is present there, it is copied to the user cache location. Note that this cloning of metadata is optimized when copy-on-write functionality is present on the filesystem, such as with btrfs.

To instruct DNF5 to operate exclusively with cached data, avoiding downloads from remote locations, two instruments are available. First, using the cacheonly configuration option, we can specify either metadata to utilize only repository metadata from the cache or all to include the entire cache, disallowing any package downloads. Alternatively, when the --cacheonly parameter 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 advantageous when optional repositories are temporarily unavailable or when we know they are unnecessary for our current use case. It is also useful when cached metadata is not the latest or has expired but is still functional.

The following commands are used for manual cache deletion and creation:

dnf5-clean(8), Clean command
dnf5-makecache(8), Makecache command

To force metadata update before executing a command, use the --refresh parameter.

See AUTHORS.md in dnf5 source distribution.

Contributors to the dnf5 project.

dnf5(8).

The man page dnf-caching(7) is an alias of dnf5-caching(7).