Changes/Python Upstream Architecture Names

Python Upstream Architecture Names

Summary

Use upstream architecture naming in Python (mostly in filenames) instead of previously patched Fedora names. For example, have /usr/lib64/python3.9/lib-dynload/array.cpython-39-powerpc64le-linux-gnu.so instead of /usr/lib64/python3.9/lib-dynload/array.cpython-39-ppc64le-linux-gnu.so. This makes packaging of Python itself a tad trickier, but it moves Fedora's Python closer to upstream. The difference only has impact on ppc64le and armv7hl (considering the architectures built by koji.fedoraproject.org). Packages assuming the filenames always contain %{_arch}-linux%{_gnu} will need to be adapted.

Owner

• Name: Miro Hrončok
• Name: Lumír Balhar
• Email: python-maint@redhat.com

Current status

• Targeted release: Fedora 34
• Last updated: 2020-08-25
• 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>

Scope

• Proposal owners:

• Other developers: N/A (not a System Wide Change)

• Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)

• Policies and guidelines: N/A (not a System Wide Change)

• Trademark approval: N/A (not needed for this Change)

• Alignment with Objectives:

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? N/A (not a System Wide Change), Yes/No
• Blocks product? product

Documentation

N/A (not a System Wide Change)