On pe, 14 helmi 2020, Paul Clifford wrote:
Earlier this month this was a report that softhsm was available but not installable in CentOS 8 due to a "No available modular metadata for modular package" error. The solution was to enable the idm:DL1 module, but my understanding is that modular packages shouldn't be visible while their modules are disabled (this seems to be the behaviour in RHEL 8).
Looking in http://mirror.centos.org/centos/8/AppStream/x86_64/os/Packages/ there are two versions of softhsm in the AppStream repository:
- softhsm-2.4.0-2.module_el8.1.0+253+3b90c921.x86_64.rpm
- softhsm-2.4.0-2.module_el8.1.0+265+e1e65be4.x86_64.rpm
The repository's modules.yaml file only describes one version of the module, idm:DL1:8010020200121181805:4a0acb9a:x86_64, which owns the newer package. When idm:DL1 is enabled this masks the older softhsm version but when it's disabled (the default) the newer package is removed from view, and with no repository metadata to indicate that the older softhsm is part of a module it effectively becomes an ordinary member of the AppStream repository.
I think both of these builds belong to idm:DL1, just to two different module builds. There are other packages from idm:DL1 module stream that are duplicated.
Module build 253: https://koji.mbox.centos.org/koji/builds?tagID=488 Module build 265: https://koji.mbox.centos.org/koji/builds?tagID=513
So "dnf install softhsm" offers two different package versions based on whether or not idm:DL1 is enabled, instead of failing with "Error: Unable to find a match" when the module is disabled.
I agree that dnf should not show any of them if they both belong to disabled module stream.