Re: F38 proposal: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/14/22 16:35, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Prevent-Providing-python3dist(pkg)%3D0

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== 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: [[User:Ksurma|Karolina Surma]]
* Email: ksurma@xxxxxxxxxx


== 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
[https://github.com/pypa/setuptools/issues/2329 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
[https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0
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
[https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/pythondistdeps.py
pythondistdeps.py]).
The generator will error and fail the build if `python3dist(...) = 0`
was to be generated.

Based on discussion on python-devel mailing list there will be no way
to opt out from this change. There will be no possibility to package a
Python package with version `0`.
Packagers who encounter such need are encouraged to work with upstream
to set the version to at least `0.0.1`.

== Feedback ==
The idea was posted on
[https://lists.fedoraproject.org/archives/list/python-devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/K35JCFVJLETVUOICQM634OSYBYQ3Q2WQ/
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.2`
in their specfiles will always require the correctly evaluated
version.

== Scope ==
* Proposal owners:
# implement & test the change in python-rpm-generators
([https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/pythondistdeps.py
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:
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_source_files_from_pypi
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.

== Release Notes ==


Hello

Based on the feedback, the proposal was updated with an opt-out:

```
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_required does.
```

https://fedoraproject.org/wiki/Changes/Prevent-Providing-python3dist(pkg)=0#Detailed_Description

--
Karolina Surma (she/her/hers)
Software Engineer
Python Maintenance Team, Red Hat
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux