What or Why DNF?

DNF or Dandified YUM is the next generation version of yum. 

DNF is a software package manager that installs, updates, and removes packages on RPM-based Linux distributions. It automatically computes dependencies and determines the actions required to install packages. DNF also makes it easier to maintain groups of machines, eliminating the need to manually update each one using rpm. Introduced in Fedora 18, it has been the default package manager since Fedora 22. So, in this post I’m not going to discuss the usage of DNF rather on why and advantages of using it. By default, DNF comes pre-installed on RHEL8.x releases. The "yum" command is a symbolic link to the "dnf" binary now.

What are the features of DNF?

• Multiple repositories/group support & Simple configuration.

• Mathematically correct and faster method for solving dependency resolution.

• Consumes less memory when compared to YUM.

• RPM-consistent behavior.

• In-built modularity support.

• A “clean”, well documented Python API with C bindings & Python 3 support.

• C bindings for lower-level libraries ( hawkey for package querying and depsolving and librepo for repo operations ).

Why do we need DNF when YUM can do the task? 

To fulfil some of the shortcomings of YUM, we need DNF.

[1] Dependency resolution and interaction with online repositories.

YUM uses its own, iterative dependency-resolution mechanism. More recent (and better performing) schemes for doing dependency resolution exist, and one, in the form of the satisfiability solving library libsolv, has been adopted by several other projects (including, of course, libsolv's origin: openSUSE's zypper package manager).

[2]  YUM’s API is not documented.

Another problem with Yum according to Kozumplík (one of the full-time developers of DNF) is that "the API is not documented. One has to browse the code to find the right means to [write a] call. This makes the maintenance and testing difficult, and building new features is slow. DNF is doing a much better job here by documenting the API, keeping it slim and well-specified”.

[3] Yet another shortcoming of YUM is that it supports only Python for extensions. DNF supports Python API and C libraries as well.

[4] Other improvements in DNF include a lower memory reduction and less automatic synchronization of metadata with repositories.

*Some of the noted functional/technical differences between DNF and YUM.

[!] Multiple DNF commands can be executed while YUM doesn't allow running another YUM transaction when one is already running.

[!] the command "yum remove kernel" would not remove the running kernel unless that is the only kernel installed. However, the command "dnf remove kernel" would also remove the running kernel if there are no older kernels installed. In RHEL8 the kernel RPM is a meta package that does not contain any files, but rather ensures that it contains the sub-packages such as kernel-core, kernel-module and kernel-modules-extra. So, ideally the "kernel-core" is the main package here.

[!] DNF does not store an unfinished transaction to /tmp/yum_save_tx.xx.xx.xx as YUM does. The issue is documented on Bug 1807446. Current ETA for storing a successful transaction e.g. on a staging system and reproducing the same transaction on a production system is RHEL 8.4.

[!] DNF does not have an equivalent of "yum history new". The command "yum history new" clears transaction history in RHEL7.x and earlier versions. This command creates a backup of the current history database, then deletes the database and creates a fresh and empty new one. Reference: https://access.redhat.com/solutions/4500331

As a workaround, remove the below files manually:

# rm -r /var/lib/dnf/history*

[!] DNF provides a modularity framework using which users would be able to make 2 version of software to live, and switch from one to another easily without much complications. 

[!] The log files of DNF are stored separately for hawkey, librepo and dnf now. These files could be found under /var/log/ folder. 

Important points to be remembered while using DNF.

→ Always review command help/man page before executing any commands and get a clear understanding about what is being done. A short help/man page is available for every subcommand of DNF. For example, to get more help on usage of DNF history, run the command “dnf history --help”.

→ Try to avoid the usage of ‘automatic yes’ ( y ) answer parameter with any of the DNF commands unless required or understood.

→ Many optional arguments are common to any DNF commands such as 

--downloadonly, --nogpgcheck, --quiet etc, which could be applied to any commands as required. 

→  The commands ‘dnf update’ & ‘dnf upgrade’ are the same.

→ The command "package-cleanup --oldkernels" has been replaced with "dnf remove --oldinstallonly" command which is the preferred method to remove old kernels.

→ Change in the way “install” command works. 

This would perform the below tasks:

• Install the latest package available in the provided repository. 

• If an earlier version of the package is already installed then it would automatically update it to the latest one available. This is because of the option “best=True” which gets set by default in the /etc/dnf/dnf.conf file.

*at the time of writing and this could change later down the time.

References:

https://rpm.org/index.html

https://dnf.readthedocs.io/en/latest/

https://en.wikipedia.org/wiki/Yum_(software)

https://www.linux-magazine.com/Issues/2014/160/DNF