Hi Jan,
On Fri Apr 26, 2024 at 08:46 +0200, Jan Kolarik wrote:
Hi Maxwell,
This contains an update to dnf 5.2.0 which has breaking API changes. I did
> not
> see these communicated anywhere and the Change Proposal did not mention
> that
> the update would include a major version bump at the same time as the
> switch to
> dnf5 as default.
>
You're right; we missed this. I'm sorry about that. Our initial intention
wasn't to do a major version bump, but implementing the new functionality
without breaking ABI and API would have required a lot of extra work.
That makes sense. I'm sorry if I was a bit harsh here.
Would it be possible to provide a testing Copr ...
>
Sure, as mentioned earlier, there's a dnf5-testing COPR specifically for
these purposes:
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-testing.
It looks like the packages in that Copr Obsolete dnf4, while I want to
keep using dnf4 on my f39 machine. I built my own dnf5 package without
the dnf5_obsoletes_dnf bcond locally, but it'd be nice to have pre-built
RPMs for that.
... and a porting guide so API users can fix their software
> before this is pushed to rawhide?
>
We'll add a section about the API changes between dnf5 versions 5.1 and
5.2, and we'll reach out to the several teams affected by this.
That would be great! It looks like work on this has started in
https://github.com/rpm-software-management/dnf5/pull/1456. Thank you.
We'll also ensure that the builds for our reverse dependencies
are
passing with this update. We definitely don't want to push this before
these projects are fixed.
Still, I hope no harm has been done yet. That's actually the
purpose of
this side-tag, to identify any gaps we may have missed while working on the
switch. The 5.2.0.0 API changes aren't significant, there are though many
ABI-breaking changes.
Yeah, as long as we make sure everything is ported before the side tag
is merged, we should be good to go.
I saw some patches for dnf 5.2.0 compatibility in ansible upstream, so
we may just need to backport those. As for fedrq, I have a WIP patch to
add compatibility for dnf 5.2.0. The only thing I have not been able to
figure out is [1]. I assume stable Fedoras will keep dnf 5.1.0, so the
plan is to maintain compatibility with those for now so users can still
opt in to the libdnf5 backend.
[1]
https://github.com/rpm-software-management/dnf5/issues/1450.
Thanks,
Maxwell