All posts by Jan Šilhan

New DNF Project Leader

I’d like to announce new team leader of DNF project as I decided to accept new challenges in a different environment.

From May 1 Daniel Mach will be officially new team lead of the project. He came from release engineer background and has been consumer of DNF for a long time. Because of  his knowledge of the ecosystem and ability to push things forward I believe he will fit into this role well.

I will still keep an eye on the project but now more like its user and occasional contributor. Thank you all who cooperated to make DNF better.


DNF 2.0.0 and DNF-PLUGINS-CORE 1.0.0 release candidate released in Fedora rawhide

DNF-2.0 is available for testing! The next major version release of DNF brings many user experience improvements such as more understandable dependency problem reporting messages, weak dependencies shown in transaction summary, more intuitive help usage invoking and others. Repoquery plugin has been moved into DNF itself. Whole DNF stack release fixes over 60 bugs. DNF-2.0 release is focused on getting rid of yum incompatibilities i.e. treat yum configuration options the same (`include`, `includepkgs` and `exclude`). Unfortunately this release is not fully compatible with DNF-1. See the list of DNF-1 and DNF-2 incompatible changes and prepare for the upcoming official release. Especially plugins will need to be changed to the new DNF argument parser. For complete list of changes see DNF and plugins release notes.

Fresh DNF for RHEL 7 and CentOS 7

DNF is in EPEL for more than one year, unfortunately there was still the old DNF-0.6.4 version. Over that time in DNF were implemented a lot of great features and plenty of bugs have been fixed. DNF (especially its libraries) could not be updated in EPEL repository because of its policy. Now we have prepared fresh DNF-1.1.9 for RHEL 7 and CentOS 7 users in our COPR repository. Note this is still experimental preview not supported by Red Hat.

In order to get DNF-1.1.9 in RHEL 7 or CentOS 7:Enable EPEL repository for additional DNF dependencies:

# wget
# sudo rpm -Uvh epel-release-latest-7*.rpm

Add DNF stack repository:

# cat <<EOF > /etc/yum.repos.d/dnf-stack-el7.repo
name=Copr repo for dnf-stack-el7 owned by @rpm-software-management

Install DNF:

# yum install dnf

Enjoy the newest DNF ;)

DNF 1.1.9 and DNF-PLUGINS-CORE 0.1.21 Released (preparation for DNF 2.0)

New version of DNF and DNF-PLUGINS-CORE is out. This release is focused on stability and should ease the transition for prepared DNF 2.0. Any call of not documented and so not supported Python methods should print warning. If you see them and you would like the methods to be included into DNF API, please, file an RFE (they will be vanished in DNF 2.0). In plugins the major improvements were made in repoquery – speedup of `- -resolve` and reverse queries on weak deps are working with glob expressions. More information about the release can be found in DNF and plugins release notes.

DNF 1.1.8 and DNF-PLUGINS-CORE 0.1.20 Released

The new version of DNF and DNF-PLUGINS-CORE has been released. It’s a stability release with a bug fixes and user experience, translations and documentation improvements. At this time DNF-PLUGINS-CORE > 0.1.18 is needed to properly connect to COPR repositories,  so please upgrade to the newest plugins to avoid potential COPR network problems. More information about the release can be found in DNF and plugins release notes.

DNF into C initiative started

As you already know, so far DNF has been using a bunch of C libraries (hawkey, librepo, libsolv, libcomps) while yum was written entirely in Python. From now some of the DNF code will be slowly rewritten into C, more precisely, moved into libhif project. The next milestone was reached by merging hawkey into libhif and further we plan to expand libhif to support general functionality of package managers.

Why have we merged hawkey into libhif

Nowadays there are three major consumers of hawkey – DNF, PackageKit and rpm-ostree. The hawkey API was not in final form yet and was changed constantly based on demands from these package managers. We have merged hawkey project inside libhif and hidden some of not yet stable API.

Merging hawkey into libhif was another step to move more code base of DNF into C. DNF will reuse some of the existing code of libhif. Having this shared library can eliminate inconsistencies about installed packages when DNF and PackageKit is used alternately. Moreover we would like to reuse the same metadata for all package managers to save your bandwidth.

Libhif should contain the common functionality for all package managers. So far libhif is providing high level API by taking care of fetching metadata from mirrors, doing dependency solving and executing RPM transaction. In the future it will support repository configuration parsing, GPG checking and so on. At this time, this is handled by all package managers separately.

Facts for Hawkey consumers:

  • libhif-0.7.0 will obsolete hawkey package
  • some of the C hawkey API from libhif will not be exposed anymore, please use libhif functions instead
  • python bindings will not change and the libhif package will still provide python2-hawkey and python3-hawkey
  • API in libhif is still not considered as fully stable yet
  • first release of libhif with hawkey inside is targeted for Fedora 25

Please watch libhif project on github and participate in pull request discussions so you can influence the development.