[Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

[Matthias Klose]

On 02.02.2016 01:30, Donald Stufft wrote:
>
>> On Feb 1, 2016, at 6:37 PM, Matthias Klose <doko at ubuntu.com> wrote:
>>
>> On 30.01.2016 00:29, Nathaniel Smith wrote:
>>> Hi all,
>>>
>>> I think this is ready for pronouncement now -- thanks to everyone for
>>> all their feedback over the last few weeks!
>>
>> I don't think so.  I am biased because I'm the maintainer for Python in Debian/Ubuntu.  So I would like to have some feedback from maintainers of Python in other Linux distributions (Nick, no, you're not one of these).
>>
>> The proposal just takes some environment and declares that as a standard.  So everybody wanting to supply these wheels basically has to use this environment. Without giving any details, without giving any advise how to produce such wheels in other environments. Without giving any hints how such wheels may be broken with newer environments.
>
> I’m not sure this is true. It tells you exactly what versions of glibc and other libraries it is allowed to link against. It can link against older if it wants, it can’t link against newer.
>
>> Without mentioning this is am64/i386 only.
>
> First sentence: This PEP proposes the creation of a new platform tag for Python package built distributions, such as wheels, calledmanylinux1_{x86_64,i686} with external dependencies limited to a standardized, restricted subset of the Linux kernel and core userspace ABI.

I read "such as wheels, calledmanylinux1_{x86_64,i686}" as not limited to such 
platforms.

> Later on: Because CentOS 5 is only available for x86_64 and i686 architectures, these are the only architectures currently supported by the manylinux1 policy.

sorry, didn't see that.

> I think it’s a reasonable policy too, AMD64 is responsible for an order of magnitude more downloads than all other architectures on Linux combined (71,424,040 vs 1,086,527 in current data set). If you compare AMD64+i386 against everything else then you’re looking at two orders of magnitude (72,142,511 vs 368,056). I think we can live with a solution that covers 99.5% of all Linux downloads from PyPI.

But then why call it manylinux instead of centos5? You build it on this OS, you 
expect others to build it on this OS. just name it what it is.

>> There might be more. Pretty please be specific about your environment.  Have a look how the LSB specifies requirements on the runtime environment ... and then ask yourself why the lsb doesn't have any real value.
>>
>
> Instead of vague references to the LSB, can you tell us why you think the LSB doesn’t have any real value, and importantly, how that relates to trying to determine a minimum set of binary ABI. In addition, can you clarify why, if your assertion is this isn’t going to work, can you state why it won’t work when it is working for many user’s in the wild through Anaconda, Enthought, the Holy Build Box, etc?

I'm not seeing the LSB used in real life (anymore), and not any recent updates. 
Furthermore, LSB packages were removed in Debian [1].

[1] https://lists.debian.org/debian-lsb/2015/07/msg00000.html, 
https://lists.debian.org/debian-lsb/2015/07/msg00002.html