Bug 15943

Currently, we have the following patches for Python 3:

0001-Make-the-build-of-pyc-files-conditional.patch
0002-Disable-buggy_getaddrinfo-configure-test-when-cross-.patch
0003-Adjust-library-header-paths-for-cross-compilation.patch
0004-Serial-ioctl-workaround.patch
0005-Misc-python-config.sh.in-ensure-sed-invocations-only.patch
0006-Add-an-option-to-disable-pydoc.patch
0007-Add-an-option-to-disable-lib2to3.patch
0008-Add-an-option-to-disable-IDLE.patch
0009-python-config.sh-don-t-reassign-prefix.patch
0010-configure.ac-move-PY_STDLIB_MOD_SET_NA-further-up.patch
0011-Add-option-to-disable-the-sqlite3-module.patch
0012-Add-an-option-to-disable-the-tk-module.patch
0013-Add-an-option-to-disable-the-curses-module.patch
0014-Add-an-option-to-disable-expat.patch
0015-fix-building-on-older-distributions.patch
0016-configure.ac-fixup-CC-print-multiarch-output-for-mus.patch
0017-lib-crypt-uClibc-ng-doesn-t-set-errno-when-encryptio.patch


This issue is just to start some discussion on removing or reworking some of these patches and to check upstream status

I'm going to skip 6-8, 11-14. These would be preferable to upstream or to find an alternative disable mechanism but so far are necessary. Some seem to require these build flags, others are being disabled via py_cv_ autoconf variables.

Patch 0001:
* Has no upstream status
* could maybe be upstreamed
* we disable it because:
  * we don't need all levels of optimization consuming disk space
  * we generate the legacy variants for sourceless distributions (https://github.com/python/cpython/issues/95827)
* We could, instead, remove the files post build instead of patching to disable it
  * this costs build time, but is one less patch to maintain since we already have a hook to remove these files in python3.mk though it is not removing opt-0.pyc
  
Patch 0002:
* no upstream status
* could maybe be upstreamed as you can't reliably run cross built code to determine bugginess of a function
* patch could be removed if we define ac_cv_buggy_getaddrinfo=no like we do other ac_cv values in python3.mk or if we explicitly set either --(en|dis)able-ipv6 (https://github.com/python/cpython/commit/9635013a8fb68c044ea2cae2ec344b3940c188b2)
  * there could be issues if there is an actually buggy IPv6 implementation

Patch 0003:
* has no upstream status
* not likely to be upstreamed
* can probably be removed because these environment variables were dropped in BR 0d327c267a57e3a75b10becde772addb7fc49297 so this patch isn't doing anything

Patch 0004:
* has no upstream status
* original discussion: http://lists.busybox.net/pipermail/buildroot/2014-July/102202.html
* may not be needed for toolchains using kernel headers newer than 3.17 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f61bf8e7d19e0a3456a7a9ed97c399e4353698dc
* what's our required minimum kernel header version? If we had one defined, we can make assumptions in our packages & patches.

Patch 0005:
* Upstream: https://github.com/python/cpython/issues/67096
* can likely be dropped since Python 3.10 https://github.com/python/cpython/commit/14086cfc5eed8c5e78342d79e5db87a135d75fa8

Patch 0010:
* no upstream status
* could maybe be upstreamed if the argument was made for it... the argument for landing this is buttressed by the other disable flags we patch in

Patch 15:
* no upstream status
* no need for one...
* should be dropped, we do not use the build host's python when cross compiling python as it requires a reasonably new version for regen, so we use the BR host version which is the same as the target version to satisfy this.
  * As of 3.12 it requires 3.10 https://github.com/python/cpython/commit/146106a0f1cc61815fa33f0d3f808a3e3e3275be
  
Patch 16:
* no upstream status
* musl and uClibc do not have official upstream support though concessions have been made for musl
* I think this needs more consideration... 
  * CPython has very specific checks for the PLATFORM_TRIPLET which got reworked for 3.13 (and actually forcibly disables uClibc)
  * There's a bug in 3.12 where the "build_os" gets substituted for the PLATFORM_TRIPLET instead of the "host_os", fixed in 3.13 via https://github.com/python/cpython/commit/c163d7f0b67a568e9b64eeb9c1cbbaa127818596
  * this commit (c163d7f0b67a568e9b64eeb9c1cbbaa127818596) also changes the PLATFORM_TRIPLET calculation
* The patch should maybe be changed to fix the build_os/host_os issue and add a line for uclibc and/or to change the platform triplet detection code to correctly identify musl/uclibc

Patch 17:
* no upstream status (cpython doesn't have uclibc support)
* should not be necessary for uClibc versions newer than 1.0.37 (see https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/libcrypt/crypt.c?id=6993d9378224489b49325bd1fb962f0e8bb935f1)
* Do we specify a minimum uClibc version requirement anywhere so we can make assumptions in our packages & patches?

--

Should the option disable patches just be a single patch? If not, I think I'd argue they should be the first few patches in the series. That way as we add and remove patches there's less patch reordering.