DNF(8)

📦
version 4.14.0 · 3 versions
, in debian bookworm

🦋 DNF — like, the whole manual, but make it make sense 🦋

okay bestie, buckle up, we're reading the DNF(8) manual together and I'm gonna hold your hand through every single flag. no skimming, no skipping, we're doing this properly. 💅

✨ NAME ✨

dnf — DNF Command Reference. that's it, that's the name. it's giving "short and iconic." 👑

✨ SYNOPSIS ✨

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

like, options first, then the command, then whatever args that command wants. easy. 🍓

✨ DESCRIPTION ✨

so. DNF is the next upcoming major version of YUM, and it's a package manager for RPM-based Linux distros. it roughly keeps CLI compatibility with YUM, and it defines a strict API for extensions and plugins. no cap.

Plugins can modify or extend DNF's features, or straight up give you additional CLI commands on top of the ones listed below. here's the cute trick: if you know the name of such a command (including the ones mentioned below), you can find/install the package that provides it using the appropriate virtual provide in the form of dnf-command(<alias>), where <alias> is the name of the command. for example, dnf install 'dnf-command(versionlock)' installs a versionlock plugin. 🫶 and this approach also works for specifying dependencies of packages that require a particular DNF command.

🎀 Return values 🎀

bestie, memorize these, they're the vibe check on whether anything worked:

  • 0 : Operation was successful. (we ate. 💅)
  • 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 squad, no one left behind:

  • 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 🎀

and here's the extra reading list, for when you're feeling studious 📚:

  • 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. every single flag, right here, no gatekeeping. 🧚

  • -4 — Resolve to IPv4 addresses only.
  • -6 — Resolve to IPv6 addresses only.
  • --advisory=<advisory>, --advisories=<advisory> — Include packages corresponding to the advisory ID, Eg. FEDORA-2201-123. Applicable for the install, repoquery, updateinfo and upgrade 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. (letting it go, respectfully 🫶)
  • --assumeno — Automatically answer no for all questions.
  • -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. so like, only the main characters get the newest version, the side characters might be older, iykyk.

  • --bugfix — Include packages that fix a bugfix issue. Applicable for the install, repoquery, updateinfo and upgrade commands.
  • --bz=<bugzilla>, --bzs=<bugzilla> — Include packages that fix a Bugzilla ID, Eg. 123123. Applicable for the install, repoquery, updateinfo and upgrade 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. ✨

  • --color=<color> — Control whether color is used in terminal output. Valid values are always, never and auto (default).
  • --comment=<comment> — Add a comment to the transaction history. (for the lore 📝)
  • -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, and upgrade 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.
  • --disableexcludes=[all|main|<repoid>], --disableexcludepkgs=[all|main|<repoid>] — Disable the configuration file excludes. Takes one of the following three options:
    • all, disables all configuration file excludes
    • main, disables excludes defined in the [main] section
    • repoid, disables excludes defined for the given repository
  • --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. (pick one bestie, you can't have both 😭)
  • --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 or reposync commands (dnf-plugins-core) or with the system-upgrade command (dnf-plugins-extras).
  • --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. ⚠️ so if you want them to STAY, don't use this, use download.

  • -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. 🔥
  • --enhancement — Include enhancement relevant packages. Applicable for the install, repoquery, updateinfo and upgrade 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.
  • --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.
    • The pluginpath and pluginconfpath are relative to the host.

Note: You may also want to use the command-line option --releasever=<release> when creating the installroot, otherwise the $releasever value is taken from the rpmdb within the installroot (and thus it is empty at the time of creation and the transaction will fail). If --releasever=/ is used, the releasever will be detected from the host (/) system. The new installroot path at the time of creation does not contain the repository, releasever and dnf.conf files.

On a modular system you may also want to use the --setopt=module_platform_id=<module_platform_name:stream> command-line option when creating the installroot, otherwise the module_platform_id value will be taken from the /etc/os-release file within the installroot (and thus it will be empty at the time of creation, the modular dependency could be unsatisfied and modules content could be excluded).

Installroot examples:

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

Permanently sets the releasever of the system in the <installroot> directory to <release>. Like, it's not vibing temporarily, it's a whole commitment 💍

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. Bestie, that's a lot of knobs at once and yet she ate ✨

  • --newpackage — Include newpackage relevant packages. Applicable for the install, repoquery, updateinfo and upgrade commands.
  • --noautoremove — Disable removal of dependencies that are no longer used. It sets 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'. No docs, only vibes 📚🚫
  • --nogpgcheck — Skip checking GPG signatures on packages (if RPM policy allows). Lowkey sketchy, do it at your own risk fr 💀
  • --noplugins — Disable all plugins. Just you, raw and unbothered 🧚
  • --obsoletes — This option has an effect on an install/update, it enables dnf's obsoletes processing logic. For more information 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. Silent. Mysterious. Iconic. 🤫
  • -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.
  • --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 is basically a shortcut for --disablerepo="*" --enablerepo=<repoid> and is mutually exclusive with the --disablerepo option. Pick a lane, bestie 🫶
  • --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 and upgrade commands.
  • --security — Includes packages that provide a fix for a security issue. Applicable for the upgrade command. Protect the peace 🛡️
  • --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. Got it? Appended, not replaced. That distinction matters, no cap.
  • --skip-broken — Resolve depsolve problems by removing packages that are causing problems from the transaction. It is 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.
  • -v, --verbose — Verbose operation, show debug messages.
  • --version — Show DNF version and exit.
  • -y, --assumeyes — Automatically answer yes for all questions. Zero questions asked, she's confident 💅

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

💖 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 be then 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 is 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. She said "not today" and bailed 💀

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 is 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.
  • 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. That backslash is the seatbelt, do not remove it 🚗

🦋 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)

See how the alias only works in the first "command" spot? She has a very specific job and she's doing it ✨

🌸 Autoremove Command 🌸

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

dnf [options] autoremove

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

Packages listed in installonlypkgs are never automatically removed by this command.

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.

There are also a few specific autoremove commands autoremove-n, autoremove-na and autoremove-nevra that allow the specification of an exact argument in the NEVRA (name-epoch:version-release.architecture) format.

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]

Checks the local packagedb and produces information on any problems it finds. You can limit the checks to be performed by using the --dependencies, --duplicates, --obsoleted and --provides options (the default is to check everything). Full health check unless you tell her to chill 🩺

💜 Check-Update Command 💜

Command: check-update Aliases: check-upgrade

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

Non-interactively checks if updates of the specified packages are available. If no <package-file-spec> is given, checks whether any updates at all are available for your system. DNF exit code will be 100 when there are updates available and a list of the updates will be printed, 0 if not and 1 if an error occurs. If --changelogs option is specified, also changelog delta of packages about to be updated is printed.

Please note that having a specific newer version available for an installed package (and reported by check-update) does not imply that subsequent dnf upgrade will install it. The difference is that dnf upgrade has restrictions (like package dependencies being satisfied) to take into account. So don't come for her when the upgrade picks something else, ok? 😭

The output is affected by the autocheck_running_kernel configuration option.

🧚 Clean Command 🧚

Command: clean

Performs cleanup of temporary files kept for repositories. This includes any such data left behind from disabled or removed repositories as well as for different distribution release versions.

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. Fresh start energy, we love a reset ✨

  • dnf clean expire-cache — marks the repository metadata as expired 💀. Next time any repo gets used, DNF re-validates its cache. that's it. that's the whole thing.
  • dnf clean metadata — yeets the repository metadata off your system 🗑️. these are the files DNF relies on to figure out whether packages are remotely available. so yeah, using this means DNF is gonna redownload all the metadata next time it runs. all of it. the whole thing.
  • dnf clean packages — removes any cached packages from the system. bye bestie 🎀
  • dnf clean all — does all of the above. iconic behaviour, honestly.

🗑️ Deplist Command

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

Deprecated alias for dnf repoquery --deplist. so like. it still works but it's giving "we're so over this". use the repoquery one 💅

🔄 Distro-Sync Command

  • Command: distro-sync
  • Aliases: dsync
  • Deprecated aliases: distrosync, distribution-synchronization
dnf distro-sync [<package-spec>...]

As necessary, it upgrades, downgrades, or just keeps the installed packages you picked so they match the latest version available from any enabled repository. like, whatever it takes to get you in sync. If you don't hand it any package, then all installed packages are considered. all of them. no cap.

See also Configuration Files Replacement Policy. 📄✨

⬇️ Downgrade Command

  • Command: downgrade
  • Aliases: dg
dnf [options] downgrade <package-spec>...

Downgrades the packages you specified down to the highest installable package of all known lower versions, if that's even possible. And if you give it a version and that version is lower than the one you've currently got installed? Then it downgrades to that target version specifically. periodt. 💅

👯 Group Command

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

Groups are like virtual collections of packages 🫶. DNF keeps track of the groups you the user selected (a.k.a. "marked") as installed, and then it can manipulate all the packages inside them with some nice simple commands. so basically a group is a squad and the packages are the members.

dnf [options] group [summary] <group-spec>

Displays an overview of how many groups are installed vs. available. Give it a spec and it limits the output to just the matching groups. Fun fact: summary is the default groups subcommand, so if you're lazy you don't even have to type it. 🎀

dnf [options] group info <group-spec>

Displays the package lists of a group. It shows you which packages are installed or available from a repository when you use -v. 👀

dnf [options] group install [--with-optional] <group-spec>...

Marks the group you named as installed and installs the packages it contains. It also pulls in the group's optional packages if you pass --with-optional. All mandatory and Default packages will be installed whenever possible. Conditional packages get installed only if they meet their requirement. If the group is already (partially) installed, the command just installs the missing packages from the group. And depending on the value of the obsoletes configuration option, group installation takes obsoletes into account. no cap, that's a real factor.

dnf [options] group list <group-spec>...

Lists all matching groups, whether that's among installed or available groups. Specify nothing and you get all known groups. The --installed and --available options narrow down the list you're asking for. Records are ordered by the display_order tag defined in the comps.xml file, because of course they are. It provides a list of all hidden groups if you use the --hidden option, and it provides group IDs when you use the -v or --ids options. ✨

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

Marks the group removed and removes those packages in the group from your system which do not belong to another installed group and were not installed explicitly by the user. so it's not gonna nuke something you deliberately wanted, bestie, chill 💀

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

Upgrades the packages from the group and upgrades the group itself. The "itself" part means installing packages that were added to the group by the distribution, and removing packages that got removed from the group — but only as far as they weren't installed explicitly by the user. 🦋

Groups can also be marked installed or removed without physically manipulating any packages. which is a whole vibe:

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 mind bestie 🧠✨

dnf [options] group mark remove <group-spec>...

Mark the specified group removed. No packages will be removed by this command. literally nothing happens to your files, it's just the bookkeeping.

See also Configuration Files Replacement Policy. 📄

❓ Help Command

  • Command: help
dnf help [<command>]

Displays the help text for all commands. If you give it a command name, then it only displays help for that particular command. bestie behaviour honestly, ask for help and get help 🫶

📜 History Command

  • Command: history
  • Aliases: hist

The history command lets you view what has happened in past transactions and act according to that information (assuming the history_record configuration option is set). it's literally the receipts of your package management life 💅

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

The default history action is listing information about the 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.

  • --reverse — the order of the history list output is printed in reverse order. yes it's exactly what it sounds like 🙈
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.

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's not possible to redo some operations due to the current state of RPMDB, then it will not redo the transaction. nope. all or nothing, bestie.

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 performs the exact same operations on the packages as in the original transaction, and it returns with an error if there are 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's an upgrade foo-1.0 -> foo-2.0 stored in the transaction, but there's foo-1.1 installed on the target system. yeah, that mismatch, we're ignoring it. 🙈
  • --ignore-extras — don't check for extra packages pulled into the transaction on the target system. E.g. the target system may not have some dependency, which was installed on the source system. The replay errors out on this by default, because the transaction wouldn't be the same. like, it's strict for a reason 💀
  • --skip-unavailable — in case some packages stored in the transaction are not available on the target system, skip them instead of erroring out. be nice to it 🫶
dnf history rollback <transaction-spec>|<package-file-spec>

Undo all transactions performed after 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's not possible to undo some transactions due to the current state of RPMDB, it will not undo any transaction. again: all or nothing. no partial rollbacks here.

dnf history store [--output <output-file>] <transaction-spec>

Store a transaction specified by <transaction-spec>. That transaction can later be replayed by the History Replay Command. cute lil save file energy 💾

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). so like. don't build your whole personality on this file format, bestie.
  • -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>

Perform the opposite operation to all operations performed in 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's not possible to undo some operations due to the current state of RPMDB, it will not undo the transaction. 🚫

dnf history userinstalled

Show all installonly packages, packages installed outside of DNF, and packages not installed as a dependency. I.e. it lists packages that will stay on the system when the Autoremove Command or the Remove Command — along with the clean_requirements_on_remove configuration option set to True — is executed. Note the same results can be accomplished with dnf repoquery --userinstalled, and the repoquery command is more powerful in formatting of the output. so like, glow-up option available ✨

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" 💅

The info command limits the displayed packages the same way as the list command.

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. If a given package or provide cannot be (and is not already) installed, the exit code will be non-zero. And heads up: if the <spec> matches both a @<module-spec> and a @<group-spec>, then only the module gets installed. them's the rules 🎀

When you hand over a <package-spec> that names the exact version of a package, bestie, DNF is gonna install that exact version you asked for — doesn't matter what version is already sitting there. And if the package isn't an installonly package, the old version gets yeeted in the process. 💅

But flip it around: if your <package-spec> is just a name, then DNF also looks at packages that obsolete it when it's deciding what to install. 👀 That's a thing only the install command does, iykyk. Heads up though — this can give you results that look lowkey cursed if a package has multiple versions and some older one is being obsoleted. It legit creates a split in the upgrade-path, and both branches are considered correct, so the winner is picked by lexicographical order. No cap. 😭

There's also a lil trio of special install commands — install-n, install-na and install-nevra — that let you drop an exact argument in the NEVRA format. 🎀

See also Configuration Files Replacement Policy.

✨ Install Examples ✨

  • dnf install tito — installs the tito package (tito is the package name, obvs).
  • 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.
  • dnf install tito-0.5.6-1.fc22 — installs the package at that specific version. If it's already installed, DNF will automatically try to downgrade or upgrade to that exact version. 🔄
  • dnf --best install tito — installs the latest available version of the package. If it's already installed, DNF tries to auto-upgrade to the newest one. And if that latest version can't be installed, the whole installation fails. no half-measures 💀
  • dnf install vim — DNF will clock that vim isn't actually a package name and go look up + install whatever package provides vim, along with all the required dependencies. Note: a package name match beats a 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 straight from a URL. 🌈
  • dnf install '@docker' — installs all the default profiles of the module docker plus their RPMs. The module streams get enabled accordingly. ✨
  • dnf install '@Web Server' — installs the 'Web Server' environmental group.
  • dnf install /usr/bin/rpmsign — installs whatever package 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 aren't needed for the package's core functionality, but they do enhance it (think extended docs, plugins, extra functions, that kind of vibe).
  • dnf install --advisory=FEDORA-2018-b7b99fe852 \* — installs all packages that belong to the "FEDORA-2018-b7b99fe852" advisory. 🫶

🌸 List Command 🌸

Command: list

Aliases: ls

This one prints out lists of packages based on how they relate to your system. A package is installed if it's chillin' in the RPMDB, and it's available if it's not installed but is present in a repository that DNF knows about. 🧚

The list command also narrows down which packages get shown according to specific criteria — like only the ones that update an installed package (respecting repository priority, ofc). The exclude option in the config file can sway the result, but if you use the --disableexcludes command line option, it guarantees that all installed packages get listed. periodt.

  • dnf [options] list [--all] [<package-file-spec>...] — lists all packages that are in the RPMDB, in a repository, or in 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, meaning packages installed on the system that aren't available in any known repository. 🙈
  • 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 that were recently added into the repositories.
  • dnf [options] list --upgrades [<package-file-spec>...] — lists the upgrades available for your installed packages. 🔥
  • dnf [options] list --autoremove — lists the packages that'll get removed by the dnf autoremove command.

By default this command 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 your enabled repositories. It tries to avoid downloading whenever it can (like when the local metadata hasn't expired yet, or when the metadata timestamp hasn't changed). 💅
  • dnf [options] makecache --timer — same energy as plain makecache, but it tells DNF to be more resource-aware: it won't do anything if you're running on battery power, and it'll bail immediately if it's too soon after the last successful makecache run (see dnf.conf(5), metadata_timer_sync). 🔋

🎀 Mark Command 🎀

Command: mark

  • dnf mark install <package-spec>... — marks the specified packages as installed by user. This is a lifesaver if some package got pulled in as a dependency and you want it to stay on the system when the Autoremove Command or the Remove Command runs with the clean_requirements_on_remove config option set to True. 🫶
  • dnf mark remove <package-spec>... — unmarks the specified packages as installed by user. Whenever you don't need a specific package anymore, you can mark it for removal. The package stays installed for now, but it'll get removed when the Autoremove Command or the Remove Command runs with clean_requirements_on_remove set to True. Use this instead of the Remove Command whenever you're not sure whether the package is a requirement of other user-installed packages on your system. 🧠
  • dnf mark group <package-spec>... — marks the specified packages as installed by group. Handy when a package came in as a dependency or as a user, and you want it protected and handled like a group member — you know, the way group remove treats things. 👑

🦋 Module Command 🦋

Command: module

The modularity overview lives at man page dnf.modularity(7). 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 didn't hand over a profile, all default profiles get installed. Module streams get enabled accordingly. ✨

This command can't be used for switching module streams. Use dnf module switch-to for that instead.

  • dnf [options] module update <module-spec>... — updates the packages associated with an active module stream, optionally restricted to a profile. If profile_name is given, only the packages referenced by that profile get updated.
  • dnf [options] module switch-to <module-spec>... — switches to or enables a module stream, changes the versions of installed packages to 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. When a profile was given, it installs that profile and does not update any already-installed profiles.

You can think of this as a beefed-up 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 also works as a stronger version of the dnf module install command, but it requires you to specify the profiles you want installed, because switch-to doesn't use default profiles. And it doesn't stop at installing profiles — it also makes a distrosync to all modular packages in the installed module.

  • dnf [options] module remove <module-spec>... — removes installed module profiles, including the packages that were installed with the dnf module install command. It will not remove packages required by other installed module profiles or by other user-installed packages. If you didn't give a profile, all installed profiles get removed. 💅
  • dnf [options] module remove --all <module-spec>... — removes installed module profiles, including the packages that were installed with the dnf module install command. With the --all option it additionally removes all packages whose names are provided by the specified modules. Packages required by other installed module profiles — and packages whose names are also provided by any other module — are not removed. 🛑
  • dnf [options] module enable <module-spec>... — enables a module stream and makes the stream's RPMs available in the package set. ✨

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

This command can't be used for switching module streams. Use the dnf module switch-to command 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's RPMs become unavailable in the package set. If there's a modular dependency issue, the operation gets rejected. To do it anyway, pls 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 the RPMs from the default stream stay available in the package set. 🌈
  • dnf [options] module provides <package-name-spec>... — shows you every modular package that matches <package-name-spec>, from all the modules (yes, even the disabled ones, we're nosy like that), plus the modules and streams each one belongs to 💅
  • dnf [options] module list [--all] [module_name...] — lists every module stream, its profiles and its state (enabled, disabled, default). Receipts for days.
  • dnf [options] module list --enabled [module_name...] — only the module streams that are enabled. The ones actually showing up to the party ✨
  • dnf [options] module list --disabled [module_name...] — only the module streams that are disabled. The ones ghosting us 💀
  • dnf [options] module list --installed [module_name...] — module streams that have installed profiles. Like, actually on your system.
  • dnf [options] module info <module-spec>... — prints the full tea ☕ on the given module stream.
  • dnf [options] module info --profile <module-spec>... — the same but for the given module profiles specifically.
  • dnf [options] module repoquery <module-spec>... — lists every available package that belongs to the selected modules.
  • dnf [options] module repoquery --available <module-spec>... — lists all the available packages belonging to the selected modules.
  • dnf [options] module repoquery --installed <module-spec>... — lists all installed packages whose names match the packages belonging to the selected modules.

🫶 Provides Command 🫶

Command: provides

Aliases: prov, whatprovides, wp

  • dnf [options] provides <provide-spec> — finds the packages that provide <provide-spec>. This is the move when you know a filename and you're like "bestie, what package even owns this file?? (installed or not)". And the way it looks for <provide-spec> is honestly iconic — it checks these places, in order:
    1. <provide-spec> gets matched against all the 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 get 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 is like "okay, so <provide-spec> is probably a system command", so it prepends /usr/bin/ and /usr/sbin/ prefixes (one at a time) and runs the file provides search again. And for legacy reasons (packages that didn't do UsrMove, if you know you know), /bin and /sbin prefixes get searched too:
$ dnf provides zless
gzip-1.9-9.fc29.x86_64 : The GNU data compression program
Matched from:
Filename    : /usr/bin/zless
  1. And if that last step also fails? DNF just returns "Error: No Matches found". Devastating. No notes. 😭
Heads up bestie: 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 packages you name, and it fails if any of them are either not installed or not available (aka there's no repository where it could download the same RPM). So it's a reinstall or nothing, no half measures 💅

🎀 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 your system, along with every package that depends on the ones being removed (sorry to the dependents, they gotta go too 😭). Each <spec> can be either a <package-spec>, which names a package directly, or a @<group-spec>, which names an (environment) group that contains it. And if clean_requirements_on_remove is enabled (which it is by default), it also removes any dependencies that are no longer needed. Spring cleaning fr fr 🧹
  • dnf [options] remove --duplicates — removes older versions of duplicate packages. To keep your system's integrity intact it reinstalls the newest package. In some cases the command just cannot resolve conflicts — and in those cases, the dnf shell command with remove --duplicates and upgrade dnf-shell sub-commands could help.
  • dnf [options] remove --oldinstallonly — removes old installonly packages, keeping only the latest versions plus the version of the running kernel. Iconic behaviour honestly 👑

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.

✨ Remove Examples ✨

Remove the acpi and tito packages:

dnf remove acpi tito

Remove packages not present in any repository, but don't remove the tito and acpi packages (though ngl, they still might get removed if they depend on some of the removed packages):

dnf remove $(dnf repoquery --extras --exclude=tito,acpi)

Remove older versions of duplicated packages (this is the equivalent of yum's package-cleanup --cleandups):

dnf remove --duplicates

🌸 Repoinfo Command 🌸

Command: repoinfo

It's an alias for the repolist command, except it gives you more detailed info — think dnf repolist -v energy 💅

🦋 Repolist Command 🦋

Command: repolist

  • dnf [options] repolist [--enabled|--disabled|--all] — depending on the exact command, it lists enabled, disabled or all known repositories. By default it lists all enabled repositories. And it gives you more detailed information when the -v option is used. Main character detail energy ✨
Same disclaimer as before bestie: 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 but for remote repositories. Obsessed with her 🫶

  • dnf [options] repoquery --groupmember <package-spec>... — lists the groups that contain <package-spec>.
  • dnf [options] repoquery --querytags — gives you 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 let you specify an exact argument in the NEVRA format (and ngl, this does not affect arguments of options like --whatprovides <arg>, ...).

⭐ Select Options ⭐

Together with <package-file-spec>, these control what packages actually show up in the output. If <package-file-spec> is given, it limits the resulting set of packages to those matching the specification. And if no <package-file-spec> is specified? All packages are considered. Everyone's invited 💖

  • <package-file-spec> — a package specification in the NEVRA format (name[-[epoch:]version[-release]][.arch]), a package provide, or a file provide. See Specifying Packages.
  • -a, --all — query all packages (for rpmquery compatibility, it's also a shorthand for repoquery '*' or repoquery with no arguments at all).
  • --arch <arch>[,<arch>...], --archlist <arch>[,<arch>...] — limit the resulting set to only packages of the selected architectures (default is all architectures). In some cases the result is affected by the basearch of the running system, so to run repoquery for an arch that's incompatible with your system, use the --forcearch=<arch> option to change the basearch. 👑
  • --duplicates — limit the resulting set to installed duplicate packages (aka more package versions for the same name and architecture). Installonly packages are excluded from this set, no cap.
  • --unneeded — limit the resulting set to leaf packages that were installed as dependencies and are therefore no longer needed. This switch lists the packages that are going to get removed after you run the dnf autoremove command. It's giving foreshadowing 💀
  • --available — limit the resulting set to available packages only (this is the default, bestie).
  • --disable-modular-filtering — disables filtering of modular packages, so that packages from inactive module streams get included in the result. Sneaky but valid.
  • --extras — limit the resulting set to packages that aren't present in any of the available repositories.
  • -f <file>, --file <file> — limit the resulting set to only the package that owns <file>.
  • --installed — limit the resulting set to installed packages only. The exclude option in the configuration file might influence the result, but if the command line option --disableexcludes is used, it ensures that all installed packages will be listed. So no gatekeeping 💅
  • --installonly — limit the resulting set to installed installonly packages.
  • --latest-limit <number> — limit the resulting set to <number> of latest packages for every package name and architecture. If <number> is negative, skip <number> of latest packages. And for a negative <number> you have to use the --latest-limit=<number> syntax, okurrr.
  • --recent — limit the resulting set to packages that were recently edited.
  • --repo <repoid> — limit the resulting set to only packages from the repository identified by <repoid>. Can be used multiple times with accumulative effect. Stack them like accessories ✨
  • --unsatisfied — report unsatisfied dependencies among installed packages (i.e. missing requires and existing conflicts). Drama report, honestly.
  • --upgrades — limit the resulting set to packages that provide an upgrade for some already installed package.
  • --userinstalled — limit the resulting set to packages installed by the user. Same deal as --installed: the exclude 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.
  • --whatdepends <capability>[,<capability>...] — limit the resulting set to only packages that require, enhance, recommend, suggest or supplement any of <capabilities>.
  • --whatconflicts <capability>[,<capability>...] — limit the resulting set to only packages that conflict with any of <capabilities>. Messy.
  • --whatenhances <capability>[,<capability>...] — limit the resulting set to only packages that enhance any of <capabilities>. And btw, use --whatdepends if you want to list all depending packages. Don't get it twisted 🫶
  • --whatobsoletes <capability>[,<capability>...] — limit the resulting set to only packages that obsolete any of <capabilities>.
  • --whatprovides <capability>[,<capability>...] — narrows your result set down to only the packages that provide any of the <capabilities> you listed. slay.
  • --whatrecommends <capability>[,<capability>...] — narrows the result set to just packages that recommend any of those <capabilities>. bestie if you actually want every package that depends, use --whatdepends instead, ok?
  • --whatrequires <capability>[,<capability>...] — narrows the result set to only packages that require any of the <capabilities>. again, want the full list of depending packages? --whatdepends. 💅
  • --whatsuggests <capability>[,<capability>...] — limit it to packages that suggest any of the <capabilities>. and yeah, --whatdepends if you want all the depending packages.
  • --whatsupplements <capability>[,<capability>...] — limit the resulting set only to packages that supplement any of the <capabilities>. --whatdepends for the full depending-packages situation, iykyk.
  • --alldeps — this one stacks with --whatrequires or --whatdepends only, no exceptions. and on top of that it adds all packages requiring the package features to the result set (and yes, this is used as default).
  • --exactdeps — stackable with --whatrequires or --whatdepends only. limits the result set to only packages that require the <capability> you specified with --whatrequires.
  • --srpm — operate on the corresponding source RPM. 🎀

✨ Query Options ✨

this is where you set what info actually gets displayed about each package, bestie. very important.

heads up: the following are mutually exclusive, meaning at most one can be specified. and if you give no query option at all, matching packages get displayed in the standard NEVRA notation. that's the vibe.
  • -i, --info — show detailed information about the package. the full tea. 🫖
  • -l, --list — show the list of files in the package.
  • -s, --source — show the package source RPM name.
  • --changelogs — print the package changelogs. the lore. 📜
  • --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. so you can go get it. 🦋
  • --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. it's giving family tree but make it packages. 🌳
  • --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 (and you can change that 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, periodt).
  • --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, your moment to shine ✨. <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. wanna see the whole list of recognized tags? just run dnf repoquery --querytags. iconic.
  • --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).

🎀 Examples 🎀

display NEVRAs of all available packages matching light*:

dnf repoquery 'light*'

display NEVRAs of all available packages matching name light* and architecture noarch (accepts only arguments in the "<name>.<arch>" format):

dnf repoquery-na 'light*.noarch'

display requires of all lighttpd packages:

dnf repoquery --requires lighttpd

display packages providing the requires of python packages:

dnf repoquery --requires python --resolve

display source rpm of ligttpd package:

dnf repoquery --source lighttpd

display package name that owns the given file:

dnf repoquery --file /etc/lighttpd/lighttpd.conf

display name, architecture and the containing repository of all lighttpd packages:

dnf repoquery --queryformat '%{name}.%{arch} : %{reponame}' lighttpd

display all available packages providing "webserver":

dnf repoquery --whatprovides webserver

display all available packages providing "webserver" but only for "i686" architecture:

dnf repoquery --whatprovides webserver --arch i686

display duplicate packages:

dnf repoquery --duplicates

display source packages that require a <provide> for a build:

dnf repoquery --disablerepo="*" --enablerepo="*-source" --arch=src --whatrequires <provide>

🌈 Repository-Packages Command 🌈

command: repository-packages

deprecated aliases: repo-pkgs, repo-packages, repository-pkgs

ok so the repository-packages command lets you run commands on top of all packages in the repository named <repoid>. however — and this is the key part bestie — any dependency resolution takes into account packages from all enabled repositories. and the <package-file-spec> and <package-spec> specifications further limit the candidates to only those packages matching at least one of them. 💜

the info subcommand lists description and summary information about packages depending on the packages' relation to the repository. the list subcommand just prints lists of those packages. simple as.

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 exit code will be 100 when there are updates available and a list of the updates will be printed. 👀

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.

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 off the press 🍓

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

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

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

install packages matching <package-spec> from the repository. and if <package-spec> isn't specified at all? install all packages from the repository. go big or go home 💅

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.

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

reinstall all those packages that are available in the repository.

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

run the reinstall-old subcommand. if it fails, run the move-to subcommand. it's got a plan B, we love that for it. 🙈

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.

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. so thorough. so clean. ✨

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

okay so bestie this one grabs every single package you installed from that repo, then for each one it either upgrades, downgrades, or just keeps it — whatever makes it line up with the newest version available in another repo. And the ones that have no other home? gone. Along with anything that depends on them, because we don't leave orphaned chaos behind. 🫶 And if clean_requirements_on_remove is on (and it's on by default, bestie), it also sweeps out any dependencies that nobody needs anymore.

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

same energy, different ending 💅 This one selects all packages installed from that repo, reinstalls the ones that exist in another repo, and removes the rest — plus everything depending on the removed ones. And yep, clean_requirements_on_remove being enabled (the default) means unused deps get cleaned too.

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

Bumps all packages up to the highest resolvable version hanging out in that repository. And if you put versions in the <package-spec>, it updates to those specific versions instead. ✨

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

A deprecated alias for the upgrade subcommand. Still works, but like… it's giving legacy. 👑

✨ Search Command ✨

Command: search

Aliases: se

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

Search the package metadata for keywords, bestie. Keywords get matched as case-insensitive substrings, and globbing is supported 🦋. By default it lists packages matching all the keys you gave it — that's an AND operation. Keys get searched in package names and summaries. But if you slap --all on there, it flips to listing packages matching at least one key (an OR operation), and bonus: the keys also get searched in the package descriptions and URLs. Results come sorted from most relevant to least, so the good stuff is up top. 💖

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 up an interactive shell so you can run a whole bunch of commands in one single DNF execution, instead of typing dnf over and over like a Victorian child. 😭 You can type the commands in manually, or feed DNF a file full of them. The commands are basically the normal DNF command line options — with a few extra ones documented right here:

config [conf-option] [value]

  • Sets a configuration option to whatever value you asked for. And if you don't give it a value? It just prints the current one. Simple. 🎀

repo [list|enable|disable] [repo-id]

  • list: lists repositories and their status
  • enable: enables a repository
  • disable: disables a repository

transaction [list|reset|solve|run]

  • list: resolves and lists the content of the transaction
  • reset: resets the transaction
  • run: resolves and runs the transaction
⚠️ Heads up bestie, this one matters: 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 (for example module enable nodejs) must also be done before you use any other shell transaction subcommand. First-thing-first, no cap. 💀

✨ Swap Command ✨

Command: swap

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

Remove one spec and install another spec, all in a single transaction. ✨ Each <spec> can be either a <package-spec>, which points at a package directly, or a @<group-spec>, which points at an (environment) group that contains it. And ngl, DNF already does automatic conflict solving — the --allowerasing option gives you the functionality of the swap command automatically. 👑

✨ 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>...]

Shows you all the update advisory tea. 🍓

Depending on the output type, DNF shows you just the counts of advisory types (that's when you omit it or use --summary), a list of advisories (--list), or detailed info (--info). The -v option extends the output — and when you pair it with --info, the info gets even more detailed. When you pair it with --list, you get an extra column showing the date of the last advisory update. ✨

<availability> decides which advisories even count:

  • omitted, or --available — advisories about newer versions of installed packages
  • --installed — advisories about equal and older versions of installed packages
  • --updates — advisories about newer versions of those installed packages for which a newer version is available
  • --all — advisories about any versions of installed packages

Most of the time, --available and --updates print the exact same output. The outputs only differ when an advisory refers to a newer version, but there's no enabled repository containing any newer version.

📌 Note: --available only takes the latest installed versions of packages into account. But for kernel packages (where multiple versions can be installed at the same time), packages of the currently running version of the kernel get added too.

Want only the advisories that reference a CVE or a bugzilla? Use --with-cve or --with-bz. And when you use those switches, the --list output changes too — it prints the ID of the CVE or the bugzilla instead of the ID of the advisory.

If you pass a <spec> and neither an ID, a type (bugfix, enhancement, security/sec), nor a package name of an advisory matches it, that advisory just doesn't get 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 every single package to the latest version that is both available and resolvable. Both. No shortcuts. 💅

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

Updates each specified package to the latest available version, and updates dependencies as needed. When versions are specified in the <package-spec>, it updates to those versions. ✨

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

An alias for the dnf module update command. iykyk 🎀

If the main obsoletes configure option is true, or the --obsoletes flag is present, dnf will include package obsoletes in its calculations. For more info see obsoletes.

See also Configuration Files Replacement Policy.

✨ Upgrade-Minimal Command ✨

Command: upgrade-minimal

Aliases: up-min

Deprecated aliases: update-minimal

dnf [options] upgrade-minimal

Updates each package to the latest available version that provides a bugfix, an enhancement, or a fix for a security issue (security). Not just any shiny new version — only the ones that actually fix something. 👑

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

Updates each specified package to the latest available version that provides a bugfix, an enhancement, or a fix for a security issue (security). Updates dependencies as needed. 🫶

🌈 SPECIFYING PACKAGES 🌈

Okay bestie, this is the part where we learn how to point at a package and be understood. 🎯

Lots of commands take a <package-spec> parameter, which selects a package for the operation. The <package-spec> argument gets matched against package NEVRAs, provides, and file provides.

<package-file-spec> is basically <package-spec>'s sibling, 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.

✨ Globs ✨

Package specification supports the exact same glob pattern matching that the shell does — and in all three of the above-mentioned things it matches against: NEVRAs, provides, and file provides. 🦋

Here are the supported patterns:

  • * — 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.
📌 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 they're quoted or escaped, dnf will not expand them. Periodt.

✨ 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 (like package-with-dashes). 💅

The first form that matches any packages is used, and the remaining forms are not tried. But if none of the forms match any packages, an attempt is made to match the <package-spec> against full package NEVRAs. That last bit 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 goes on to attempt matching against the provides and file provides of packages as well. 🫶

You can specify globs as part of any of the five NEVRA components. You can also specify a glob pattern that matches over multiple NEVRA components — in other words, to match across the NEVRA separators. In that case though, you need to write the spec so it matches against full package NEVRAs, because it's not possible to split such a spec into NEVRA forms. 😭

✨ Specifying NEVRA Matching Explicitly ✨

Some commands (autoremove, install, remove, and repoquery) also have aliases with the suffixes -n, -na, and -nevra, which 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.

💖 SPECIFYING PROVIDES 💖

So when you see <provide-spec> chillin' in a command description, it means that command is gonna operate on packages that provide the thing you asked for. Bestie, that could be:

  • an explicit provide (the package literally declares it),
  • an implicit provide — aka just the name of the package, iconic behaviour,
  • or a file provide.

The selection is case-sensitive and yes, globbing is supported, go off. ✨

🦋 Specifying File Provides 🦋

If your spec starts with either / or */, it's getting treated as a potential file provide. That's it, that's the rule. 💅

🌸 SPECIFYING GROUPS 🌸

<group-spec> is how you pick which (environment) groups a particular operation should work on. It's a case insensitive string (and yeah, it supports globbing characters 🫶) that gets matched against:

  • a group's ID,
  • its canonical name,
  • and its name translated into the current LC_MESSAGES locale (if that's even possible).

✨ SPECIFYING MODULES ✨

<module-spec> lets you select modules or profiles for an operation to work on. It's giving very structured, very slay. The full form is:

NAME:STREAM:VERSION:CONTEXT:ARCH/PROFILE

and the supported partial forms are:

  • 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)

Now, if the stream isn't specified, the enabled or the default stream is used — in this order, no skipping the line. And if the profile isn't specified, the system default profile or the 'default' profile is used. Periodt. 👑

💜 SPECIFYING TRANSACTIONS 💜

<transaction-spec> can show up in one of several forms, so pay attention bestie:

  • If it's an integer, it specifies a transaction ID.
  • last — same as specifying the ID of the most recent transaction. The way that's convenient 😭
  • last-<offset> — where <offset> is a positive integer. It specifies the offset-th transaction preceding the most recent transaction. So last-1 is the one before the newest, etc.

🔥 PACKAGE FILTERING 🔥

Package filtering filters packages out of the available package set, which makes them invisible to most dnf commands. And no, you can't use them in a transaction. Gone, blocked, not invited to the party. 💀

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. You can modify it with either the includepkgs or excludepkgs configuration options in configuration files. The --disableexcludes command line option can be used to override excludes from configuration files. And in addition to your 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.

So like, to disable all excludes for e.g. the install command, you can use this combination of command line options:

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

🧚 Modular Filtering 🧚

Please see the modularity documentation for details on how Modular Filtering works — that's the homework, bestie.

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.

Disabling of modular filtering is not recommended, because it could cause the system to get into a broken state. 😭 Seriously, don't.

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. Iykyk. 🌈

🌟 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 operation considerably slows it down and costs bandwidth for both the client and the repository provider. So we don't do that, obviously. 💅

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's 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. That's the whole deal, no cap.

To further reduce the bandwidth load, some of the commands where having up-to-date metadata is not critical (e.g. the list command) don't 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. And note that in all situations, the user can force synchronization of all enabled repositories with the --refresh switch. Slay. ✨

🎀 CONFIGURATION FILES REPLACEMENT POLICY 🎀

Okay so this one's a lil nuanced. The updated packages could replace the old modified configuration files with the new ones, or keep the older files. But plot twist — 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 — it's specified by each package itself, following packaging guideline. So don't come for dnf about it, it's not her call. 🙈

👑 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. She's shy, go read the file. 🫶

2012-2023, Red Hat, Licensed under GPLv2+

and that's the whole page bestie!! 🎉✨💖

This was DNF version 4.14.0, dated May 23, 2023 — so if you're reading this and the version's moved on, go check the fresh one, okay? 💅 Mwah, go install something cute. 🦋👑

📦 where this page comes from