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.
Red Hat Enterprise Linux
Newsletters and articles of interest
Page editor: Rebecca Sobol
Next page: Development>>
Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds