No edit summary |
No edit summary |
||
Line 55: | Line 55: | ||
It does not affect any other provides. | It does not affect any other provides. | ||
More about the provides: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Machine-readable-provides | More about the provides: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Machine-readable-provides | ||
An example of the incorrect provides | |||
``` | |||
$ rpm -qpP python3-ssh-python-0.10.0-5.fc38.x86_64.rpm | |||
python-ssh-python = 0.10.0-5.fc38 | |||
python3-ssh-python = 0.10.0-5.fc38 | |||
python3-ssh-python(x86-64) = 0.10.0-5.fc38 | |||
python3.11-ssh-python = 0.10.0-5.fc38 | |||
python3.11dist(ssh-python) = 0 | |||
python3dist(ssh-python) = 0 | |||
``` | |||
In January 2022 the umbrella Bugzilla ticket was created for Python packages providing this incorrect provide: https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0 | In January 2022 the umbrella Bugzilla ticket was created for Python packages providing this incorrect provide: https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0 |
Revision as of 08:30, 11 November 2022
Prevent from building packages providing python3dist(...) = 0
Summary
It sometimes happens that Python packages succeed to build with false version metadata. They generate a wrong provide in format python3dist(...) = 0. While version 0 (or equal versions like 0.0 or 0.0.0) is probably technically valid, in most cases they indicates a packaging error. We propose to prevent this error from happening by explicitly erroring (and failing the build) when such provides was generated.
Owner
- Name: Miro Hrončok, Karolina Surma
- Email: mhroncok@redhat.com, ksurma@redhat.com
Current status
- Targeted release: Fedora Linux 38
- Last updated: 2022-11-11
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
This change is about automatic RPM provides in the following form:
python3(.x)dist(distname) = 0
It does not affect any other provides. More about the provides: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Machine-readable-provides
An example of the incorrect provides
`
$ rpm -qpP python3-ssh-python-0.10.0-5.fc38.x86_64.rpm
python-ssh-python = 0.10.0-5.fc38
python3-ssh-python = 0.10.0-5.fc38
python3-ssh-python(x86-64) = 0.10.0-5.fc38
python3.11-ssh-python = 0.10.0-5.fc38
python3.11dist(ssh-python) = 0
python3dist(ssh-python) = 0
`
In January 2022 the umbrella Bugzilla ticket was created for Python packages providing this incorrect provide: https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0 On Nov 10 2022 there are 22 linked Bugzilla tickets, 13 of which are not closed. The change doesn't affect a big part of the Python ecosystem.
We aim to prevent such situation from happening by increasing the robustness of the python-rpm-generators (namely pythondistdeps.py: https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/pythondistdeps.py). The generator will error and fail the build if python3dist(pkgname) = 0 was to be generated.
Feedback
The idea was posted on python-devel mailing list and received a positive feedback. No alternatives to this approach were proposed: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/K35JCFVJLETVUOICQM634OSYBYQ3Q2WQ/
Benefit to Fedora
The correct metadata is essential for the whole package ecosystem. More deterministic behavior of the generators will bring those benefits:
The packages will stop lying about the version they provide.
The requirements generators (eg. %pyproject_buildrequires
) will correctly evaluate the Build- and Runtime Requirements based on the correct Provides.
The package maintainers who BuildRequire %{py3dist pkgname} in their specfiles will always require the correctly evaluated version.
Scope
- Proposal owners:
- implement & test the change in python-rpm-generators (pythondistdeps.py)
- ...
- Other developers:
- fix the packaging error to prevent from generating such metadata
TBD how
- Release engineering: not needed for this Change
- Policies and guidelines: not needed for this Change
- Trademark approval: not needed for this Change
- Alignment with Objectives: No
Upgrade/compatibility impact
None.
How To Test
TBD
User Experience
The actual users should notice no difference.
Dependencies
TBD
Contingency Plan
- Contingency mechanism: TBD
- Contingency deadline: TBD
- Blocks release? No
Documentation
N/A (not a System Wide Change)