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 1651701
Summary: | DNF module conflict error on dependencies | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Partha Aji <paji> |
Component: | dnf | Assignee: | Jaroslav Mracek <jmracek> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | high | ||
Version: | 28 | CC: | dmach, mblaha, mhatina, packaging-team-maint, paji, psabata, rpm-software-management, sgallagh, vmukhame |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | dnf-4.1.0-1.fc29 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-02-21 02:56:51 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
Partha Aji
2018-11-20 15:48:37 UTC
The module declares it could run with either walrus:0.71 or walrus:5.21, yet DNF is looking for "module(walrus:0.71):5.21)", which seems like a bug in both processing the dependencies and constructing the solvables. Please can you provide a repo metadata with a problem? Petr please can you provide an official full specification of modular yaml file that is part of metadata? I created a patch that should solve the issue (https://github.com/rpm-software-management/libdnf/pull/646) Do you need anything besides https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L78 ? Please can you clarify following text? I cannot guess what it means. dependencies: # Build on all available platforms except for f27, f28 and epel7 # After build, the runtime dependency will match the one used for # the build. - buildrequires: platform: [-f27, -f28, -epel7] requires: platform: [-f27, -f28, -epel7] Another part is also unclear: # For platform:epel7, build against against all available extras # streams and moreextras:foo and moreextras:bar. The number of builds # in this case will be 2 * <the number of extras streams available>. # At runtime, both extras and moreextras will match whatever stream was # used for build. - buildrequires: platform: [epel7] extras: [] moreextras: [foo, bar] requires: platform: [epel7] extras: [] moreextras: [foo, bar] Additionally please can you confirm that current behavior of dnf after applying patch form Comment 4 is according to specification? DNF deals with runtime dependencies only, so the build dependencies can be ignored. The dependencies block is a list of dictionaries of build time and runtime dependencies. Runtime dependencies are dictionaries of module names and a list of valid streams. Any of the dependencies blocks and any of the specified streams are valid, thus if I have a module with something like this: dependencies: - requires: platform: [f28] foo: [a] - requires: platform: [f29, f30] foo: [b, c] I can install it on f28 together with foo:a, or on f29 or f30 together with either foo:b or foo:c. Five possible combinations in total. An empty list means "any". Streams prefixed with a dash mean "any but <...>", therefore an expression like "[-f27, -f28, -epel7]" means "any platform but f27, f28 or epel7". Definitions like "[-f27, f28]" are nonsensical and therefore invalid, but this is handled on the libmodulemd level. Regarding the test, could you provide a COPR build? And Partha, could you help with the testing? I create a copr repo for Fedora 29 with patched libdnf (https://copr.fedorainfracloud.org/coprs/jmracek/Modularity). Petr please can you update https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L78 according to Comment 7 that explains it much better? libcomps-0.1.10-2.fc29 libdnf-0.26.0-1.fc29 dnf-plugins-core-4.0.4-1.fc29 dnf-plugins-extras-4.0.2-1.fc29 dnf-4.1.0-1.fc29 librepo-1.9.4-1.fc29 createrepo_c-0.12.1-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-1fccede810 createrepo_c-0.12.1-1.fc29, dnf-4.1.0-1.fc29, dnf-plugins-core-4.0.4-1.fc29, dnf-plugins-extras-4.0.2-1.fc29, libcomps-0.1.10-2.fc29, libdnf-0.26.0-1.fc29, librepo-1.9.4-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1fccede810 createrepo_c-0.12.1-1.fc29, dnf-4.1.0-1.fc29, dnf-plugins-core-4.0.4-1.fc29, dnf-plugins-extras-4.0.2-1.fc29, libcomps-0.1.10-2.fc29, libdnf-0.26.0-1.fc29, librepo-1.9.4-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |