[Distutils] draft PEP: manylinux2

[Ivan Pozdeev]

On 05.02.2018 16:51, Nick Coghlan wrote:
> On 5 February 2018 at 18:03, Ivan Pozdeev via Distutils-SIG
> <distutils-sig at python.org> wrote:
>> On 05.02.2018 5:15, Nick Coghlan wrote:
>>> The intended benefit of that is that it would allow folks to go ahead
>>> and propose newer manylinux variants that allow for ppc64le and
>>> aarch64 support as needed, without having to guess where those
>>> definitions should come in a sequential series.
>> IMO this will bring forth more confusion that it'll solve. Technically, the
>> ABI is linked to kernel and library versions rather than dates.
>> Since Linux, unlike commercial products, is not locked into a particular
>> vendor and thus doesn't have a single product life cycle forced upon it,
>> those vary wildly between distibutions and running installations.
> We pick the library API & ABI versions based on "compatible with most
> distributions released since year <X>", though (that's the "many" in
> "manylinux").
>
> As an illustrative example, manylinux1 was essentially manylinux2007,
> and it's now running into problems precisely because that baseline is
> more than a decade old. That's not obvious if all you know is the
> sequential number "1", but it makes intuitive sense once you realise
> the effective baseline year is back in 2007.
>
> Similarly, neither manylinux1 nor the proposed manylinux2[010] will
> ever support ppc64le or aarch64, because those instruction set
> architectures are too new relative to the API/ABI definitions. With
> the sequential numbering, any of that kind of reasoning based on
> relative dates requires looking up the PEP that defined that version,
> finding which version of RHEL/CentOS we used as a baseline, and then
> finding when the corresponding x.0 major version of RHEL was released.
>
> Or, we can just put the year directly in the version number, so that
> publishers can go "I'm happy to target manylinux2010, because I'm fine
> with users of distros that are more than 7 years old needing to
> compile from source".
The point is, a year has negative informativity in this case.

The very reasoning "compatible with most distributions released since 
year <X>" is flawed 'cuz it's vague and nonintuitive. Which is "most" 
distributions? Which part of the year X? Does that mean <distribution X 
version Y> is included or not? How do I even know all that without 
checking the spec? (Normally, a year in an entity's name means that 
entity's release year.) That, provided I even remember the relevant 
years -- since compatibility is governed by other things, I have 
absolutely no reason to.

A year would thus add confusion and/or encourage people to use that 
"easy way out" reasoning and not actually check what they're signing up 
for -- with the ensuing landmines to step on.

-- 
Regards,
Ivan