Tracker - libdnf breaking API changes

[imcleod]

The DNF developers have warned that they intend to make a breaking API change as part of a rewrite and refactor. This will dramatically simplify their stack but is something that all API consumers will need to adapt to.

I have asked for a public/upstream location where existing API consumers can discuss this and provide feedback for the change. In that spirit, I'm creating an issue here, in the rpm-ostree upstream.

[cgwalters]

Since we use libdnf as a git submodule, it's totally easy for us to adapt to breaking changes on our schedule, and I'd be fine with dealing with some.

[cgwalters]

(A big motivation for us using libdnf as a git submodule is precisely to allow it to evolve, because it's still quite distant from a library that one could imagine being ABI stable)

[dustymabe]

This issue was pointed at during this week's FCOS community meeting as the tracker for experimenting with using the dnf5 version of libdnf.

There is a change proposal for making dnf5 the default for F39.

[cgwalters]

FWIW rpm-software-management/libdnf@d0b8a8b ➡️ https://github.com/rpm-software-management/dnf5

[jmarrero]

@dustymabe for rpm-ostree we are not planning to migrate to dnf5 at the moment. The amount of work to do this vs the benefits, do not make this a priority currently.

[dustymabe]

That's OK. There was an announcement saying that DNF5 is getting delayed to Fedora 41 anyway.