Description of problem: Updating to the latest libmodulemd from updates-testing (libmodulemd-2.1.0) causes "dnf update" to break with the error "ValueError: Namespace Modulemd not available for version 1.0". Downgrading to libmodulemd-1.7.0 fixes the problem. Version-Release number of selected component (if applicable): * libmodulemd-2.1.0-1.fc28.x86_64 * dnf-2.7.5-12.fc28.noarch How reproducible: * 100% (Updating to 2.1.0 always breaks dnf; downgrading to 1.7.0 always fixes dnf.) Steps to Reproduce: 1. Enable updates-testing: $ dnf config-manager --set-enabled updates-testing 2. Update libmodulemd $ dnf update libmodulemd 3. Run dnf $ dnf --version Actual results: $ dnf --version Traceback (most recent call last): File "/usr/bin/dnf", line 57, in <module> from dnf.cli import main File "/usr/lib/python3.6/site-packages/dnf/__init__.py", line 31, in <module> import dnf.base File "/usr/lib/python3.6/site-packages/dnf/base.py", line 30, in <module> from dnf.module.metadata_loader import ModuleMetadataLoader File "/usr/lib/python3.6/site-packages/dnf/module/metadata_loader.py", line 25, in <module> gi.require_version('Modulemd', '1.0') File "/usr/lib64/python3.6/site-packages/gi/__init__.py", line 134, in require_version (namespace, version)) ValueError: Namespace Modulemd not available for version 1.0 Expected results: $ dnf --version 2.7.5 Additional info: * dnf is fixed after downgrading libmodulemd: $ wget https://rpmfind.net/linux/fedora/linux/updates/28/Everything/x86_64/Packages/l/libmodulemd-1.7.0-1.fc28.x86_64.rpm $ rpm -Uvh --oldpackage libmodulemd-1.7.0-1.fc28.x86_64.rpm $ dnf --version 2.7.5 Andrew
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.