The idea is that the extra subpackage only has requirements specific to that extra.
The logic however only excluded requirements without markers,
but requirements with *a* marker that was correct leaked to all extras subpackages.
E.g. with the following requirements:
Requires-Dist: base-dependency
Requires-Dist: base-dependency-with-matching-marker ; python_version < "3.15"
Requires-Dist: base-dependency-with-unmatching-marker ; python_version < "3.8"
Provides-Extra: an-extra
Requires-Dist: extra-only-dependency-with-matching-marker ; extra == 'an-extra' and python_version < "3.15"
Requires-Dist: extra-only-dependency-with-unmatching-marker ; extra == 'an-extra' and python_version < "3.8"
On Python 3.10, the base package generated the following requirements:
python3.10dist(base-dependency)
python3.10dist(base-dependency-with-matching-marker)
And for the [an-extra] extra:
python3.10dist(base-dependency-with-matching-marker) <--- REDUNDANT, WRONG
python3.10dist(extra-only-dependency-with-matching-marker)
Now we no longer just check if the marker evaluates to True,
but we also check that the same marker evaluates to False when the extra is not given.
A real package with this issue is build[virtualenv] 0.8.0, which we use for tests. The package has:
Requires-Dist: tomli (>=1.0.0) ; python_version < "3.11"
And on Python 3.10, it generated the following dependency for python3-build+virtualenv-0.8.0-2.fc37.noarch.rpm:
python3.10dist(tomli) >= 1
Now it no longer does. This is asserted in tests.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2090186
Upstream PR: https://github.com/rpm-software-management/python-rpm-packaging/pull/16
Miro Hrončok
Tomas Orsava