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 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.
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.