< Changes
| Line 200: | Line 200: | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: | * Contingency mechanism: Revert <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: | * Contingency deadline: Beta freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== Documentation == | == Documentation == | ||
Revision as of 14:27, 11 November 2022
Prevent from building RPM packages providing python3dist(...) = 0
Summary
It sometimes happens that Python packages succeed to build with incorrect version metadata.
They generate a wrong provide in format python3dist(...) = 0 and python3.Xdist(...) = 0.
While version 0 (or equal versions like 0.0 or 0.0.0) is probably technically valid, in most cases this indicates a packaging error.
We propose to prevent this error from happening by explicitly failing the RPM build instead of generating such provides.
Owner
- Name: Karolina Surma
- Email: 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:
python3dist(distname) = 0python3.Xdist(distname) = 0
Where X is the Python minor version (eg. 10, 11...) It does not affect any other provides. More about the provides: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Machine-readable-provides
The provides are automatically generated from upstream metadata and sometimes such information s missing due to packaging error. Setuptools generates sometimes 0 which is bad, we agreed and proposed we will not accept the state
Setuptools sets this to 0.0.0 https://github.com/pypa/setuptools/issues/2329 packaging from git no example when someone wanted to package 0.0.0
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:
On Nov 10 2022 there are 22 linked Bugzilla tickets, 13 of which are not closed.
New check: 9 packages, in all cases this is wrong
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).
The generator will error and fail the build if python3dist(...) = 0 was to be generated.
Based on discussion on Fedora-devel there will be no way to opt out from this. Packagers who want to... encouraged to ask upstream to package at least 0.0.1
Feedback
The idea was posted on python-devel mailing list and received a positive feedback. No alternatives to this approach were proposed.
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} >= 0.2in 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 generate correct metadata and successful build
TBD how there's no common way to deal with such packages, it's one-by-one issue that originates mostly from packaging errors, ask the change owners if need a way forward
- Release engineering: not needed for this Change
- Policies and guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_source_files_from_pypi - this is said here and that's enough even when we change the python RPM generators behavior
- Trademark approval: not needed for this Change
- Alignment with Objectives: No
Upgrade/compatibility impact
None.
How To Test
TBD take package that provides 0 or prepare a package that has a version 0, build RPM, fail, profit
User Experience
The actual users should notice no difference.
Dependencies
None
Contingency Plan
- Contingency mechanism: Revert
- Contingency deadline: Beta freeze
- Blocks release? No
Documentation
N/A (not a System Wide Change)