- Changes in DNF CLI compared to YUM
- Update and Upgrade Commands are the Same
clean_requirements_on_removeon by default
- Excludes and repo excludes apply to all operations
- YUM’s conf directive
dnf provides /bin/<file>does not find any packages on Fedora
skip_if_unavailableenabled by default
overwrite_groupsdropped, comps functions acting as if always disabled
- metalink not recognized in the
dnf history rollbackcheck dropped
- Packages replacement without
- Dependency processing details are not shown in the CLI
dnf providescomplies with the YUM documentation of the command
- Bandwidth limiting
- The usage of Delta RPM files
- Handling .srpm files and non-existent packages
- Promoting package to install to a package that obsoletes it
- Behavior of
- Different prompt after transaction table
- List command shows all repo alternatives
- Changes in DNF plugins compared to YUM plugins
- Changes in DNF plugins compared to YUM utilities
For install command:
--skip-broken option is an alias for
--setopt=strict=0. Both options could be used
with DNF to skip all unavailable packages or packages with broken dependencies given to DNF
without raising an error causing the whole operation to fail. This behavior can be set as default
in dnf.conf file. See strict conf option.
For upgrade command:
The semantics that were supposed to trigger in YUM with
--skip-broken are now set for plain
dnf update as a default. There is no need to use
--skip-broken with the
command. To use only the latest versions of packages in transactions, there is the
command line switch.
dnf update or
dnf upgrade, in all their forms, has the same
effect in DNF, with the latter being preferred. In YUM
yum upgrade was
yum --obsoletes update.
The clean_requirements_on_remove switch is on by default in DNF. It can thus be confusing to compare the “remove” operation results between DNF and YUM as by default DNF is often going to remove more packages.
The YUM version of this command is maintained for legacy reasons only. The user
can just use
dnf provides to find out what package provides a particular file.
An alternative to the YUM
deplist command to find out dependencies of a package
dnf repoquery --deplist using repoquery command.
Alternatively there is a YUM compatibility support where
yum deplist is alias for
dnf repoquery --deplist command
YUM only respects excludes during installs and upgrades. DNF extends this to all
operations, among others erasing and listing. If you e.g. want to see a list of
python-f* packages but not any of the Flask packages, the
following will work:
dnf -x '*flask*' list installed 'python-f*'
include directive name of [main] and Repo configuration is a more logical and better named counterpart of
exclude in DNF.
After UsrMove there’s no
/bin on Fedora systems and no files get installed there,
/bin is only a symlink created by the
filesystem package to point to
/usr/bin. Resolving the symlinks to their real path would only give the
user a false sense that this works, while in fact provides requests using globs
dnf provides /b*/<file>
will fail still (as they do in YUM now). To find what provides a particular binary, use the actual path for binaries on Fedora:
dnf provides /usr/bin/<file>
This config option has been dropped. When DNF sees several groups with the same group ID it merges the groups’ contents together.
To simplify things for the user, DNF uses
metadata_expire for both expiring
metadata and the mirrorlist file (which is a kind of metadata itself).
Done to simplify the configuration. Users will typically want to decide what packages to install per-group and not via a global setting:
dnf group install with-optional Editors
Dropping this config option with blurry semantics simplifies the
configuration. DNF behaves as if this was disabled. If the user wanted to
upgrade everything to the latest version she’d simply use
Since DNF tolerates the use of other package managers, it is possible that not
all changes to the RPMDB are stored in the history of transactions. Therefore, DNF
does not fail if such a situation is encountered and thus the
is not needed anymore.
Time after time one needs to remove an installed package and replace it with a different one, providing the same capabilities while other packages depending on these capabilities stay installed. Without (transiently) breaking consistency of the package database this can be done by performing the remove and the install in one transaction. The common way to set up such a transaction in DNF is to use
dnf shell or use the
E.g. say you want to replace
P) with B (also providing
P, conflicting with
A) without deleting
C (which requires
P) in the process. Use:
dnf --allowerasing install B
This command is equal to
yum swap A B.
DNF provides swap command but only
dnf swap A B syntax is supported
During its depsolving phase, YUM outputs lines similar to:
---> Package rubygem-rhc.noarch 0:1.16.9-1.fc19 will be an update --> Processing Dependency: rubygem-net-ssh-multi >= 1.2.0 for package: rubygem-rhc-1.16.9-1.fc19.noarch
DNF does not output information like this. The technical reason is that depsolver below DNF always considers all dependencies for update candidates and the output would be very long. Secondly, even in YUM this output gets confusing very quickly especially for large transactions and so does more harm than good.
See the the related Fedora bug 1044999.
When one executes:
yum provides sandbox
YUM applies extra heuristics to determine what the user meant by
sandbox, for instance it sequentially prepends entries from the
PATH environment variable to it to see if it matches a file provided by some package. This is an undocumented behavior that DNF does not emulate. Just typically use:
dnf provides /usr/bin/sandbox
dnf provides '*/sandbox'
to obtain similar results.
This switch has been dropped. It is not documented for YUM and of questionable use (all plugins are enabled by default).
DNF supports the
bandwidth options familiar from YUM.
Contrary to YUM, when multiple downloads run simultaneously the total
downloading speed is throttled. This was not possible in YUM since
downloaders ran in different processes.
Compared to YUM, DNF appends list values from the
installonlypkgs config option to DNF defaults, where YUM overwrites the defaults by option values.
deltarpm option controls whether delta RPM files are used. Compared to YUM, DNF does not support
deltarpm_percentage and instead chooses some optimal value of DRPM/RPM ratio to decide whether using deltarpm makes sense in the given case.
DNF will terminate early with an error if a command is executed requesting an installing operation on a local
$ dnf install fdn-0.4.17-1.fc20.src.rpm tour-4-6.noarch.rpm Error: Will not install a source rpm package (fdn-0.4.17-1.fc20.src).
The same applies for package specifications that do not match any available package.
YUM will only issue a warning in this case and continue installing the “tour” package. The rationale behind the result in DNF is that a program should terminate with an error if it can not fulfill the CLI command in its entirety.
DNF will not magically replace a request for installing package
X to installing package
X. YUM does this if its
obsoletes config option is enabled but the behavior is not properly documented and can be harmful.
See the the related Fedora bug 1096506 and guidelines for renaming and obsoleting packages in Fedora.
DNF offers more predictable behavior of installroot. DNF handles the path differently
--config command-line option, where this path is always related to the host
system (YUM combines this path with installroot). Reposdir is also handled slightly
differently, if one path of the reposdirs exists inside of installroot, then
repos are strictly taken from installroot (YUM tests each path from reposdir
separately and use installroot path if existed). See the detailed description for
DNF doesn’t provide download functionality after displaying transaction table. It only asks user whether to continue with transaction or not. If one wants to download packages, they can use the ‘download’ command.
|Original YUM tool||DNF command/option||Package|
Plugins that have not been ported yet:
Feel free to file an RFE for missing functionality if you need it.
All ported YUM tools are now implemented as DNF plugins.
|Original YUM tool||New DNF command||Package|
||dnf list installed||
||dnf list, dnf repoquery||
||dnf download –resolve –alldeps||
Detailed table for
DNF does not have a direct replacement of yum-updateonboot command.
However, the similar result can be achieved by
dnf automatic command (see DNF Automatic).
You can either use the shortcut:
$ systemctl enable dnf-automatic-install.timer && systemctl start dnf-automatic-install.timer
apply_updates option of
/etc/dnf/automatic.conf to True and use generic timer unit:
$ systemctl enable dnf-automatic.timer && systemctl start dnf-automatic.timer
The timer in both cases is activated 1 hour after the system was booted up and then repetitively once every 24 hours. There is also a random delay on these timers set to 5 minutes. These values can be tweaked via
dnf-automatic*.timer config files located in the