We haven’t had any additional comments here in a few days, so I wanted to attempt to summarize the relevant discussion and talk about next steps:
(Please feel free to correct me if I’m missing, misconstruing or misunderstanding anything that was said)
- There is some confusion here about how only specifying the libc provider / libc version determines valid libraries to link against
- Saying “if it works for your users, it’s valid” might be too vague, and we would still need to explicitly define install-time checks to determine compatibility
- Generally it would be “if auditwheel (or another tool which does publication-time checking) allows it”, but we would need to point to such a tool in the specification
- If the glibc provider/version is only being used as a heuristic, it’s confusing to use it in the tag name
- It might be better instead make individual “heuristics” which can explicitly specify symbol version bounds for relevant libraries
- This sounds a lot like manylinux!
- Additional heuristics would also allow us to distro/VFX-specific heuristics
- It seems like folks are on board with allowing additional heuristics if possible
- Generally seems like folks value the detailed specification for binary compatibility such a proposal would provide
- Doesn’t seem to be any complaints about adding the additional PowerPC/ARM architectures that CentOS 7 supports.
- Unclear whether the proposed ARM architectures would be compatible w/ modern Raspbian
A combined proposal
If we can accept that manylinux is the “de-facto” glibc heuristic, perhaps we can continue to use this, with some additional flexibility, while remaining open to defining additional heuristics in the future.
@njs suggested a tag like:
manylinux_12_x86_64 (= installs on systems with glibc 2.12+)
This allows us to let the glibc version “slide” along the manylinux specification, but still has the issue of vaguely-specified symbol version bounds for relevant libraries.
What if we used a heuristic like:
manylinux2014_2_12_x86_64 (= installs on systems with glibc 2.12+, backed by a manylinux2014 spec)
We could explicitly specify some things (CXXABI, GLIBCXX, GCC, and externally provided libraries) in a manylinux2014 PEP, while still using the glibc as the “heuristic version identifier”. This means we don’t need a new PEP to use a different glibc version.
At a certain point in time, the glibc version will become too new compared to (CXXABI, GLIBCXX, GCC, etc) and we would still need to write a new manylinuxNNNN specification.
Would this work? Does it make sense? Would it be a good balance between the two ideas?