Package managers are such an integral part of a distribution that the idea of replacing one may seem surprising – or even a challenge to the distribution’s identity. Yet that is what Aleš Kozumplík and the other contributors to DNF are preparing to do. With version 0.4.11 just released, DNF is currently available in Fedora 20 and is tentatively scheduled to replace Fedora’s package manager Yum entirely by the end of 2014.

Kozumplík is a Red Hat employee working out of Prague. “I had my first serious open source inside exposure in 2009 when I started to work on Anaconda, the Fedora system installer,” he says. “Anaconda interacts with Yum, of course, so I learned about the general issues with packaging then.”

Gaining experience and wanting to work on something different, Kozumplík began exploring Fedora’s packaging tools in late 2011. Today, DNF is developed full time by Kozumplík and Radek Holý, with contributions from Yum expert Zdeněk Pavlas and university student Jan Šilhan. Other contributors include Michael Schroeder on libsolv, Tomáš Mlčoch on a C library for metadata synchronization and downloads, Richard Hughes on the PackageKit front end, and Jindřich Luža on the library for handling high-level distribution metadata.

The name DNF, as Kozumplík is probably tired of explaining, does not stand for anything. As he explains on the project wiki, “it has no relevant meaning” and is “meant as a project name only.” The sole concern in naming the package manager was the need to avoid a naming conflict with Yum, because in the early stages of development, it often co-exists with its predecessor.

The Problems with Yum

DNF began as a fork of Yum and is meant to address several longstanding problems in Yum, the most pressing of which is dependency resolution and interaction with online repositories.

“There are better dependency solvers out there,” Kozumplík says, speaking about Yum’s capabilities. DNF’s own solution uses SUSE’s libsolv, with hawkey as a C and Python wrapper. Libsolv, he adds, “employs a very solid algorithm to do the resolving. Its other main strength is effective representation of the packaging data in memory. It has a very generic API able to handle many different packaging tasks and situations, which can make it a bit intimidating to start using. That’s where hawkey comes in, with its simplified workflow.”

Another problem with Yum according to Kozumplík is that “the API is not documented. One has to browse the code to find the right means to [write a] call. This in effect means that everything in Yum is considered a public API and that means the maintainers have got their hands twisted behind their backs when trying to refactor or remove unused stuff.” For example, “there is a method in Yum with a typo in its name that nobody can remove or fix for this reason. This makes the maintaining 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.”

Yet another shortcoming of Yum is that it supports only Python for extensions. “Everyone but Python developers has a hard time using it and are calling for a C API,” Kozumplík says. “For instance, PackageKit needs to do packaging in a way that’s guaranteed to be compatible with how DNF does it, and it should be able to without having to spawn a separate DNF process or embed a Python interpreter. That’s why we built hawkey and librepo [a C and Python library for downloading metadata and packages from repositories.]. More C APIs are to come later.”

Other improvements in DNF include a lower memory reduction and less automatic synchronization of metadata with repositories – a process that users often complain “happens too often and takes too much time.”

Asked why he did not simply contribute patches to Yum, Kozumplík explains that “gradual patching was technically hard and politically even harder. At the time I was starting to work, it was just not realistically possible to join the Yum upstream development and have changes of this magnitude submitted. The maintainers were against such changes, and when you compare the two code bases now, you can’t blame them. For starts, DNF is 29k lines of code, having had lots of internals moved out into the underlying C libraries, while Yum is 56k lines of code. DNF is still a branch of Yum of sorts, but for practical reasons (early testing, integration within fedora) we are making our own releases.”

In the end, Kozumplík says, “We had no choice, really,” except to fork.

The Current State of DNF Integration

DNF made its first general appearance in Fedora 18. In Fedora 20, general users are being openly invited to start using DNF instead of Yum.

Behind the scenes, the plan is to increase integration with PackageKit and to expand the API to start importing Yum’s plugins. “We could have ported the plugins already,” Kozumplík explains, “but they’d have to use undocumented methods, which would only bring the same problems Yum is suffering from now. And we don’t like to walk in circles.”

However, the most difficult and most controversial aspect of readying DNF for its upcoming role is implementing all of Yum’s options. “Everything one uses daily in Yum is there in DNF,” Kozumplík says, and the current version supports routine installation and erasure, as well as installing in packaging groups, downgrading packages, upgrading to a specific package version, searching for packages, and viewing active repositories and command history.

By contrast, numerous Yum commands and plugins have yet to find their way into DNF. These include debugging and verbose modes and the ability to enable repos or exclude specific packages or skip broken ones during installation.

These and other unimplemented features are now being considered for inclusion in DNF. “Yum has a set of quirky features that are either partially or fully undocumented, and there are some users in the habit of using them,” Kozumplík says. “What we do is to take these cases one by one and decide whether DNF is or is not the right opportunity to fix them, and we document these decisions meticulously so the users are not in for bad surprises.”

Yet, despite all precautions, some of these decisions are almost inevitably going to be questioned by the Fedora user base. For example, like Yum, DNF includes a feature for removing extra kernels when a new one in installed. This feature prevents the /boot partition of a system from filling up with unnecessary kernels.

However, in the latest version of DNF, if not configured properly, this feature can remove all kernels from a system, including the current one, resulting in an unbootable system. For several days, the issue was a major thread on the Fedora devel list, not just because of the debate about how the feature should be implemented, but also because of the questioning of how such important decisions should be made in Fedora. In the end, the issue faded, more because of a lack of anything new to say than because the concern had been resolved to everybody’s satisfaction.

The concern is probably unjustified – Kozumplík insists that, in the end, “no major feature of Yum will be dropped; otherwise, we would not be able to proceed with replacing it in Fedora.” All the same, the question of how old kernels are removed is unlikely to be the last controversy DNF faces as it moves toward general release. In the end, some users may continue to prefer Yum even after DNF becomes the Fedora default, just as some now use use alternatives to Yum.

Replacing such a major part of Fedora is a large challenge, but it’s one that Kozumplík and the other DNF programmers are bracing to meet. “We try to make DNF as modern and as feature-complete a package manager as possible, given the constraints imposed by Fedora’s legacy – that is, having to be based on RPM and having to give a familiar feel to the Yum users while tackling the problems inherent to Yum. Given these options, there’s no competition to DNF; otherwise, Fedora would use it already,” says Kozumplík.