[Distutils] Working toward Linux wheel support

[David Cournapeau]

On Thu, Aug 13, 2015 at 2:05 AM, Nathaniel Smith <njs at pobox.com> wrote:

> On Aug 12, 2015 13:57, "Nate Coraor" <nate at bx.psu.edu> wrote:
> >
> > Hello all,
> >
> > I've implemented the wheel side of Nick's suggestion from very early in
> this thread to support a vendor-providable binary-compatibility.cfg.
> >
> >   https://bitbucket.org/pypa/wheel/pull-request/54/
> >
> > If this is acceptable, I'll add support for it to the pip side. What
> else should be implemented at this stage to get the PR accepted?
>
> From my reading of what the Enthought and Continuum folks were saying
> about how they are successfully distributing binaries across different
> distributions, it sounds like the additional piece that would take this
> from a interesting experiment to basically-immediately-usable would be to
> teach pip that if no binary-compatibility.cfg is provided, then it should
> assume by default that the compatible systems whose wheels should be
> installed are: (1) the current system's exact tag, (2) the special
> hard-coded tag "centos5". (That's what everyone actually uses in practice,
> right?)
>
> To make this *really* slick, it would be cool if, say, David C. could make
> a formal list of exactly which system libraries are important to depend on
> (xlib, etc.), and we could hard-code two compatibility profiles
> "centos5-minimal" (= just glibc and the C++ runtime) and "centos5" (= that
> plus the core too-hard-to-ship libraries), and possibly teach pip how to
> check whether that hard-coded core set is available.
>

So this is a basic list I got w/ a few minutes of scripting, by installing
our 200 most used packages on centos 5, ldd'ing all of the .so, and
filtering out a few things/bugs of some of our own packages):

/usr/lib64/libatk-1.0.so.0
/usr/lib64/libcairo.so.2
/usr/lib64/libdrm.so.2
/usr/lib64/libfontconfig.so.1
/usr/lib64/libGL.so.1
/usr/lib64/libGLU.so.1
/usr/lib64/libstdc++.so.6
/usr/lib64/libX11.so.6
/usr/lib64/libXau.so.6
/usr/lib64/libXcursor.so.1
/usr/lib64/libXdmcp.so.6
/usr/lib64/libXext.so.6
/usr/lib64/libXfixes.so.3
/usr/lib64/libXft.so.2
/usr/lib64/libXinerama.so.1
/usr/lib64/libXi.so.6
/usr/lib64/libXrandr.so.2
/usr/lib64/libXrender.so.1
/usr/lib64/libXt.so.6
/usr/lib64/libXv.so.1
/usr/lib64/libXxf86vm.so.1
/usr/lib64/libz.so.1

This list should only be taken as a first idea, I can work on a more
precise list including the versions if that's deemed useful.

One significant issue is SSL: in theory, we (as a downstream distributor)
really want to avoid distributing such a key piece of infrastructure, but
in practice, there are so many versions which are incompatible across
distributions that it is not an option.

David

> Compare with osx, where there are actually a ton of different ABIs but in
> practice everyone distributing wheels basically sat down and picked one and
> wrote some ad hoc tools to make it work, and it does:
> https://github.com/MacPython/wiki/wiki/Spinning-wheels
>
> -n
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150813/d01e870a/attachment.html>