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 |