Bug 1898548

I cannot reproduce it. What dnf version do you have installed? Do you have enables sources repositories?

Created attachment 1730542 [details]
Enabled repos and dnf version

The source repos are enabled. But why this should affect the installation of a modular packages? I do not really understand, src.rpm's do not even have MODULARITYLABEL rpm tag by the nature.
So, what is the reason of this?

Enabling the source repositories should not affected it. I've just tried with enabled source repositories and it did not change anything for me.
However, I can see that your dnf is not up to date. The latest one in RHEL 8.3 is dnf-4.2.23-4.el8. Also your libdnf is old. Could you update them?
Also does the issue only exhibit with this one module, or does it happen for you with other modules?

If you install "@perl-App-cpanminus:1.7044/common", then DNF should install all packages listed in the "common" profile of "1.7044" stream of "perl-App-cpanminus" module. And that is "perl-App-cpanminus" package. The "artifacts" section only enumerates what packages belongs to what module build. The list is used for making the packages available. (Because otherwise modular packages are not available to the DNF dependency solver.) The list is not used for installing anything.

Created attachment 1730546 [details]
Updated dnf

After updating dnf, we have the same issue

Do you have up-to-date dependencies of DNF?

# rpm -q libmodulemd librepo python3-hawkey
libmodulemd-2.9.4-2.el8.x86_64
librepo-1.12.0-2.el8.x86_64
python3-hawkey-0.48.0-5.el8.x86_64

Maybe it's some incompatibility in python3-dnf-plugin-spacewalk that I do not have installed.

Neither installing python3-dnf-plugin-spacewalk helps me to reproduce it.
Frankly I cannot see anything specific to perl-App-cpanminus:1.7044 in this bug report. All modules looks like that. Reassigning to DNF.

Created attachment 1730562 [details]
Other dnf-related info

It seems that libmodulemd librepo python3-hawkey are same

But I also have python3-dnf-plugin-spacewalk-2.8.5-11 installed

I have python3-dnf-plugin-spacewalk-2.8.5-11.module+el8.1.0+3455+3ddf2832. But I don't use any Satellite server, thus my spacewalk plugin is not configured.

Are your repositories generated by a Satellite server? Could you show me the complete DNF output when installing the module? I'm especially interested from which repository comes the source package. DNF shows the the repository identifier in the fourth column.

Created attachment 1730897 [details]
additional info log

So, the src.rpm is taken from
Repository   : rhel-8-for-x86_64-appstream-source-rpms

I just installed my rhel8, registered and got the error.
Also
# cat /etc/dnf/plugins/spacewalk.conf 

[main]
enabled = 0
gpgcheck = 1
timeout = 120

What's a URL of the rhel-8-for-x86_64-appstream-source-rpms repository (Repo-baseurl value in "dnf repolist --repoid=rhel-8-for-x86_64-appstream-source-rpms -v" output)?

I have another conjecture. Your rhel-8-for-x86_64-appstream-rpms is missing perl-App-cpanminus package, and thus DNF attempts to install perl-App-cpanminus from another repository and the only package it founds is the source package in rhel-8-for-x86_64-appstream-source-rpms. What repositories reports "dnf info perl-App-cpanminus" command?

Created attachment 1730906 [details]
Repo info

(In reply to Mikhail Campos from comment #11)
> Created attachment 1730906 [details]
> Repo info

This is not a "dnf repolist -v" output.

Well, that is exactly as you asked, 2 commands from comment #10

Anyway, those repo investigation leads to nothing, that MUST work with any official repo combination enabled/disabled. Especially, for freshly installed rhel from ISO, registered by officially provided guide from access.redhat.com.

As I remeber, those src.rpm in artifacts have not been provided in some rhel8.0/8.1 modules, but now they are for any module. As I said before this looks like "broken logic" for dnf, those src.rpm do not even have modularitylabel, so why do not treat them as those "normal" like in BaseOS I mean ALWAYS visible in dnf ops?

I see. I downloaded a wrong attachment. If you pasted the outputs into the comments, or named the attachment files differently, it would be easier for me.

You can try passing --disablerepo=\*-source-rpms option to dnf when installing the module. It could help you as a workaround.

Your "dnf info" lists two perl-App-cpanminus packages. For noarch and for src architecture, each from the correct repository.
But both packages have 1.7044-5.module+el8.1.0+2942+5e3df93c version. But that's old version. The latest version and the one your DNF complains about is 1.7044-5.module+el8.2.0+4278+abcfa81a.

Also what puzzles me is that your DNF error reports 1.7044-5.module+el8.2.0+4278+abcfa81a package build which is for perl:5.30 stream. But you stated you have a default installation and the default one has perl:5.26 as the default stream, so DNF should show and install builds for perl:5.26.

I recommend you to contact Red Hat support <https://access.redhat.com/support/>. They should help you with debugging your issue.

Oh, well, of course I changed default perl to 5.30. Sorry, I forgot to mention this.

Perhaps, I should try to reproduce it again in more "clean" way starting from the clean installation.

OK, after installing rhel8.3 from scratch, I was able to reproduce it only, if src.rpm repos are enabled.
Please, confirm if it's more like a "feature" rather than a bug.
As I see enabling source repos should not affect modular installations.

In my opinion, this is definitely a bug. But let's wait for DNF developers to evaluate it.

I create a patch that will resolve the issue.

PR: https://github.com/rpm-software-management/dnf/pull/1691
Test: https://github.com/rpm-software-management/ci-dnf-stack/pull/915

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (dnf bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1657