What Is DNF Package Manager And How To Use It

​A package file is an archive which contains the binaries and other resources that make software and the pre and post installation scripts. They also provide the information regarding dependencies and other packages required for the installation and running of the software.

 In the Linux world, there are two main types of packaging formats, .deb for those in the Debian and Ubuntu world and the .rpm for the Fedora, RHEL and CentOS. These formats also have their own tools for package management. The .debs use apt or aptitude and dpkg while the .rpms have been using YUM, at least until recently. Fedora recently replaced YUM with their new package manager, DNF. Yup, they built from the ground up a new package manager, the Dandified YUM (DNF), to replace it. ​

​RPM packages will not install unless the prerequisites are installed first so YUM performed the dependency analysis and installed pre-requisites before installing the package. So the people at Fedora developed DNF as a successor or next generation version of YUM. DNF does all of these and supposedly more. DNF stands for nothing in particular. Or it stands for Dandified YUM. DNF was first introduced in Fedora 18 and replaced YUM completely in Fedora 22.

Why was DNF needed in the first place? What are the shortcomings of yum that required a whole new package? The few of them are listed below –

• An undocumented API for YUM
• Fedora switch to Python 3 which YUM does not support
• A broken dependency solving algorithm
• Difficulty in building new features
• Inability to extend it other than with Python

Basically, all they are saying is yum was just too outdated for the demands of Fedora in these times.

​But then still, others ask why didn’t they just go for something like zif or SUSE’s Zypper just adopted since a similar algorithm is employed in DNF? The following were presented –

• DNF looks for a middle ground between a sane API and some backward compatibility.
• DNF and Hawkey are first steps toward using the same resolver across the entire stack.
• Libsolv is a well tested and proven code base, currently the most sophisticated and optimized dependency solving implementation.

The key components of DNF are:Libsolv – A free package dependency solver using a satisfiability algorithm for solving packages and reading repositories
Hawkey – High-level API for the libsolv library. Hawkey, a library providing simplified C and Python API to libsolv.
Librepo – A library providing C and Python (libcURL like) API for downloading Linux repository metadata and packages
Libcomps – Libcomps is alternative for yum.comps library. It’s written in pure C as a library and there are bindings for python 2 and python 3.

​DNF comes with a simplified code with about 29000 lines of code compared to over 59000 in YUM. The following features of DNF have been mentioned.

• Support for multiple repositories
• Simple configuration
• Dependency calculation based on modern depsolving technology
• Faster and less memory-intensive operation
• RPM-consistent behavior
• Package group support, including multiple-repository groups
• Simple interface
• Documented, solid Python API
• DNF runs in both Python 2 and Python 3
• C bindings for lower level libraries:
• Hawkey for package querying and depsolving. PackageKit is already making use of Hawkey
• librepo for repo operations. PackageKit is already making use of librepo
• libcomps for comps operations

These few commands are to show you that there is not much difference between DNF and YUM. For more commands, you can see the DNF wiki page.

​Everything works basically just the same. The only issue now is your muscle memory. For a power user, if you happen to enter YUM instead of DNF, there will be a warning prompt informing you that you have to use dnf instead. Whether DNF is in the right direction or not, it is here to stay. Hopefully, it will replace YUM altogether. Share your thoughts with us in the comments.