The regex was broken for two+ digit minor version.
Providing python(abi) = 3.10 confuses the dependency resolution in the
Python 3.10 testing copr.
E.g. python3-sphinx requires `python(abi) = 3.10` and `/usr/bin/python3`.
In certain circumstances, dnf installs python3 and python3.10 from rawhide,
satisfying both of the dependencies.
Running `sphinx-build` hence ends up with:
Traceback (most recent call last):
File "/usr/bin/sphinx-build", line 5, in <module>
from sphinx.cmd.build import main
ModuleNotFoundError: No module named 'sphinx'
The `dirname $0` breaks the script when it is linked to a different location,
for example the RHEL's /usr/libexec/platform-python-config.
The error handling was never reachable, failed exec ends the script.
See https://src.fedoraproject.org/rpms/python3.9/pull-request/38
We create an artificial Git repo to apply patches.
Python build system thinks that it's building from Git and embeds a bogus
branch name into its version string:
$ python3
Python 3.9.0b5 (heads/master-dirty:24c7f56, Aug 3 2020, 00:00:00)
[GCC 10.2.1 20200804 (Red Hat 10.2.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
Tell configure that Git is not installed. This reverts that part
of sys.version to "default".
Pythons in RHEL/Fedora use different names for some architectures
than upstream and other distros (for example ppc64 vs. powerpc64).
See patch 274.
That means that an extension built with the default upstream settings
(on other distro or as an manylinux wheel) cannot be found by Python
on RHEL/Fedora because it has a different suffix.
This patch adds the original names to importlib so Python is able
to import extensions with an original architecture name in its
file name.
This saves about 2 MiB from the package. When all rpms get extracted,
the comparison is as follows on an ext4 filesystem:
With this patch:
$ du -s usr
195828 usr/
Without this patch:
$ du -s usr
198224 usr/
Which is a difference of 2.396 MiB.
To reduce the filesystem footprint of the Python installation, some
files are now being removed and only one level of their pycache
(non-optimized) is being kept.
These particular files were chosen for their size and the fact that they
are autogenerated, thus hard to read.
Patch 189 is still applied conditionally, so we need to use %autosetup with -N,
to prevent automatic patch application.
Later, the patches are applied automatically up to 188 (with -M for maximum),
patch 189 is applied conditionally,
and finally patches from 190 up are applied (with -m for minimum).
Once patch 189 is reworked to be applicable at all times (or removed), this can be dropped.
While not necessary shorter, this no longer requires adding/removing %patch XYZ
when adding/removing patches.
While at it, we also use git am to apply the patches
since they are all generated from git anyway.
This makes it easier if we ever patch binary files.
