On Mon, Mar 14, 2022 at 12:59 PM Christian Heimes email@example.com wrote:
On 14/03/2022 19.37, Brett Cannon wrote:
On Fri, Mar 11, 2022 at 5:04 PM Victor Stinner <firstname.lastname@example.org mailto:email@example.com> 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
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.
That concept doesn't exist anymore thanks to perennial manylinux support: https://peps.python.org/pep-0600/ .
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.
Since the glibc version support is now embedded as part of the tag for wheels on Linux, I don't think we can really specify a minimum anymore. In that case it probably comes down to simply saying a platform using glibc for the libc implementation is enough.