Monthly Archives: January 2014

Nightly builds of DNF available

We are glad to announce the launch of continuous integration job for DNF. Each change now starts the bunch of DNF tests on top of upstream versions of hawkey, librepo and libcomps.

It also means that from now nightly builds of DNF and its dependencies are available to you. Download them at will from http://jenkins.cloud.fedoraproject.org/job/DNF/lastSuccessfulBuild/artifact/. To check presence of new builds please follow the RSS channel http://jenkins.cloud.fedoraproject.org/job/DNF/rssAll. You should also be able to use that source as a DNF/yum repository.

edit: Please note that we have moved the CI. Take a look at: http://dnf.baseurl.org/2015/09/21/ci-moved-to-copr/

DNF 0.4.12 Released

We’re happy to announce another patchlevel release today, builds are available in Fedora 20 and Rawhide.

The main reason to release today were some negative reactions about the fastestmirror feature. While measuring pinging latency to different mirrors is a good idea in theory, fastestmirror in practice generally yields worse mirror picks then MirrorManager offers by default. Further, because even measuring the latency takes a couple of seconds, the results of the tests are cached (e.g. /var/cache/dnf/x86_64/20/fastestmirror.cache). The cache is then used for 30 days and then the test is redone. For users who move between different networks (home, office) the cached value is often wrong, pointing to a lot slower mirror then actually available. We thus make fastestmirror configurable starting with 0.4.12, the default being off.

A serious bug was discovered in the erase command that can possibly cause unintended removal of important packages that DNF considers uneeded dependencies. The presented release fixes that.

There’s also two updates to the User’s FAQ. See more in the release notes.

Plugins Are On

The current 0.4.11 release of DNF is the first one to support plugins to some useful degree. We released dnf-plugins-core in Fedora yesterday, containing the two plugins: noroot that blocks any potential RPMDB-transacting operation early for non-root users, thus saving them time and bandwidth, and kickstart that lets one install packages via a kickstart file.

People are already asking how to contribute plugins. The answer is: just build them. Package them on your own for Fedora or however you like. We might try to arrange to have them moved into dnf-plugins-core later. The main criteria would be:

  • The plugin is licensed under GPLv2+
  • The code is in a maintainable state or the contributor agrees to maintaining it.
  • There is a serious interest of at least some users in the provided functionality.
  • The presence of the plugin does not cause worse user experience for the majority of users.

The API is not fully fledged yet. But try to stick to those parts that are, because by using the undocumented calls one is running the risk of having them pulled off from under one’s feet later. Instead consider opening a bugzilla that states the use case of a missing call.

Fedora specific why do we ship plugins separately from the main package? Mostly maintainability/engineering reasons: releasing separately from the main package, with less rigorous documentation, without as much worrying about CLI compatibility, with experimental features coming and going. But also to reduce dependencies of the main package: having the kickstart plugin in the main package for instance would mean a pykickstart dependency (besides the extra dep, pykickstart is not yet py3 ready). Think of DNF in this case as a lib and the plugins as clients.

Edit: We also should point out that some fundamental features (like excluding packages from transactions) should not be done on the plugin level because these features need to be common with other packaging tools such as PackageKit.

DNF 0.4.11 Released

After the Fedora Users Mailing List announcement last month we’re releasing dnf-0.4.11 today. The release fixes many of the bugs from the pile that came in after the announcement.

In another thread on the Development discussions ML, DNF received both critique and praise for the way it treats (or rather does not treat) the kernel package in a special way. Since the topic escalated into emotional arguing very fast (over 110 emails in three days), the team decided to let the situation cool off for some time while looking for a consistent and user-friendly resolution, if any will be needed.

The new release also brings new API features, this time all of them are in one way or the other related to writing plugins. Please come check out the release notes.

Happy packaging in 2014.

DNF 0.4.10 Released

Hello and let us present you the 0.4.10, which brings enhancements to the plugin mechanism and fixes to eleven bugzillas.

The plugins can now use two new hooks triggered after the sack is loaded and when a transaction is finished. Further power of the DNF plugins is going to be in their ability to register their own CLI commands. For instance, work is underway to implement dnf kickstart as a plugin to install packages given by a kickstart file

As usual, the release notes give the full story of enhancements and fixes in this release.

Fedora specific note: unfortunately due to some problems in unrelated packages, the Rawhide build is not available yet. We hope to be able to make one the next week.

“dnf update” and “yum update” produce different output

Seeing many users confused about the difference in the outputs and transactions of running yum update versus dnf update I feel I should explain that this is the expected result and not a bug. One reason is that DNF does not list update candidates as it explores them. More frequently however the reporter means actual difference in the proposed transaction. This is most often because the metadata the two packagers are working with were taken at a different time (DNF has a notoriously looser schedule on metadata updates to save time and bandwidth), and sometimes also because the depsolvers inside are designed to take a different course of action when encountering specific update scenario.

The bottom line is: unless a real update problem occurs (i.e. DNF refuses to update a package that Yum updates) with the same set of metadata (dnf clean all; yum clean all), this is not an issue.