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.
