DNF replacing yum

Fedora has been planning to replace the yum package manager for quite some time. The designated replacement, DNF, is a rewrite that offers several advantages, including faster and better dependency resolution. But users (arguably Linux users in particular) tend to get attached to their tools, so the prospect of switching over all at once can be a hard sell. The Fedora Engineering Steering Committee (FESCo) decided in June 2014 that the switch would finally take place in Fedora 22. Now that Fedora 22 is on the verge of release, though, the practical difficulties involved in changing such a low-level program have bubbled up to the surface again.

On April 1, FESCo member Kevin Fenzi outlined the changes in package management that would arrive in Fedora 22, noting that there had previously been some confusion about the plan. DNF will be installed by default, as will the transitional package dnf-yum, which turns /usr/bin/yum into a script that redirects to dnf. Nevertheless, users can still install yum manually, and the yum package will still be installed if the user installs anything that lists yum as a dependency. In addition, as Jan Silhan added, a migrate plugin has been developed that will migrate the machine's yum history and metadata to DNF.

But there is a bit more to it than that. The Fedora 22 "yum" package will also install dnf-yum as a dependency, and the yum package's executable will be /usr/bin/yum-deprecated (with /usr/bin/yum still just wrapping DNF). Furthermore, running yum will issue a warning message to the user:

    Yum command has been deprecated, use dnf instead.
    See 'man dnf' and 'man yum2dnf' for more information.
    To transfer transaction metadata from yum to DNF, run 'dnf migrate'

Below the warning, it will also notify the user that the yum command entered is being redirected to the corresponding DNF command.

Not everyone embraced this transition plan with enthusiasm, however. In reply to Fenzi, Nico Kadel-Garcia said the plan was "unnecessarily confusing" and that adding hooks for the /etc/alternatives framework would be better than renaming or redirecting binaries and making the two packages forcibly compete with each other. "This approach is old and effective for Java, for /usr/sbin/sendmail, and for numerous other tools. Why would you want to reinvent the wheel and prevent people from having either as needed?"

Jan Zelený argued that /etc/alternatives was meant to choose between active alternative tools, whereas yum is being deprecated and will be phased out. What followed next was a lengthy debate that focused largely on the relative merits of yum and DNF. Bruno Wolff questioned DNF's compatibility with yum (specifically with respect to yum's --skip-broken flag), saying that he would prefer to keep using yum than to undertake the workarounds that are necessary to make DNF behave like yum.

To that, Zelený replied that full compatibility between the two tools had never been promised:

The ensuing discussion made a few viewpoints clear. First, not everyone involved has the same definition of "as compatible as possible." Zelený agreed only that the most common package-management use cases will be covered; some less-frequently-needed yum commands may never be implemented in DNF at all (in the FESCo ticket that deals with the transition plan, Josh Boyer pointed to a number of yum features that the DNF team had no plans to implement). While this is perhaps sensible from an engineering standpoint, others argued that this stance results in mixed messages for the user. As Przemek Klosowski said:

The --skip-broken flag, first brought up in the thread by Wolff, is indicative in many respects of the irritation some users feel about the yum-to-DNF transition, but it has wider implications as well. A yum update operation that used --skip-broken would skip all updates for packages with broken dependencies. DNF skips such broken updates—silently—by default. As several in the thread pointed out, there are ways to get DNF to report the existence of broken packages, such as running dnf check-update after running an update.

To Steve Clark, however, that simply means that DNF requires more work to use. To Vít Ondruch, it means that dnf update is an unreliable command. Moreover, although the DNF team seemed to regard --skip-broken as a kludge used to work around situations that are best avoided in the first place (such as mixing packages from several different repositories or package maintainers pushing broken updates), a number of users found it naive to expect that users will not have to deal with broken packages. Tom Hughes noted that feedback about broken packages from yum is one of the main ways packagers learn about packaging problems.

Zelený capped off the discussion—at least for now—by inviting community members to work on DNF plugins to implement the functionality that they want. Perhaps predictably, that answer did not sit well with everyone who participated in the thread. But regardless of how the masses may feel about the differences between DNF and yum, the long-awaited transition appears to finally be underway.

In some respects, the push to migrate Fedora from yum to DNF even through a transition some will find painful is just the most recent example of a recurring issue for free-software projects. Whether it is a compiler, a compositor, or desktop panel, making a clean break from the past is rarely easy, but sometimes it must be done. This migration may prove to be a contentious one for Fedora, but eventually the distribution will emerge on the other side.