
On 14/03/2022 19.37, Brett Cannon wrote:
On Fri, Mar 11, 2022 at 5:04 PM Victor Stinner <vstinner@python.org <mailto:vstinner@python.org>> wrote:
Hi Brett, You can put my name as Contact of all Fedora and RHEL platforms. Note: Fedora "Rawhide" is the rolling release and it's common that these buildbots are broken by kernel, compiler or glibc updates, rather than actual Python regressions. Time to time, it detects real Python regressions. Tier 2 should only target Fedora *Stable* (which is the case ;-)). > glibc XXX [fedora-stable] Mentioning that Fedora uses glibc is nice, but I don't think that it's worth it to mention the glibc version. Fedora is released every 6 months and the glibc version is updated at each Fedora release.
Christian had suggested/asked for that. So are people okay dropping the glibc version and instead documenting that it's testing glibc instead of e.g. musl?
Looks like I was not communicating my intention clearly. I don't want to list libc ABI and Kernel ABI of every targeted distro. Instead I would like to include only the glibc version of the oldest manylinux wheel standard that is supported by PyPI.
glibc has a strong forward compatibility guarantee. If something works with glibc 2.17, then it will also work with 2.34. A minimum glibc version sets the minimum feature set that we can rely on. If we say that Python is tested with glibc 2.17 and Kernel ABI 3.10 (CentOS 7), then we set CentOS 7 a baseline for users that also covers Debian Oldstable.
glibc and Kernel ABI are relevant for some features like getrandom() syscall, memfd_create, and similar.
Christian