Fedora Account System
Red Hat Associate
Red Hat Customer
As more and more packages move to pryproject macros we keep getting issues with the upstream metadata being sometimes too restrictive with no good reason, e.g. setting an upper bound for a dependency on an imaginary future version, requiring a very specific version only or simply just pinning the last version they tested which could be very outdated. Hence packagers resort to sed-ing or patching the problematic metadata from the various files, cluttering the SPEC files and making things brittle for every rebase when the metadata is updated. I propose the addition of an "-S" aka "set" flag which would allow packagers to set/modify/transform/tweak/adjust/alter/filter the resulting requirements. We can bikeshed on the various naming schemes. Providing here some examples on how this feature could work: Removing upper and lower bounds %pyproject_buildrequires -S pkg:remove_upper %pyproject_buildrequires -S pkg:remove_lower %pyproject_buildrequires -S pkg:remove_all Changing bounds %pyproject_buildrequires -S pkg:change_upper:4.0 %pyproject_buildrequires -S pkg:change_lower:1.5.4 Remove the package entirely from deps %pyproject_buildrequires -S pkg:ignore Multiple packages %pyproject_buildrequires -S pkg1:remove_upper -S pkg2:change_upper:3.0 Change deps generation from a specific file %pyproject_buildrequires requirements.txt -S pkg:remove_upper Multiple flags compatibility %pyproject_buildrequires -N requirements.txt -S pkg:remove_upper %pyproject_buildrequires -R -S pkg:remove_upper %pyproject_buildrequires -t -x testing -g docs -S pkg:remove_upper Reproducible: Always
An additional application for this functionality would be where a single source RPM is used to build several closely-related wheels and several python3-* subpackages. This is not well-supported by the pyproject-rpm-macros, and one-source-package-per-PyPI-project tends to be easier when it is practical. Still, such multi-wheel packages are feasible, already exist in Fedora, and are sometimes the least unpleasant option for packaging certain projects. An idiosyncratic example (with, among other oddities, a weird, customized build system controlled by environment variables) is python-typer. The python-fastapi and fastapi-cli packages are similar. Another, less peculiar examples is the python-py-key-value package, now under review in bug 2427769. Typically, one finds that some of the wheels generate runtime dependencies on each other, and these need to be filtered out so that the source package does not have an unnecessary bootstrapping loop on itself. See https://bugzilla.redhat.com/show_bug.cgi?id=2427769#c3 for one workaround, and the following comment for the reason it may be brittle. This proposal would be a much better option.
(In reply to Ben Beasley from comment #1) > An additional application for this functionality would be where a single > source RPM is used to build several closely-related wheels and several > python3-* subpackages. This is not well-supported by the > pyproject-rpm-macros, and one-source-package-per-PyPI-project tends to be > easier when it is practical. Still, such multi-wheel packages are feasible, > already exist in Fedora, and are sometimes the least unpleasant option for > packaging certain projects. > > An idiosyncratic example (with, among other oddities, a weird, customized > build system controlled by environment variables) is python-typer. The > python-fastapi and fastapi-cli packages are similar. Another, less peculiar > examples is the python-py-key-value package, now under review in bug 2427769. > > Typically, one finds that some of the wheels generate runtime dependencies > on each other, and these need to be filtered out so that the source package > does not have an unnecessary bootstrapping loop on itself. See > https://bugzilla.redhat.com/show_bug.cgi?id=2427769#c3 for one workaround, > and the following comment for the reason it may be brittle. This proposal > would be a much better option. I (plus AI), implemented the change here: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/564 Feel free to chime in the PR. It adds a -D flag to %pyproject_buildrequires with actions: remove_upper, remove_lower, remove_all, change_upper:VERSION, change_lower:VERSION, ignore. e.g.: %pyproject_buildrequires -D cython:remove_upper -D numpy:change_upper:2.0 This only works for BuildRequires however. The RPM generators grab the runtime requirements from the upstream metadata and it's a different mechanism, so you can consider the current change as Phase 1. If the overridden package is also a runtime dependency, the build will error out and prompt for patching the metadata. I plan to work on the runtime requires as well after it, which will need to touch on python-rpm-generators also. The -D ignore implemented in this PR should work for your usecase when the next phase gets implemented.
Please provide feedback here: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/745UW6JJTIAMQKDWYQRJQZ2E3VN74HO7/
FEDORA-2026-09d59b0e65 (pyproject-rpm-macros-1.20.0-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-09d59b0e65
FEDORA-2026-09d59b0e65 (pyproject-rpm-macros-1.20.0-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-c50219cb79 (pyproject-rpm-macros-1.20.0-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-c50219cb79
FEDORA-2026-051d1b3285 (pyproject-rpm-macros-1.20.0-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-051d1b3285
FEDORA-2026-051d1b3285 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-051d1b3285` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-051d1b3285 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-c50219cb79 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-c50219cb79` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-c50219cb79 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-b365003f50 (pyproject-rpm-macros-1.20.1-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-b365003f50
FEDORA-2026-b365003f50 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-b365003f50` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-b365003f50 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-f83c29a149 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-f83c29a149` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-f83c29a149 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-0a10b4d589 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-0a10b4d589` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-0a10b4d589 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-f83c29a149 (pyproject-rpm-macros-1.21.0-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-df48a8f3e0 (pyproject-rpm-macros-1.21.0-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-aefbbc6b17 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-aefbbc6b17` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-aefbbc6b17 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-aefbbc6b17 (pyproject-rpm-macros-1.22.1-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.