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 -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
