.\" Man page generated from reStructuredText. . . .nr rst2man-indent-level 0 . .de1 rstReportMargin \\$1 \\n[an-margin] level \\n[rst2man-indent-level] level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] - \\n[rst2man-indent0] \\n[rst2man-indent1] \\n[rst2man-indent2] .. .de1 INDENT .\" .rstReportMargin pre: . RS \\$1 . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin] . nr rst2man-indent-level +1 .\" .rstReportMargin post: .. .de UNINDENT . RE .\" indent \\n[an-margin] .\" old: \\n[rst2man-indent\\n[rst2man-indent-level]] .nr rst2man-indent-level -1 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]] .in \\n[rst2man-indent\\n[rst2man-indent-level]]u .. .TH "DNF5-CACHING" "7" "Apr 23, 2025" "" "dnf5" .SH NAME dnf5-caching \- Caching .SH DESCRIPTION .sp 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. .SH CACHED DATA LOCATION .sp Following directory structure illustrates a typical DNF5 cache directory: .INDENT 0.0 .INDENT 3.5 .sp .EX /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 .EE .UNINDENT .UNINDENT .sp The default root cache directory is \fB/var/cache/libdnf5\fP, but when DNF5 runs as another user, it uses the cache from \fB~/.cache/libdnf5\fP with the same structure. The root cache directory can be redefined using the \fBsystem_cachedir\fP configuration option, and the user cachedir with the \fBcachedir\fP option. .sp Within the cache directory, there are subdirectories corresponding to each configured repository, such as \fBfedora\-*\fP and \fBupdates\-*\fP\&. These contain metadata files in the \fBrepodata\fP directory and solver\-generated cached files in the \fBsolv\fP 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 \fBbuild_cache\fP configuration option. The \fBpackages\fP directory may store downloaded packages from a repository, and a \fBmetalink\fP or \fBmirrorlist\fP file provides information on the remote locations of the repository data. .sp Additionally, the root cache directory contains a \fBtemporary_files.toml\fP file related to temporarily stored packages in the system. .SH METADATA TYPES .sp There are several types of metadata downloaded from remote locations and processed in DNF5. .sp Some metadata is mandatory and always considered. The main repository metadata file, \fBrepomd.xml\fP, 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 \fBprimary\fP metadata file, providing detailed information about available packages, including package names, versions, dependencies, etc. If DNF5 is compiled with modularity support, \fBmodules\fP metadata is also downloaded and processed. .sp Other metadata types are optional and can be loaded into DNF5 in the following ways: .INDENT 0.0 .IP \(bu 2 Explicit user request by adding the requested type to the \fBoptional_metadata_types\fP configuration option .IP \(bu 2 Automatically during runtime, depending on the CLI command used .IP \(bu 2 For \fBfilelists\fP metadata, when the user passes any filepath argument .UNINDENT .sp Here is the list of supported optional metadata types: .INDENT 0.0 .IP \(bu 2 \fBcomps\fP: Metadata containing package groups and environment descriptions .IP \(bu 2 \fBfilelists\fP: Information about all files provided by packages .IP \(bu 2 \fBupdateinfo\fP: Security\-related updates and advisories information .IP \(bu 2 \fBpresto\fP: Information related to delta RPMs .IP \(bu 2 \fBother\fP: Additional metadata, such as changelogs .UNINDENT .sp 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. .SH CACHING PACKAGES .sp By default, DNF5 does not cache downloaded package data, as the \fBkeepcache\fP option is configured to \fBFalse\fP\&. With this setting, every time DNF5 downloads a package from the remote location, it tracks it within the \fBtemporary_files.toml\fP 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. .sp When the keepcache option is set to \fBTrue\fP, downloaded files are not tracked, and they could be removed later, either manually or by executing the \fBclean\fP command, for example, \fBdnf5 clean packages\fP\&. .sp Packages are always retained when downloaded using the \fBdownload\fP command. .SH SHARING ROOT CACHE AMONG USERS .sp 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\(aqs cache. .sp In DNF5, when checking for empty, expired, or invalid repository metadata while running under a non\-root account, we first examine the root\(aqs 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. .SH CACHEONLY OPTION VS PARAMETER .sp To instruct DNF5 to operate exclusively with cached data, avoiding downloads from remote locations, two instruments are available. First, using the \fBcacheonly\fP configuration option, we can specify either \fBmetadata\fP to utilize only repository metadata from the cache or \fBall\fP to include the entire cache, disallowing any package downloads. Alternatively, when the \fB\-\-cacheonly\fP parameter is employed, it automatically sets the configuration option to \fBall\fP, resulting in a fully cache\-driven operation. .sp Using the \fBmetadata\fP value for the \fBcacheonly\fP 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. .SH DELETE, CREATE, UPDATE .sp The following commands are used for manual cache deletion and creation: .INDENT 0.0 .INDENT 3.5 .nf \fBdnf5\-clean(8)\fP, \fI\%Clean command\fP \fBdnf5\-makecache(8)\fP, \fI\%Makecache command\fP .fi .sp .UNINDENT .UNINDENT .sp To force metadata update before executing a command, use the \fB\-\-refresh\fP parameter. .SH AUTHOR See AUTHORS.md in dnf5 source distribution. .SH COPYRIGHT Contributors to the dnf5 project. .\" Generated by docutils manpage writer. .