A lot has been said on fedora-devel in the last few weeks about DNF and Yum. I thought it might be useful to contribute my own views, considering I’ve spent the last half-decade consuming the internal Yum API and the last couple of years helping to design the replacement with about half a dozen of the packaging team here at Red Hat. I’m also a person who unsuccessfully tried to replace Yum completely with Zif in fedora a few years ago, so I know quite a bit about packaging systems and metadata parsing.
From my point of view, the hawkey depsolving library that DNF is designed upon is well designed, optimised and itself built on a successful low-level SAT library that SUSE has been using for years on production level workloads. The downloading and metadata parsing component used by DNF, librepo, is also well designed and complements the hawkey API nicely.
Rather than use the DNF framework directly, PackageKit uses librepo and hawkey to share 80% of the mechanism between PK and DNF. From what I’ve seen of the DNF codebase it’s nice, with unit tests and lots of the older compatibility cruft removed and the only reason it’s not used in PK was that the daemon is written in C and didn’t want to marshal everything via python for latency reasons.
So, from my point of view, DNF is a new command line tool built on 3 new libraries. It’s history may be of a fork from yum, but it resembles more of a 2014 rebuilt American hot-rod with all new motor-sport parts apart from the 1965 modified and strengthened chassis. Renaming DNF to Yum2 would be entirely the wrong message; it’s a new project with a new team and new goals.
The big problem I have with DNF is the name. It’s going to require people to relearn a command that has history back to Fedora Core 1! Yum *IS* Fedora. Why not just call dnf Yum 4.0 since it’s largely a drop in replacement. Also, DNF doesn’t even mean anything. When people ask, why is it called DNF there isn’t a good answer.
Changing the name of the tool you use to install packages from ‘yum’ to ‘dnf’ is going to do nothing but confuse people unncessarily.
I agree the name sucks; but calling it yum is going to confuse people when they try to use the python API and it’s completely different.
Yet the example of Bind9 using a complete different API from Bind8 discussed on Fedora development mailing list shows there is less confusion because of the documented changes. Another historical example was GCC and EGCS where the latter was in fact renamed GCC with full support of FSF who dropped the original GCC 2.x.
I don’t know for sure, but I don’t think the people still maintaining Yum don’t want DNF to become-and-replace Yum.
I’d name it up3date.
@hughsie, one can very well communicate the API change without changing the command line name. Besides, the dnf team wants to have a compatibility wrapper for a while anyway, so the current plan is the worst of both worlds.
From someone that consumes the yum API, my judgement would be that’s it’s impossible to write a compatibility shim for yumBase. It’s just full of complexity and odd quirks.
You misunderstood me. I wasn’t suggesting any compatibility wrapper for the API. If you read the plan in full proposed by dnf developers, it includes a wrapper for yum just for the command line. I am just pointing out the impact of that.
Given how Fedora changed the init system, that comes from the early days of Unix, with a completely different beast, systemd, I don’t understand the problem of changing a CL tool by another CL that does basically the same.
Go ahead and forget yum as we forgot init.d shell scripts
The end user likely doesn’t care about API compatibility. Regardless, that’s why http://www.semver.org is common place.
“Given a version number MAJOR.MINOR.PATCH, increment the:
1. MAJOR version when you make incompatible API changes,”