[Python-modules-team] [critical] #958166 - python3-all has had python3.7 removed

[Luke Kenneth Casson Leighton]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958166

this is serious enough to bring to a wider audience's attention,
immediately.  just as happened over 10 years ago, a mistake made by
the ubuntu team making python-all depend on only a single version of
python has just been repeated, in debian.

the consequences are not immediately obvious however are beginning to
bleed through already.  the issue is *not* if a "fresh install" (in
this case of debian/testing) is carried out, it's if someone tries to
do a rolling-update.  i managed to catch this because i never do
apt-get dist-upgrade (or full reinstalls - never going to happen with
5 million source code files accumulated over 8 years).  instead i add
debian/testing and "on-demand" perform periodic apt-get installs which
will pull in required dependencies.

this allows me early detection the scenarios that would cause
stable-to-stable upgrades to FAIL, 100%, just as they did for the
ubuntu team when transitioning from python 2.5 to python 2.6.

with python3-all having had python 3.7 removed, c-based python3
packages are now being built that can NEVER be simultaneously
installed whilst python 3.8 is also installed on the same system.

likewise, if python 3.8 is ever also installed on the same system and
packages which *do* depend solely and exclusively on python 3.8 get
installed, if there are any dependencies further up the chain, one of
which depends on one c-module-based package compiled exclusively for
python 3.7 AND ONE WHICH DEPENDS ON 3.8, all hell will break loose.

i cannot emphasise enough how serious this will become if
python3-numpy gets recompiled and uploaded as only depending on python
3.8
https://packages.debian.org/testing/python3-numpy

right now - thank goodness - the current version in sid is dependent
on both 3.7 and 3.8:
https://packages.debian.org/sid/python3-numpy

martin points out that python3-all is critical in determining how
multi-python c-based module compilation works:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958043

thus, when python3-numpy is next recompiled, it's going to be for a
single version of python3.  with apt-cache rdepends showing 439
packages depending on python3-numpy, that's going to create absolute
havoc.

the versions of python3 that are in python3-all *must* cover at least
the current stable LTSes *right* the way through to the current
version of python.  with debian 10 being dependent on python 3.7, that
means it *must* stay in python3-all at least until debian 11 is
released.

if python 3.9 is ever included in debian/testing, then that means that
python3-all *must* depend on python 3.7, 3.8 *and* python 3.9.  the
last time this happened was (i think) debian 8, where python 2.4, 2.5
*and* 2.6 had to be included for a while.

i cannot emphasise enough how critical this is to rectify as fast as
possible before any further python3 c-based packages are compiled up,
mistakenly, for only the one version of python3.  the more that get
uploaded, the more reports will come in of package conflicts during
upgrades.

l.