Changes/Prevent-Providing-python3dist(pkg)=0

Prevent from building RPM packages providing python3dist(...) = 0

Summary

It sometimes happens that Python packages succeed to build as RPM 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-12-01
• devel thread
• FESCo issue: #2903
• Tracker bug: #2150046
• Release notes tracker: #929

Detailed Description

This change is about automatic RPM provides in the following form:

• python3dist(distname) = 0
• python3.Xdist(distname) = 0

Where X is the Python minor version (eg. 10, 11...). It does not affect any other provides. More about these provides: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Machine-readable-provides

The provides generated during the RPM build come from the upstream Python package metadata. Some Python building backends, eg. setuptools, explicitly allow creating package with version 0.0.0 when the version used by a project is not known. This was discussed upstream with conclusion that it's an intended behavior.

In other cases, for example when building package from a particular git commit, the incorrect provide can be generated due to a packaging error. We've never encountered a situation when packaging the version 0 was the package maintainers intention. After a discussion on python-devel mailing list we agreed we'd like to prevent such situations from happening in Fedora.

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

Why is it bad?

If any package requires python3-ssh-python > 0.9 (correctly assuming there's 0.10.0 in Fedora's repositories), the automatic dependency generators will not discover the example package, making the other package non-installable.

In January 2022 the umbrella Bugzilla ticket was created for Python packages providing version 0. In all cases the automatic provide wasn't intended.

Affected packages (as of Nov 11 2022):

b43-tools
dionaea
marisa
python-podman-api
rpkg
spectrographic
python-ssh-python
python-streamlink

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 the discussion on fedora-devel mailing list, there will be a mechanism to opt out from this change. A macro with a provisional name (TBD) %__python_dist_allow_version_zero will be created. If defined in the specfile, it will change the invocation of the Python RPM generators not to fail if a package providing version 0 was created. It will behave the same way as an already existing macro %_python_no_extras_requires does.

Feedback

The idea was posted on python-devel mailing list and received a positive feedback. No alternatives to this approach were proposed.

After the Change was announced on fedora-devel, it was requested to provide a mechanism to opt out from the Change. It was pointed out that we shouldn't dictate the upstream's decisions, especially that PEP 440 doesn't forbid using the version 0.0.0. OTOH semver specification recommends starting at 0.1.0. The Change was updated to provide such mechanism, see Detailed Description.

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.2 in their specfiles will always require the correctly evaluated version.

Scope

• Proposal owners:

1. implement & test the change in python-rpm-generators (pythondistdeps.py)

• Other developers:
  • Fix the packaging error to generate correct metadata and successful build. There's no common way to deal with such packages. In most of the cases the issue originates from packaging errors that need to be fixed. Contact the change owners if you need help with the necessary changes to your package.

• Release engineering: not needed for this Change

• Policies and guidelines: Python Packaging Guidelines cover the topic of creating the version string. This will be valid 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

• Prepare a Python package, set the version to 0

or

• Use one of the known packages that provide version 0.
• Try to build an RPM package in a regular way (eg. mockbuild)
• The build should fail.

User Experience

The actual users should notice no difference.

Dependencies

None

Contingency Plan

• Contingency mechanism: Revert
• Contingency deadline: Beta freeze
• Blocks release? No

Documentation

This page is the documentation of this change.