What were you trying to do that didn't work?

In order to install a custom flavour of PHP (from "Remi's repos"), customer "reposynced" the repo in question on its Satellite server, in a repo named "rhel-php-latest". He was not able to install the 'php:<stream_wanted>' DNF module after following the upstream (3rd party) instructions, which were absolutely standard ('module reset php' then 'module enable <module>'). The error was absolutely not self-explanatory, and we, the support, were hiding behind the fact it's a 3rd party.

Into practice, the customer synchronized the repo for a wrong architecture (aarch64 instead of x86_64), leading to this misleading error. Checking what modules provide for 'php' finally put us on the good track ('dnf module provides php').

Setting the severity as Minor, since the issue is likely very rare.

Please provide the package NVR for which bug is seen:

dnf-4.7.0-16.el8_8.noarch

libsolv-0.7.20-4.el8_7.x86_64

How reproducible:

Always

Steps to reproduce

• Setup the below repositories on an x86_64 system

  https://rpms.remirepo.net/enterprise/8/remi/aarch64
  https://rpms.remirepo.net/enterprise/8/modular/aarch64

• Run the following commands to enable a given php flavour:

  # dnf module reset php
  # dnf module enable php:remi-7.4
  

  Expected results

Something like this to put the user on the right track:

- module XXX does not have a compatible architecture
- nothing provides ld-linux-aarch64.so.1(GLIBC_2.17)(64bit) needed by php-7.4.33-9.el8.remi.aarch64

Actual results

# dnf module enable php:remi-7.4
 :
Modular dependency problem: Problem: nothing provides requested module(composer:2:20231113181904)
Error: Problems in request:
Modular dependency problems: 
 Problem 1: nothing provides requested module(composer:2:20231113181904)
 Problem 2: nothing provides requested module(php:remi-7.4:20231113181904)