On 02.02.2016 01:30, Donald Stufft wrote:
On Feb 1, 2016, at 6:37 PM, Matthias Klose <d...@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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
