Hi Pavla,
I noticed today that a backwards incompatible update was pushed to Fedora 29 stable for libdnf[0]. This breaks Bodhi[1], which uses hawkey.Repo which was removed in that version. The update notes did not mention a backwards incompatible API, and in general backwards incompatible updates should not be pushed to stable Fedora versions[2]. This causes problems for Fedora users who may be using your library, but it also causes issues in this case for the Fedora Infrastructure team[3]. Please do not push backwards incompatible updates in the future.
That said, we now need to take some action to solve the problem. Ideally, we would revert the libdnf in Fedora 29 since that update should not have happened. I also noticed the Fedora 30 does not have this version of libdnf (so, Fedora 29 has the backwards incompatible change, but Fedora 30 does not.) This means that users upgrading from Fedora 28 to Fedora 31 will experience 3 backwards breaking changes, instead of just one (which should happen in Fedora 31 only).
Can we revert this change?
[0] https://bodhi.fedoraproject.org/updates/FEDORA-2019-2612a121ba [1] https://github.com/fedora-infra/bodhi/issues/3193 [2] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases [3] https://pagure.io/fedora-infrastructure/issue/7748
Also, I cannot find documentation on the new version of hawkey as distributed with libdnf. Since the change is in Rawhide, I will need to adjust Bodhi's code[0] so that it works with the new version of hawkey.
Can you advise me about what I should use in place of the cited code with the new version of hawkey?
[0] https://github.com/fedora-infra/bodhi/blob/cb07ce2c82385a186245f1c6dbef0c2f2...
This backwards incompatible update fixes accepted F30 blocker [0], so we probably can't just revert this one.
That's a very unfortunate situation. The API change is a clear breakage of the Update guidelines. The version bump that is done in the patch 0.28.1 → 0.29.0 is also wrong, since this number also describes the python API, and changes that remove names need to bump the major number to signal backwards incompatibility.
The least-bad solution would be to add back something in the python API to restore compatibility. Some feedback from the dnf side whether this is possible would be very useful.
On Mon, 2019-04-29 at 20:45 +0000, Zbigniew Jędrzejewski-Szmek wrote:
That's a very unfortunate situation. The API change is a clear breakage of the Update guidelines. The version bump that is done in the patch 0.28.1 → 0.29.0 is also wrong, since this number also describes the python API, and changes that remove names need to bump the major number to signal backwards incompatibility.
The least-bad solution would be to add back something in the python API to restore compatibility. Some feedback from the dnf side whether this is possible would be very useful.
+1 to this whole thread. For the record, and just to be clear, the backwards-incompatible change here was *not* the thing we needed to fix the release-blocking upgrade bug. It just came along for the ride. DNF team's current practice seems to be to not use stable branches, but simply keep all development for libdnf and dnf in a single stream, constantly cut releases of them, and send those releases out as updates to all Fedora versions.
DNF team, *this is not sustainable*. It is clearly leading to problematic violations of the Fedora packaging guidelines like this. Now DNF is in RHEL 8, you are *definitely* going to start hearing about this from RHEL stakeholders, because this is very definitely not how things work on RHEL either.
You must either stop making API-breaking changes or start using stable branches so non-API-breaking fixes can be sent out to stable distros without disruptive changes. It is just not acceptable to tie needed bugfixes to API changes in this way.
I also find it significant that libdnf still has, so far as I can tell, absolutely no interface documentation - https://github.com/rpm-software-management/libdnf links to "the hawkey documentation page", which is obviously wildly outdated at this point - and that this API-breaking change was not even mentioned in the libdnf release notes: https://github.com/rpm-software-management/libdnf/blob/master/docs/release_n...
On Mon, 2019-04-29 at 14:49 -0700, Adam Williamson wrote:
I also find it significant that libdnf still has, so far as I can tell, absolutely no interface documentation - https://github.com/rpm-software-management/libdnf links to "the hawkey documentation page", which is obviously wildly outdated at this point
and that this API-breaking change was not even mentioned in the libdnf release notes: https://github.com/rpm-software-management/libdnf/blob/master/docs/release_n...
I filed issues about this:
https://github.com/rpm-software-management/libdnf/issues/719 https://github.com/rpm-software-management/libdnf/issues/720
infrastructure@lists.fedoraproject.org
-
Adam Williamson -
Frantisek Zatloukal -
Randy Barlow -
Zbigniew Jędrzejewski-Szmek