2:31 p.m.
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
2:34 p.m.
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/cb07ce2c82385a186245f1c6dbef0c...
2:49 p.m.
This backwards incompatible update fixes accepted F30 blocker [0], so we
probably can't just revert this one.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1688462
3:45 p.m.
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.
4:49 p.m.
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/releas...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5:11 p.m.
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/releas...
I filed issues about this:
https://github.com/rpm-software-management/libdnf/issues/719
https://github.com/rpm-software-management/libdnf/issues/720
1823
days inactive
1823
days old
infrastructure@lists.fedoraproject.org
5 comments
4 participants
participants (4)
-
Adam Williamson -
Frantisek Zatloukal -
Randy Barlow -
Zbigniew Jędrzejewski-Szmek