#1883 Request for rebase of libdnf/dnf after Fedora 28 GA
Closed 3 years ago Opened 3 years ago by jmracek.

Justification:
When a user installs modular Fedora 28 Server, upgrades performed by PackageKit break package set. DNF team works on changing libdnf to provide a package filtering according to enabled modules for PackageKit. PackageKit will be still unable to install modules, but upgrades will not break anything.

We consider this a huge change, that's why we avoided rebasing the dnf stack right before the GA release. We propose to push it to updates-testing for 2 weeks at minimum or keep it there for longer time until it's considered stable.

DNF team originally planned the rebase for Fedora 29, but if PackageKit in modular F28 Server should be fixed, we don't see any other option than to do the rebase in Fedora 28.

Content of rebase:
Basic support of modularity in libdnf (package filtering according to enabled and default modules)
New software (history) database
Bug-fixes and development for about 6 months
New C++ objects
Performance improvements

DNF team would like to avoid backporting changes to stable libdnf-0.11.x, because the upstream version contains many enablers for modularity features mixed with performance improvements and code cleanup. The backport would be very difficult and time consuming.


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.

Metadata Update from @maxamillion:
- Issue tagged with: meeting

3 years ago

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.

Metadata Update from @bowlofeggs:
- Issue untagged with: meeting

3 years ago

Metadata Update from @zbyszek:
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata