Abstract

This PEP proposes the creation of amanylinux2014 platform tag tosucceed themanylinux2010 tag introduced byPEP 513. It alsoproposes that PyPI andpip both be updated to support uploading,downloading, and installingmanylinux2014 distributions oncompatible platforms.

Rationale

CentOS 6 is now the oldest supported CentOS release, and will receivemaintenance updates through November 30th, 2020,[1] at which pointit will reach end-of-life, and no further updates such as securitypatches will be made available. All wheels built under themanylinux2010 images will remain at obsolete versions after thatpoint.

Therefore, we propose the continuation of the existing manylinuxstandard, and that a newPEP 425-style platform tag calledmanylinux2014 be derived from CentOS 7 and that themanylinuxtoolchain, PyPI, andpip be updated to support it.

Similar to howPEP 571 andPEP 513 drew allowed sharedlibraries and their symbol versions from CentOS 5.11 and CentOS 6,respectively, amanylinux2014 platform tag will draw its librariesand symbol versions from CentOS 7, which will reach end-of-life onJune 30th, 2024.[1]

ThemanylinuxYYYY pattern has a number of advantages that motivatecontinuing with the current status quo:

• Well-defined Docker images with clearly specified compatiblelibraries;
• No need to survey for compatibility issues across multiple releases;
• A single build image andauditwheel profile per architecture.

There are also some disadvantages:

• Requires drafting a new PEP for every new standard;
• Requires adding the new platform tag to installers (e.g.,pip);
• Installers are unable to install a platform tag which predates agiven release.

There are also challenges which would exist for any proposal,including the time and effort it takes to define, prepare and releasethe Docker images and correspondingauditwheel profiles. Thesechallenges were experienced in the long rollout period formanylinux2010, which took approximately 1 year from PEP acceptanceto compatible build environment published.[3]

However, if this PEP can be an indicator, the process is nowwell-defined and easily repeatable, which should increase the timelinefor rollout of a newer, updated platform tag.

Themanylinux2014 policy

The following criteria determine alinux wheel’s eligibility forthemanylinux2014 tag:

1. The wheel may only contain binary executables and shared objectscompiled for one of the following architectures supported by CentOS7, or a CentOS 7 compatible base image (such as ubi7):[4]

   x86_64i686aarch64armv7lppc64ppc64les390x

   This list adds support for ARMv7 (armv7l), ARMv8 (aarch64) and PowerPC(ppc64, ppc64le) architectures supported by the CentOS AlternativeArchitecture Special Interest Group, as well as the IBM Z (s390x)architecture.[5]

2. The wheel’s binary executables or shared objects may not linkagainst externally-provided libraries except those in the followinglist:

   libgcc_s.so.1libstdc++.so.6libm.so.6libdl.so.2librt.so.1libc.so.6libnsl.so.1libutil.so.1libpthread.so.0libresolv.so.2libX11.so.6libXext.so.6libXrender.so.1libICE.so.6libSM.so.6libGL.so.1libgobject-2.0.so.0libgthread-2.0.so.0libglib-2.0.so.0

   This list is identical to the externally-provided librariesoriginally allowed formanylinux2010, with one exception:libcrypt.so.1 was removed due to being deprecated in Fedora 30.libpythonX.Y remains ineligible for inclusion for the samereasons outlined inPEP 513.

   On Debian-based systems, these libraries are provided by thepackages:

   Package	Libraries
   libc6	libdl.so.2, libresolv.so.2, librt.so.1, libc.so.6,libpthread.so.0, libm.so.6, libutil.so.1, libnsl.so.1
   libgcc1	libgcc_s.so.1
   libgl1	libGL.so.1
   libglib2.0-0	libgobject-2.0.so.0, libgthread-2.0.so.0, libglib-2.0.so.0
   libice6	libICE.so.6
   libsm6	libSM.so.6
   libstdc++6	libstdc++.so.6
   libx11-6	libX11.so.6
   libxext6	libXext.so.6
   libxrender1	libXrender.so.1

   On RPM-based systems, they are provided by these packages:

   Package	Libraries
   glib2	libglib-2.0.so.0, libgthread-2.0.so.0, libgobject-2.0.so.0
   glibc	libresolv.so.2, libutil.so.1, libnsl.so.1, librt.so.1,libpthread.so.0, libdl.so.2, libm.so.6, libc.so.6
   libICE	libICE.so.6
   libX11	libX11.so.6
   libXext:	libXext.so.6
   libXrender	libXrender.so.1
   libgcc:	libgcc_s.so.1
   libstdc++	libstdc++.so.6
   mesa	libGL.so.1

3. If the wheel contains binary executables or shared objects linkedagainst any allowed libraries that also export versioned symbols,they may only depend on the following maximum versions:

   GLIBC_2.17CXXABI_1.3.7,CXXABI_TM_1isalsoallowedGLIBCXX_3.4.19GCC_4.8.0

   As an example,manylinux2014 wheels may include binaryartifacts that requireglibc symbols at versionGLIBC_2.12,because this an earlier version than the maximum ofGLIBC_2.17.

4. If a wheel is built for any version of CPython 2 or CPythonversions 3.0 up to and including 3.2, itmust include a CPythonABI tag indicating its Unicode ABI. Amanylinux2014 wheelbuilt against Python 2, then, must include either thecpy27mutag indicating it was built against an interpreter with the UCS-4ABI or thecpy27m tag indicating an interpreter with the UCS-2ABI. (PEP 3149[7])
5. A wheelmust not require thePyFPE_jbuf symbol. This isachieved by building it against a Python compiledwithout the--with-fpectlconfigure flag.

Compilation of Compliant Wheels

Likemanylinux1, theauditwheel tool addsmanylinux2014platform tags tolinux wheels built bypipwheel orbdist_wheel in amanylinux2014 Docker container.

Platform Detection for Installers

Platforms may define amanylinux2014_compatible boolean attributeon the_manylinux module described inPEP 513. A platform isconsidered incompatible withmanylinux2014 if the attribute isFalse.

If the_manylinux module is not found, or it does not have theattributemanylinux2014_compatible, tools may fall back tochecking for glibc. If the platform has glibc 2.17 or newer, it isassumed to be compatible unless the_manylinux module saysotherwise.

Specifically, the algorithm we propose is:

defis_manylinux2014_compatible():# Only Linux, and only supported architecturesfromdistutils.utilimportget_platformifget_platform()notin["linux-x86_64","linux-i686","linux-aarch64","linux-armv7l","linux-ppc64","linux-ppc64le","linux-s390x",]:returnFalse# Check for presence of _manylinux moduletry:import_manylinuxreturnbool(_manylinux.manylinux2014_compatible)except(ImportError,AttributeError):# Fall through to heuristic check belowpass# Check glibc version. CentOS 7 uses glibc 2.17.# PEP 513 contains an implementation of this function.returnhave_compatible_glibc(2,17)

Backwards compatibility withmanylinux2010 wheels

As explained inPEP 513, the specified symbol versions formanylinux1 allowed libraries constitute anupper bound. Thesame is true for the symbol versions defined formanylinux2014 inthis PEP. As a result,manylinux1 andmanylinux2010 wheelsare consideredmanylinux2014 wheels. Apip that recognizesthemanylinux2014 platform tag will thus installmanylinux2010wheels formanylinux2014 platforms – even when explicitly set –when nomanylinux2014 wheels are available.

PyPI Support

PyPI should permit wheels containing themanylinux2014 platformtag to be uploaded in the same way that it permitsmanylinux2010.

If technically feasible, PyPI should attempt to verify thecompatibility ofmanylinux2014 wheels, but that capability is nota requirement for adoption of this PEP.

Package authors should not upload non-compliantmanylinux2014wheels to PyPI, and should be aware that PyPI may begin blockingnon-compliant wheels from being uploaded.

References

Acceptance

PEP 599 wasaccepted by Paul Moore on July 31, 2019.

Copyright

This document is placed in the public domain or under theCC0-1.0-Universal license, whichever is more permissive.