Consider a RHEL 9 spec file with does things like: %generate_buildrequires %global python3_pkgversion 3 %pyproject_buildrequires %global python3_pkgversion 3.11 %pyproject_buildrequires %build %global python3_pkgversion 3 %pyproject_wheel %global python3_pkgversion 3.11 %pyproject_wheel %install %global python3_pkgversion 3 %pyproject_install %pyproject_save_files module %global python3_pkgversion 3.11 %pyproject_install %pyproject_save_files module This should work, but it will blow up at the install stage: Traceback (most recent call last): File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 775, in <module> main(cli_args) File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 730, in main file_section, module_names = pyproject_save_files_and_modules( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 708, in pyproject_save_files_and_modules parsed_records = load_parsed_record(pyproject_record) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 676, in load_parsed_record raise FileExistsError("%pyproject install has found more than one *.dist-info/RECORD file. " FileExistsError: %pyproject install has found more than one *.dist-info/RECORD file. Currently, %pyproject_save_files supports only one wheel → one file list mapping. Feel free to open a bugzilla for pyproject-rpm-macros and describe your usecase. Even if we manage to fix this somehow, there are 2 wheels built in pyproject-wheeldir when the Python project contains an extension module: $ ls -1 /var/lib/mock/centos-stream+epel-next-9-x86_64/root/builddir/build/BUILD/pyproject-wheeldir/ reproducer_double-1-cp39-cp39-linux_x86_64.whl reproducer_double-1-cp311-cp311-linux_x86_64.whl And the %pyproject_insatll macro will likely try to install them both or blow up differently. -------------- I propose we include %{python3_pkgversion} in: - %{_pyproject_wheeldir} - %{_pyproject_builddir} - %{_pyproject_files_prefix} That should isolate the entire state between different %{python3_pkgversion} values. If we want to make this 100% backwards compatible, we could only include %{python3_pkgversion} when it is not 3.
Created attachment 1966164 [details] A reproducer spec (for c9s) with an extension module
Something like this should do: %_pyproject_files_pkgversion %{expr:"%{python3_pkgversion}" != "3" ? "-%{python3_pkgversion}" : ""} %_pyproject_wheeldir %{_builddir}%{?buildsubdir:/%{buildsubdir}}/pyproject-wheeldir%{_pyproject_files_pkgversion} %_pyproject_builddir %{_builddir}%{?buildsubdir:/%{buildsubdir}}/.pyproject-builddir%{_pyproject_files_pkgversion} %_pyproject_files_prefix %{name}-%{version}-%{release}.%{_arch}%{_pyproject_files_pkgversion}
I don't think this will work properly now that we've memoized a bunch of the `%python3_...` macros.
Yeah, the memoization will make this tricky. I was thinking a global way of disabling it and/or using %{python3_pkgversion} as a key in some Lua table.
Related PR: https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/161
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/433
FEDORA-2024-b6801d4514 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-b6801d4514
FEDORA-2024-b6801d4514 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-dcec42f261 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2024-dcec42f261
FEDORA-2024-6c9a7ef1f2 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-6c9a7ef1f2
FEDORA-2024-6c9a7ef1f2 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-6c9a7ef1f2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6c9a7ef1f2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-dcec42f261 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-dcec42f261` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-dcec42f261 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-6c9a7ef1f2 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-dcec42f261 (pyproject-rpm-macros-1.12.0-1.fc38) has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.