摘要

本 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 中提取了其白名单共享库及其符号版本，这是编写 PEP 时最旧的支持的 CentOS 版本。不幸的是，CentOS 5.11 已于 2017 年 3 月 31 日结束生命周期，并明确警告不要继续使用。 [4] 不会再有进一步的更新，例如安全补丁。这意味着其软件包将保持过时版本，阻碍了使用 manylinux1 Docker 镜像的 Python 软件打包者的努力。

CentOS 6 现在是最旧的支持的 CentOS 版本，并将通过 2020 年 11 月 30 日收到维护更新。 [5] 我们提议创建一个新的 PEP 425 风格的平台标签，名为 manylinux2010，该标签将源自 CentOS 6，并更新 manylinux 工具链、PyPI 和 pip 以支持它。

最初提议将其命名为 manylinux2，但版本控制已更改为使用日历年（也称为 CalVer [22]）。这使得更容易按任意顺序定义未来的 manylinux 标签：例如，一个假设的 manylinux2017 标准可以通过新的 PEP 在 manylinux2014 之前定义，或者可以定义一个 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] 出于与 PEP 513 中概述的相同原因，libpythonX.Y 仍然不符合包含条件。

   在 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_2.4 版本 glibc 符号的二进制工件，因为这是早于 GLIBC_2.12 最大值的版本。

4. 如果 wheel 是为 CPython 2 的任何版本或 Python 3.0（包括 3.2）的版本构建的，那么它必须包含一个 CPython ABI 标签，指示其 Unicode 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 平台标签添加到在 manylinux2010 Docker 容器中通过 pip wheel 或 bdist_wheel 构建的 linux wheel 中。

安装程序的平台检测

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

如果找不到 _manylinux 模块，或者它没有 manylinux2010_compatible 属性，工具可以回退到检查 glibc。如果平台具有 glibc 2.12 或更新版本，则假定其兼容，除非 _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 wheel 被视为 manylinux2010 wheel。因此，一个识别 manylinux2010 平台标签的 pip，即使在明确设置的情况下，当没有可用的 manylinux2010 wheel 时，也会为 manylinux2010 平台安装 manylinux1 wheel。 [21]

PyPI 支持

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

PEP 571 变更摘要

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

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

参考资料

版权

本文档已进入公共领域。