这四个包管理器比创建它们的 Linux 发行版更持久
对于那些花费大量时间宣扬稳定性的项目来说，Linux 发行版却异常容易消亡。一个发行版可能会失去企业支持、分化成多个分支、更换基金会，或者逐渐从行业讨论中消失，直到它仅作为你多年前使用过的安装程序界面的模糊记忆存在。与此同时，它引入的软件包管理器往往会不以为意地继续存在，伴随完整的依赖图穿越 Linux 历史，其目的保持不变。
这是包管理器有趣的部分。它们不仅仅是你从论坛上复制的命令，并希望你的系统不会因此崩溃。它们是基础设施，而基础设施往往比品牌存在得更久。一个发行版可能消失、缩小或转为不同角色，但如果它的工具解决了实际问题，这些工具往往会找到新的归宿。有时它们成为企业级 Linux 的基础层。有时它们成为兼容的操作习惯。有时它们最终隐藏在设备的构建系统中，而这些设备看起来完全不像启发它们的发行版。
转速
红帽 Linux 的软件包格式成为了大家的基础设施
RPM是显而易见的起点，因为它可能是最成功的从原始发行版环境中脱颖而出的软件包工具的例子。老的红帽Linux系列在2000年代初结束，Fedora成为面向社区的分支，而红帽企业Linux成为稳定的、受支持的、适合公司使用的订阅版本，这些公司喜欢诸如“认证平台”这样的短语。与此同时，RPM并没有收起它的宏而退休。
最初被称为红帽软件包管理器——后来采用了巧妙的递归缩写“RPM软件包管理器”——它为Linux软件提供了一种更有条理的方式来安装、查询、验证、升级和移除软件。现在听起来很平凡，但当替代方案是手动解压tar包并发现你的系统已经变成依赖关系的犯罪现场时，“平凡”就是一种赞美。
重要的警告是，Red Hat 并没有消失。它变得更加有影响力，而不是减少。RPM 所超越的，是赋予它名字的最初 Red Hat Linux 背景。今天，RPM 仍然是 Fedora、RHEL、CentOS Stream、AlmaLinux、Rocky Linux、openSUSE、Mageia、OpenMandriva、Oracle Linux 以及许多企业软件发行版的基础层。大多数用户并不会每天直接使用它，因为 DNF、Zypper 和其他前端工具位于其之上，用于管理基于 RPM 的 Linux 发行版的软件包，但这只证明了这一点。RPM 已成为基础设施，而良好的基础设施不是你每天早上都会考虑的东西。当它停止工作时，你会很快注意到。
好吃
Yellow Dog 的更新器世系变成了 Red Hat 的肌肉记忆
YUM 有一个那种听起来像玩笑的 Linux 名字，直到你意识到其中隐藏了多少服务器历史。Yellowdog Updater, Modified 来源于 Yellow Dog Updater (yup) 血统，但这个工具本身是在杜克大学开发的，旨在使基于 RPM 的包管理不那么痛苦。这个区别很重要，因为 YUM 并不仅仅是 Yellow Dog Linux 的包管理器闯入 Red Hat 领域。它是对一个想法的重写和进化，这个想法远远超越了它最初的 PowerPC 风格血统。它的工作很容易解释，也很令人愉快体验：不让人们手动追逐 RPM 依赖。
在像 YUM 这样的工具变得普及时，在基于 RPM 的系统上安装软件可能需要经历一次令人头疼的依赖搜索。你想要安装一个软件包，然后它需要三个库，再然后那些库又需要其他东西，最终你不得不开始质疑自己周末的计划。YUM 通过使用软件仓库、解决依赖关系并拉取必要的软件包，使这个过程变得更加合理。
很长一段时间，YUM 是你在 Fedora、CentOS、RHEL、Scientific Linux、Oracle Linux 以及其他基于 RPM 的系统上预期使用的包管理器。如果你在那个时代学习 Linux 管理，yum install 很可能和 service httpd restart 以及对损坏仓库的轻微恐惧一样，存放在你大脑的同一个抽屉里。
这里有趣的生存故事并不是 YUM 仍然是光明的未来。事实并非如此。多年前，Fedora 就已经将 DNF 作为默认的命令行包管理器，而现代的 RHEL 在底层使用了 DNF 技术。然而，Red Hat 仍然保留了 yum 这个术语以保持连续性。当你比较 APT、DNF 和 YUM 时，你会发现，在较新的系统上，yum 和 dnf 通常作为兼容路径进入相同的现代机制。
APT-RPM
活过一位巴西先驱的弗兰肯斯坦怪物
APT-RPM 是我会推荐给那些喜欢在 Linux 历史中寻找秘密通道的读者的内容。回到 1990 年代末和 2000 年代初，Linux 生态系统的分裂不仅体现在桌面环境和 init 参数上，还体现在包管理理念上。一方面，Debian 拥有 apt-get，它很神奇，因为它可以自动解决和下载软件依赖。另一方面，基于 RPM 的发行版使用 RPM 格式，这种格式功能强大且被广泛使用。然而，如果手动管理软件包，日常体验仍可能变成依赖地狱。
Conectiva 观看了那个问题并选择了混乱，但那是有用的混乱。这款巴西的 Linux 发行版喜欢 RPM 软件包，但它显然不喜欢管理这些软件包时经常出现的痛苦。因此，它的开发者将 Debian 的高级打包工具（Advanced Packaging Tool）改造为可以与 RPM 数据库而不是 Debian 的 .deb 软件包一起使用。APT-RPM 在 YUM 和 DNF 成为显而易见的解决方案之前，为 RPM 用户提供了一种 apt 风格的体验。它可以安装、升级和删除软件，同时自动处理依赖关系，这让人感觉好像有人将 Debian 的简便性偷偷带入了 RPM 领域。如果你当时被困在旧的软件包管理分界中，这可是一件大事。
Conectiva 本身并未作为独立的发行版存活下来。2005 年，Mandrakesoft 收购了 Conectiva，合并后的公司成为 Mandriva。Mandriva 后来分裂并逐渐淡出 Linux 的历史，只留下项目、分支以及桌面 Linux 曾经是一个拥挤市场的回忆，那时每个人都在不同的软件包格式上争论不休。与此同时，APT-RPM 比 Conectiva 这个名字存续的时间要长得多。像 ALT Linux、Vine Linux 和 PCLinuxOS 这样的发行版将其作为重要的软件包管理工具使用。尤其是 PCLinuxOS，多年来将 APT-RPM 与 Synaptic 配对使用，创造出一种奇妙而奇特的体验，让用户通过他们惯于 Debian 风格系统使用的工具来管理 RPM 软件包。
现代的警告很重要：APT-RPM 不再是未来。它的开发已经冷却，更广泛的 RPM 世界围绕 YUM 然后是 DNF 集中起来，即使是 PCLinuxOS 也一直在转向 DNF，因为它旧的 APT/Synaptic 堆栈不再有足够的长期维护。
搬运
Gentoo 从未消亡，但 Portage 的发展超出了预期
Portage 是这里最棘手的条目，因为 Gentoo 并没有消亡。它依然活跃，依然自豪地属于 Gentoo，并且仍在等待合适的人来决定编译浏览器是一种性格锻炼。所以故事并不是 Portage 以同样的方式比 Gentoo 存活得更久，就像 RPM 比 Red Hat Linux 存活得久，或者 APT-RPM 比 Conectiva 存活得久。更好的故事是，Portage 超越了 Gentoo 的主流影响力。
Gentoo 曾在 Linux 文化中占据一个特殊的位置。在2000年代初至中期，使用它带有某种声望。它是那些希望每个软件包都为其硬件特意编译、通过精细调整的 USE 标志控制每个功能、并从源代码组装系统每个角落的人所使用的发行版。编译时间可能会很折磨人，但炫耀权利和深度定制往往使切换到 Gentoo Linux 的麻烦值得。随着 Linux 变得更加易于访问，以及像 Ubuntu 这样的发行版普及了一种几乎不费力的体验，Gentoo 的影响力逐渐从主流讨论中消退。
然而，Portage 从未遵循相同的轨迹。
Portage 是一个基于源代码的包管理系统，围绕 ebuild、配置文件、覆盖层、依赖逻辑和 USE 标志构建，这些标志允许在构建时启用或禁用特性，并可以精细地定制系统。
这种灵活性也是 Portage 在 Chromium OS 和 Chrome OS 开发中获得意想不到的第二生命的原因。谷歌的 Chromium OS 构建环境使用 Gentoo 的 Portage 和 emerge 进行包管理。在这种情况下，使用 Portage 并不是因为有人想要一个复古爱好者的桌面系统。而是因为它的 ebuilds、覆盖层、每块板的配置、交叉编译和特性标志的模型，非常适合应对为多种硬件目标构建操作系统镜像的复杂现实。
在谷歌的 ChromeOS Bazel 迁移工作中，韧性依然可见。即使 ChromeOS 正在向 Bazel 过渡，旧的 Portage 配置模型也已经深深嵌入，无法通过一次英雄式的提交来完全替换。迁移设计讨论了 ebuild 仓库、覆盖层、USE 标志，以及将 Portage 富表达的配置模型直接翻译成 Bazel 概念的困难。
发行版会消亡；好的工具不会
包管理器解决了一个问题，这个问题不会因为发行版的资金枯竭或其目标受众转移而消失。只要在 Linux 系统上需要安装、更新和删除软件，任何能够很好完成这项工作的工具都会找到新的使用者。
发行版获取截图和发布名称，但包管理器往往成为 Linux 长期使用的机制，即使原始故事已经过去很久。