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 1670435 - Installing perl-5.24 breaks updates due to interference from perl-5.26 packages
Summary: Installing perl-5.24 breaks updates due to interference from perl-5.26 packages
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: perl-5.24-module
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Petr Pisar
QA Contact: RHEL CS Apps Subsystem QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-29 14:17 UTC by Stephen Tweedie
Modified: 2020-12-16 08:35 UTC (History)
7 users (show)

Fixed In Version: perl-5.24-820190207164249.ee766497
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2019-06-14 01:40:45 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Proposed fix for perl.spec (3.23 KB, patch)
2019-01-31 16:18 UTC, Petr Pisar 		no flags Details | Diff
View All

Description Stephen Tweedie 2019-01-29 14:17:04 UTC 
Description of problem:
If the perl:5.24 module is enabled and installed "yum update" breaks due to dependency errors.

The issue appears to be that perl-interpreter is an ursine RPM which Obsoletes: perl, so once perl-5.24 is installed, perl-interpreter tries to replace it and fails due to missing 5.26 dependencies.

Version-Release number of selected component (if applicable):
perl-interpreter-4:5.26.3-416.el8
perl-5.24.4-401.module+el8+2464+d274aed1.x86_64


How reproducible:
100%

NB. installing with perl:5.24/minimal is enough to reproduce this problem but the problem persists with the larger, default module install too.

Steps to Reproduce:
1. # yum module install perl:5.24/minimal
2. # yum update

Actual results:
 Problem: package perl-interpreter-4:5.26.3-416.el8.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed
  - package perl-interpreter-4:5.26.3-416.el8.x86_64 requires perl-libs(x86-64) = 4:5.26.3-416.el8, but none of the providers can be installed
  - cannot install the best update candidate for package perl-4:5.24.4-401.module+el8+2464+d274aed1.x86_64
  - package perl-libs-4:5.26.3-416.el8.x86_64 is excluded
==============================================================================
 Package                Arch         Version            Repository     Size
==============================================================================
Skipping packages with broken dependencies:
 perl-interpreter       x86_64       4:5.26.3-416.el8   rhel8-devel    6.3 M

Transaction Summary
==============================================================================
Skip  1 Package

Nothing to do.
Complete!


Expected results:
The system should update without errors, especially if there are not any applicable updates!

Additional info:
# dnf list --obsoletes
...

Obsoleting Packages
perl-interpreter.x86_64 4:5.26.3-416.el8                      rhel8-devel 
    perl.x86_64         4:5.24.4-401.module+el8+2464+d274aed1 @rhel8-beta-appstream

It appears that this Obsoletes: is causing the (visible) perl-interpreter RPM to be considered an update to perl, even though the rest of the perl:5.26 module is unavailable due to selection of a different stream.

This is reproducible on both the latest nightly/ and rel-eng/ (ie. HTB) RHEL8 composes.
Comment 3 Petr Pisar 2019-01-30 08:23:20 UTC 
There three possible fixes:

(1) Remove the Obsoletes from 5.26 perl-interpreter. The Obsoletes comes from Fedora to swap perl and perl-interpreter packages when upgrading to newer Fedora. This use case is not applicable to RHEL. Except when a RHEL user switches from perl:5.24 stream to a different stream. Not swapping the packages only results into a fatter installation (5.26 perl package has many additional dependencies).

(2) Add (a dummy) perl-interpreter package to perl:5.24 stream. Having a same-named package in an enabled module will mask the bare 5.26 perl-interpreter.

(3) This is a bug in libdnf solver. If I'm not mistaken Obsoletes were considered only if they were in an installed or being installed package. Obsoletes semantics was to uninstall a package that has been replaced by another already installed one. I noticed recently that DNF started to apply Obsoletes defined in packages that are not installed. E.g. in this case perl:5.24 stream does not contain any perl-interpreter package and is not installed. (Although 5.24 perl package Provides: perl-interpreter.) Yet DNF wants to install perl-interpreter package and obsolete perl package.

I'd like to hear a clarification from package management team regarding (3). If this is not a bug in DNF, I'd probably choose (2). (2) papers the issue but is future proof since Fedora will contain the Obsoletes and newer perl streams in RHEL will inherit it. (I.e. the issue would recurrent with adding any new perl stream.)
Comment 4 Petr Pisar 2019-01-31 12:35:14 UTC 
There is no need to install a profile. This can be reproduced with enabling perl:5.24 stream and having installed the perl package:

# dnf module list |grep 'perl[^-]'
perl                 5.24 [e]     common [d], minimal                      Practical Extraction and Report Language                           
perl                 5.26 [d]     common [d], minimal                      Practical Extraction and Report Language   

# rpm -q perl
perl-5.24.4-401.module+el8+2464+d274aed1.x86_64

# rpm -q perl-interpreter
package perl-interpreter is not installed

# dnf upgrade 
[...]
 Problem: package perl-interpreter-4:5.26.3-416.el8.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed
  - package perl-interpreter-4:5.26.3-416.el8.x86_64 requires perl-libs(x86-64) = 4:5.26.3-416.el8, but none of the providers can be installed
  - cannot install the best update candidate for package perl-4:5.24.4-401.module+el8+2464+d274aed1.x86_64
  - package perl-libs-4:5.26.3-416.el8.x86_64 is excluded
==========================================================================================
 Package                 Arch          Version                   Repository          Size
==========================================================================================
Skipping packages with broken dependencies:
 perl-interpreter        x86_64        4:5.26.3-416.el8          rhel-8-base        6.3 M

Transaction Summary
==========================================================================================
Skip  1 Package


However there is definitely something fishy in DNF:

# dnf upgrade --allowerasing
Last metadata expiration check: 2:57:34 ago on Thu 31 Jan 2019 10:29:47 AM CET.
Dependencies resolved.
Nothing to do.
Complete!

# dnf upgrade --allowerasing --best
Last metadata expiration check: 2:58:23 ago on Thu 31 Jan 2019 10:29:47 AM CET.
Dependencies resolved.
==========================================================================================
 Package             Arch   Version                               Repository         Size
==========================================================================================
Removing:
 perl                x86_64 4:5.24.4-401.module+el8+2464+d274aed1 @rhel-8-appstream  13 M
Removing dependent packages:
 perl-Errno          x86_64 1.25-401.module+el8+2464+d274aed1     @rhel-8-appstream 9.1 k
 perl-File-Path      noarch 2.12-367.module+el8+2464+d274aed1     @rhel-8-appstream  57 k
 perl-IO             x86_64 1.36-401.module+el8+2464+d274aed1     @rhel-8-appstream 138 k
 perl-PathTools      x86_64 3.63-367.module+el8+2464+d274aed1     @rhel-8-appstream 180 k
 perl-Socket         x86_64 4:2.027-2.module+el8+2464+d274aed1    @rhel-8-appstream 122 k
 perl-Text-Tabs+Wrap noarch 2013.0523-395.module+el8+2464+d274aed1
                                                                  @rhel-8-appstream  24 k
 perl-Unicode-Normalize
                     x86_64 1.25-1000.module+el8+2464+d274aed1    @rhel-8-appstream 622 k
 perl-constant       noarch 1.33-1000.module+el8+2464+d274aed1    @rhel-8-appstream  26 k
 perl-threads        x86_64 1:2.21-2.module+el8+2464+d274aed1     @rhel-8-appstream 107 k
 perl-threads-shared x86_64 1.58-2.module+el8+2464+d274aed1       @rhel-8-appstream  77 k
 python3-rpkg        noarch 1.57-2.el8eng                         @rhpkg            579 k
 rhpkg               noarch 1.35-7.el8eng                         @rhpkg            385 k
 rpmlint             noarch 1.10-13.el8                           @rhel-8-appstream 725 k

Transaction Summary
==========================================================================================
Remove  14 Packages

So forcing the highest versions uninstalls perl package, but does not any replacement, namely perl-interpreter package. This is not how Obsoletes should be handled.

Moreover distr-sync is confirms the system is up-to-date:

# dnf distrosync
Last metadata expiration check: 3:03:06 ago on Thu 31 Jan 2019 10:29:47 AM CET.
Dependencies resolved.
Nothing to do.
Complete!

But:

# dnf distrosync --best
Last metadata expiration check: 3:03:54 ago on Thu 31 Jan 2019 10:29:47 AM CET.
Error: 
 Problem: package perl-interpreter-4:5.26.3-416.el8.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed
  - package perl-interpreter-4:5.26.3-416.el8.x86_64 requires perl-libs(x86-64) = 4:5.26.3-416.el8, but none of the providers can be installed
  - cannot install the best update candidate for package perl-4:5.24.4-401.module+el8+2464+d274aed1.x86_64
  - package perl-libs-4:5.26.3-416.el8.x86_64 is excluded

Reports the same issue. What's the difference between "distrosync" and "distrosync --best"? In my opinion there should not be any.
Comment 5 Petr Pisar 2019-01-31 12:40:11 UTC 
As I don't have any respond from DNF maintainer, I'm going to update perl:5.24 stream by adding an empty perl-interpreter subpackage to perl.spec.
Comment 7 Petr Pisar 2019-01-31 16:18:21 UTC 
Created attachment 1525487 [details]
Proposed fix for perl.spec
Comment 11 Petr Pisar 2019-02-04 11:38:33 UTC 
dmach confirmed off-line that the new DNF behavior (an Obsoletes from noninstalled packaged affects system) is intentional. So we indeed need to fix it in the perl:5.24 module.
Comment 15 Petr Pisar 2019-02-07 16:31:41 UTC 
Some tests actually expect installing "perl" package also installs "perl-interpreter" RPM symbol. To make this change less obtrusive I will make the dependency between perl and perl-interpreter symmetric.
Note You need to log in before you can comment on or make changes to this bug.