From Fedora Project Wiki
(Empty proposal)
 
m (How To Test: Also repoquery the source repo for BuildRequires)
 
(22 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->


= Change Proposal Name <!-- The name of your change proposal --> =
= Python Dist RPM provides to only provide PEP503-normalized names <!-- The name of your change proposal --> =


== Summary ==
== Summary ==
<!-- 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?". -->
The legacy `python3dist(NAME)` and `python3.11dist(NAME)` RPM provides with dots (`.`) in `NAME` will no longer be automatically provided. `NAME` will only be normalized according to [https://www.python.org/dev/peps/pep-0503/#normalized-names PEP 503]. E.g. on Fedora 36 a package provides both `python3dist(ruamel-yaml)` and `python3dist(ruamel.yaml)`, on Fedora 37+ it will only provide `python3dist(ruamel-yaml)` (and similarly, `python3.11dist(ruamel-yaml)`).


== Owner ==
== Owner ==
Line 11: Line 13:
This should link to your home wiki page so we know who you are.  
This should link to your home wiki page so we know who you are.  
-->
-->
* Name: [[User:FASAcountName| Your Name]]
* Name: [[User:Churchyard|Miro Hrončok]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: <your email address so we can contact you, invite you to meetings, etc. Please provide your Bugzilla email address if it is different from your email in FAS>
* Email: mhroncok@redhat.com
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
-->
-->


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF37]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 30: Line 31:
<!-- [[Category:SystemWideChange]] -->
<!-- [[Category:SystemWideChange]] -->


* Targeted release: [[Releases/<number> | Fedora Linux <number> ]]  
* Targeted release: [[Releases/37 | Fedora Linux 37 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 38: Line 39:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2746 #2746]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2052217 #2052217]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: <will NOT be assigned by the Wrangler - not user-facing>


== Detailed Description ==
== Detailed Description ==
<!-- 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 about automatic RPM provides in the following forms:
* `python3dist(NAME)`
* `python3.Xdist(NAME)`
It does not affect any other provides or package names.
Historically, Python package names were normalized by the RPM dependency generators in a way that diverged from upstream behavior. In upstream (e.g. when using `pip`) a package name with a dot is equal to a package name with a dash (e.g. `pip install ruamel.yaml` and `pip install ruamel-yaml` are equivalent). In Fedora, the ''Provides'' and ''Requires'' included the dot, but upstream rules defined in [https://www.python.org/dev/peps/pep-0503/#normalized-names PEP 503] demand the dot to be replaced by a dash. This caused trouble when other packages required the packages via a name with a dash. Hence, we have slowly been migrating to PEP 503 name normalization.
* Since Fedora 32, Python dependency generators have generated both variants of the ''Provides'' as a preparation for the transition to PEP 503-only.
* Since Fedora 33, Python dependency generators have generated ''Requires'' in the PEP 503 form (no dots).
* Only packages with manual ''BuildRequires'', ''Requires'', ''Recommends'' etc. with requirements such as `python3dist(foo.bar)` would be affected by this change. We have fixed all of them in Fedora 36.
Hence, together with [[Changes/Python3.11|the update to Python3.11]], we will disable the legacy form of the provides.
Python packages with dots in their name will only provide the names with dashes.
=== RHEL/EPEL compatibility ===
This change is fully compatible with RHEL/EPEL 9, which behaves like Fedora 34 and hence has ''Provides'' in both forms but ''Requires'' in the PEP 503 form (no dots).
This change is not compatible with RHEL/EPEL 8. If you need to have manual requirements in the specfile that should work on Fedora 37+ and RHEL/EPEL 8 in this form and the name includes a dot, we recommend using [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#py3_dist `%py3_dist`].
This change is not relevant to RHEL 7.
This change is not compatible with EPEL 7. If you need to have manual requirements in the specfile that should work on Fedora 37+ and RHEL/EPEL 7 in this form and the name includes a dot, we recommend using [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#py3_dist `%py3_dist`].


== Feedback ==
== Feedback ==
Line 76: Line 106:
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
-->
-->
* Less automatic provides in the repos - there are 93+93=186 provides like `python3dist(x.y)` and `python3.Xdist(x.y)` in rawhide today.
* There will be only one way to express a Python package name in this context, not two.
* One more thing the Python maintainers will cross off their TODO list.


== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners:
# check there are really no more manual requirements with dots
# disable the automatically generated provides with dots when we update to Python 3.11
# double-check there are really no more manual requirements with dots
<!-- 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 -->
** stop adding new manual Python dist requirements with dots
<!-- 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?-->


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: not needed for this Change <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->


* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: they already only cover PEP 503 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. -->


* Trademark approval: N/A (not needed for this Change)
* Trademark approval: not needed for this Change
<!-- 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:  
* Alignment with Objectives: not really
<!-- 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 101: Line 139:


<!-- 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.


== How To Test ==
== How To Test ==
Line 119: Line 157:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
The following 2 commands should yield nothing:


$ repoquery --repo=rawhide --provides | grep -E '^python3(\.[[:digit:]]+)?dist\(\S+\.\S+\)'
$ repoquery --repo=rawhide{,-source} --requires | grep -E '^python3(\.[[:digit:]]+)?dist\(\S+\.\S+\)'
With the exception of packages that failed to rebuild with Python 3.11 (and those will need to be dealt with anyway one way or another).
The following example commands should only give the variant with dashes:
$ repoquery --repo=rawhide --provides python3-ruamel-yaml | grep -E '^python3(\.[[:digit:]]+)?dist\('
$ repoquery --repo=rawhide --provides python3-jaraco-path | grep -E '^python3(\.[[:digit:]]+)?dist\('
There should be no new broken dependencies because of this.
Note that wiki is eating my double `[]` in the regexes above around `:digit:`. See the page source for the actual commands :(


== User Experience ==
== User Experience ==
Line 132: Line 185:
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
-->
-->
The actual users should notice no difference.


== Dependencies ==
== Dependencies ==
Line 137: Line 191:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
We need [[Changes/Python3.11]] to happen together with this.


== Contingency Plan ==
== Contingency Plan ==


<!-- 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: (What to do?  Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: the change owners will revert the change and the mass rebuild will handle the packages that need the legacy form of the provides <!-- 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: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: mass rebuild <!-- 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? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 


== Documentation ==
== Documentation ==

Latest revision as of 14:34, 10 February 2022


Python Dist RPM provides to only provide PEP503-normalized names

Summary

The legacy python3dist(NAME) and python3.11dist(NAME) RPM provides with dots (.) in NAME will no longer be automatically provided. NAME will only be normalized according to PEP 503. E.g. on Fedora 36 a package provides both python3dist(ruamel-yaml) and python3dist(ruamel.yaml), on Fedora 37+ it will only provide python3dist(ruamel-yaml) (and similarly, python3.11dist(ruamel-yaml)).

Owner

Current status

  • Targeted release: Fedora Linux 37
  • Last updated: 2022-02-10
  • FESCo issue: #2746
  • Tracker bug: #2052217
  • Release notes tracker: <will NOT be assigned by the Wrangler - not user-facing>

Detailed Description

This change is only about about automatic RPM provides in the following forms:

  • python3dist(NAME)
  • python3.Xdist(NAME)


It does not affect any other provides or package names.

Historically, Python package names were normalized by the RPM dependency generators in a way that diverged from upstream behavior. In upstream (e.g. when using pip) a package name with a dot is equal to a package name with a dash (e.g. pip install ruamel.yaml and pip install ruamel-yaml are equivalent). In Fedora, the Provides and Requires included the dot, but upstream rules defined in PEP 503 demand the dot to be replaced by a dash. This caused trouble when other packages required the packages via a name with a dash. Hence, we have slowly been migrating to PEP 503 name normalization.

  • Since Fedora 32, Python dependency generators have generated both variants of the Provides as a preparation for the transition to PEP 503-only.
  • Since Fedora 33, Python dependency generators have generated Requires in the PEP 503 form (no dots).
  • Only packages with manual BuildRequires, Requires, Recommends etc. with requirements such as python3dist(foo.bar) would be affected by this change. We have fixed all of them in Fedora 36.


Hence, together with the update to Python3.11, we will disable the legacy form of the provides.

Python packages with dots in their name will only provide the names with dashes.

RHEL/EPEL compatibility

This change is fully compatible with RHEL/EPEL 9, which behaves like Fedora 34 and hence has Provides in both forms but Requires in the PEP 503 form (no dots).

This change is not compatible with RHEL/EPEL 8. If you need to have manual requirements in the specfile that should work on Fedora 37+ and RHEL/EPEL 8 in this form and the name includes a dot, we recommend using %py3_dist.

This change is not relevant to RHEL 7.

This change is not compatible with EPEL 7. If you need to have manual requirements in the specfile that should work on Fedora 37+ and RHEL/EPEL 7 in this form and the name includes a dot, we recommend using %py3_dist.

Feedback

Benefit to Fedora

  • Less automatic provides in the repos - there are 93+93=186 provides like python3dist(x.y) and python3.Xdist(x.y) in rawhide today.
  • There will be only one way to express a Python package name in this context, not two.
  • One more thing the Python maintainers will cross off their TODO list.

Scope

  • Proposal owners:
  1. check there are really no more manual requirements with dots
  2. disable the automatically generated provides with dots when we update to Python 3.11
  3. double-check there are really no more manual requirements with dots
  • Other developers:
    • stop adding new manual Python dist requirements with dots
  • Release engineering: not needed for this Change
  • Policies and guidelines: they already only cover PEP 503
  • Trademark approval: not needed for this Change
  • Alignment with Objectives: not really

Upgrade/compatibility impact

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.

How To Test

The following 2 commands should yield nothing:

$ repoquery --repo=rawhide --provides | grep -E '^python3(\.digit:+)?dist\(\S+\.\S+\)'
$ repoquery --repo=rawhide{,-source} --requires | grep -E '^python3(\.digit:+)?dist\(\S+\.\S+\)'

With the exception of packages that failed to rebuild with Python 3.11 (and those will need to be dealt with anyway one way or another).


The following example commands should only give the variant with dashes:

$ repoquery --repo=rawhide --provides python3-ruamel-yaml | grep -E '^python3(\.digit:+)?dist\('
$ repoquery --repo=rawhide --provides python3-jaraco-path | grep -E '^python3(\.digit:+)?dist\('

There should be no new broken dependencies because of this.

Note that wiki is eating my double [] in the regexes above around :digit:. See the page source for the actual commands :(

User Experience

The actual users should notice no difference.

Dependencies

We need Changes/Python3.11 to happen together with this.

Contingency Plan

  • Contingency mechanism: the change owners will revert the change and the mass rebuild will handle the packages that need the legacy form of the provides
  • Contingency deadline: mass rebuild
  • Blocks release? No

Documentation

N/A (not a System Wide Change)

Release Notes