Would PackageKit or any of the other libdnf consumers need to be rebased as well? Would they need to be rebuilt against the updated libdnf? I'm curious how broad of an impact across the Fedora package set this would be.

In general, I support this. I just want to make sure it's coordinated well.

PackageKit would need some minor code changes and rebuilt against new libdnf, but that should be very simple to do.

I agree with @jwboyer that it should be coordinated. we should make sure that packagekit and anything else needing adjustment has it and has builds in the one update. Overall I am in favour of allowing this in.

This seems like the kind of update that Fedora usually doesn't allow in stable releases.

What is changed in dnf 3, compared to current dnf 2? Does dnf 3 have the new yumdb replacement? Are users automatically converted to the new db? The implication here is that anyone who has run dnf 3 will be unable to run dnf 2 afterwards as their db is going to be incompatible (updated to new format). Are existing dnf 2 plugins compatible with dnf 3?

This really needs a Change page with carefully thought out fallback plan and devel list discussion etc.

I'm not part of the main DNF development team, but I do maintain the DNF stack in Mageia; openSUSE; and OpenMandriva, and do contribute upstream and track it closely, so I can answer some of these questions.

What is changed in dnf 3, compared to current dnf 2?

A lot. :sweat_smile:

At the core of it is that a huge chunk of the logic in the DNF stack has been deduplicated and pushed into libdnf in C++. The library is also undergoing a transition from glib2-C to standard C++ and has dropped GObject Introspection for SWIG.

Does dnf 3 have the new yumdb replacement? Are users automatically converted to the new db?

Yes it does. The SWDB (not the greatest name in the world...), as it's called, replaces the historical DNF YumDB. The current code forces the migration to SWDB.

The implication here is that anyone who has run dnf 3 will be unable to run dnf 2 afterwards as their db is going to be incompatible (updated to new format).

Unfortunately, yes. It might be possible to revert the SWDB changes, but they're quite invasive. I don't know if it'd even be reasonably feasible to restore the dual YumDB/SWDB mode.

Are existing dnf 2 plugins compatible with dnf 3?

So far, mostly. The main APIs that changed are related to DB access, which don't really affect most plugins, but it does affect dnfdaemon, since it accesses that information.

The implication here is that anyone who has run dnf 3 will be unable to run dnf 2 afterwards as their db is going to be incompatible (updated to new format).

Downgrade from dnf-3.0 to dnf-2.x will be possible, but the new history entries created from dnf-3 will be invisible to dnf-2.x. And via reversa, if dnf-2.x is upgraded again to dnf-3.0, dnf-3.0 don't see any history created by downgraded dnf-2.x. But even missing parts of history has limited impact on dnf functionality and user experiences.

In general, I support this. I just want to make sure it's coordinated well.

The release of dnf-3.0 will be coordinated with maintainers of PackageKit, rpm-ostree, microdnf, yumex-dnf.

@jmracek, yumex-dnf is gone, replaced by dnfdragora.

This was discussed in the FESCo meeting on 2018-04-20:
AGREED: FESCo requires this to be working in Rawhide first and the Bodhi update containing the rebase must not go to stable without a FESCo +5 vote (+1:7, -1:0, +1:0)

I don't think there's anything else for FESCo to decide now. Let's get this changes underway in Rawhide, and involve the maintainers of PackageKit, rpm-ostree, microdnf, dnfdragora.