On 05.02.2018 5:15, Nick Coghlan wrote:
On 1 February 2018 at 10:01, Mark Williams <m...@enotuniq.org> wrote:
Hi everyone!
The manylinux1 platform tag has been tremendously useful, but unfortunately
it's showing its age:
https://mail.python.org/pipermail/distutils-sig/2017-April/030360.html
https://mail.python.org/pipermail/wheel-builders/2016-December/000239.html
Nathaniel identified a list of things to do for its successor, manylinux2:
https://mail.python.org/pipermail/distutils-sig/2017-April/030361.html
Please find below a draft PEP for manylinux2 that attempts to address these
issues.
Thanks for this!
Something we've discussed in the past is switching manylinux over to a
variant of CalVer, where the manylinux version number inherently
conveys the era of operating system compatibility that each variant is
targeting. In the case of this PEP, that would be `manylinux2010`,
since the RHEL/CentOS 6 ABI was formally set with the release of RHEL
6 in November 2010.
The intended benefit of that is that it would allow folks to go ahead
and propose newer manylinux variants that allow for ppc64le and
aarch64 support as needed, without having to guess where those
definitions should come in a sequential series.
IMO this will bring forth more confusion that it'll solve. Technically,
the ABI is linked to kernel and library versions rather than dates.
Since Linux, unlike commercial products, is not locked into a particular
vendor and thus doesn't have a single product life cycle forced upon it,
those vary wildly between distibutions and running installations.
Would a manylinux2 -> manylinux2010 version numbering switch
significantly complicate implementation of the PEP?
Cheers,
Nick.
--
Regards,
Ivan
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
