Packages in RHEL 8 should not use, Require or BuildRequire `/usr/bin/python3` because that file is provided by all the Python stacks - 3.6 (the main one), 3.8, 3.9, and 3.11. The particular version `/usr/bin/python3` points to depends on the system of alternatives and is determined either by the priority of the individual options or by manual setting by the system administrator. Python 3.6 has the highest priority, so if it is installed, `/usr/bin/python3` means Python 3.6 by default. However, when Python 3.6 is not installed, `/usr/bin/python3` can mean almost anything. Python 3.6 is the only Python in RHEL 8 with a full 10+ years of support and all system packages should depend on it. All other Python stacks have a shorter support period. If you wish to use an alternate Python version becasue the life cycle of your package allows you to do it, always choose that version explicitly rather than allowing dnf to pull in any Python version. Packages that Require `/usr/bin/python3` used to install Python 3.6 as a dependency by default, so for majority of use cases this problem never surfaced. However, python3.11 sort alphabetically sooner than python36, so users of RHEL 8.8 will get Python 3.11 by default when a package requires `/usr/bin/python3`. Please, switch the BuildRequires to `python3-devel` and make sure to always use %{python3} during the build when invoking Python rather than invoking `/usr/bin/python3`. If your need to, you can change shebangs by the %py3_shebang_fix macro. Shebangs of installed files are automatically mangled by `/usr/lib/rpm/redhat/brp-mangle-shebangs`. It is absolutely essential that no RHEL 8 package Requires `/usr/bin/python3` on runtime. Even if you are confident that your code will work on any Python future version, it is not a good idea to support this for our customers. And also do not hesitate to let me know if you need any assistance or more information.
A lot has been said about RHEL, but this comes from Fedora. Therefore should be solved there first, if needed. So what is recommendation for Fedora? Also looking at the sources, the irony is that it seems that with all the magic you wrote above and what not, the specific test case might be skipped after all: https://github.com/cucumber/aruba/blob/e9192bec97e8d26c7382efee5f8bbd06fb96a924/features/step_definitions/hooks.rb#L3-L7 https://github.com/cucumber/aruba/blob/e9192bec97e8d26c7382efee5f8bbd06fb96a924/features/03_testing_frameworks/cucumber/steps/command/run_commands_which_require_a_shell.feature#L14-L39 IOW how to make packaging nightmare from naive test case
You can depend on python3-devel in Fedora/EPEL.
But here actually python3-devel is not needed, all needed is /usr/bin/python3.
If you are okay with the fact that /usr/bin/python3 can be provided by Python versions 3.6, 3.8, 3.9, and 3.11 now and possibly more in the future, it's fine. In this case, it's build-time-only dependency.
Also, in the guidelines: Every package that uses Python (at runtime and/or build time) and/or installs Python modules MUST explicitly include BuildRequires: python3-devel in its .spec file, even if Python is not actually invoked during build time. https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_distro_wide_guidelines
For Fedora (i.e. not for EPEL), I just killed python related test and so removed BR: python entirely: the (python related) test is not important anyway.
Thank you. I implemented that change for epel8. I'll have an updated build in a little bit.
FEDORA-EPEL-2023-06046a646d has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-06046a646d
FEDORA-EPEL-2023-06046a646d has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-06046a646d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-06046a646d has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.