| DNF(8) | DNF | DNF(8) |
dnf - DNF Command Reference
dnf [options] <command> [<args>...]
DNF is the next upcoming major version of YUM, a package manager for RPM-based Linux distributions. It roughly maintains CLI compatibility with YUM and defines a strict API for extensions and plugins.
Plugins can modify or extend features of DNF or provide additional CLI commands on top of those mentioned below. If you know the name of such a command (including commands mentioned below), you may find/install the package which provides it using the appropriate virtual provide in the form of dnf-command(<alias>), where <alias> is the name of the command; e.g.``dnf install 'dnf-command(versionlock)'`` installs a versionlock plugin. This approach also applies to specifying dependencies of packages that require a particular DNF command.
Return values:
Available commands:
Additional information:
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.
--disableexcludes=[all|main|<repoid>], --disableexcludepkgs=[all|main|<repoid>]
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:
This option also displays capabilities that the package obsoletes when used together with the repoquery command.
Configuration Option: obsoletes
List options are comma-separated. Command-line options override respective settings from configuration files.
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.
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.
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>...]
dnf alias [options] add <name=value>...
dnf alias [options] delete <name>...
If there are defined aliases in=install and FORCE="--skip-broken --disableexcludes=all":
If there is defined alias in=install:
Command: autoremove Aliases for explicit NEVRA matching: autoremove-n, autoremove-na, autoremove-nevra
dnf [options] autoremove
Packages listed in installonlypkgs are never automatically removed by this command.
dnf [options] autoremove <spec>...
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.
Command: check
dnf [options] check [--dependencies] [--duplicates] [--obsoleted] [--provides]
Command: check-update Aliases: check-upgrade
dnf [options] check-update [--changelogs] [<package-file-spec>...]
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.
The output is affected by the autocheck_running_kernel configuration option.
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.
Command: distro-sync Aliases: dsync Deprecated aliases: distrosync, distribution-synchronization
See also Configuration Files Replacement Policy.
Command: downgrade Aliases: dg
Command: group Aliases: grp Deprecated aliases: groups, grouplist, groupinstall, groupupdate, groupremove, grouperase, groupinfo
Groups are virtual collections of packages. DNF keeps track of groups that the user selected ("marked") installed and can manipulate the comprising packages with simple commands.
Groups can also be marked installed or removed without physically manipulating any packages:
See also Configuration Files Replacement Policy.
Command: help
Command: history Aliases: hist
The history command allows the user to view what has happened in past transactions and act according to this information (assuming the history_record configuration option is set).
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.
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.
Command: info
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.
Command: install Aliases: in Aliases for explicit NEVRA matching: install-n, install-na, install-nevra Deprecated aliases: localinstall
When <package-spec> to specify 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 non-installonly package.
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.
See also Configuration Files Replacement Policy.
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.
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). The exclude 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.
This command by default does not force a sync of expired metadata. See also Metadata Synchronization.
Command: makecache Aliases: mc
Command: mark
Command: module
Modularity overview is available at man page dnf.modularity(7). Module subcommands take <module-spec>... arguments that specify modules or profiles.
This command cannot be used for switching module streams. Use the dnf module switch-to command for that.
This command can be used as a stronger version of the dnf module enable command, which not only enables modules, but also does a distrosync to all modular packages in the enabled modules.
It can also be used as a stronger version of the dnf module install command, but it requires to specify profiles that are supposed to be installed, because switch-to command does not use default profiles. The switch-to command doesn't only install profiles, it also makes a distrosync to all modular packages in the installed module.
Modular dependencies are resolved, dependencies checked and also recursively enabled. In case of modular dependency issue the operation will be rejected. To perform the action anyway please use --skip-broken option.
This command cannot be used for switching module streams. Use the dnf module switch-to command for that.
Command: provides Aliases: prov, whatprovides
$ dnf provides /usr/bin/gzip gzip-1.9-9.fc29.x86_64 : The GNU data compression program Matched from: Filename : /usr/bin/gzip
$ 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
$ dnf provides zless gzip-1.9-9.fc29.x86_64 : The GNU data compression program Matched from: Filename : /usr/bin/zless
This command by default does not force a sync of expired metadata. See also Metadata Synchronization.
Command: reinstall Aliases: rei
Command: remove Aliases: rm Aliases for explicit NEVRA matching: remove-n, remove-na, remove-nevra Deprecated aliases: erase, erase-n, erase-na, erase-nevra
There are also a few specific remove commands remove-n, remove-na and remove-nevra that allow the specification of an exact argument in the NEVRA format.
Remove older versions of duplicated packages (an equivalent of yum's package-cleanup --cleandups):
dnf remove --duplicates
Command: repoinfo
Command: repolist
This command by default does not force a sync of expired metadata. See also Metadata Synchronization.
Command: repoquery Aliases: rq Aliases for explicit NEVRA matching: repoquery-n, repoquery-na, repoquery-nevra
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 (does not affect arguments of options like --whatprovides <arg>, ...).
Together with <package-file-spec>, control what packages are displayed in the output. If <package-file-spec> is given, limits the resulting set of packages to those matching the specification. All packages are considered if no <package-file-spec> is specified.
Set what information is displayed about each package.
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.
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>
Command: repository-packages Deprecated aliases: repo-pkgs, repo-packages, repository-pkgs
The repository-packages command allows the user to run commands on top of all packages in the repository named <repoid>. However, 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.
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.
Command: search Aliases: se
This command by default does not force a sync of expired metadata. See also Metadata Synchronization.
Command: shell Aliases: sh
Note that all local packages must be used in the first shell transaction subcommand (e.g. install /tmp/nodejs-1-1.x86_64.rpm /tmp/acpi-1-1.noarch.rpm) otherwise an error will occur. Any disable, enable, and reset module operations (e.g. module enable nodejs) must also be performed before any other shell transaction subcommand is used.
Command: swap
dnf [options] swap <remove-spec> <install-spec>
Command: updateinfo Deprecated aliases: list-updateinfo, list-security, list-sec, info-updateinfo, info-security, info-sec, summary-updateinfo
Depending on the output type, DNF displays just counts of advisory types (omitted or --summary), list of advisories (--list) or detailed information (--info). The -v option extends the output. When used with --info, the information is even more detailed. When used with --list, an additional column with date of the last advisory update is added.
<availability> specifies whether 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) are taken into account. Most of the time, --available and --updates displays the same output. The outputs differ only in the cases when an advisory refers to a newer version but there is no enabled repository which contains any newer version.
Note, that --available tooks only the latest installed versions of packages into account. In case of the kernel packages (when multiple version could be installed simultaneously) also packages of the currently running version of kernel are added.
To print only advisories referencing a CVE or a bugzilla use --with-cve or --with-bz options. When these switches are used also the output of the --list is altered - 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 in the case of advisory IDs and package names, globbing is supported.
Output of the --summary option is affected by the autocheck_running_kernel configuration option.
Command: upgrade Aliases: up Deprecated aliases: update, upgrade-to, update-to, localupdate
If the main obsoletes configure option is true or the --obsoletes flag is present, dnf will include package obsoletes in its calculations. For more information see obsoletes.
See also Configuration Files Replacement Policy.
Command: upgrade-minimal Aliases: up-min Deprecated aliases: update-minimal
Many commands take a <package-spec> parameter that selects a package for the operation. The <package-spec> argument is matched against package NEVRAs, provides and file provides.
<package-file-spec> is similar to <package-spec>, except provides matching is not performed. Therefore, <package-file-spec> is matched only against NEVRAs and file provides.
<package-name-spec> is matched against NEVRAs only.
Package specification supports the same glob pattern matching that shell does, in all three above mentioned packages it matches against (NEVRAs, provides and file provides).
The following patterns are supported:
When matching against NEVRAs, partial matching is supported. DNF tries to match the spec against the following list of NEVRA forms (in decreasing order of priority):
Note that name can in general contain dashes (e.g. package-with-dashes).
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.
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.
Some commands (autoremove, install, remove and repoquery) also have aliases with suffixes -n, -na and -nevra that allow to explicitly specify how to parse the arguments:
<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.
<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).
<module-spec> allows one to select modules or profiles a particular operation should work on.
It is in the form of NAME:STREAM:VERSION:CONTEXT:ARCH/PROFILE and supported partial forms are the following:
In case stream is not specified, the enabled or the default stream is used, in this order. In case profile is not specified, the system default profile or the 'default' profile is used.
<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 offset-th transaction preceding the most recent transaction.
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. Packages can be filtered out by either Exclude Filtering or Modular 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.
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
Please see the modularity documentation for details on how Modular Filtering works.
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. 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.
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. 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.
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.
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 additional suffix to the origin name. Which file should maintain the true name after transaction is not controlled by package manager but is specified by each package itself, following packaging guideline.
See AUTHORS in DNF source distribution.
2012-2021, Red Hat, Licensed under GPLv2+
| March 1, 2021 | 4.5.2 |