[Distutils] draft PEP: manylinux1

[Matthias Klose]

On 21.01.2016 04:55, Nathaniel Smith wrote:

the choice of compiler is questionable.  Just a pick into a release series. Not 
even the last released version on this release series.  Is this a good choice? 
Maybe for x86_64 and i386, but not for anything else.

> The permitted external shared libraries are: ::
>
>      libpanelw.so.5
>      libncursesw.so.5

this doesn't include libtinfo, dependency of libncursesw.

>      libgcc_s.so.1
>      libstdc++.so.6

if you insist on a version built from before GCC 5, you are in trouble with the 
libstdc++ ABI. So maybe link that one statically.

>      libgobject-2.0.so.0
>      libgthread-2.0.so.0
>      libglib-2.0.so.0

while glib2.0 is somehow frozen, what will you do if these change the soname?

libgfortran is missing from this list while later down you mention gfortran. 
This will include libquadmath too.

Any reason to not list libz?

> Compilation and Tooling
> =======================

so how are people supposed to build these wheels?  will you provide a 
development distribution, or do you "trust" people building such wheels?

> Platform Detection for Installers
> =================================
>
> Because the ``manylinux1`` profile is already known to work for the many
> thousands of users of popular commercial Python distributions, we suggest that
> installation tools like ``pip`` should error on the side of assuming that a
> system *is* compatible, unless there is specific reason to think otherwise.
>
> We know of three main sources of potential incompatibility that are likely to
> arise in practice:
>
> * A linux distribution that is too old (e.g. RHEL 4)
> * A linux distribution that does not use glibc (e.g. Alpine Linux, which is
>    based on musl libc, or Android)
> * Eventually, in the future, there may exist distributions that break
>    compatibility with this profile

add: "A Linux distribution that is built with clang", e.g. Mageia (libc++ 
instead of libstdc++).

> Security Implications
> =====================
>
> One of the advantages of dependencies on centralized libraries in Linux is
> that bugfixes and security updates can be deployed system-wide, and
> applications which depend on on these libraries will automatically feel the
> effects of these patches when the underlying libraries are updated. This can
> be particularly important for security updates in packages communication
> across the network or cryptography.
>
> ``manylinux1`` wheels distributed through PyPI that bundle security-critical
> libraries like OpenSSL will thus assume responsibility for prompt updates in
> response disclosed vulnerabilities and patches. This closely parallels the
> security implications of the distribution of binary wheels on Windows that,
> because the platform lacks a system package manager, generally bundle their
> dependencies. In particular, because its lacks a stable ABI, OpenSSL cannot be
> included in the ``manylinux1`` profile.

so you rely on the python build to provide this and access OpenSSL through the 
standard library?


 From my point of view this draft is too much influenced by Anaconda and their 
needs.  It doesn't talk at all about interaction with other system libraries, or 
interaction with extensions provided by distributions.

Matthias