On Tue, Jul 8, 2025, 7:23 PM Paolo Bonzini <pbonz...@redhat.com> wrote:
> On 7/8/25 22:36, John Snow wrote: > > centos_stream_9 3.9.23 21.3.1 53.0.0 3.4.3 BaseOS, CRB > > Ok, so the lowest version of Sphinx (3.4.3) is currently used for CentOS > Stream 9. It's supported for roughly 2 more years, until 12.0. > Yep. I am thinking however that because 3.9 is soon to be EOL this autumn, it may become reasonable to start requiring newer Python interpreters for this platform as well. They *are* available. I won't do it without a reason, but I think this may be a reasonable policy moving forward- If your platform is otherwise supported by our policy but ships a version of Python from more than five years ago (aka is EOL upstream), you *may* be required to install a newer, optional version (if and only if one is reasonably available from official distro repositories.) In general, this should have little to no impact except that isolated, offline builds (a la rpmbuild) may fail to produce documentation unless special considerations are taken for the build environment (namely, sphinx needs to be loaded for the newer interpreter). I think this is a reasonable compromise. If distributions want to package bleeding edge QEMU with five-years-old dependencies, they can expect to face *some* hurdles, and figuring out how to get sphinx as a builddep to build an optional component is not entirely unreasonable. TLDR - I pledge to support any platform covered by our promise for building, but testing and documentation *requires* a non-EOL interpreter. This should have little to no effect for developers or users building from source or git, but has minor drawbacks for downstream maintainers of enterprise distributions that may attempt to backport bleeding edge QEMU versions. > > opensuse_leap_15_6 3.6.15 20.0.2 44.1.1 2.3.1 updates/sle, > > We use the 3.11 runtime in the dockerfile, see > tests/lcitool/mappings.yml. That is a bare minimum install, so > configure won't use the distro sphinx and instead use 5.3.0 from > pythondeps.toml. > Yep, this tool was made to show the platform defaults only for now. Maybe I'll add a "show first party backports" flag in the future, if anyone more than just my own personal self would find that useful. (Speak up if so.) > > main/oss > > pkgsrc_current 3.12.11 25.1.1 80.9.0 8.2.3 --- > > ubuntu_22_04 3.10.12 22.0.2 59.6.0 4.3.2 > > jammy-updates/main, jammy/universe, jammy/main > > This is the second oldest version of Sphinx. > With us until 26.04, in about 0.75 years. This seems like a reasonable new minimum if we wanted to increase it, though that does artificially drop support for RHEL9/CentOS stream building documentation from source under rpmbuild. (FWIW I probably can continue to support sphinx 3.x for a little while, the code is gross but it does appear functional. The only thing we *need* to do is bump the preferred version, I think. This support generally comes at the expense of type checking support for the docs code, as it's so gross I couldn't get it to work from 3.x to 8.x inclusive.) > > ubuntu_24_04 3.12.3 24.0 68.1.2 7.2.6 noble/main, > > noble/universe > > ubuntu_24_10 3.12.7 24.2 74.1.2 7.4.7 > > oracular/main, oracular/universe > > ubuntu_25_04 3.13.3 25.0 75.8.0 8.1.3 plucky/main, > > plucky/universe > > > > (3) CentOS stream does not ship "sphinx" except via "CRB", which I > > think may not be enabled by default. > > It's not, but it's intended to be enabled when developing against the > Red Hat packages. We enable it in the dockerfile: > > dnf config-manager --set-enabled -y crb > Sounds good! I was just taking care to be diligent about which repositories this tool compiled info from in order to give a very honest snapshot. I made careful note of any "weird" ones that may or may not be considered platform standards. > > (4) OpenSUSE Leap 15.6 is egregiously old. 16.x is promised for later > > this year, but we are past the promised "five year" support window for > > this platform in some sense -- 15.0 released in 2018 -- so I believe > > it can actually be ignored. > > As far as Python is concerned, OpenSUSE 15 doesn't cause trouble anyway, > because we do not use the 3.6 interpreter and its very old distro packages. > > So that's two reasons to ignore OpenSUSE. > Yep, just formally stating that not only do we have a workaround, but we may have run afoul of the five year window regardless. Hopefully a non-issue once 16 ships. (I am of course glad it works anyway!) Just interesting to note that OpenSUSE would already have the same problems CentOS 9 might in the near future: optional Python upgrade is available, but distro-packaged Sphinx upgrade may not be. > > (5) Ubuntu only ships pip in "universe", but also ships some Python > > 3.x interpreter updates to that repository as well. I have filtered > > this list to only use Universe for pip packages, leaving Python the > > base version that ships with the platform in x/main or x-updates/main. > > Yes, fair enough. Ubuntu 22.04 came out more recently than CentOS > Stream 9, after all, and its base distribution is more up to date than > CS9 with respect to the Python ecosystem. Rust is where Ubuntu (both > 22.04 and 24.04) is considerably less updated. > > Paolo > > > (6) "ports" collections (FreeBSD, NetBSD, OpenBSD/pkgsrc_current, > > Homebrew and MacPorts) do not necessarily have the concept of a > > platform default Python interpreter version, but other packages in the > > collection can be used as a heuristic to determine which one is best > > suited. > > > > For instance, FreeBSD and NetBSD only ship pip et al for a single > > interpreter version. > > OpenBSD has a symbolic "python3" package that installs a specific > > version. Homebrew has a "python3" alias that chooses a specific Python > > interpreter version. MacPorts similarly has a symbolic "py-setuptools" > > package that will choose a specific interpreter version. > > > > These are used as heuristics to determine a "de-facto" default for the > > ports collection platforms. > > > > - > > > > That's all for now. I will publish the script to the list later, > > though I have no intention of cleaning it up for inclusion in our > > tree. When I send it, bookmark the email if you'd like to try using > > this for other purposes or running it for yourself. Maybe I will throw > > it up on my personal GitLab in case it is useful to other subsystem > > maintainers in the future. The filtering code is a little messy, but > > it got the job done and should be reasonably straightforward to make > > sense of at a glance. It uses only the 'requests' library as a third > > party dependency. > > > > Your humble Python sin-eater, > > --js > > > > > > > >
