[Distutils] draft PEP: manylinux1

[Nathaniel Smith]

On Fri, Jan 29, 2016 at 11:35 AM, Nate Coraor <nate at bx.psu.edu> wrote:
> On Fri, Jan 22, 2016 at 6:29 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> On 22 January 2016 at 20:48, M.-A. Lemburg <mal at 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