[Distutils] draft PEP: manylinux2

[Joni Orponen]

On Mon, Feb 5, 2018 at 10:01 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 6 February 2018 at 00:35, Joni Orponen <j.orponen at 4teamwork.ch> wrote:
> > On Mon, Feb 5, 2018 at 2:51 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >>
> >> 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.
> >
> >
> > The 2007 baseline of a fairly conservative enterprise Linux distribution,
> > which relatively liberally backports features in point releases over the
> > lifespan.
>
> Red Hat only backports features that don't break ABI, so the year
> still sets the ABI baseline.
>

I'm not convinced all the dependencies of Python and especially of eggs out
there actually fall within compatibility level 2.

https://access.redhat.com/articles/rhel-abi-compatibility

> As discussed, the year does not ultimately mean all that much.
>
> It does, it drives the entire process, as we want to maintain
> compatibility with a broad range of environments, and the simplest
> metric for ensuring that is "How old is the baseline?".


Unless the name conveys the tie to RHEL, the easier assumption to make is
an Ubuntu LTS release as they brand versions with the year semantics. I'd
prefer a sequential number and an associated compatibility table.

It doesn't though, since once we have a few versions out there, it
> conveys *no* information about which potential users and deployment
> environments are being excluded by targeting a particular manylinux
> version.
>
> Compare:
>
> - manylinux1 vs manylinux2 vs manylinux3
> - manylinux2007 vs manylinux2010 vs manylinux2014
>
> In the first one, you have to go look at the PEPs defining each
> version to get any sense whatsoever of who you might be excluding by
> targeting each variant.
>
> In the second, it's pretty clear that you'd be excluding users of
> pre-2007 distros, pre-2010 distros, and pre-2014 distros respectively.
> It's a heuristic, not a precise guideline (you'll still need to
> compare PEPs to distro ABIs to get the exact details), but it conveys
> a lot more useful information than the plain sequential numbering
> does.


I'm not sharing the view of packagers being as systems oriented or aware of
packaging PEPs to catch this. What's happening within my bubble of
associates is "this is how you manylinux" and that'd be followed "this is
how you manylinux2 now".  The effort of providing the docker images and
such make this so opaque convenient people do not have to care. This is a
sign of a job very well done. Congratulations.

> Is there a particular reason for not picking RHEL 7 as the base for
> > manylinux2 at this point?
>
> Yes, it's too new - it would set the baseline at around 2014, which
> cuts out a lot of end user environments that are still in the process
> of being upgraded to newer alternatives (most notably RHEL/CentOS 6,
> since they're still supported, but other LTS distros still tend to
> linger past their nominal end of life dates).


These users would still be catered to by manylinux1.

I've provided an opinion and there is no need to seek consensus with me
beyond this exchange. Ultimately I'm nitpicking on semantics, which is not
very meaningful for the larger topic at hand.

-- 
Joni Orponen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180206/cb7cfb1e/attachment-0001.html>