Testing the hawkey backend in Fedora 20

The grand plan is that Fedora is replacing yum with dnf in Fedora 21/22. For a few technical reasons PackageKit isn’t going to be using the python DNF layer, but instead using the main two libraries that DNF is build upon directly, namely hawkey (which in turn uses libsolv) and librepo.

I’ve been working with the hawkey and librepo developers on-and-off for a few months now, and we’ve now got a “hawkey” backend in PackageKit which I’ve been stress-testing every day for the last week or so. Today I released PackageKit 0.8.13 with all the fixes in the hawkey backend that make it, well, actually work correctly.

If you’d like to test out the backend, the procedure is pretty simple. Either wait for PackageKit-0.8.13-1.fc20 to hit updates-testing or manually download all the packages. Make sure you’ve updated to 0.8.13-1, and then install the PackageKit-hawkey subpackage and then remove the PackageKit-yum subpackage. If you don’t know how to do this you probably should stick to the tried and tested yum backend for now :)

Reboot, and then pkcon backend-details should tell you that you’re indeed running with the hawkey backend. The first transaction will take a little time as all the metadata will be downloaded and built into a .solv file, but after that it should be fine. From there, test offline updates, gnome-software and all the new stuff and file bugs with a way to reproduce and a backtrace if anything fails (and grab me on IRC if you can). Known issues is that installing and removing groups is not implemented, but that should only affect the old gpk-application application.

And the most important question… Is hawkey faster than yum? I’ll have to let the early adopters be the judge of that. :)

Published by


Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

4 thoughts on “Testing the hawkey backend in Fedora 20”

    1. Well, that’s an interesting question. It’s faster to depsolve (as we’re using SAT now, rather than the yum-compatible iterative depsolver) but slower to load as we have to load (and sometimes build) the .solv files. As most of the guts in the hawkey backend are just “zif” renamed to “hif” the actual transaction speed should be exactly the same :)

  1. Regarding the question of Hawkey being faster than yum, it may be much more important for someone who needs to recover a system ASAP, and needs that patch yesterday, but for me the guy who runs yum in the background,
    whether it is 15 minutes or 30 minutes, I don’t really care much, unless

    “it is midnight and I want to close the system until tomorrow after work. and patches are being downloaded.”

    I presume both yum and the Hawkey functionality deliver the same software in a flawless manner.

  2. Seems to be faster but still not at the level I would want. If you need more info from me, let me know.

Comments are closed.