From Fedora Project Wiki
(Initial draft)
 
No edit summary
Line 6: Line 6:
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->


It may happen that Python packages built using setuptools build with false version metadata.  
It sometimes happens that Python packages succeed to build with false version metadata.
They generate a wrong  provide in format python3dist(...) = 0.
They generate a wrong  provide in format python3dist(pkgname) = 0.
While version 0 (or equal versions like 0.0 or 0.0.0) is probably technically valid, in most cases it indicates a packaging error.  
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.
We propose to prevent this error from happening by explicitly erroring (and failing the build) when such provides was generated.


Line 49: Line 49:
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->


This change is only about automatic RPM provides in the following forms:
This change is about automatic RPM provides in the following form:
 
* `python3(.x)dist(pkgname) = 0`


* `python3dist(...) = 0`


It does not affect any other provides.
It does not affect any other provides.


TBD
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 ==
== Feedback ==
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->


TBD: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/K35JCFVJLETVUOICQM634OSYBYQ3Q2WQ/
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 ==
== Benefit to Fedora ==
Line 91: Line 99:
-->
-->


Much.
The correct metadata is essential for the whole package ecosystem. More deterministic behavior of the generators will bring those benefits:
TBD
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 ==
== Scope ==
* Proposal owners:
* Proposal owners:
# implement & test the change in pythondistdeps.py
# implement & test the change in python-rpm-generators (pythondistdeps.py)
# ...
# ...
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** ...
** fix the packaging error to prevent from generating such metadata
TBD how
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


Line 114: Line 125:
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->


* Alignment with Objectives: TBD
* Alignment with Objectives: No
<!-- Does your proposal align with the current Fedora Objectives: https://docs.fedoraproject.org/en-US/project/objectives/ ? It's okay if it doesn't, but it's something to consider -->
<!-- Does your proposal align with the current Fedora Objectives: https://docs.fedoraproject.org/en-US/project/objectives/ ? It's okay if it doesn't, but it's something to consider -->


Line 121: Line 132:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
This is done together with the Python 3.11 update to not have to deal with little problems, such as packages that can't be rebuilt after the manual requirements were changed.
None.
 


== How To Test ==
== How To Test ==

Revision as of 11:10, 10 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(pkgname) = 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

Current status

  • Targeted release: Fedora Linux 38
  • Last updated: 2022-11-10
  • 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(pkgname) = 0


It does not affect any other provides.

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:
  1. implement & test the change in python-rpm-generators (pythondistdeps.py)
  2. ...
  • 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)

Release Notes