摘要

本 PEP 提案创建一个 manylinux2010 平台标签，以取代由 PEP 513 引入的 manylinux1 标签。它还建议更新 PyPI 和 pip 以支持在兼容平台上上传、下载和安装 manylinux2010 发行版。

基本原理

顾名思义，manylinux1 平台标签使得在许多 Linux 系统上安装二进制扩展模块成为现实。像 cryptography [2] 和 numpy [3] 这样的库现在更容易被 Python 开发人员访问，因为它们在常见架构上的安装不再依赖于脆弱的开发环境和构建工具链。

manylinux1 wheel 通过允许它们包含的扩展模块仅链接到一小部分导出足够旧的版本化符号以受益于向后兼容性策略的系统级共享库来实现其可移植性。例如，manylinux1 wheel 中依赖于 glibc 的扩展模块必须针对 2.5 或更早版本构建；然后它们可以在提供更新的 glibc 版本但仍然在 2.5 版本导出所需符号的系统上运行。

PEP 513 从 CentOS 5.11 中提取了其白名单共享库及其符号版本，CentOS 5.11 是其编写时最旧的支持的 CentOS 版本。不幸的是，CentOS 5.11 于 2017 年 3 月 31 日终止支持，并明确警告不要继续使用。 [4] 将不再提供任何更新，例如安全补丁。这意味着其软件包将保持在过时的版本，这阻碍了使用 manylinux1 Docker 镜像的 Python 软件打包人员的工作。

CentOS 6 现在是最旧的支持的 CentOS 版本，并且将在 2020 年 11 月 30 日之前收到维护更新。 [5] 我们建议从 CentOS 6 派生一个名为 manylinux2010 的新的 PEP 425 样式平台标签，并且更新 manylinux 工具链、PyPI 和 pip 以支持它。

最初将其提议为 manylinux2，但版本控制已更改为使用日历年份（也称为 CalVer [22]）。这使得更容易无序地定义未来的 manylinux 标签：例如，假设的 manylinux2017 标准可以在 manylinux2014 之前通过新的 PEP 定义，或者可以定义 manylinux2007 标准，该标准针对比本 PEP 旧但比 manylinux1 新的系统。

日历版本控制也大致了解哪些 Linux 发行版支持哪些标签：manylinux2010 将适用于 2010 年以来发布的大多数发行版版本。但这只是一个近似值：实际的兼容性规则定义如下，一些更新的发行版可能不满足这些规则。

manylinux2010 策略

以下标准决定了 linux wheel 是否有资格获得 manylinux2010 标签

1. wheel 只能包含为 CentOS 6 支持的两种架构之一编译的二进制可执行文件和共享对象：x86_64 或 i686。 [5]
2. wheel 的二进制可执行文件或共享对象不得链接到外部提供的库，除非是在以下白名单中

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

   此列表与 manylinux1 的白名单外部提供的库相同，减去 libncursesw.so.5 和 libpanelw.so.5。 [7] libpythonX.Y 由于与 PEP 513 中概述的原因相同，因此仍不符合包含条件。

   在 Fedora 30 发布包含 libcrypt.so.2 而不是 libcrypt.so.1 后，libcrypt.so.1 已从白名单中追溯删除。

   在基于 Debian 的系统上，这些库由以下软件包提供

   软件包	库
   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

   在基于 RPM 的系统上，它们由这些软件包提供

   软件包	库
   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. 如果 wheel 包含链接到任何也导出版本化符号的白名单库的二进制可执行文件或共享对象，则它们只能依赖于以下最大版本

   GLIBC_2.12
   CXXABI_1.3.3
   GLIBCXX_3.4.13
   GCC_4.5.0
   

   例如，manylinux2010 wheel 可以包含需要 glibc 版本为 GLIBC_2.4 的符号的二进制构件，因为这比 GLIBC_2.12 的最大值早。

4. 如果为任何版本的 CPython 2 或 CPython 3.0 及其包括 3.2 的版本构建 wheel，则 *必须* 包含一个指示其 Unicode ABI 的 CPython ABI 标签。然后，针对 Python 2 构建的 manylinux2010 wheel 必须包含 cpy27mu 标签（表示它针对具有 UCS-4 ABI 的解释器构建）或 cpy27m 标签（表示针对具有 UCS-2 ABI 的解释器构建）。（PEP 3149， [9]）
5. wheel *不得* 要求使用 PyFPE_jbuf 符号。这是通过针对 *不带* --with-fpectl configure 标记编译的 Python 构建它来实现的。

兼容 Wheel 的编译

与 manylinux1 一样，auditwheel 工具将 manylinux2010 平台标签添加到由 pip wheel 或 bdist_wheel 在 manylinux2010 Docker 容器中构建的 linux wheel。

安装程序的平台检测

平台可以在 PEP 513 中描述的 _manylinux 模块上定义一个 manylinux2010_compatible 布尔属性。如果该属性为 False，则认为该平台与 manylinux2010 不兼容。

如果找不到 _manylinux 模块，或者它没有 manylinux2010_compatible 属性，则工具可能会回退到检查 glibc。如果平台具有 glibc 2.12 或更高版本，则假设它与 manylinux2010 兼容，除非 _manylinux 模块另有说明。

具体来说，我们提出的算法是

def is_manylinux2010_compatible():
    # Only Linux, and only x86-64 / i686
    from distutils.util import get_platform
    if get_platform() not in ["linux-x86_64", "linux-i686"]:
        return False

    # Check for presence of _manylinux module
    try:
        import _manylinux
        return bool(_manylinux.manylinux2010_compatible)
    except (ImportError, AttributeError):
        # Fall through to heuristic check below
        pass

    # Check glibc version. CentOS 6 uses glibc 2.12.
    # PEP 513 contains an implementation of this function.
    return have_compatible_glibc(2, 12)

与 manylinux1 wheel 的向后兼容性

如 PEP 513 中所解释的，为 manylinux1 白名单库指定的符号版本构成一个上限。对于本 PEP 中为 manylinux2010 定义的符号版本也是如此。因此，manylinux1 轮子被视为 manylinux2010 轮子。因此，识别 manylinux2010 平台标签的 pip 将为 manylinux2010 平台安装 manylinux1 轮子（即使显式设置），前提是没有任何可用的 manylinux2010 轮子。[21]

PyPI 支持

PyPI 应该允许上传包含 manylinux2010 平台标签的轮子，就像允许上传 manylinux1 轮子一样。它不应尝试验证 manylinux2010 轮子的兼容性。

PEP 571 的更改总结

根据在 PEP 批准后收到的反馈，对 PEP 进行了以下更改

• libgcc_s 的最大版本符号已从 GCC_4.3.0 更新到 GCC_4.5.0 以解决 32 位 Cent OS 6 的问题。这不会影响 x86_64，因为 x86_64 的 libgcc_s 在 GCC_4.3.0 到 GCC_4.5.0 之间没有额外的符号。

参考文献

版权

本文档已进入公有领域。