0.4.3 also brings back support for
group info and
group remove commands. The official release notes have been published.
Let’s say a few words about using a precise version
Requires: in an RPM spec, in Fedora. DNF currently uses few libraries that are new, that are developing violently and that unfortunately change their API now and then. I maintain one of them (hawkey) and know what it is like a for a new lib to commit to a certain API from the start and so didn’t require that from libcomps nor librepo. To have some control however over what version DNF is using, because after all if the API changes and new library is released into Fedora repositories, the users will experience and report the strangest bugs, the spec contained lines like:
Requires: python-librepo = 0.1.2
The deal was that the librepo maintainer (and others) would let me know when he’s about to do a new Fedora build, we’d update DNF to use the API at the desired librepo version and do a build in a lock-step with librepo.
There are several drawbacks to this which together render the whole approach unworkable. Most of them have to do with buildroots in a branched Fedora, where only packages tagged stable or put into a “buildroot override” can be built against. This slows down the builds as e.g. putting a new librepo into the buildroot override does not happen instantly.
Even worse can be the situation in the rawhide Fedora. If a packager of a required library suddenly decides to make a new build without cooperating with the DNF team, the koji builder won’t stop him. It just considers the last built version the current and starts sending emails around that DNF has broken dependencies as it depends on a version that is no longer current. And we receive bugs.
The new arrangement is the same as for most packages: have some minimal dependency version and require a version greater or equal that. While it is promising to make our life easier, it will occasionally break things for the user. In part, this exposes how imperfect the current Fedora build and update policies are, and in part it supports two concepts that we so often fight against in packaging: support for multiple parallel versions in a distribution and app bundling.