On Thu, Jan 21, 2016 at 8:18 PM, Matthias Klose <d...@ubuntu.com> wrote:
> 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. FWIW, the list of libraries and the dockerfile was originally built from communications I had w/ Nathaniel and Matthew Brett, and I work for a continuum's competitor, so you can be fairly confident that there is no hidden agenda. David > > Matthias > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
