RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1757460 - dnf does not consider newer module versions when a new context is added
Summary: dnf does not consider newer module versions when a new context is added
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: dnf
Version: 8.2
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: 8.3
Assignee: Jaroslav Mracek
QA Contact: Eva Mrakova
URL:
Whiteboard:
Depends On: 1763593
Blocks: 1666770 1713592 1825061 1837369
TreeView+ depends on / blocked
 
Reported: 2019-10-01 15:01 UTC by Petr Pisar
Modified: 2021-03-01 13:43 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1763593 1837369 (view as bug list)
Environment:
Last Closed: 2020-07-08 12:45:43 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Petr Pisar 2019-10-01 15:01:38 UTC 
We have two streams of perl in RHEL-8.1.0:

perl:5.24
perl:5.26

We have a stream of perl-DBI built for both perl streams, that means two contexts:

perl-DBI:1.641:8010020190322130042:16b3ab4d for perl:5.26
perl-DBI:1.641:8010020190322130042:e1f37755 for perl:5.24

Now I added a new perl:5.30 stream (bug #1713592) into RHEL-8.2.0:

perl:5.30

I can enable perl:5.30 stream:

# dnf --quiet --allowerasing module enable perl:5.30 
Problems in request:
Modular dependency problems with Defaults:

 Problem: conflicting requests
  - module perl-DBI:1.641:8010020190322130042:16b3ab4d-0.x86_64 requires module(perl:5.26), but none of the providers can be installed
  - module perl-DBI:1.641:8010020190322130042:e1f37755-0.x86_64 requires module(perl:5.24), but none of the providers can be installed
  - module perl:5.26:820181219174508:9edba152-0.x86_64 conflicts with module(perl:5.30) provided by perl:5.30:8020020190927112308:1b153fc7-0.x86_64
  - module perl:5.30:8020020190927112308:1b153fc7-0.x86_64 conflicts with module(perl:5.26) provided by perl:5.26:820181219174508:9edba152-0.x86_64
  - module perl:5.24:8010020190529084201:3af8e029-0.x86_64 conflicts with module(perl:5.30) provided by perl:5.30:8020020190927112308:1b153fc7-0.x86_64
  - module perl:5.30:8020020190927112308:1b153fc7-0.x86_64 conflicts with module(perl:5.24) provided by perl:5.24:8010020190529084201:3af8e029-0.x86_64
Is this ok [y/N]: Y

# dnf --quiet --allowerasing module list perl | grep 5.30
perl 5.30 [e] common [d], minimal Practical Extraction and Report Language

Then I rebuilt perl-DBI:1.641 in a new version to provide perl-DBI builds for all three contexts:

perl-DBI-1.641-8020020190923125347.80dfbdb3 for perl:5.30
perl-DBI-1.641-8020020190923125347.31e953cd for perl:5.26
perl-DBI-1.641-8020020190923125347.a7d630c8 for perl:5.24

Now I want to enable perl-DBI:1.641 stream. I expect perl-DBI-1.641-8020020190923125347.80dfbdb3 will satisfy the modular dependencies:

# dnf --quiet --allowerasing module enable perl-DBI:1.641
Error: Problems in request:
Modular dependency problems:

 Problem: conflicting requests
  - module perl-DBI:1.641:8010020190322130042:16b3ab4d-0.x86_64 requires module(perl:5.26), but none of the providers can be installed
  - module perl-DBI:1.641:8010020190322130042:e1f37755-0.x86_64 requires module(perl:5.24), but none of the providers can be installed
  - module perl:5.26:820181219174508:9edba152-0.x86_64 conflicts with module(perl:5.30) provided by perl:5.30:8020020190927112308:1b153fc7-0.x86_64
  - module perl:5.30:8020020190927112308:1b153fc7-0.x86_64 conflicts with module(perl:5.26) provided by perl:5.26:820181219174508:9edba152-0.x86_64
  - module perl:5.24:8010020190529084201:3af8e029-0.x86_64 conflicts with module(perl:5.30) provided by perl:5.30:8020020190927112308:1b153fc7-0.x86_64
  - module perl:5.30:8020020190927112308:1b153fc7-0.x86_64 conflicts with module(perl:5.24) provided by perl:5.24:8010020190529084201:3af8e029-0.x86_64

But DNF rejects it. Reading the error message suggests that DNF ignores 8020020190923125347 perl-DBI version completely and for some reason it insists on using the old 8010020190322130042 version.

I consider this a bug it prevents me from adding perl:5.30 into RHEL-8.2.0.


Tested with:

dnf-4.2.7-6.el8.noarch
libmodulemd-2.5.0-2.el8.x86_64

If you observe more error messages, just disable the offending modules.
Comment 2 Jaroslav Mracek 2019-10-03 07:00:48 UTC 
For the further development of modularity including resolving this issue, DNF team needs specifications (distribution restrictions) what is allowed during the life cycle of stream/module. Like changes in rpm artifacts (adding, removal, replacing), profiles, or module dependencies. The current situation with no restrictions limits changes in modular solving. The restrictions must be announced as a restriction and not as a example of a usage. Additional step would be that the release process must reject any update that do not fulfill the requirements.

From the DNF side the most critical part in modular dependency solving is related to missing upgrade path between contexts. The upgrade path is synthetically calculated but we cannot ensure that the new version of the module is child of any previous version. The situation result in:
1. Errors that are not errors (Current behavior)
2. Ignoring critical problems

The specific part in modular dependencies is represented by platform_id. Platform ID cannot be distinguished from real dependencies but it is strictly artificial object nearly identical to releasever. From our experience we discovered that auto-detection from metadata brakes some user-case where standard distribution based on releasever works.

My question is what the plan?
Comment 6 Jaroslav Mracek 2020-02-26 12:48:58 UTC 
I create a github repository with modify repodata that will resolve adding new context or EOL. See: https://github.com/j-mracek/module_repos. The solution is based on filling metadata gaps by duplication of existing data with modified version. It does not requires any additional rpm or module builds.
Note You need to log in before you can comment on or make changes to this bug.