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
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
