User: Password:
Subscribe / Log in / New account

Fedora and DNF

This article brought to you by LWN subscribers

Subscribers to made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

July 2, 2014

This article was contributed by Adam Saunders

Fedora has relied on the Yum package manager since its inception, but that won't last much longer. Last month, the Fedora Engineering Steering Committee (FESCo) approved using the DNF package manager by default for Fedora 22. Since I am a Fedora user who mostly manages the installation, updating, and removal of software through Yum on the command line, this upcoming drastic change (albeit one coming nearly a year from now) piqued my interest. With the current version of DNF available in Fedora 20, I decided to investigate DNF to see how well it could replace Yum as default package manager, and how the recent 0.5.2 release and Core DNF Plugins stable release compared to the state of DNF when LWN last looked in on it this past January.

While it was originally released for testing purposes in January 2013 for Fedora 18, DNF development began in 2011. It started a couple of years after Red Hat employee Aleš Kozumplík's work on the Anaconda system installer led him to discover a number of technical quirks with the interaction between the installer and Yum. DNF, which famously doesn't stand for anything, offers a cleaner code base than Yum: in particular, it has an API in the process of stabilizing that will allow developers to write Python plugins to extend its functionality. DNF relies upon two libraries for dependency resolution: hawkey, which provides a Python and C API to libsolv, a library developed by openSUSE for use with its zypper package manager. Libsolv uses a Boolean satisfiability-solving algorithm to resolve dependencies.

When the issue of replacing Yum with DNF came up at the FESCo meeting on June 18, the committee members debated the merits of DNF. The IRC transcript reveals conflicting ideas about how to deal with naming issues; Fedora Project Leader Matthew Miller suggested DNF should be renamed as Yum for Fedora 22, while others debated the merits of users facing a "nag script" to stop using Yum, or automatically running the transaction through DNF when users try to run Yum transactions in Fedora 22. After about 40 minutes of lively discussion, FESCo voted unanimously in favor of using DNF as the default package manger for Fedora 22. However, deciding the details of its implementation, including naming issues, was put off for future meetings.

Controversy about DNF as default dates back to at least this past January, when Harald Reindl raised concerns about missing functionality and system-breaking behavior. Following FESCo's decision, Reindl again raised concerns that some transactions will offer to uninstall core parts of the operating system when certain dependencies are removed. This can include systemd, RPM itself, or the running kernel. That issue is being addressed: Kozumplík suggested the issue could be addressed through a plugin that checks for "protected" packages.

The newly stable Core Plugins package, which is an official project to provide a set of extended functionality to DNF that began in late 2013, offers welcome utility; this will likely go some way toward addressing past complaints of missing features. For example, dnf builddep foo will install needed dependencies based on descriptions in a .spec or .src.rpm file. Users will also welcome the copr plugin, which simplifies managing Copr repositories; Copr provides a system for building unofficial third-party packages for Fedora users, similar to Ubuntu's Personal Package Archive (PPA) feature. Another, non-interactive plugin, generate-completion-cache, speeds up performance by producing data to accelerate command-line completion.

Speed is definitely the most visible improvement for end users familiar with Yum. It was surprising to see how fast DNF resolved dependencies on Fedora 20. For example, DNF resolved dependencies for installing VirtualBox in about 0.5 seconds, while Yum took 2.9 seconds to do so. This speed is probably thanks to libsolv, which will also likely benefit from shared development between the Fedora and openSUSE communities. This speedup alone can be enough to convince one to dnf install foo rather than yum install foo going forward.

DNF's behavior does, of course, differ from Yum, in ways which may surprise veteran Fedora users. For example, DNF doesn't save aborted transactions, while Yum automatically generates a .yumtx file which can be run with yum load-transaction /tmp/filename.yumtx. One of the bigger surprises comes from dnf update, which has completely different output from yum update: it lacks dependency processing information. This is also not a bug, since printing those details would be quite lengthy, as it is with Yum.

The DNF documentation also criticizes the dependency output behavior in Yum for potentially bewildering users if an update turns out to be a sizable transaction. This is not a particularly convincing rationale to me; most users who would be confused by printed dependency resolution output are probably using a graphical front-end like GNOME Software for package management. For those interested in knowing which packages are tied to particular dependencies, the absence of this output may be frustrating, although one can include "-v" with one's transactions to see that output.

DNF and Yum also have different policies for when to schedule metadata updates. This has confused some users in the past. The DNF developers prefer longer periods between metadata updates, largely for resource efficiency; forcing DNF to run a metadata update for a particular transaction can be done by running dnf clean all to clean out the existing metadata before the transaction.

DNF is promising, which probably explains why FESCo approved the still-in-development project for future inclusion as default in Fedora. Its dependency resolution speed makes Yum seem sluggish. That alone may be enough for longtime Yum users to incorporate DNF as part of their package management rhythm. However, certain issues (particularly potential system-breaking through dnf remove foo) have also kept me using Yum, mostly for uninstallation transactions. While DNF does have a number of remaining problems to fix and bugs to squash, the development team does appear to be on top of those issues. I expect that DNF will be a positive (if not universally embraced) change to Fedora's package management system when Fedora 22 is released.

(Log in to post comments)

Fedora and DNF

Posted Jul 3, 2014 3:32 UTC (Thu) by raven667 (subscriber, #5198) [Link]

It seems that to replace yum that dnf should really add all of the features which yum has, or provide a justification as to why that feature doesn't need to be there, even if the feature in yum was originally added without justification, rather than try to quietly walk away from features they don't want to implement. If the feature really isn't a good idea then it should be justifiable to remove it, so asking for written justification shouldn't be too hard.

Fedora and DNF

Posted Jul 3, 2014 10:19 UTC (Thu) by roblucid (subscriber, #48964) [Link]

What are the reasons why Fedora didn't adopt openSUSE's libzypp & libsolv together?

As libzypp has been used for years, the kernel has multiversion support to avoid deleting the running kernel, in zypp.conf :

multiversion = provides:multiversion(kernel)

## Note: This entry is not evaluated by libzypp, but by the
## purge-kernels service (via /sbin/purge-kernels).
## Default: Do not delete any kernels if multiversion = provides:multiversion(kernel) is set
multiversion.kernels = latest,latest-1,running

I actually like to keep the oldest to, specific versions can be kept to, which allows periodic removal if I want a newer version to be the baseline, which handles neatly the (hypothetic) case of a series of slightly broken updates for my hardware.

Fedora and DNF

Posted Jul 3, 2014 12:00 UTC (Thu) by asn (subscriber, #62311) [Link]

Why not simply use zypper? It is the best package manager out there. dnf is nice, but compared to zypper only a small step forward.

Fedora and DNF

Posted Jul 3, 2014 15:50 UTC (Thu) by drag (subscriber, #31333) [Link]

Yum can be symlinked to dnf and almost nobody would notice the difference.

Dnf is effectively 'yum 2.0'. There really isn't any advantage to switching to something like zypper that would require end users changing their scripts around.

Fedora and DNF

Posted Jul 3, 2014 11:39 UTC (Thu) by georgm (subscriber, #19574) [Link]

Is there somehow a way to use a shared package info cache?

When querying for a package as a normal user, all the package info gets downloaded into a per-user temp directory, and this could take some time...

Fedora and DNF

Posted Jul 3, 2014 12:39 UTC (Thu) by johannbg (subscriber, #65743) [Link]

I think people should ask themselves why RHEL felt the need to re-invent the wheel instead of simply use zypper and strengthen it's development as well as the question why the Fedora community was not given the option to choose between DNF and zypper.

Fedora and DNF

Posted Jul 3, 2014 13:41 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Because nobody went to the effort of proposing Zypper?

Fedora and DNF

Posted Jul 3, 2014 14:02 UTC (Thu) by michich (subscriber, #17902) [Link]

There was an effort to package libzypp and zypper for Fedora, but it died out and nobody stepped up to revive it:

Fedora and DNF

Posted Jul 3, 2014 15:50 UTC (Thu) by drag (subscriber, #31333) [Link]

So the answer is: nobody cared.

Fedora and DNF

Posted Jul 4, 2014 16:02 UTC (Fri) by mcatanzaro (subscriber, #93033) [Link]

It now stands for Dandified Yum:

Which is just dandy.

Fedora and DNF

Posted Jul 4, 2014 18:41 UTC (Fri) by smitty_one_each (subscriber, #28989) [Link]

"DNF, which famously doesn't stand for anything"

Don't (K)now Fahrvergnügen?

The name

Posted Jul 14, 2014 16:26 UTC (Mon) by Max.Hyre (guest, #1054) [Link]

Possibly unfortunately, to anyone who follows competition of any sort over a course (Formula One, NASCAR, road rallying, randonneuring, &c.), DNF means 'Did Not Finish'. :-)

Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds