On 6 February 2018 at 00:38, Ivan Pozdeev <vano@mail.mipt.ru> wrote:
On 05.02.2018 16:51, Nick Coghlan wrote:
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?
For most distribution decisions, that level of detail is going to be irrelevant: what's relevant is being able to get a rough sense of how exclusive you're being. Choosing manylinux2010 in 2018+ means "not very exclusive", as if someone is in a sufficiently conservative deployment environment that the base platform isn't even keeping within 8 years of upstream development, the fact they can't use community provided precompiled binaries is likely to be among the least of their concerns. By contrast, choosing manylinux2014 in 2018 *would* risk excluding quite a few common deployment environments, since it's still in that 5-7 year window where a lot of conservative environments are grudgingly admitting that they really do need to update their base platform.
(Normally, a year in an entity's name means that entity's release year.)
The year we happen to define any given manylinux version is pretty close to entirely irrelevant to anything (e.g. manylinux1 was defined in 2016, but the platform interface it describes has been available since 2007). The only reason the definition year isn't *completely* irrelevant is because pip et al can only start supporting it once we define it, so folks that aren't following our "always use a recent version of the installation toolchain, regardless of target platform" guidance may end up needing to care about when a particular version was defined.
That, provided I even remember the relevant years -- since compatibility is governed by other things, I have absolutely no reason to.
The year informs the versions of libraries that we pick to include the baseline: every ABI in manylinux2[010] will have been available to distros in 2010 (when RHEL 6 was released), just as everything in manylinux1 was around in 2007 (when RHEL 5 was released). The fuzziness is then conveyed by the "many" in manylinux, since we do things like assuming the use of glibc, which isn't a universally accurate assumption (e.g. the default Alpine Linux based images published by Docker use musl libc rather than glibc, so they don't provide a manylinux compatible platform). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia