DNF4(8)

๐Ÿ’… DNF4(8) โ€” the DNF Command Reference, bestie edition โœจ

okay so. hi. you're reading the dnf4 man page, which means you're officially in your package-manager-main-character era. this is part 1, it's long, and honestly? iconic. let's go ๐ŸŽ€


๐ŸŒธ NAME ๐ŸŒธ

dnf4 โ€” DNF Command Reference


๐Ÿฆ‹ SYNOPSIS ๐Ÿฆ‹

dnf [options] <command> [<args>...]

that's it. that's the whole shape of it. dnf, then some options if you're feeling fancy, then the command, then whatever args that command wants. periodt.


โœจ DESCRIPTION โœจ

so DNF is the next upcoming major version of YUM, which is a package manager for RPM-based Linux distributions, and it lives over here: https://github.com/rpm-software-management/dnf/. YUM itself lives at http://yum.baseurl.org/ if you wanna go say hi to your ancestor ๐Ÿ’–

ngl it roughly maintains CLI compatibility with YUM (roughly, bestie, don't come for me) and it defines a strict API for extensions and plugins. strict as in it-means-business strict. slay.

๐Ÿซถ Plugins, and how to get more commands

Plugins can modify or extend features of DNF, or straight up hand you additional CLI commands on top of the ones listed below. so like โ€” if you know the name of one of those commands (including commands mentioned below, yes those count too), you may find/install the package that provides it using the appropriate virtual provide, which looks like:

dnf-command(<alias>)

where <alias> is the name of the command. example, and I'm not making this up:

dnf install 'dnf-command(versionlock)'

...installs a versionlock plugin. ๐ŸŒˆ This same approach also applies to specifying dependencies of packages that require a particular DNF command. iykyk.

๐Ÿ’€ Return values (the vibes check)

  • 0 โ€” Operation was successful. we love to see it โœจ
  • 1 โ€” An error occurred, which was handled by dnf.
  • 3 โ€” An unknown unhandled error occurred during operation. ๐Ÿ˜ญ
  • 100 โ€” See check-update
  • 200 โ€” There was a problem with acquiring or releasing of locks.

๐Ÿ‘‘ Available commands

here's the whole roster, no skips, no cuts:

  • alias
  • autoremove
  • check
  • check-update
  • clean
  • deplist
  • distro-sync
  • downgrade
  • group
  • help
  • history
  • info
  • install
  • list
  • makecache
  • mark
  • module
  • provides
  • reinstall
  • remove
  • repoinfo
  • repolist
  • repoquery
  • repository-packages
  • search
  • shell
  • swap
  • updateinfo
  • upgrade
  • upgrade-minimal

๐ŸŒธ Additional information

more sections for you to devour later, bestie:

  • Options
  • Specifying Packages
  • Specifying Provides
  • Specifying File Provides
  • Specifying Groups
  • Specifying Transactions
  • Metadata Synchronization
  • Configuration Files Replacement Policy
  • Files
  • See Also

๐ŸŽ€ OPTIONS ๐ŸŽ€

okay this is the big one. grab a snack. ๐Ÿ“ every single flag, accounted for, no cap.

  • -4 โ€” Resolve to IPv4 addresses only. four. quad. classic.
  • -6 โ€” Resolve to IPv6 addresses only. six. neon. futuristic. โœจ
  • --advisory=<advisory>, --advisories=<advisory> โ€” Include packages corresponding to the advisory ID, Eg. FEDORA-2201-123. Applicable for the install, repoquery, updateinfo, upgrade and offline-upgrade (dnf-plugins-core) commands.
  • --allowerasing โ€” Allow erasing of installed packages to resolve dependencies. This option could be used as an alternative to the yum swap command where packages to remove are not explicitly defined.
  • --assumeno โ€” Automatically answer no for all questions. the "no thoughts, just no" option ๐Ÿ™ˆ
  • -b, --best โ€” Try the best available package versions in transactions. Specifically during dnf upgrade, which by default skips over updates that can not be installed for dependency reasons, the switch forces DNF to only consider the latest packages. When running into packages with broken dependencies, DNF will fail giving a reason why the latest version can not be installed.

Note that the use of the newest available version is only guaranteed for the packages directly requested (e.g. as a command line arguments), and the solver may use older versions of dependencies to meet their requirements.

  • --bugfix โ€” Include packages that fix a bugfix issue. Applicable for the install, repoquery, updateinfo, upgrade and offline-upgrade (dnf-plugins-core) commands.
  • --bz=<bugzilla>, --bzs=<bugzilla> โ€” Include packages that fix a Bugzilla ID, Eg. 123123. Applicable for the install, repoquery, updateinfo, upgrade and offline-upgrade (dnf-plugins-core) commands.
  • -C, --cacheonly โ€” Run entirely from system cache, don't update the cache and use it even in case it is expired. โœจ

DNF uses a separate cache for each user under which it executes. The cache for the root user is called the system cache. This switch allows a regular user read-only access to the system cache, which usually is more fresh than the user's and thus he does not have to wait for metadata sync. (yes bestie, free access to the good cache, no waiting in line ๐Ÿ’…)

  • --color=<color> โ€” Control whether color is used in terminal output. Valid values are always, never and auto (default). never?? in this economy?? ๐Ÿ˜ญ
  • --comment=<comment> โ€” Add a comment to the transaction history. leave a lil note for future you ๐ŸŒธ
  • -c <config file>, --config=<config file> โ€” Configuration file location.
  • --cve=<cves>, --cves=<cves> โ€” Include packages that fix a CVE (Common Vulnerabilities and Exposures) ID (http://cve.mitre.org/about/), Eg. CVE-2201-0123. Applicable for the install, repoquery, updateinfo, upgrade and offline-upgrade (dnf-plugins-core) commands.
  • -d <debug level>, --debuglevel=<debug level> โ€” Debugging output level. This is an integer value between 0 (no additional information strings) and 10 (shows all debugging information, even that not understandable to the user), default is 2. Deprecated, use -v instead. ๐Ÿ’€
  • --debugsolver โ€” Dump data aiding in dependency solver debugging into ./debugdata. it just... makes a folder. it's giving detective ๐Ÿ•ต๏ธ
  • --disableexcludes={all|main|<repoid>}, --disableexcludepkgs={all|main|<repoid>} โ€” Disable excludepkgs and includepkgs configuration options. Takes one of the following three options:
    • all, disables all excludepkgs and includepkgs configurations
    • main, disables excludepkgs and includepkgs defined in the [main] section
    • repoid, disables excludepkgs and includepkgs defined for the given repository

Note that the --exclude option appends to the [main] excludepkgs configuration and therefore is disabled when main or all is specified.

  • --disable, --set-disabled โ€” Disable specified repositories (automatically saves). The option has to be used together with the config-manager command (dnf-plugins-core).
  • --disableplugin=<plugin names> โ€” Disable the listed plugins specified by names or globs.
  • --disablerepo=<repoid> โ€” Temporarily disable active repositories for the purpose of the current dnf command. Accepts an id, a comma-separated list of ids, or a glob of ids. This option can be specified multiple times, but is mutually exclusive with --repo. โš ๏ธ not both, bestie, pick a lane.
  • --downloaddir=<path>, --destdir=<path> โ€” Redirect downloaded packages to provided directory. The option has to be used together with the --downloadonly command line option, with the download, modulesync, reposync or system-upgrade commands (dnf-plugins-core).
  • --downloadonly โ€” Download the resolved package set without performing any rpm transaction (install/upgrade/erase).

Packages are removed after the next successful transaction. This applies also when used together with --destdir option as the directory is considered as a part of the DNF cache. To persist the packages, use the download command instead. ๐Ÿซถ (translation: they're not yours forever. use download if you want to keep them.)

  • -e <error level>, --errorlevel=<error level> โ€” Error output level. This is an integer value between 0 (no error output) and 10 (shows all error messages), default is 3. Deprecated, use -v instead. ๐Ÿ’€
  • --enable, --set-enabled โ€” Enable specified repositories (automatically saves). The option has to be used together with the config-manager command (dnf-plugins-core).
  • --enableplugin=<plugin names> โ€” Enable the listed plugins specified by names or globs.
  • --enablerepo=<repoid> โ€” Temporarily enable additional repositories for the purpose of the current dnf command. Accepts an id, a comma-separated list of ids, or a glob of ids. This option can be specified multiple times. โœจ (yes you can stack it. go off.)
  • --enhancement โ€” Include enhancement relevant packages. Applicable for the install, repoquery, updateinfo, upgrade and offline-upgrade (dnf-plugins-core) commands.
  • -x <package-file-spec>, --exclude=<package-file-spec> โ€” Exclude packages specified by <package-file-spec> from the operation.
  • --excludepkgs=<package-file-spec> โ€” Deprecated option. It was replaced by the --exclude option. ๐Ÿ’€
  • --forcearch=<arch> โ€” Force the use of an architecture. Any architecture can be specified. However, use of an architecture not supported natively by your CPU will require emulation of some kind. This is usually through QEMU. The behavior of --forcearch can be configured by using the arch and ignorearch configuration options with values <arch> and True respectively.
  • -h, --help, --help-cmd โ€” Show the help. the ole reliable ๐Ÿซถ
  • --installroot=<path> โ€” Specifies an alternative installroot, relative to where all packages will be installed. Think of this like doing chroot <root> dnf, except using --installroot allows dnf to work before the chroot is created. It requires absolute path. ๐Ÿ”ฅ
    • cachedir, log files, releasever, and gpgkey are taken from or stored in the installroot. Gpgkeys are imported into the installroot from a path relative to the host which can be specified in the repository section of configuration files.
    • configuration file and reposdir are searched inside the installroot first. If they are not present, they are taken from the host system. Note: When a path is specified within a command line argument (--config=<config file> in case of configuration file and --setopt=reposdir=<reposdir> for reposdir) then this path is always relative to the host with no exceptions.
    • vars are taken from the host system or installroot according to reposdir. When reposdir path is specified within a command line argument, vars are taken from the installroot. When varsdir paths are specified within a command line argument (--setopt=varsdir=<reposdir>) then those path are always relative to the host with no exceptions.
๐ŸŒˆ okay that's the end of part 1 bestie!! more parts incoming, don't go anywhere, we are literally just getting started ๐Ÿ’–
  • The pluginpath and pluginconfpath are relative to the host. ๐Ÿซถ
โš ๏ธ ok so listen bestie โ€” you probably ALSO wanna throw in the command-line option --releasever=<release> when you're building the installroot, because otherwise the $releasever value gets pulled straight outta the rpmdb inside the installroot (which means it's literally empty at the moment of creation and the whole transaction fails ๐Ÿ˜ญ). If you use --releasever=/, then releasever gets detected from the host (/) system instead. Also heads up: the new installroot path, at the time of creation, does not contain the repository, releasever and dnf.conf files.

On a modular system you might also wanna use the --setopt=module_platform_id=<module_platform_name:stream> command-line option while creating the installroot โ€” otherwise the module_platform_id value gets taken from the /etc/os-release file within the installroot (and thus it's empty at creation time, the modular dependency could be unsatisfied, and modules content could be excluded). ๐Ÿ’€

Installroot examples, iconic edition:

dnf --installroot=<installroot> --releasever=<release> install system-release

Permanently sets the releasever of the system in the <installroot> directory to <release>. slay.

dnf --installroot=<installroot> --setopt=reposdir=<path> --config /path/dnf.conf upgrade

Upgrades packages inside the installroot from a repository described by --setopt using configuration from /path/dnf.conf. ๐ŸŽ€

  • --newpackage โ€” Include newpackage relevant packages. Applicable for the install, repoquery, updateinfo, upgrade and offline-upgrade (dnf-plugins-core) commands.
  • --noautoremove โ€” Disable removal of dependencies that are no longer used. It sets the clean_requirements_on_remove configuration option to False. โœจ
  • --nobest โ€” Set best option to False, so that transactions are not limited to best candidates only.
  • --nodocs โ€” Do not install documentation. Sets the rpm flag RPMTRANS_FLAG_NODOCS.
  • --nogpgcheck โ€” Skip checking GPG signatures on packages (if RPM policy allows). ๐Ÿ™ˆ
  • --noplugins โ€” Disable all plugins.
  • --obsoletes โ€” This one has an effect on an install/update: it enables dnf's obsoletes processing logic. For more info see the obsoletes option.

This option also displays capabilities that the package obsoletes when used together with the repoquery command. ๐Ÿ’…

Configuration Option: obsoletes

  • -q, --quiet โ€” In combination with a non-interactive command, shows just the relevant content. Suppresses messages notifying about the current state or actions of DNF.
  • -R <minutes>, --randomwait=<minutes> โ€” Maximum command wait time.
  • --refresh โ€” Set metadata as expired before running the command.
  • --releasever=<release> โ€” Configure DNF as if the distribution release was <release>. This can affect cache paths, values in configuration files and mirrorlist URLs.
  • --releasever_major=<major version> โ€” Override the releasever_major variable, which is usually automatically detected or taken from the part of $releasever before the first .. This option does not affect the $releasever variable.
  • --releasever_minor=<minor version> โ€” Override the releasever_minor variable, which is usually automatically detected or taken from the part of $releasever after the first .. This option does not affect the $releasever variable.
  • --repofrompath <repo>,<path/url> โ€” Specify a repository to add to the repositories for this query. This option can be used multiple times. ๐ŸŒˆ
    • The repository label is specified by <repo>.
    • The path or url to the repository is specified by <path/url>. It is the same path as a baseurl and can be also enriched by the repo variables.
    • The configuration for the repository can be adjusted using --setopt=<repo>.<option>=<value>.
    • If you want to view only packages from this repository, combine this with the --repo=<repo> or --disablerepo="*" switches.
  • --repo=<repoid>, --repoid=<repoid> โ€” Enable just specific repositories by an id or a glob. Can be used multiple times with accumulative effect. It's basically a shortcut for --disablerepo="*" --enablerepo=<repoid> and is mutually exclusive with the --disablerepo option. ๐Ÿ‘‘
  • --rpmverbosity=<name> โ€” RPM debug scriptlet output level. Sets the debug level to <name> for RPM scriptlets. For available levels, see the rpmverbosity configuration option.
  • --sec-severity=<severity>, --secseverity=<severity> โ€” Includes packages that provide a fix for an issue of the specified severity. Applicable for the install, repoquery, updateinfo, upgrade and offline-upgrade (dnf-plugins-core) commands.
  • --security โ€” Includes packages that provide a fix for a security issue. Applicable for the install, repoquery, updateinfo, upgrade and offline-upgrade (dnf-plugins-core) commands.
  • --setopt=<option>=<value> โ€” Override a configuration option from the configuration file. To override configuration options for repositories, use repoid.option for the <option>. Values for configuration options like excludepkgs, includepkgs, installonlypkgs and tsflags are appended to the original value, they do not override it. However, specifying an empty value (e.g. --setopt=tsflags=) will clear the option. ๐Ÿ’–
  • --skip-broken โ€” Resolve depsolve problems by removing packages that are causing problems from the transaction. It's an alias for the strict configuration option with value False. Additionally, with the enable and disable module subcommands it allows one to perform an action even in case of broken modular dependencies.
  • --showduplicates โ€” Show duplicate packages in repositories. Applicable for the list and search commands.
  • --transient โ€” Applicable only on bootc (bootable containers) systems. Perform transactions using a transient overlay which will be lost on the next reboot. See also the persistence configuration option.
  • -v, --verbose โ€” Verbose operation, show debug messages.
  • --version โ€” Show DNF version and exit.
  • -y, --assumeyes โ€” Automatically answer yes for all questions. ๐Ÿ’…

List options are comma-separated. Command-line options override respective settings from configuration files. periodt.


๐ŸŒธ COMMANDS ๐ŸŒธ

For an explanation of <package-spec>, <package-file-spec> and <package-name-spec> see Specifying Packages.

For an explanation of <provide-spec> see Specifying Provides.

For an explanation of <group-spec> see Specifying Groups.

For an explanation of <module-spec> see Specifying Modules.

For an explanation of <transaction-spec> see Specifying Transactions.


๐Ÿ”ฎ Alias Command

Command: alias

Allows the user to define and manage a list of aliases (in the form <name=value>), which can then be used as dnf commands to abbreviate longer command sequences. For examples on using the alias command, see Alias Examples. For examples on the alias processing, see Alias Processing Examples. ๐Ÿ’ซ

To use an alias (name=value), the name must be placed as the first "command" (e.g. the first argument that is not an option). It's then replaced by its value, and the resulting sequence is again searched for aliases. The alias processing stops when the first found command is not a name of any alias.

In case the processing would result in an infinite recursion, the original arguments are used instead. ๐Ÿ˜Œ

Also, like in shell aliases, if the result starts with a \, the alias processing will stop.

All aliases are defined in configuration files in the /etc/dnf/aliases.d/ directory in the [aliases] section, and aliases created by the alias command are written to the USER.conf file. In case of conflicts, the USER.conf has the highest priority, and alphabetical ordering is used for the rest of the configuration files.

Optionally, there's the enabled option in the [main] section defaulting to True. This can be set for each file separately in the respective file, or globally for all aliases in the ALIASES.conf file. ๐Ÿซถ

dnf alias [options] [list] [<name>...]

List aliases with their final result. The [<alias>...] parameter further limits the result to only those aliases matching it.

dnf alias [options] add <name=value>...

Create new aliases.

dnf alias [options] delete <name>...

Delete aliases.


๐ŸŽ€ Alias Examples

dnf alias list

Lists all defined aliases.

dnf alias add rm=remove

Adds a new command alias called rm which works the same as the remove command. slay.

dnf alias add upgrade="\upgrade --skip-broken --disableexcludes=all --obsoletes"

Adds a new command alias called upgrade which works the same as the upgrade command, with additional options. Note that the original upgrade command is prefixed with a \ to prevent an infinite loop in alias processing. ๐Ÿ”


๐Ÿฆ‹ Alias Processing Examples

If there are defined aliases in=install and FORCE="--skip-broken --disableexcludes=all":

  • dnf FORCE in will be replaced with dnf --skip-broken --disableexcludes=all install
  • dnf in FORCE will be replaced with dnf install FORCE (which will fail) ๐Ÿ’€

If there is defined alias in=install:

  • dnf in will be replaced with dnf install
  • dnf --repo updates in will be replaced with dnf --repo updates in (which will fail)

โญ Autoremove Command

Command: autoremove Aliases for explicit NEVRA matching: autoremove-n, autoremove-na, autoremove-nevra

dnf [options] autoremove

Removes all packages from the system that were originally installed as dependencies of user-installed packages, but which are no longer required by any such package. ๐Ÿงน

dnf [options] autoremove <spec>...

This is an alias for the Remove Command command with clean_requirements_on_remove set to True. It removes the specified packages from the system along with any packages depending on the packages being removed. Each <spec> can be either a <package-spec>, which specifies a package directly, or a @<group-spec>, which specifies an (environment) group which contains it. It also removes any dependencies that are no longer needed. โœจ

Also there's this โœจeliteโœจ little trio of autoremove commands โ€” autoremove-n, autoremove-na and autoremove-nevra โ€” that let you pass one exact argument in NEVRA (name-epoch:version-release.architecture) format. Precision queen behaviour, we love to see it. ๐ŸŽฏ

Heads up though bestie: this command by default does not force a sync of expired metadata. See also Metadata Synchronization.


๐Ÿ•ต๏ธโ™€๏ธ Check Command ๐Ÿ•ต๏ธโ™€๏ธ

Command: check

dnf [options] check [--dependencies] [--duplicates] [--obsoleted] [--provides]

Okay so this one โœจinvestigatesโœจ your local packagedb and spills all the tea on any problems it finds. You can keep it on a leash by only running the checks you want with --dependencies, --duplicates, --obsoleted and --provides โ€” because by default it checks literally everything. No filter, all vibes. ๐Ÿ˜ญ


๐Ÿ“ฌ Check-Update Command ๐Ÿ“ฌ

Command: check-update Aliases: check-upgrade

dnf [options] check-update [--changelogs] [<package-file-spec>...]

Non-interactively checks whether updates for the packages you named are available. Give it no <package-file-spec> and it just checks whether any updates at all exist for your system. Very "do I have mail" energy. ๐Ÿ“ฎ

The exit codes here are iconic and you WILL be checking them in scripts, so memorise:

  • 100 โ€” updates are available, and the list of updates gets printed ๐ŸŽ‰
  • 0 โ€” no updates, we're chilling
  • 1 โ€” an error happened ๐Ÿ˜ญ

Add --changelogs and it also prints the changelog delta of the packages that are about to be updated. Delicious detail, no cap.

Real talk: having a specific newer version available for an installed package (which is exactly what check-update reports) does not mean a later dnf upgrade will actually install it. The difference is that dnf upgrade has restrictions to take into account โ€” like package dependencies being satisfied. So don't come for upgrade when check-update promised you the world. ๐Ÿ’…

The output is affected by the autocheck_running_kernel configuration option.


๐Ÿงผ Clean Command ๐Ÿงผ

Command: clean

Performs cleanup of temporary files kept for repositories. And yes, that includes any such data left behind from disabled or removed repositories, plus data from different distribution release versions. We're cleaning out the whole group chat. ๐Ÿงนโœจ

  • dnf clean dbcache โ€” Removes cache files generated from the repository metadata. This forces DNF to regenerate the cache files the next time it is run. Glow-up by deletion. ๐ŸŽ€
  • dnf clean expire-cache โ€” Marks the repository metadata expired. DNF will re-validate the cache for each repository the next time it is used.
  • dnf clean metadata โ€” Removes repository metadata. Those are the files which DNF uses to determine the remote availability of packages. Using this option will make DNF download all the metadata the next time it is run. Full reset, main character energy. ๐Ÿ‘‘
  • dnf clean packages โ€” Removes any cached packages from the system.
  • dnf clean all โ€” Does all of the above. The "yes, everything, I'm done" button.

๐Ÿ“œ Deplist Command ๐Ÿ“œ

dnf [options] deplist [<select-options>] [<query-options>] [<package-spec>]

Deprecated alias for dnf repoquery --deplist. It's giving legacy. Go use the real one, bestie. ๐Ÿ™ˆ


๐Ÿ”„ Distro-Sync Command ๐Ÿ”„

Command: distro-sync Aliases: dsync Deprecated aliases: distrosync, distribution-synchronization

dnf distro-sync [<package-spec>...]

As necessary, upgrades, downgrades or keeps selected installed packages to match the latest version available from any enabled repository. Name no package and all installed packages get considered. It's the "everyone gets to the same version, no drama" command. ๐ŸŒˆ

See also Configuration Files Replacement Policy.


โฌ‡๏ธ Downgrade Command โฌ‡๏ธ

Command: downgrade Aliases: dg

dnf [options] downgrade <package-spec>...

Downgrades the packages you name to the highest installable package of all known lower versions, if possible. And when you give a version that's lower than the version of the installed package, then it downgrades to that target version. Yes bestie, sometimes we go back. It's called growth. ๐Ÿ’€


๐Ÿซ‚ Group Command ๐Ÿซ‚

Command: group Aliases: grp Deprecated aliases: groups, grouplist, groupinstall, groupupdate, groupremove, grouperase, groupinfo

Groups are virtual collections of packages โ€” like a friend group but for RPMs. ๐ŸŽ€ DNF keeps track of the groups the user selected ("marked") installed, and can manipulate all the packages inside them with simple commands. No micromanaging every single package by hand.

๐Ÿ“‹ dnf [options] group [summary] <group-spec>

Display an overview of how many groups are installed and available. Give it a spec and it limits the output to the matching groups. And fun fact: summary is the default groups subcommand, so it's the one that shows up if you don't pick one. Lowkey the chillest of the bunch.

๐Ÿ” dnf [options] group info <group-spec>

Display package lists of a group. Shows which packages are installed or available from a repository when -v is used.

๐Ÿ“ฆ dnf [options] group install [--with-optional] <group-spec>...

Marks the specified group installed and installs the packages it contains. Also includes optional packages of the group if --with-optional is specified. All Mandatory and Default packages will be installed whenever possible. Conditional packages are installed if they meet their requirement. If the group is already (partially) installed, the command installs the missing packages from the group. Depending on the value of the obsoletes configuration option, group installation takes obsoletes into account.

๐Ÿ“ dnf [options] group list <group-spec>...

List all matching groups, either among installed or available groups. Specify nothing and it lists all known groups. The --installed and --available options narrow down the requested list. Records are ordered by the display_order tag defined in the comps.xml file. It provides a list of all hidden groups by using the option --hidden. And it provides group IDs when the -v or --ids options are used. So many options, so much power. ๐Ÿ’…

๐Ÿ—‘๏ธ dnf [options] group remove <group-spec>...

Marks the group removed and removes those packages in the group from the system which do not belong to another installed group and were not installed explicitly by the user. Very "I didn't pick you, so you're safe" of it. ๐Ÿซถ

โฌ†๏ธ dnf [options] group upgrade <group-spec>...

Upgrades the packages from the group and upgrades the group itself. That second part means installing packages that were added to the group by the distribution, and removing packages that got removed from the group โ€” as far as they were not installed explicitly by the user. The group gets the full makeover. โœจ


Groups can also be marked installed or removed without physically manipulating any packages. Pure label energy, no installs, no removals:

๐Ÿท๏ธ dnf [options] group mark install <group-spec>...

Mark the specified group installed. No packages will be installed by this command, but the group is then considered installed. It's all in the paperwork, bestie. ๐ŸŽ€

๐Ÿท๏ธ dnf [options] group mark remove <group-spec>...

Mark the specified group removed. No packages will be removed by this command.


See also Configuration Files Replacement Policy.


๐Ÿ†˜ Help Command ๐Ÿ†˜

Command: help

dnf help [<command>]

Displays the help text for all commands. Give it a command name and it only displays help for that particular command. When the man page is giving you the cold shoulder. ๐Ÿ˜ญ


๐Ÿ•ฐ๏ธ History Command ๐Ÿ•ฐ๏ธ

Command: history Aliases: hist

The history command lets you view what has happened in past transactions and act according to this information (assuming the history_record configuration option is set). It's your DNF year-in-review, on demand. ๐Ÿฆ‹

dnf history [list] [--reverse] [<spec>...]

The default history action is listing information about given transactions in a table. Each <spec> can be either a <transaction-spec>, which specifies a transaction directly, or a <transaction-spec>..<transaction-spec>, which specifies a range of transactions, or a <package-name-spec>, which specifies a transaction by a package which it manipulated. When no transaction is specified, it lists all known transactions.

Note that transient transactions (see --transient) will be listed even though they do not make persistent changes to files under /usr or to the RPM database. Sneaky but logged. ๐Ÿ‘€

The "Action(s)" column lists each type of action taken in the transaction. The possible values are:

  • Install (I): a new package was installed on the system
  • Downgrade (D): an older version of a package replaced the previously-installed version
  • Obsolete (O): an obsolete package was replaced by a new package
  • Upgrade (U): a newer version of the package replaced the previously-installed version
  • Remove (E): a package was removed from the system
  • Reinstall (R): a package was reinstalled with the same version
  • Reason change (C): a package was kept in the system but its reason for being installed changed

The "Altered" column lists the number of actions taken in each transaction, possibly followed by one or two of the following symbols:

  • >: The RPM database was changed, outside DNF, after the transaction
  • <: The RPM database was changed, outside DNF, before the transaction
  • *: The transaction aborted before completion
  • #: The transaction completed, but with a non-zero status
  • E: The transaction completed successfully, but had warning/error output
  • --reverse โ€” The order of history list output is printed in reverse order.

dnf history info [<spec>...]

Describe the given transactions. The meaning of <spec> is the same as in the History List Command. When no transaction is specified, it describes what happened during the latest transaction. Just the most recent drama, summarised. ๐Ÿ’…

dnf history redo <transaction-spec>|<package-file-spec>

Repeat the specified transaction. It uses the last transaction (with the highest ID) if more than one transaction for the given <package-file-spec> is found. If it is not possible to redo some operations due to the current state of RPMDB, it will not redo the transaction. So close to a do-over, but the universe said no. ๐Ÿ™ˆ

dnf history replay [--ignore-installed] [--ignore-extras] [--skip-unavailable] <filename>

Replay a transaction stored in the file <filename> by the History Store Command. The replay will perform the exact same operations on the packages as in the original transaction, and will return with an error in case of any differences in installed packages or their versions. See also the Transaction JSON Format specification of the file format.

  • --ignore-installed โ€” Don't check for the installed packages being in the same state as those recorded in the transaction. E.g. in case there is an upgrade foo-1.0 -> foo-2.0 stored in the transaction, but there is foo-1.1 installed on the target system.
  • --ignore-extras โ€” okay so this one tells DNF to not go poking around for extra packages that got pulled into the transaction on the target system. Like, the target system might legitimately not have some dependency that was installed on the source system. And by default the replay just ๐Ÿ’€ errors out when that happens, because the transaction wouldn't be the same. So this flag is the "chill, it's fine" button.
  • --skip-unavailable โ€” if some packages stored in the transaction simply aren't available on the target system, skip them instead of erroring out. Bestie said "don't make it a whole thing." ๐Ÿซถ

๐ŸŒˆ History Rollback (yes it's still the history command, we're living here now) ๐ŸŒˆ

  • dnf history rollback <transaction-spec>|<package-file-spec> โ€” undoes every single transaction performed after the one you point at. If more than one transaction matches a given <package-file-spec>, it goes with the last one (the one with the highest ID). And important: if it's not possible to undo some transactions because of the current state of RPMDB, then it won't undo any transaction. All or nothing, no crumbs left behind. ๐Ÿ˜ญ
  • dnf history store [--output <output-file>] <transaction-spec> โ€” stores a transaction specified by <transaction-spec>. That transaction can later be replayed by the History Replay Command. Cute, right?
Warning: the stored transaction format is considered unstable and may change at any time ๐Ÿ‘€. It will work if the same version of dnf is used to store and replay (or between versions as long as it stays the same).
  • -o <output-file>, --output=<output-file> โ€” store the serialized transaction into <output-file. Default is transaction.json.
  • dnf history undo <transaction-spec>|<package-file-spec> โ€” performs the opposite operation to all operations performed in the specified transaction. If more than one transaction matches a given <package-file-spec>, it uses the last transaction (the highest ID). And same energy as rollback: if it can't undo some operations because of the current state of RPMDB, it will not undo the transaction. โœจ
  • dnf history userinstalled โ€” shows all packages installed by user, installed from a group or a module profile, and packages installed outside of DNF. I.e. it lists the packages that will stay on the system when the Autoremove Command or Remove Command is executed along with the clean_requirements_on_remove configuration option set to True. Lowkey note: the same results can be accomplished with dnf repoquery --userinstalled, and honestly the repoquery command is more powerful when it comes to formatting the output. ๐Ÿ“
This command by default does not force a sync of expired metadata, except for the redo, rollback, and undo subcommands. See also Metadata Synchronization and Configuration Files Replacement Policy.

๐Ÿฆ‹ Info Command ๐Ÿฆ‹

Command: info Aliases: if

  • dnf [options] info [<package-file-spec>...] โ€” lists description and summary information about installed and available packages. It's giving "tell me everything, bestie." ๐Ÿ’–

The info command limits the displayed packages the same way as the list command does. (They're matching, your honor.)

This command by default does not force a sync of expired metadata. See also Metadata Synchronization.

๐Ÿ‘‘ Install Command ๐Ÿ‘‘

Command: install Aliases: in Aliases for explicit NEVRA matching: install-n, install-na, install-nevra Deprecated aliases: localinstall

  • dnf [options] install <spec>... โ€” makes sure that the given packages and their dependencies are installed on the system. Each <spec> can be either a <package-spec>, or a @<module-spec>, or a @<group-spec>. See Install Examples below, they're iconic. If a given package or provide cannot be (and is not already) installed, the exit code will be non-zero. And if the <spec> matches both a @<module-spec> and a @<group-spec>, only the module is installed.

When a <package-spec> that specifies the exact version of the package is given, DNF will install the desired version, no matter which version of the package is already installed. The former version of the package will be removed in the case of a non-installonly package.

On the other hand, if <package-spec> specifies only a name, DNF also takes into account packages obsoleting it when picking which package to install. This behaviour is specific to the install command. Note that this can lead to seemingly unexpected results if a package has multiple versions and some older version is being obsoleted. It creates a split in the upgrade-path and both ways are considered correct โ€” the resulting package is picked simply by lexicographical order. ๐Ÿค“

There are also a few specific install commands โ€” install-n, install-na and install-nevra โ€” that allow the specification of an exact argument in the NEVRA format. As a consequence, <spec> will not be matched with provides and file provides.

See also Configuration Files Replacement Policy.


๐Ÿ’… Install Examples ๐Ÿ’…

  • dnf install tito โ€” installs the tito package (tito is the package name).
  • dnf install ~/Downloads/tito-0.6.2-1.fc22.noarch.rpm โ€” installs a local rpm file tito-0.6.2-1.fc22.noarch.rpm from the ~/Downloads/ directory. Local girl behavior. ๐ŸŽ€
  • dnf install tito-0.5.6-1.fc22 โ€” installs the package with a specific version. If the package is already installed, it will automatically try to downgrade or upgrade to that specific version.
  • dnf --best install tito โ€” installs the latest available version of the package. If the package is already installed, it will try to automatically upgrade to the latest version. And if the latest version of the package cannot be installed, the installation will fail. No compromises. ๐Ÿ’€
  • dnf install vim โ€” DNF will automatically recognize that vim is not a package name, but will look up and install a package that provides vim, with all the required dependencies. Note: package name match has precedence over package provides match.
  • dnf install https://kojipkgs.fedoraproject.org//packages/tito/0.6.0/1.fc22/noarch/tito-0.6.0-1.fc22.noarch.rpm โ€” installs a package directly from a URL. Slay, straight from the source. ๐Ÿ”ฅ
  • dnf install '@docker' โ€” installs all default profiles of module 'docker' and their RPMs. Module streams get enabled accordingly.
  • dnf install '@Web Server' โ€” installs the 'Web Server' environmental group.
  • dnf install /usr/bin/rpmsign โ€” installs a package that provides the /usr/bin/rpmsign file.
  • dnf -y install tito --setopt=install_weak_deps=False โ€” installs the tito package (tito is the package name) without weak deps. Weak deps are not required for core functionality of the package, but they enhance the original package (like extended documentation, plugins, additional functions, etc.).
  • dnf install --advisory=FEDORA-2018-b7b99fe852 \* โ€” installs all packages that belong to the "FEDORA-2018-b7b99fe852" advisory.

๐Ÿ“ List Command ๐Ÿ“

Command: list Aliases: ls

Prints lists of packages depending on the packages' relation to the system. A package is installed if it is present in the RPMDB, and it is available if it is not installed but is present in a repository that DNF knows about. Simple as that. โœจ

The list command also limits the displayed packages according to specific criteria, e.g. to only those that update an installed package (respecting the repository priority #repo-priority-label). The exclude #exclude-label option in the configuration file can influence the result, but if the --disableexcludes command line option is used, it ensures that all installed packages will be listed. Periodt.

  • dnf [options] list [--all] [<package-file-spec>...] โ€” lists all packages, present in the RPMDB, in a repository, or both.
  • dnf [options] list --installed [<package-file-spec>...] โ€” lists installed packages.
  • dnf [options] list --available [<package-file-spec>...] โ€” lists available packages.
  • dnf [options] list --extras [<package-file-spec>...] โ€” lists extras, that is packages installed on the system that are not available in any known repository. (They're not like other packages. ๐Ÿ’…)
  • dnf [options] list --obsoletes [<package-file-spec>...] โ€” lists packages installed on the system that are obsoleted by packages in any known repository.
  • dnf [options] list --recent [<package-file-spec>...] โ€” lists packages recently added into the repositories.
  • dnf [options] list --upgrades [<package-file-spec>...] โ€” lists upgrades available for the installed packages.
  • dnf [options] list --autoremove โ€” lists packages which will be removed by the dnf autoremove command.
This command by default does not force a sync of expired metadata. See also Metadata Synchronization.

๐ŸŒธ Makecache Command ๐ŸŒธ

Command: makecache Aliases: mc

  • dnf [options] makecache โ€” downloads and caches metadata for enabled repositories. It tries to avoid downloading whenever possible (e.g. when the local metadata hasn't expired yet or when the metadata timestamp hasn't changed). Efficient queen. ๐Ÿ‘‘
  • dnf [options] makecache --timer โ€” like plain makecache, but instructs DNF to be more resource-aware, meaning it will not do anything if running on battery power ๐Ÿ”‹, it will terminate immediately if it's too soon after the last successful makecache run (see dnf.conf(5), metadata_timer_sync #metadata-timer-sync-label), and if the first mirror in a repository mirrorlist fails, it will not try to synchronize the metadata from more mirrors for that repository.

๐Ÿงš Mark Command ๐Ÿงš

Command: mark

  • dnf mark install <package-spec>... โ€” marks the specified packages as installed by user. This can be useful if any package was installed as a dependency and is desired to stay on the system when the Autoremove Command or Remove Command is executed along with the clean_requirements_on_remove configuration option set to True. Protect her at all costs. ๐Ÿ›ก๏ธ
  • dnf mark remove <package-spec>... โ€” unmarks the specified packages as installed by user. Whenever you as a user don't need a specific package, you can mark it for removal. The package stays installed on the system but will be removed when the Autoremove Command or Remove Command is executed along with the clean_requirements_on_remove configuration option set to True. You should use this operation instead of the Remove Command if you're not sure whether the package is a requirement of other user-installed packages on the system. It's the cautious route, and we love her for it. ๐Ÿ™ˆ
  • dnf mark group <package-spec>... โ€” marks the specified packages as installed by group. This can be useful if any package was installed as a dependency or by a user and is desired to be protected and handled as a group member, like during group remove.

๐Ÿ’œ Module Command ๐Ÿ’œ

Command: module

โš ๏ธ Warning: Modularity is deprecated, and functionality will be removed in a future release of DNF5. Not me delivering bad news first thing ๐Ÿ˜ญ

The full modularity overview lives over in the man page dnf.modularity(7), bestie โ€” go read that if you want the whole lore. Module subcommands take <module-spec>... arguments that specify modules or profiles. ๐Ÿ’…


dnf [options] module install <module-spec>...

Installs module profiles, including their packages. If you don't hand it a profile, all the default profiles get installed, no questions asked. Module streams get enabled accordingly. โœจ

Heads up: this command cannot be used for switching module streams. For that you want the dnf module switch-to command. Periodt.

dnf [options] module update <module-spec>...

Updates the packages tied to an active module stream, optionally narrowed down to a profile. If the profile_name is provided, only the packages referenced by that profile get updated. ๐ŸŽ€

dnf [options] module switch-to <module-spec>...

The main character of module commands, honestly. It switches to or enables a module stream, changes the versions of installed packages to the versions provided by the new stream, and removes packages from the old stream that are no longer available. It also updates installed profiles if they're available for the new stream. And if a profile was provided, it installs that profile and does not update any already-installed profiles. ๐Ÿ‘‘

Think of it as a stronger version of the dnf module enable command โ€” it doesn't just enable modules, it also does a distrosync to all modular packages in the enabled modules. ๐Ÿ”ฅ

It can also be a stronger version of the dnf module install command, but plot twist: you must specify the profiles you want installed, because switch-to does not use default profiles. And it's not just profile-installing either โ€” it also makes a distrosync to all modular packages in the installed module. It's giving overachiever. ๐ŸŒˆ

dnf [options] module remove <module-spec>...

Removes installed module profiles, including the packages that came in via the dnf module install command. It will not remove packages required by other installed module profiles, or by other user-installed packages. If no profile was provided, all installed profiles get removed. ๐Ÿงš

dnf [options] module remove --all <module-spec>...

Same deal โ€” removes installed module profiles, including packages installed with the dnf module install command. But with the --all option it additionally removes all packages whose names are provided by the specified modules. What it won't touch: packages required by other installed module profiles, and packages whose names are also provided by any other module. Not on its watch. ๐Ÿ™ˆ

dnf [options] module enable <module-spec>...

Enables a module stream and makes the stream RPMs available in the package set. ๐Ÿ’–

Modular dependencies get resolved, dependencies get checked, and everything gets recursively enabled. If there's a modular dependency issue, the operation gets rejected. Want to force it anyway? Use the --skip-broken option, iykyk.

Again: this command cannot be used for switching module streams. Use dnf module switch-to for that.

dnf [options] module disable <module-name>...

Disables a module. All related module streams become unavailable. Consequently, all installed profiles get removed and the module RPMs become unavailable in the package set. If there's a modular dependency issue, the operation gets rejected โ€” to do it anyway, use the --skip-broken option. ๐Ÿ’€

dnf [options] module reset <module-name>...

Resets the module state so it's no longer enabled or disabled. Consequently, all installed profiles get removed, and only RPMs from the default stream will be available in the package set. Fresh start energy. ๐Ÿฆ‹

dnf [options] module provides <package-name-spec>...

Lists all modular packages matching <package-name-spec> from all modules (yes, even the disabled ones ๐Ÿ‘€), along with the modules and streams they belong to.

dnf [options] module list [--all] [module_name...]

Lists all module streams, their profiles, and their states (enabled, disabled, default).

dnf [options] module list --enabled [module_name...]

Lists module streams that are enabled. โœจ

dnf [options] module list --disabled [module_name...]

Lists module streams that are disabled. ๐Ÿ˜ด

dnf [options] module list --installed [module_name...]

Lists module streams that have installed profiles.

dnf [options] module info <module-spec>...

Prints detailed information about the given module stream. ๐ŸŽ€

dnf [options] module info --profile <module-spec>...

Prints detailed information about the given module profiles.

dnf [options] module repoquery <module-spec>...

Lists all available packages belonging to the selected modules.

dnf [options] module repoquery --available <module-spec>...

Lists all available packages belonging to the selected modules.

dnf [options] module repoquery --installed <module-spec>...

Lists all installed packages with the same name as packages belonging to the selected modules.


โœจ Provides Command โœจ

Command: provides Aliases: prov, whatprovides, wp

dnf [options] provides <provide-spec>

Finds the packages providing the given <provide-spec>. This is the iconic move when you know a filename but you're like "okay but WHICH package gives me this file??" โ€” installed or not, it'll find it. ๐Ÿ’…

The <provide-spec> is gradually looked for at the following locations:

  1. The <provide-spec> is matched with all file provides of any available package:
$ dnf provides /usr/bin/gzip
gzip-1.9-9.fc29.x86_64 : The GNU data compression program
Matched from:
Filename    : /usr/bin/gzip
  1. Then all provides of all available packages are searched:
$ dnf provides "gzip(x86-64)"
gzip-1.9-9.fc29.x86_64 : The GNU data compression program
Matched from:
Provide     : gzip(x86-64) = 1.9-9.fc29
  1. DNF assumes the <provide-spec> is a system command, prepends it with /usr/bin/, /usr/sbin/ prefixes (one at a time) and does the file provides search again. And for legacy reasons (packages that didn't do UsrMove), the /bin and /sbin prefixes are being searched too:
$ dnf provides zless
gzip-1.9-9.fc29.x86_64 : The GNU data compression program
Matched from:
Filename    : /usr/bin/zless
  1. If this last step also fails, DNF returns "Error: No Matches found". ๐Ÿ˜ญ

This command by default does not force a sync of expired metadata. See also Metadata Synchronization.


โœจ Reinstall Command โœจ

Command: reinstall Aliases: rei

dnf [options] reinstall <package-spec>...

Installs the specified packages, and it fails if some of the packages are either not installed or not available (i.e. there's no repository where to download the same RPM). It's giving "all or nothing" energy. ๐Ÿ’€


โœจ Remove Command โœจ

Command: remove Aliases: rm Aliases for explicit NEVRA matching: remove-n, remove-na, remove-nevra Deprecated aliases: erase, erase-n, erase-na, erase-nevra

dnf [options] remove <package-spec>...

Removes the specified packages from the system, along with any packages depending on the packages being removed. Each <spec> can be either a <package-spec>, which specifies a package directly, or a @<group-spec>, which specifies an (environment) group that contains it. If clean_requirements_on_remove is enabled (the default ๐ŸŒธ), it also removes any dependencies that are no longer needed.

dnf [options] remove --duplicates

Removes older versions of duplicate packages. To ensure the integrity of the system, it reinstalls the newest package. In some cases the command cannot resolve conflicts. In those cases, the dnf shell command with the remove --duplicates and upgrade dnf-shell sub-commands could help. ๐Ÿซถ

dnf [options] remove --oldinstallonly

Removes old installonly packages, keeping only the latest versions and the version of the running kernel. ๐Ÿ‘‘

There are also a few specific remove commands โ€” remove-n, remove-na and remove-nevra โ€” that let you specify an exact argument in the NEVRA format. As a consequence, <spec> will not be matched with provides and file provides.

๐Ÿ’– Remove Examples ๐Ÿ’–

  • dnf remove acpi tito โ€” Remove the acpi and tito packages.
  • dnf remove $(dnf repoquery --extras --exclude=tito,acpi) โ€” Remove packages not present in any repository, but don't remove the tito and acpi packages (they still might get removed if they depend on some of the removed packages). ๐Ÿ˜ฌ
  • dnf remove --duplicates โ€” Remove older versions of duplicated packages (an equivalent of yum's package-cleanup --cleandups).

โœจ Repoinfo Command โœจ

Command: repoinfo

An alias for the repolist command that provides more detailed information, like dnf repolist -v. โœจ


โœจ Repolist Command โœจ

Command: repolist

dnf [options] repolist [--enabled|--disabled|--all]

Depending on the exact command, lists enabled, disabled, or all known repositories. By default it lists all enabled repositories. It provides more detailed information when the -v option is used. ๐ŸŽ€

This command by default does not force a sync of expired metadata. See also Metadata Synchronization.


โœจ Repoquery Command โœจ

Command: repoquery Aliases: rq Aliases for explicit NEVRA matching: repoquery-n, repoquery-na, repoquery-nevra

dnf [options] repoquery [<select-options>] [<query-options>] [<package-file-spec>]

Searches available DNF repositories for selected packages and displays the requested information about them. It's basically the equivalent of rpm -q for remote repositories. ๐Ÿ’…

dnf [options] repoquery --groupmember <package-spec>...

Lists the groups that contain <package-spec>.

dnf [options] repoquery --querytags

Provides the list of tags recognized by the --queryformat repoquery option. ๐Ÿฆ‹

There are also a few specific repoquery commands โ€” repoquery-n, repoquery-na and repoquery-nevra โ€” that allow the specification of an exact argument in the NEVRA format (this does not affect arguments of options like --whatprovides <arg>, ...). As a consequence, <spec> will not be matched with file provides.

Select Options โœจ

ok so these ones team up with <package-file-spec> to decide which packages even show up in your output ๐Ÿ’… If you hand over a <package-file-spec>, it narrows the result set down to just the packages that match it. No spec? Then literally all packages are up for consideration. no cap.

  • <package-file-spec> โ€” the package spec, in NEVRA format: name[-[epoch:]version[-release]][.arch], or a file provide. Peep "Specifying Packages" for the deets ๐Ÿซถ
  • -a, --all โ€” query all the packages (this exists for rpmquery compatibility, and it's also a shorthand for repoquery '*' or for repoquery with no arguments at all) ๐Ÿ’ซ
  • --arch <arch>[,<arch>...], --archlist <arch>[,<arch>...] โ€” limit the result set to packages of the architectures you picked (default is all architectures, because she contains multitudes ๐ŸŒˆ). Fair warning bestie: sometimes the result is affected by the basearch of the running system, so if you wanna run repoquery for an arch that's incompatible with your system, use the --forcearch=<arch> option to change the basearch ๐Ÿ‘‘
  • --duplicates โ€” limit the result set to installed duplicate packages (as in, more package versions for the same name and architecture). Installonly packages are excluded from this set, sorry bestie ๐Ÿ™ˆ
  • --unneeded โ€” limit the result set to leaf packages that were installed as dependencies and so are no longer needed. This switch lists the packages that are going to be removed after you run the dnf autoremove command. it's giving pre-breakup clarity ๐Ÿ’€
  • --available โ€” limit the result set to available packages only (this is set by default โœจ)
  • --disable-modular-filtering โ€” disables filtering of modular packages, so packages from inactive module streams get included in the result ๐Ÿ‘€
  • --extras โ€” limit the result set to packages that aren't present in any of the available repositories ๐Ÿฆ‹
  • -f <file>, --file <file> โ€” limit the result set to only the package that owns <file> ๐Ÿ”
  • --installed โ€” limit the result set to installed packages only ๐ŸŽ€ The exclude <#exclude-label> option in the config file might influence the result, BUT if you use the command line option --disableexcludes, that ensures all installed packages will be listed. periodt.
  • --installonly โ€” limit the result set to installed installonly packages ๐Ÿ“ฆ
  • --latest-limit <number> โ€” limit the result set to <number> of latest packages for every package name and architecture. If <number> is negative, it skips <number> of the latest packages. For a negative <number> you gotta use the --latest-limit=<number> syntax, iykyk ๐Ÿ’…
  • --recent โ€” limit the result set to packages that were recently edited โฐ
  • --repo <repoid> โ€” limit the result set to only packages from the repository identified by <repoid>. You can use this multiple times and the effects stack up accumulatively ๐ŸŒธ
  • --unsatisfied โ€” report unsatisfied dependencies among installed packages (meaning missing requires and existing conflicts) ๐Ÿ˜ญ
  • --upgrades โ€” limit the result set to packages that provide an upgrade for some already installed package โฌ†๏ธ
  • --userinstalled โ€” limit the result set to packages installed by the user ๐Ÿซถ The exclude <#exclude-label> option in the config file might influence the result, but if the command line option --disableexcludes is used, it ensures that all installed packages will be listed. same energy as --installed, iconic.
  • --whatdepends <capability>[,<capability>...] โ€” limit the result set to only packages that require, enhance, recommend, suggest or supplement any of <capabilities> ๐Ÿ•ธ๏ธ
  • --whatconflicts <capability>[,<capability>...] โ€” limit the result set to only packages that conflict with any of <capabilities> โš”๏ธ
  • --whatenhances <capability>[,<capability>...] โ€” limit the result set to only packages that enhance any of <capabilities>. Use --whatdepends if you want to list all the depending packages โœจ
  • --whatobsoletes <capability>[,<capability>...] โ€” limit the result set to only packages that obsolete any of <capabilities> ๐Ÿ’€
  • --whatprovides <capability>[,<capability>...] โ€” limit the result set to only packages that provide any of <capabilities> ๐ŸŽ
  • --whatrecommends <capability>[,<capability>...] โ€” limit the result set to only packages that recommend any of <capabilities>. Use --whatdepends if you want to list all the depending packages ๐Ÿ’–
  • --whatrequires <capability>[,<capability>...] โ€” limit the result set to only packages that require any of <capabilities>. Use --whatdepends if you want to list all the depending packages ๐Ÿ™
  • --whatsuggests <capability>[,<capability>...] โ€” limit the result set to only packages that suggest any of <capabilities>. Use --whatdepends if you want to list all the depending packages ๐Ÿ’ญ
  • --whatsupplements <capability>[,<capability>...] โ€” limit the result set to only packages that supplement any of <capabilities>. Use --whatdepends if you want to list all the depending packages ๐ŸŒŸ
  • --alldeps โ€” this option is stackable with --whatrequires or --whatdepends only. On top of that it adds all packages requiring the package features to the result set (this is used as default) ๐Ÿ”ฅ
  • --exactdeps โ€” this option is stackable with --whatrequires or --whatdepends only. Limit the result set to only packages that require <capability> as specified by --whatrequires ๐ŸŽฏ
  • --srpm โ€” operate on the corresponding source RPM ๐Ÿ“œ

Query Options ๐Ÿ‘‘

These set what info gets displayed about each package. the main character decisions, fr fr.

Heads up bestie: the following are mutually exclusive, i.e. at most ONE can be specified. If no query option is given, matching packages are displayed in the standard NEVRA notation ๐ŸŽ€
  • -i, --info โ€” show detailed info about the package ๐Ÿ“‹
  • -l, --list โ€” show the list of files in the package ๐Ÿ—‚๏ธ
  • -s, --source โ€” show the package source RPM name ๐Ÿงš
  • --changelogs โ€” print the package changelogs ๐Ÿ“
  • --conflicts โ€” display capabilities that the package conflicts with. Same as --qf "%{conflicts}. โš”๏ธ
  • --depends โ€” display capabilities that the package depends on, enhances, recommends, suggests or supplements ๐Ÿ•ธ๏ธ
  • --enhances โ€” display capabilities enhanced by the package. Same as --qf "%{enhances}"" โœจ
  • --location โ€” show a location where the package could be downloaded from ๐Ÿ“
  • --obsoletes โ€” display capabilities that the package obsoletes. Same as --qf "%{obsoletes}" ๐Ÿ’€
  • --provides โ€” display capabilities provided by the package. Same as --qf "%{provides}" ๐ŸŽ
  • --recommends โ€” display capabilities recommended by the package. Same as --qf "%{recommends}" ๐Ÿ’–
  • --requires โ€” display capabilities that the package depends on. Same as --qf "%{requires}" ๐Ÿ™
  • --requires-pre โ€” display capabilities that the package depends on for running a %pre script. Same as --qf "%{requires-pre}" ๐Ÿ› ๏ธ
  • --suggests โ€” display capabilities suggested by the package. Same as --qf "%{suggests}" ๐Ÿ’ญ
  • --supplements โ€” display capabilities supplemented by the package. Same as --qf "%{supplements}" ๐ŸŒŸ
  • --tree โ€” display a recursive tree of packages with capabilities specified by one of these supplementary options: --whatrequires, --requires, --conflicts, --enhances, --suggests, --provides, --supplements, --recommends ๐ŸŒณ
  • --deplist โ€” produce a list of all direct dependencies and what packages provide those dependencies for the given packages. The result only shows the newest providers (which you can change by using --verbose) ๐Ÿ“œ
  • --nvr โ€” show found packages in the name-version-release format. Same as --qf "%{name}-%{version}-%{release}" ๐Ÿท๏ธ
  • --nevra โ€” show found packages in the name-epoch:version-release.architecture format. Same as --qf "%{name}-%{epoch}:%{version}-%{release}.%{arch}" (this is the default btw โœจ)
  • --envra โ€” show found packages in the epoch:name-version-release.architecture format. Same as --qf "%{epoch}:%{name}-%{version}-%{release}.%{arch}" ๐ŸŒˆ
  • --qf <format>, --queryformat <format> โ€” custom display format ๐Ÿ’… <format> is the string to output for each matched package. Every occurrence of %{<tag>} within it gets replaced by the corresponding attribute of the package. You can see the list of recognized tags by running dnf repoquery --querytags ๐Ÿ‘‘
  • --recursive โ€” query packages recursively. Has to be used with --whatrequires <REQ> (optionally with --alldeps, but not with --exactdeps) or with --requires <REQ> --resolve ๐Ÿ”
  • --resolve โ€” resolve capabilities to originating package(s) ๐ŸŽฏ

Repoquery Examples ๐Ÿ“

ok now the fun part, copy-paste these bestie:

  • dnf repoquery 'light*' โ€” Display NEVRAs of all available packages matching light* โœจ
  • dnf repoquery-na 'light*.noarch' โ€” Display NEVRAs of all available packages matching name light* and architecture noarch (accepts only arguments in the "<name>.<arch>" format) ๐Ÿฆ‹
  • dnf repoquery --requires lighttpd โ€” Display requires of all lighttpd packages ๐Ÿ™
  • dnf repoquery --requires python --resolve โ€” Display packages providing the requires of python packages ๐ŸŽฏ
  • dnf repoquery --source lighttpd โ€” Display source rpm of lighttpd package ๐Ÿ“œ
  • dnf repoquery --file /etc/lighttpd/lighttpd.conf โ€” Display package name that owns the given file ๐Ÿ”
  • dnf repoquery --queryformat '%{name}.%{arch} : %{reponame}' lighttpd โ€” Display name, architecture and the containing repository of all lighttpd packages ๐Ÿ’…
  • dnf repoquery --whatprovides webserver โ€” Display all available packages providing "webserver" ๐ŸŽ
  • dnf repoquery --whatprovides webserver --arch i686 โ€” Display all available packages providing "webserver" but only for "i686" architecture ๐Ÿ‘‘
  • dnf repoquery --duplicates โ€” Display duplicate packages ๐Ÿ™ˆ
dnf repoquery --disablerepo="*" --enablerepo="*-source" --arch=src --whatrequires <provide>

โ€” Display source packages that require a <provide> for a build ๐Ÿ› ๏ธ


Repository-Packages Command ๐ŸŽ€

Command: repository-packages Deprecated aliases: repo-pkgs, repo-packages, repository-pkgs

The repository-packages command lets you run commands on top of all the packages in the repository named <repoid> ๐Ÿ‘‘ BUT โ€” and this is the important bit โ€” any dependency resolution takes into account packages from all enabled repositories ๐ŸŒˆ The <package-file-spec> and <package-spec> specifications further limit the candidates to only those packages matching at least one of them. no cap.


okay so, info vs list?? ๐Ÿ’– literally the same energy but different vibes: the info subcommand hands you the description and summary deets about packages, and what you get depends on how those packages relate to the repo. The list subcommand is the low-key version โ€” it just prints lists of those packages. no extra lore. periodt. ๐Ÿ’…


check-update ๐ŸŒธ

dnf [options] repository-packages <repoid> check-update
[<package-file-spec>...]

Non-interactively checks if updates of the specified packages in the repository are available. DNF's exit code will be 100 when there are updates available, and a list of the updates gets printed. no cap, that 100 is the whole personality of this flag.

info ๐ŸŽ€

dnf [options] repository-packages <repoid> info [--all]
[<package-file-spec>...]

List all related packages.

dnf [options] repository-packages <repoid> info --installed
[<package-file-spec>...]

List packages installed from the repository.

dnf [options] repository-packages <repoid> info --available
[<package-file-spec>...]

List packages available in the repository but not currently installed on the system.

dnf [options] repository-packages <repoid> info --extras
[<package-file-specs>...]

List packages installed from the repository that are not available in any repository. (yes bestie, specs with an s โ€” that's how the page says it, we don't touch it ๐Ÿ’€)

dnf [options] repository-packages <repoid> info --obsoletes
[<package-file-spec>...]

List packages in the repository that obsolete packages installed on the system.

dnf [options] repository-packages <repoid> info --recent
[<package-file-spec>...]

List packages recently added into the repository. fresh drops only โœจ

dnf [options] repository-packages <repoid> info --upgrades
[<package-file-spec>...]

List packages in the repository that upgrade packages installed on the system.

install ๐Ÿ›๏ธ

dnf [options] repository-packages <repoid> install [<package-spec>...]

Install packages matching <package-spec> from the repository. And if you don't pass a <package-spec> at all? it installs every single package from the repository. the whole thing. all of it. icon status fr. ๐Ÿ‘‘

list ๐Ÿฆ‹

dnf [options] repository-packages <repoid> list [--all]
[<package-file-spec>...]

List all related packages.

dnf [options] repository-packages <repoid> list --installed
[<package-file-spec>...]

List packages installed from the repository.

dnf [options] repository-packages <repoid> list --available
[<package-file-spec>...]

List packages available in the repository but not currently installed on the system.

dnf [options] repository-packages <repoid> list --extras
[<package-file-spec>...]

List packages installed from the repository that are not available in any repository.

dnf [options] repository-packages <repoid> list --obsoletes
[<package-file-spec>...]

List packages in the repository that obsolete packages installed on the system.

dnf [options] repository-packages <repoid> list --recent
[<package-file-spec>...]

List packages recently added into the repository.

dnf [options] repository-packages <repoid> list --upgrades
[<package-file-spec>...]

List packages in the repository that upgrade packages installed on the system.

move-to ๐Ÿ’ซ

dnf [options] repository-packages <repoid> move-to [<package-spec>...]

Reinstall all those packages that are available in the repository.

reinstall โ™ป๏ธ

dnf [options] repository-packages <repoid> reinstall [<package-spec>...]

Runs the reinstall-old subcommand first. If that fails, it runs the move-to subcommand instead. backup plan behaviour, we love to see it.

reinstall-old ๐Ÿงš

dnf [options] repository-packages <repoid> reinstall-old
[<package-spec>...]

Reinstall all those packages that were installed from the repository and simultaneously are available in the repository. both boxes checked or it's not happening bestie.

remove ๐Ÿ’€

dnf [options] repository-packages <repoid> remove [<package-spec>...]

Remove all packages installed from the repository, along with any packages depending on the packages being removed. And if clean_requirements_on_remove is enabled (which it is by default) it also removes any dependencies that are no longer needed.

remove-or-distro-sync ๐Ÿ˜ญ

dnf [options] repository-packages <repoid> remove-or-distro-sync
[<package-spec>...]

Select all packages installed from the repository. Then: upgrade, downgrade, or keep the ones that are available in another repository so they match the latest version available there โ€” and remove the others along with any packages depending on the packages being removed. If clean_requirements_on_remove is enabled (the default) it also removes any dependencies that are no longer needed.

remove-or-reinstall ๐Ÿ”ฅ

dnf [options] repository-packages <repoid> remove-or-reinstall
[<package-spec>...]

Select all packages installed from the repository. Reinstall the ones that are available in another repository, and remove the others along with any packages depending on the packages being removed. If clean_requirements_on_remove is enabled (the default) it also removes any dependencies that are no longer needed.

upgrade โฌ†๏ธ

dnf [options] repository-packages <repoid> upgrade [<package-spec>...]

Update all packages to the highest resolvable version available in the repository. And when versions are specified in the <package-spec>, update to those versions. specificity is a love language.

upgrade-to ๐Ÿซถ

dnf [options] repository-packages <repoid> upgrade-to
[<package-specs>...]

A deprecated alias for the upgrade subcommand. (yes, specs, plural again โ€” verbatim, bestie ๐Ÿ’œ)


Search Command ๐Ÿ”โœจ

Command: search Aliases: se

dnf [options] search [--all] <keywords>...

Searches package metadata for keywords. The keywords are matched as case-insensitive substrings, and globbing is supported. By default it lists packages that match all of the requested keys (that's an AND operation), and the keys get searched in package names and summaries.

If you use the --all option, it lists packages that match at least one of the keys (an OR operation) โ€” and on top of that, the keys get searched in the package descriptions and URLs too. The result comes sorted from the most relevant to the least. relevance-ordered, the algorithm said slay.

This command by default does not force a sync of expired metadata. See also Metadata Synchronization.


Shell Command ๐Ÿš๐Ÿ’ป

Command: shell Aliases: sh

dnf [options] shell [filename]

Opens an interactive shell so you can run multiple commands during a single execution of DNF. Those commands can be typed in manually or passed to DNF from a file. The commands are much the same as the normal DNF command line options โ€” plus a few extra ones, documented right here bestie:

  • config [conf-option] [value]
    • Set a configuration option to a requested value. If no value is given, it prints the current value.
  • repo [list|enable|disable] [repo-id]
    • list: list repositories and their status
    • enable: enable repository
    • disable: disable repository
  • transaction [list|reset|solve|run]
    • list: resolve and list the content of the transaction
    • reset: reset the transaction
    • run: resolve and run the transaction
Important bestie, do NOT skip this: all local packages must be used in the first shell transaction subcommand (like install /tmp/nodejs-1-1.x86_64.rpm /tmp/acpi-1-1.noarch.rpm) โ€” otherwise an error will occur. And any disable, enable, and reset module operations (like module enable nodejs) must also be performed before any other shell transaction subcommand is used. order matters, no exceptions. ๐Ÿ™ˆ

Swap Command ๐Ÿ”„๐ŸŒธ

Command: swap

dnf [options] swap <remove-spec> <install-spec>

Remove remove-spec and install install-spec in one single transaction. Each <spec> can be either a <package-spec>, which specifies a package directly, or a @<group-spec>, which specifies an (environment) group that contains it.

Automatic conflict solving is provided in DNF by the --allowerasing option, which gives you the functionality of the swap command automatically. convenient king behaviour.


Updateinfo Command ๐Ÿ“œ๐Ÿ’–

Command: updateinfo Aliases: upif Deprecated aliases: list-updateinfo, list-security, list-sec, info-updateinfo, info-security, info-sec, summary-updateinfo

dnf [options] updateinfo [--summary|--list|--info] [<availability>]
[<spec>...]

Displays information about update advisories. ๐ŸŽ€

Depending on the output type, DNF shows you either just counts of advisory types (omitted or --summary), a list of advisories (--list), or detailed information (--info). The -v option extends the output โ€” when it's used with --info, the info gets even more detailed; when it's used with --list, an additional column with the date of the last advisory update is added.

<availability> decides which advisories get taken into account: advisories about newer versions of installed packages (omitted or --available), advisories about equal and older versions of installed packages (--installed), advisories about newer versions of those installed packages for which a newer version is available (--updates), or advisories about any versions of installed packages (--all). Most of the time --available and --updates display the same output. The outputs differ only in the cases when an advisory refers to a newer version but there is no enabled repository containing any newer version. subtle difference, still a real one.

Note that --available takes only the latest installed versions of packages into account. In the case of the kernel packages (when multiple versions could be installed simultaneously) also packages of the currently running version of kernel are added. kernel stays special, always.

To print only advisories referencing a CVE or a bugzilla, use --with-cve or --with-bz. When these switches are used, the output of --list is altered too โ€” the ID of the CVE or the bugzilla is printed instead of the one of the advisory.

If given, and if neither ID, type (bugfix, enhancement, security/sec) nor a package name of an advisory matches <spec>, the advisory is not taken into account. The matching is case-sensitive, and for advisory IDs and package names, globbing is supported.

Output of the --summary option is affected by the autocheck_running_kernel configuration option. ๐Ÿซถ

Upgrade Command โฌ†๏ธ๐Ÿ‘‘

Command: upgrade Aliases: up Deprecated aliases: update, upgrade-to, update-to, localupdate

dnf [options] upgrade

Updates each package to the latest version that is both available and resolvable. both, bestie, not just one.

dnf [options] upgrade <package-spec>...

Updates each specified package to the latest available version, and updates dependencies as necessary. When versions are specified in the <package-spec>, update to those versions. ๐Ÿ’…

dnf [options] upgrade @<spec>...

Alias for the dnf module update command. That's it, that's the whole vibe ๐Ÿ’…

If the main obsoletes configure option is true, or the --obsoletes flag is hanging around, dnf will lowkey fold package obsoletes into its calculations. More deets over at obsoletes. ๐Ÿ‘€

Also peep the Configuration Files Replacement Policy section, linked right down below. iykyk.


๐ŸŒธ Upgrade-Minimal Command ๐ŸŒธ

Command: upgrade-minimal

Aliases: up-min

Deprecated aliases: update-minimal (old, don't be that girl)

dnf [options] upgrade-minimal

Updates each package to the nearest available version that provides a bugfix, enhancement or a fix for a security issue (security). bestie it is NOT gonna jump you to the newest shiny thing, it's the closest one that actually does something for you ๐Ÿซถ

dnf [options] upgrade-minimal <package-spec>...

Updates each specified package to the nearest available version that provides a bugfix, enhancement or a fix for security issue (security). Updates dependencies as necessary. periodt. โœจ


๐ŸŒˆ SPECIFYING PACKAGES ๐ŸŒˆ

So many commands take a <package-spec> parameter that picks out a package for the operation. The <package-spec> argument gets matched against package NEVRAs, provides and file provides. all three, she's versatile ๐Ÿ’…

  • <package-file-spec> is basically <package-spec>'s cousin โ€” same energy โ€” except provides matching is not performed. So <package-file-spec> is matched only against NEVRAs and file provides.
  • <package-name-spec> is matched against NEVRAs only. that's it, that's her whole personality ๐ŸŽ€

๐Ÿฆ‹ Globs ๐Ÿฆ‹

Package specification supports the same glob pattern matching that shell does, in all three of the above mentioned things it matches against (NEVRAs, provides and file provides). slay.

The following patterns are supported:

  • * โ€” Matches any number of characters.
  • ? โ€” Matches any single character.
  • [] โ€” Matches any one of the enclosed characters. A pair of characters separated by a hyphen denotes a range expression; any character that falls between those two characters, inclusive, is matched. If the first character following the [ is a ! or a ^ then any character not enclosed is matched. it's giving "not like other girls" energy ๐Ÿ’€
Note: Curly brackets ({}) are not supported. You can still use them in shells that support them and let the shell do the expansion, but if quoted or escaped, dnf will not expand them. sorry babes ๐Ÿ™ˆ

๐Ÿ‘‘ NEVRA Matching ๐Ÿ‘‘

When matching against NEVRAs, partial matching is supported. DNF tries to match the spec against this list of NEVRA forms, in decreasing order of priority:

  • name-[epoch:]version-release.arch
  • name.arch
  • name
  • name-[epoch:]version-release
  • name-[epoch:]version

Note that name can in general contain dashes (e.g. package-with-dashes). yes she can have layers ๐Ÿ’…

The first form that matches any packages is used and the remaining forms are not tried. If none of the forms match any packages, an attempt is made to match the <package-spec> against full package NEVRAs. This is only relevant if globs are present in the <package-spec>.

<package-spec> matches NEVRAs the same way <package-name-spec> does, but in case matching NEVRAs fails, it attempts to match against provides and file provides of packages as well. she tries again, she's resilient โœจ

You can specify globs as part of any of the five NEVRA components. You can also specify a glob pattern to match over multiple NEVRA components (in other words, to match across the NEVRA separators). In that case, however, you need to write the spec to match against full package NEVRAs, as it is not possible to split such spec into NEVRA forms. no cap. ๐Ÿงš

๐Ÿ’œ Specifying NEVRA Matching Explicitly ๐Ÿ’œ

Some commands (autoremove, install, remove and repoquery) also have aliases with suffixes -n, -na and -nevra that let you explicitly say how to parse the arguments:

  • Command install-n only matches against name.
  • Command install-na only matches against name.arch.
  • Command install-nevra only matches against name-[epoch:]version-release.arch.

pick your fighter ๐ŸŽ€


๐Ÿซถ SPECIFYING PROVIDES ๐Ÿซถ

<provide-spec> in command descriptions means the command operates on packages providing the given spec. This can either be an explicit provide, an implicit provide (i.e. name of the package) or a file provide. The selection is case-sensitive and globbing is supported. okurrr ๐Ÿ’…

๐ŸŒธ Specifying File Provides ๐ŸŒธ

If a spec starts with either / or */, it is considered as a potential file provide. that leading slash is the whole giveaway bestie ๐ŸŒˆ


๐Ÿ’– SPECIFYING GROUPS ๐Ÿ’–

<group-spec> allows one to select (environment) groups a particular operation should work on. It is a case insensitive string (supporting globbing characters) that is matched against a group's ID, canonical name and name translated into the current LC_MESSAGES locale (if possible). so she speaks your language, literally ๐ŸŒธ


โœจ SPECIFYING MODULES โœจ

<module-spec> allows one to select modules or profiles a particular operation should work on. main character energy fr fr ๐Ÿ‘‘

It is in the form of NAME:STREAM:VERSION:CONTEXT:ARCH/PROFILE and the supported partial forms are the following:

  • NAME
  • NAME:STREAM
  • NAME:STREAM:VERSION
  • NAME:STREAM:VERSION:CONTEXT
  • all above combinations with ::ARCH (e.g. NAME::ARCH)
  • NAME:STREAM:VERSION:CONTEXT:ARCH
  • all above combinations with /PROFILE (e.g. NAME/PROFILE)

In case stream is not specified, the enabled or the default stream is used, in that order. In case profile is not specified, the system default profile or the 'default' profile is used. she has backup plans for her backup plans ๐Ÿ’…


๐ŸŽ€ SPECIFYING TRANSACTIONS ๐ŸŽ€

<transaction-spec> can be in one of several forms. If it is an integer, it specifies a transaction ID. Specifying last is the same as specifying the ID of the most recent transaction. The last form is last-<offset>, where <offset> is a positive integer. It specifies the offset-th transaction preceding the most recent transaction. time travel but make it package management โญ


๐ŸŒˆ PACKAGE FILTERING ๐ŸŒˆ

Package filtering filters packages out from the available package set, making them invisible to most of dnf commands. They cannot be used in a transaction. bye girl, you're not invited ๐Ÿ™ˆ

Packages can be filtered out by either Exclude Filtering or Modular Filtering.

๐Ÿฆ‹ Exclude Filtering ๐Ÿฆ‹

Exclude Filtering is a mechanism used by a user or by a DNF plugin to modify the set of available packages. Exclude Filtering can be modified by either includepkgs or excludepkgs configuration options in configuration files. The --disableexcludes command line option can be used to override excludes from configuration files. In addition to user-configured excludes, plugins can also extend the set of excluded packages. To disable excludes from a DNF plugin you can use the --disableplugin command line option. the plugins are being messy and you can tell them no ๐Ÿ’…

To disable all excludes for e.g. the install command you can use the following combination of command line options:

dnf --disableexcludes=all --disableplugin="*" install bash

that's the nuclear option bestie, use it wisely ๐Ÿ”ฅ

๐Ÿงš Modular Filtering ๐Ÿงš

Please see the modularity documentation for details on how Modular Filtering works. (homework, but make it optional reading ๐Ÿซถ)

With modularity, only RPM packages from active module streams are included in the available package set. RPM packages from inactive module streams, as well as non-modular packages with the same name or provides as a package from an active module stream, are filtered out. Modular filtering is not applied to packages added from the command line, installed packages, or packages from repositories with module_hotfixes=true in their .repo file. those ones get a hall pass โœจ

Disabling of modular filtering is not recommended, because it could cause the system to get into a broken state. To disable modular filtering for a particular repository, specify module_hotfixes=true in the .repo file or use --setopt=<repo_id>.module_hotfixes=true.

To discover the module which contains an excluded package use dnf module provides.


๐Ÿ’œ METADATA SYNCHRONIZATION ๐Ÿ’œ

Correct operation of DNF depends on having access to up-to-date data from all enabled repositories, but contacting remote mirrors on every single operation considerably slows it down and costs bandwidth for both the client and the repository provider ๐Ÿ˜ญ the way that metadata is expensive...

The metadata_expire (see dnf.conf(5)) repository configuration option is used by DNF to determine whether a particular local copy of repository data is due to be re-synced. It is crucial that the repository providers set the option well, namely to a value where it is guaranteed that if particular metadata was available in time T on the server, then all packages it references will still be available for download from the server in time T + metadata_expire. no cap, this one actually matters ๐Ÿ’€

To further reduce the bandwidth load, some of the commands where having up-to-date metadata is not critical (e.g. the list command) do not look at whether a repository is expired and whenever any version of it is locally available to the user's account, it will be used. For non-root use, see also the --cacheonly switch. Note that in all situations the user can force synchronization of all enabled repositories with the --refresh switch. so if you NEED fresh metadata, just say the word bestie ๐Ÿ’…


๐ŸŒธ CONFIGURATION FILES REPLACEMENT POLICY ๐ŸŒธ

The updated packages could replace the old modified configuration files with the new ones, or keep the older files. Neither of the files are actually replaced. To the conflicting ones RPM gives an additional suffix to the origin name. Which file should maintain the true name after the transaction is not controlled by the package manager but is specified by each package itself, following packaging guideline. the packages decide, not the package manager. it's giving "each to their own" ๐ŸŽ€


โญ FILES โญ

  • Cache Files โ€” /var/cache/dnf
  • Main Configuration โ€” /etc/dnf/dnf.conf
  • Repository โ€” /etc/yum.repos.d/

๐Ÿ‘‘ SEE ALSO ๐Ÿ‘‘

๐Ÿ’– Author ๐Ÿ’–

See AUTHORS in DNF source distribution.

2012-2020, Red Hat, Licensed under GPLv2+


and that's the whole page bestie, we made it to the end ๐Ÿซถ๐Ÿ’…โœจ the footer says 4.24.0, dated Feb 19, 2026, and yes it's DNF4(8) โ€” the icon, the moment, the manual page. go forth and dnf responsibly. mwah ๐ŸŽ€

๐Ÿ“ฆ where this page comes from