> On Jan 22, 2016, at 5:48 AM, M.-A. Lemburg <m...@egenix.com> wrote: > > Embedding additional libraries in the wheels files to overcome > deficiencies in the PEP design simply doesn't feel right > to me. > > People who rely on Linux distributions want to continue > to do so and get regular updates for system packages from > their system vendor. Having wheel files override these > system packages by including libs directly in the wheel > silently breaks this expectation, potentially opening > up the installations for security holes, difficult to > track bugs and possible version conflicts with already > loaded versions of the shared libs. > > IMO, that's much worse than having to install additional > system packages to make a Python wheel work. > > The embedding approach also creates licensing problems, > since those libs may be under different licenses than the > package itself. And of course, it increases the size of the > wheel files, causing more bandwidth to be necessary, > more disk space to be used for wheel caches, etc.
I think there are a few things here, but this is not my area of expertise so I could be wrong. As I understand it, The manylinux platform definition is largely going to be a documentation effort and there isn't going to be much in the way of enforcement. That means that people who build wheels against the manylinux platform tag are free to really do whatever they want even if it doesn't strictly match the definition of the manylinux platform. The difference here is that if you link against something that isn't included in the set of libraries, and that subsequently breaks due to an ABI incompatability, that's not a pip bug or a manylinux bug, that's a packaging bug with that particular library and they'll have to decide how they want to resolve it (if they want to resolve it). So you'll be free to link to anything you want, but you get to keep both pieces if it breaks and it's outside this defined set of libraries. I also agree that it's OK for users to have to ``apt-get`` (or whatever) a particular library to use something and we don't have to *only* rely on items that are installed as part of a "standard" linux base system. However, what is not OK (IMO) is for the PEP to bless something that has a high chance of ending up with ABI issues rather than "need to apt-get install" issues. For instance, even if you compile against a sufficiently old copy of OpenSSL, OpenSSL (to my understanding) does not have a stable ABI and you cannot take something compiled against OpenSSL on CentOS 5.reallyold and expect it to work on say Arch Linux. So I think there's an explicit list of packages that we know will generally work as long as you build against a sufficiently old copy of them and outside of that it's really a big unknown in general if a particular library can be used in this way or not. We obviously can't enumerate the list of every possible C library that has a stable ABI that can sanely be used cross distro but I think it's reasonable to list some sort of base minimum here, and if people experiment with stepping outside the standard list and can come to us and show "hey, I tried it with xyz library, we've gotten X installs and no complaints" we can then possibly expand the definition of the manylinux platform to include that library and move that project from depending on undefined behavior to defined behavior. Thinking of it in terms of a C like "undefined behavior" is probably a reasonable way of doing it. Linking against a system provided library that is on this list is a defined behavior of the manylinux "platform", linking against something else is undefined and may or may not work. At some level, once you've gotten to the point you're using pip to manage some set of your packages it doesn't really matter if that set of things you're pulling from PyPI includes a C library or not. If you're relying on say psycopg2 it's not clear to me that libpq *needs* to be getting security any more than psycopg2 itself does and so you'll need some method of solving that problem for your Python level dependencies anyways. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
