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: dnfAssignee: Jaroslav Mracek <jmracek>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: high    
Version: 28CC: 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
I have a module with the following definition. Make a note of the build requires section
 
"""
---
document: modulemd
version: 2
data:
  name: duck
  stream: 0
  version: 201809302113907
  context: deadbeef
  arch: noarch
  summary: Duck 0.8 module
  description: >-
    A module for the duck 0.8 package
  license:
    module:
      - MIT
  dependencies:
  - buildrequires:
      walrus: [0.71, 5.21]
      platform: [f28]
    requires:
      walrus: [0.71, 5.21]
      platform: [f28]
  profiles:
    default:
      rpms:
        - duck
  artifacts:
    rpms:
      - duck-0:0.8-1.noarch
...
"""


It requires 2 other modules which are also defined in the same modules.yaml file. Here are the dependency snippets which are defined in the smae file.

"""
---
document: modulemd
version: 2
data:
  name: walrus
  stream: 5.21
  version: 20180704144203
  context: deadbeef
  arch: x86_64
  summary: Walrus 5.21 module
  description: >-
    A module for the walrus 5.21 package
  license:
    module:
      - MIT
  profiles:
    default:
      rpms:
        - walrus
  artifacts:
    rpms:
      - walrus-0:5.21-1.noarch
...
---
document: modulemd
version: 2
data:
  name: walrus
  stream: 0.71
  version: 20180707144203
  context: c0ffee42
  arch: x86_64
  summary: Walrus 0.71 modulerm -rf rpm-with-modules
tar zxf ~/rpm-with-modules.tgz 

  description: >-
    A module for the walrus 0.71 package
  license:
    module:
      - MIT
  profiles:
    default:
      rpms:
        - walrus
    flipper:
      rpms:
        - walrus
  artifacts:
    rpms:
      - walrus-0:0.71-1.noarch
...
"""

When I point the repo to my fedora 28 box (with the latest dnf, got it from nightly copr repo), and run 'dnf module list'. I get

"""
# dnf clean all
46 files removed
# dnf module list
......
rpm-with-modules                                                                                                                              44 kB/s | 8.1 kB     00:00    
Modular dependency problems:

 Problem 1: conflicting requests
  - nothing provides module(walrus:0.71):5.21) needed by module duck:0:201809302113907:deadbeef-0.noarch
 Problem 2: conflicting requests
  - nothing provides module(walrus:5.21)) needed by module duck:0:20180704244205:deadbeef-0.noarch
.....
"""

Rpms: 
"""
# rpm -qa|grep dnf
libdnf-0.22.2-0.19gf0d9a64a.fc28.x86_64
python3-dnf-4.0.8-0.26gb9a915f0.fc28.noarch
python3-dnf-plugins-core-4.0.2-0.20g1500088.fc28.noarch
dnf-yum-4.0.8-0.26gb9a915f0.fc28.noarch
python3-libdnf-0.22.2-0.19gf0d9a64a.fc28.x86_64
dnf-data-4.0.8-0.26gb9a915f0.fc28.noarch
dnf-4.0.8-0.26gb9a915f0.fc28.noarch
dnf-plugins-core-4.0.2-0.20g1500088.fc28.noarch
"""

Steps to reproduce:
1) 
"""
# cat /etc/yum.repos.d/test.repo 
[oh-man]
name=rpm-with-modules
baseurl=https://partha.fedorapeople.org/test-repos/rpm-with-modules-bz/
enabled=1
gpgcheck=0
"""
2) dnf clean all; dnf repolist

"""
# dnf repolist
Last metadata expiration check: 0:14:37 ago on Tue 20 Nov 2018 03:33:23 PM UTC.
Modular dependency problems:

 Problem 1: conflicting requests
  - nothing provides module(walrus:0.71):5.21) needed by module duck:0:201809302113907:deadbeef-0.noarch
 Problem 2: conflicting requests
  - nothing provides module(walrus:5.21)) needed by module duck:0:20180704244205:deadbeef-0.noarch
.........
"""

Comment 1 Petr Šabata 2018-11-20 15:51:25 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.

Comment 2 Jaroslav Mracek 2018-11-26 13:26:08 UTC
Please can you provide a repo metadata with a problem?

Comment 3 Jaroslav Mracek 2018-11-27 09:38:12 UTC
Petr please can you provide an official full specification of modular yaml file that is part of metadata?

Comment 4 Jaroslav Mracek 2018-11-27 10:24:40 UTC
I created a patch that should solve the issue (https://github.com/rpm-software-management/libdnf/pull/646)

Comment 5 Petr Šabata 2018-11-28 13:38:39 UTC
Do you need anything besides https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L78 ?

Comment 6 Jaroslav Mracek 2018-11-28 19:15:47 UTC
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?

Comment 7 Petr Šabata 2018-11-28 19:41:37 UTC
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?

Comment 8 Jaroslav Mracek 2018-11-29 14:20:56 UTC
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?

Comment 9 Fedora Update System 2019-02-18 10:15:18 UTC
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

Comment 10 Fedora Update System 2019-02-19 06:27:18 UTC
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

Comment 11 Fedora Update System 2019-02-21 02:56:51 UTC
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.

Comment 12 Red Hat Bugzilla 2023-09-12 01:35:39 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days