New package: python3.11 3.11.6

[ahesford]

Python minor upgrades are all-or-nothing commitments to Void. Working through revbumps and runtime tests uncover a lot of incompatibilities, but runtime testing is limited to whatever testers happen to use. We are all familiar with the post-upgrade press to fix the tens of broken packages that shake out once the broader community gets the packages.

Even worse, large and sometimes important projects (firefox, chromium and electron*) use Python for their build processes and tend to slip past the upgrade testing procedure. These packages generally FTBFS and can require extensive patching of a litany of vendored Python packages. This is a painful process but, if we waited for upstream fixes for everything, we might lag behind several Python minor cycles. (Firefox still requires patching for Python 3.11.)

To make this upgrade easier in the future, I propose to provide the python3-legacy package, which will lag behind python3 by at least one minor version. This package (and its -devel subpackage) provide us a few nice advantages:

1. It is sufficient to bootstrap a virtual environment. Users that have packages fundamentally incompatible with new Python can install python3-legacy and create an older venv that will provide some consistency.
2. It can live alongside the system python3, so users that have existing virtual environments which link against the prior Python libraries can be kept functional by installing python3-legacy. (Right now, any existing venvs will break on upgrade because the requisite shared library will be removed.)
3. Our firefox, electron19 and electron24 packages can use the legacy version for builds, so we avoid breaking these major packages without being forced to patch them. (I have started builds of electron* and watched them continue through ~7k files so far, and I've watched firefox for the first several minutes. I'll need to actually run through the complete builds to be sure.)

Note that python3-legacy is NOT intended to be an alternative to the system Python. It is a minimal installation ONLY and its sole purpose for end users is to create virtual environments. We should NEVER allow any package in the repository to provide files in the site-packages tree for this version or link against its libpython. (To enforce this, I am deliberately leaving python3-legacy out of common/shlibs.) Any future upgrade of python3 must still ensure that every Python package at least installes in the new $py3_sitelib.

I've left idle out of this package but kept tkinter built in, although we can drop tkinter or add idle if others think there is merit in doing so.

Testing the changes

• I tested the changes in this PR: IN PROCESS

[ci skip]

cc: @void-linux/pkg-committers

[Vaelatern]

This seems cool, so long as users do not think they are getting a full install

short_desc="Python programming language (${version%.*} series)"

Maybe something like "Python programing language provided as a break-glass ( ${version%.*} series)"

[ahesford]

Early feedback: rename to python3.11 (from sgn), added limited install to short_desc (from Vaelatern).

[classabbyamp]

looks like this will be useful for qt5-webengine too #38229 (comment)

[ahesford]

electron24 and firefox build for x86_64 with these changes. electron19 is more than halfway through; seems the OSSL 3 update triggered an unrelated build failure that can be worked around with NODE_OPTIONS.

[leahneukirchen]

Firefox tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1857515

Chromium tracking bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1487454

[ahesford]

437f47a