On Fri, Jan 29, 2016 at 11:35 AM, Nate Coraor <nate@bx.psu.edu> wrote:
On Fri, Jan 22, 2016 at 6:29 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 22 January 2016 at 20:48, M.-A. Lemburg <mal@egenix.com> wrote:
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.
For the time being, these users should either pass the "--no-binary" option to pip, ask their distro to provide an index of pre-built wheel files for that distro (once we have the distro-specific wheel tagging PEP sorted out), or else ask their distro to update system Python packages in a more timely fashion (or all of the above).
Is there a distro-specific wheel tagging PEP in development somewhere that I missed? If not, I will get the ball rolling on it.
It's all yours, I think :-). Some unsolicited advice that you can take or leave...: I think there are two separable questions that are easy to conflate here: (1) the use of a distro tag to specify an ABI ("when I say libssl.so.1, I mean one that exports the same symbols and semantics as the one that Fedora shipped"), and (2) the use of a distro tag for packages that want to depend on more system-supplied libraries and let the distro worry about updating them. I also think there are two compelling use cases for these: (a) folks who would be happy with manylinux, except for whatever reason they can't use it, e.g. because they're on ARM. I bet a platform tag for Raspbian wheels would be quite popular, even if it still required people to vendor dependencies. (b) folks who really want integration between pip and the distro package manager. So my suggestion would be to start with one PEP that just tries to define distro-specific platform tags to answer question (1) and targeting use case (a), and then a second PEP that adds new metadata for specifying external system requirements to answer question (1) and target use case (b). The advantage of doing things in this order is that once you have a platform tag saying "this is a Debian wheel" or "this is a Fedora wheel" scoping you to a particular distribution, then your external package metadata can say "I need the package 'libssl1.0.2' version 1.0.2e-1 or better" or "I need the package 'openssl' version 1.0.2e-5.fc24 or better", and avoid the tarpit of trying to define some cross-distro standard for package naming. -n -- Nathaniel J. Smith -- https://vorpus.org