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/
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.
Linux Magazine article: Behind the Scenes at Fedora’s Future Package Manager.
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 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.
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.