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

TL;DR:
Create a RHEL 10.1 ppc64le mock chroot.

Longer explanation:
EPEL 10 has minor versions. Each minor version initially builds against CentOS 10, then is switched to build against the matching RHEL 10 minor version once it is released. EPEL Release Engineering made this change earlier this week, in accordance with the EPEL Minor EOL SOP. Afterwards we realized that EPEL 10.1 ppc64le builds had started failing (originally reported in releng#13082, later migrated to epel/releng#67). I was able to minimally reproduce the bug with dnf outside of koji and mock, using a similar install command that mock uses (install python3-dnf dnf-plugins-core). Further troubleshooting revealed that redhat-release-10.1-17.el10 introduces a dependency on rpm, and this dramatically increases the size of the initial dependency loop group in the bootstrap package set. This doesn't seem to matter on most arches, but for some reason on ppc64le it gets ordered differently and crypto-policies fails to install. Something similar was previously observed in rhbz#2244744. Excluding redhat-release-10.1-17.el10 and falling back to redhat-release-10.1-16.el10 (which does not have a dependency on rpm) resolves the issue.

What is the impact of this issue to you?

Archful EPEL 10.1 builds were unable to be completed for an extended period of time. To work around this for now we've removed redhat-release-10.1-17.el10 from the Fedora Infrastructure mirror, and modified our sync script to delete it again after syncing the latest RHEL 10.1 content. If more redhat-release builds are published that have the same dependency on rpm, we'll have to remove those as well.

Please provide the package NVR for which the bug is seen:

redhat-release-10.1-17.el10

How reproducible is this bug?:

always on ppc64le, never on other arches

Steps to reproduce

1. create local dnf.conf with RHEL 10.1 repos
2. dnf-3 --config dnf.conf --releasever 10 --repo baseos,appstream,crb --installroot $(pwd)/installroot install python3-dnf dnf-plugins-core

Alternate steps to reproduce, with rpm deploop logging

1. create local dnf.conf with RHEL 10.1 repos
2. dnf-3 --config dnf.conf --releasever 10 --repo baseos,appstream,crb --installroot $(pwd)/installroot download --resolve --downloaddir pkgs python3-dnf dnf-plugins-core
3. rpm -U --deploops --root $(pwd)/installroot pkgs/*.rpm

Expected results

successful installation of the bootstrap package set, leading to successful mock chroot initialization, leading to successful mock builds

Actual results

  Running scriptlet: crypto-policies-20250905-2.gitc7eb7b2.el10_1.noarch                                58/122
error: failed to exec scriptlet interpreter /bin/sh: No such file or directory
error: %prein(crypto-policies-20250905-2.gitc7eb7b2.el10_1.noarch) scriptlet failed, exit status 127

Error in PREIN scriptlet in rpm package crypto-policies
  Installing       : glibc-common-2.39-58.el10_1.2.ppc64le                                              59/122
error: crypto-policies-20250905-2.gitc7eb7b2.el10_1.noarch: install failed

Additional info

The rpm dependency was added to redhat-release in RHELBLD-17163 as Requires: rpm >= 4.19.1.1-19. The goal was to prevent users from selectively upgrading only redhat-release and getting the new PQC key without proper PQC support in rpm. I imagine simply removing the dependency is not appealing, so I experimented with some other solutions.

The first thing I tried was changing the dependency to Requires(meta): rpm >= 4.19.1.1-19, utilizing the meta dependency qualifier. This still results in a dependency, but that dependency is excluded from transaction ordering. This worked to resolve the mock chroot initialization.

The second thing I tried was changing the dependency to Requires: (rpm >= 4.19.1.1-19 if rpm), utilizing the if boolean operator. My thinking was that this would only enforce the minimum version of rpm if rpm is installed, but not pull it into the transaction otherwise. This did not work to resolve the mock chroot initialization.

The third thing I thought of, but did not explicitly try, was removing Requires: rpm >= 4.19.1.1-19 and instead using Conflicts: rpm < 4.19.1.1-19. Conflicts are not used for dependency ordering, so in the chroot initialization this should behave the same as redhat-release-10.1-16.el10 with no dependency on rpm. It should still achieve the end goal of preventing combining redhat-release with the PQC key and rpm without PQC support, as dnf will upgrade rpm when upgrading redhat-release to resolve the conflict.