当我们谈论包管理器时，apt、dnf、pacman 与 npm、pip、cargo 常常被混为一谈。两者都解决依赖、下载代码、安装软件，但它们演化的目标场景截然不同，而这个交叠区域恰恰是所有摩擦的来源。C 库恰好坐落在两个生态系统的正中央：语言包需要它们，系统包管理器提供它们，但双方都无法以对方可理解的方式表达这种依赖关系。这种断裂构成了包管理领域中一个结构性的「C 型缺口」。
演化路径的根本分歧
系统包管理器的设计初衷是应用程序分发。用户需要安装 Firefox 或 LibreOffice，将应用分解为共享库只是一种实现优化手段，依赖图谱的存在是为了服务终端用户的补丁推送和安全更新。以 Debian 为例，python3-requests 这个包之所以存在，不是因为 Python 生态需要它，而是因为某个 GUI 应用或系统工具依赖它，维护者才将其打包进发行版。这种模式下，系统包管理器通常只保留每个包的一个版本，简化依赖解析的复杂度，但也意味着用户无法在不升级整个系统的情况下获取特定版本的库。这种「-stop-the-world」的模型催生了诸如将 python2 和 python3 命名为独立包之类的变通方案。
语言包管理器走了相反的道路。npm、pip、cargo 是面向开发者的依赖组装工具，它们允许项目无限期保留每个版本，支持精确的版本锁定，并且从设计之初就是跨平台的。pip 不关心自己运行在 Debian 还是 Fedora 上，因此即使它想调用系统包管理器安装 C 依赖也无法实现。pip install httpie 能直接得到一个可用的命令行工具，这只是副作用而非目的。这些工具的存在价值在于让开发者能够在清单文件中声明 requests>=2.28，然后获得一个可工作的依赖树。这种能力需要多个版本共存的能力，而系统包管理器从架构上就无法提供。
C 库的命名碎片化困境
C 语言从未发展出像 crates.io 或 npm 那样统一的包注册中心。它早于「从互联网下载依赖」的模式流行，当这种模式成为标准时，生态系统已经过于碎片化，难以收敛。pkg-config 作为部分词汇表存在，但它只是一个查询机制，用于发现系统中已安装的库，而非声明或获取依赖的方式。Conan 和 vcpkg 虽然存在并积极维护，但它们都没有获得 crates.io 或 npm 那样的文化普及度。对于「如何依赖 libcurl」这个问题，不存在像「如何依赖 serde」那样的默认答案。
系统包管理器以默认方式填补了这一空白。如果你需要 libcurl 或 OpenSSL 或 zlib，你通过 apt 或 dnf 或 brew 安装。这使得系统包管理器成为了事实上的 C 包管理器，无论它是否为此设计。而每个发行版对同一库的命名完全不同：Debian 上是 libssl-dev，Fedora 上是 openssl-devel，Alpine 上是 openssl，Homebrew 上是 openssl@3。同一个库，四种不同的名字，之间没有任何映射关系。每种需要 C 绑定包的语言都独立解决了分发问题：Python 有打包编译扩展的 wheels，Node 有在安装时编译系统头文件的 node-gyp，Rust 有调用 pkg-config 的 build.rs 脚本，Go 有自己的 cgo 链接策略，Ruby 有在 gem install 时编译的原生扩展。这些机制都无法以机器可读的方式真正声明 C 依赖。
如果你的 Python 包需要 libffi，这个需求只能存在于 README、Dockerfile 或者部落知识中。pyproject.toml 中没有字段能够表达「需要 libffi>=3.4」并让 pip 采取行动。PEP 725 从 2023 年起一直是草案状态，提议在 Python 打包元数据中添加外部 C 依赖的声明，但至今未能落地。结果是你得到了两个重叠在 C 库上的依赖图谱，却无法相互通信。
跨生态系统依赖的可见性工程
Conda 可能是目前最成功的桥接尝试。它将 C 库、Python、R 和其他语言打包进同一个依赖图中，允许用户同时声明对 libcurl 和 requests（或 libcurl 和某个 R 包）的依赖，并让 Conda 理解这意味着什么。这种方法在科学计算领域取得了成功，因为 NumPy 链接 BLAS、SciPy 需要 LAPACK、HDF5 绑定处理数据科学工作流，这些项目的原生代码库复杂，从源码编译痛苦，需要 Python 包装器和底层 C 库之间的版本匹配。Conda 为所有这些内容提供了 proper 的元数据和版本约束。
但 Conda 从未变得普遍，部分原因是它将解决 C 依赖这个难题与一个对纯 Python 包不那么引人注目的解决方案捆绑在一起。如果你不需要编译扩展，Conda 就是大材小用。而且即使你需要它，conda 环境也比虚拟环境更重，依赖解析器在处理非平凡环境时曾经慢得令人难以忍受。Mamba 的存在很大程度上就是因为 conda 的依赖解析在复杂环境下的性能问题。Spack 和 EasyBuild 在 HPC 领域占据类似领地，需要对编译器标志、MPI 实现和硬件特定优化进行细粒度控制。Spack 有着异常复杂的依赖模型，能够在依赖链的各个点对编译器进行版本控制，并记录构建涉及的一切以保证可复现性，但这种复杂性只对大多数开发者永远不会遇到的使用场景才是合理的。
Nix 和 Guix 采取了另一种方式，以内容寻址存储和可复现性为核心设计目标。它们仍然是系统包管理器，仍然交付应用程序，但它们有更好的模型将语言包映射到那个世界。它们重新打包 PyPI 和 npm 上的内容，将 C 依赖和 Python 依赖表达在同一个依赖图中。有一个庞大的社区在保持这些映射的最新状态，将哪些 Python 和 npm 包依赖哪些系统库编码进去。这确实有效，但这仍然是一个系统吸收另一个系统，而不是两个系统相互对话，而且这些映射存在于 nixpkgs 中，而不是存在于上游包元数据中，其他工具本可以使用这些元数据。
工程实践中的监控与应对策略
解决这个缺口需要将隐式依赖变成显式依赖。当前的变通方案依赖人类在运行时发现缺失的依赖：运行 pip install，碰到关于缺少头文件的编译错误，然后谷歌哪个 apt 包提供了这些头文件。Dockerfile 积累了大量 RUN apt-get install 行来编码这些知识。漏洞扫描器查看语言包元数据，什么都看不到。Syft 这类工具爬取容器文件系统，在已知位置寻找已知的二进制文件和包清单。这是一种粗暴的手段，因为元数据根本不存在，所以 Syft 必须从文件系统启发式重建它能重建的一切。
更系统的方法是通过符号挖掘来映射跨生态依赖。nm、objdump 和 readelf 可以列出库导出的符号。在 apt、apk、rpm 和 Homebrew 包上运行这些工具，可以得到一个数据库：SSL_connect 符号来自 libssl，在 Debian 中打包为 libssl3，在 Alpine 中打包为 openssl，在 Homebrew 中打包为 openssl@3。对 wheel、gem 和原生 Node 模块做同样的事情，记录哪些符号是未定义的，哪些库是捆绑在包内部的。然后交叉引用：当一个 wheel 有一个未定义的符号时，数据库告诉它哪个系统库提供了它；当一个 wheel 捆绑了一个库时，你可以识别上游项目和版本。
这种数据的用途是多方面的。在可持续性层面，如果 Open Source Pledge 要求公司为其依赖付费，那么对系统库的依赖就无处可循，这意味着它们是隐形的。NumPy 严重依赖 OpenBLAS，但这种关系在赞助 NumPy 或分析其依赖树时不会显示出来。OpenBLAS 维护者不会因为使 NumPy 变快的工作而获得认可。如果软件引用在学术界流行，同样的问题也适用：引用 NumPy 的论文应该将学分传播到 BLAS，但前提是我们能够追踪依赖关系。
在安全层面，当一个 C 库有 CVE 时，目前没有人能够告诉哪些 wheel 或 npm 包或 gem 捆绑了受影响版本。漏洞扫描器查看语言包元数据，什么都看不到。有了符号数据库，你可以从 CVE 追踪到上游库，再到每个捆绑它的包，跨生态系统。这也使得 SBOM 更准确：现在为一个项目生成 SBOM 会遗漏所有捆绑在包内部的 C 库。
面向未来的协议层思考
任何关于包管理协议的严肃尝试都需要应对这个 C 型缺口。跨生态系统依赖不是边缘情况，它们无处不在，只是不可见。将这些隐式依赖提升为一流公民是两个世界之间缺失的一层，它需要成为协议进一步被调查时对话的一部分。HyperRes 这类超图依赖解析方法试图通过形式化系统来描述版本化依赖解析，能够表达许多生态系统并解决它们之间的依赖约束，这为跨生态依赖提供了理论框架。
在实践中，团队可以采取几项具体措施来缓解这个问题。首先是在构建流程中显式声明系统级依赖，将 apt、apk 或 brew 的包列表纳入版本控制，而非依赖文档或口头传承。其次是使用容器作为锁文件，确保每次构建得到相同的字节，减少「在我机器上能运行」的问题。第三是集成软件成分分析工具，定期扫描捆绑的原生依赖，追踪其安全漏洞。最后是在评估新依赖时，不仅考虑语言层的依赖，还要追溯到底层的 C 库依赖，评估其维护状态和潜在风险。
包管理器的 C 型缺口不是一个可以轻松「修复」的问题，它是两个演化路径不同的生态系统在各自优化目标时的必然交集。认识到这个缺口的存在，理解其根源，是在这个复杂领域中做出明智决策的第一步。
参考资料
- Andrew Nesbitt，《The C-Shaped Hole in Package Management》，2026 年 1 月 27 日，https://nesbitt.io/2026/01/27/the-c-shaped-hole-in-package-management.html
- Ryan Gibb 等，《Solving Package Management via Hypergraph Dependency Resolution》，arXiv:2506.10803，2024 年
- PEP 725，《Specifying external C library dependencies in pyproject.toml》，https://peps.python.org/pep-0725/