> Slow-releasing/stable/"enterprise" distributions like RHEL, Debian,
> Ubuntu LTS and SLED are the usual sticking point for dependency versions.
>
> My understanding is that the main blocker for using Python 3 is
> that RHEL/CentOS 7 doesn't have it built-in, only as part of a secondary
> "software collection"?
Yeah, that's also what I heard when the topic came up on IRC, but similarly
vague re RHEL.. :)
> For what it's worth, requiring Python 3 would be no problem from Debian's
> perspective, as long as it isn't assumed to be /usr/bin/python: for
> compatibility with historical scripts, if /usr/bin/python exists then
> it is always Python 2, while Python 3 is available at /usr/bin/python3
> if installed. Using Python 3 for all programs that can work in either
> version is recommended, and in particular we've used Python 3 for the GLib
> and GObject-Introspection build tools since Debian 9 'stretch' (2017).
>
> We don't normally backport the latest GNOME versions to stable releases
> anyway; but if we do, the latest stable release (Debian 9 'stretch')
> has Python 3.5 as its supported Python 3 version, and the one before that
> (Debian 8 'jessie', 2015) had 3.4.
>
> Ubuntu is in about the same situation as Debian, with new LTS releases
> every 2 years, although a year out of phase with Debian (the most recent
> LTS releases were in 2018 and 2016 and have contemporary Python 3 versions).
That's good to know, thanks!
I'll try to summarize the remaining cases:
SLED/SLES:
They use old versions [0] [1], so unlikely that they will try to backport
things now imo. I couldn't find a working package index for SLED, I assume it
is similar to SLES.
[0] https://www.suse.com/LinuxPackages/packageRouter.jsp?product=server&version=12&service_pack=&architecture=x86_64&package_name=libglib-2_0-0
[1] https://www.suse.com/LinuxPackages/packageRouter.jsp?product=server&version=11&service_pack=&architecture=i386&package_name=glib2
--
Frédéric Crozat