Bug 1669950

We believed that the problem is caused by rebase of libmodulemd.

I could not downgrade libmodulemd, because rpm complained of python3-libmodulemd needing libmodulemd-2.7.  But in koji, I found that there was an additional package in the libmodulemd-2.7 build, libmodulemd1-1.8.2-1.fc28.x86_64.rpm.  I downloaded that package, and installed it with rpm, and dnf is working again.  It seems there might be a missing dependency, since this didn't automatically install with the upgrade to libmodulemd-2.7.

https://koji.fedoraproject.org/koji/packageinfo?packageID=24950

dnf was completely unusable until I did this.

Thanks for opening the ticket.

Edit:  It is libmodulemd 2.1, not libmodulemd 2.7 in my comment above.

Problem appears to be upgrade path.  I think the intent was 
libmodulemd-1.7.0-1.fc28  =>  libmodulemd1-1.8.2-1.fc28

but instead 'dnf update' does
libmodulemd-1.7.0-1.fc28  =>  libmodulemd-2.1.0-1.fc28

instead.  Digging in libmodulemd.spec, it includes:

%package -n libmodulemd1
Summary: Compatibility package for libmodulemd 1.x
Obsoletes: libmodulemd < 2
Provides: libmodulemd = %{libmodulemd_v1_version}-%{release}
Provides: libmodulemd%{?_isa} = %{libmodulemd_v1_version}-%{release}

So, for some reason, dnf isn't respecting the 
Obsoletes: libmodulemd < 2

For giggles, this appears to get dnf closer to the right thing:

$ sudo dnf update --exclude=libmodulemd
...
Dependencies resolved.
=========================================================================
 Package          Arch       Version           Repository           Size
=========================================================================
Installing dependencies:
 libmodulemd1     x86_64     1.8.2-1.fc28      updates-testing     174 k
     replacing  libmodulemd.x86_64 1.7.0-1.fc28

This is once again https://github.com/openSUSE/libsolv/issues/146 that libsolv upstream refuses to fix.

Regardless of which packages dnf chooses to auto-update, we should also
add necessary Required/Conflicts tags in case the user tries to install
libmodulemd-2.1 manually (without also installing libmodulemd1-1.7).

I'm not an expert on the SPEC format, but it seems what we want to do
is:

1. In dnf.spec, change

Requires:       libmodulemd >= %{libmodulemd_version}

to

Requires:       (libmodulemd1 >= %{libmodulemd_version} or (libmodulemd >= %{libmodulemd_version} and libmodulemd < 2))

and bump the version to dnf-2.7.5-XX.

2. In libmodulemd.spec, add

Conflicts: dnf < 2.7.5-XX

I'm not sure dnf will auto-update libmodulemd -> libmodulemd1 however
(based on the issue Kevin posted, it probably won't), so if security
updates only go to libmodulemd1, that could be bad for the user as he
won't receive those updates.

Andrew

The solution from comment 7 only solves the issue after upgrade of dnf, therefore not correct one. The change should be handled from libmodulemd side.

Handling of obsoletes:

The question here is what is the best candidate. If package is obsoleted then the best candidate is obsoleting package. If original package has an upgrade that is not obsoleted, then the best candidate is a package with highest version.

I am not sure but what about to use so name bump for libmodulemd-2.1? Or conflict in libmodulemd with dnf could also help?

The upgrade to 2.0 was probably unwise for Fedora 28. It has been unpushed from Fedora 28 updates-testing and I'm looking at shipping only 1.8.2 in that release. I'll test it thoroughly before submitting it again.

I do want to note, however, that libdnf in Fedora 29+ needs to be depending on libmodulemd1[-devel] explicitly until the code is ported to the new API.

I plan to drop the libmodulemd1 compatibility package before Beta Freeze of Fedora 31, so please account for that in planning. Six months should be plenty of time to migrate.

> The solution from comment 7 only solves the issue after upgrade of
> dnf, therefore not correct one.

Actually, it is a complete solution. The "Conflicts: dnf < 2.7.5-XX"
change to libmodulemd-2.1 ensures you can't install libmodulemd-2.1
unless you either upgrade to the fixed version of dnf (the one that
wants libmodulemd < 2 or libmodulemd1), or remove dnf completely.

And now that I think about it, there is no security issue either, since
the libmodulemd-1.7 -> libmodulemd-2.1 is automatic -- meaning the user
will no longer have the obsolete libmodulemd-1.7 package on his system
after running "dnf update".

> The upgrade to 2.0 was probably unwise for Fedora 28. It has been
> unpushed from Fedora 28 updates-testing and I'm looking at shipping
> only 1.8.2 in that release.

That works, too.

libmodulemd-2.1.0-1.fc28.1 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-1e79a2acad

libmodulemd-2.1.0-1.fc28.1 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.