Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1669950
Summary: | libmodulemd-2.1.0 breaks dnf (ValueError: Namespace Modulemd not available for version 1.0) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andrew D'Addesio <andrew> |
Component: | libmodulemd | Assignee: | Stephen Gallagher <sgallagh> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 28 | CC: | andrew, dmach, fedoraproject, gajownik, gryt2, jmracek, jrohel, kevin, mblaha, mhatina, nphilipp, packaging-team-maint, pkratoch, rdieter, richard, rpm-software-management, sgallagh, vmukhame |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libmodulemd-2.1.0-1.fc28.1 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-03-01 23:09:54 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Andrew D'Addesio
2019-01-28 07:23:53 UTC
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. |