![许多包管理器 - RedHat/CentOs 上的 .deb](https://linux22.com/image/194141/%E8%AE%B8%E5%A4%9A%E5%8C%85%E7%AE%A1%E7%90%86%E5%99%A8%20-%20RedHat%2FCentOs%20%E4%B8%8A%E7%9A%84%20.deb.png)
(对于 Linux 发行版来说相对较新)
是什么禁止我在 Redhat/CentOS 上安装 .deb 软件包(使用 apt 或 dpkg)?或者 Debian/Ubuntu 中的 .rpm 软件包?
据我了解,基于 Debian/Ubuntu 的系统使用 apt 和 dpkg(.deb 文件)作为包管理器,而基于 RedHat 的系统使用 .rpm。但这些只是惯例/偏好还是差异更深远?
Internet 上描述如何在 RedHat/CentOs 上安装 .deb 软件包的每个页面都讨论了如何转换首先到 .rpm 文件。
但是,是什么从根本上禁止某人在 RedHat/CentOS 中安装 dpkg 或 apt,然后使用它直接安装 .deb 文件呢?
我的理解是.deb 和 .rpm 都只是精美的 tarball!底层二进制文件应该能够在 RedHat/CentOs 和 Debian 中运行,对吗?我的意思是,如果我要在两个发行版中手动拥有相同的可执行文件,那么它应该在两个发行版中运行? (如果没有的话我当然会理解 .rpm 和 .deb 之间的不兼容性)
附加问题:当有人想要将二进制文件分发到 Linux 世界时,他必须支持多少个系统并将该二进制文件打包到其中? (显然他想要多少就多少,但你明白我的意思)
我觉得这很可疑,而且有点令人沮丧,因为以前似乎没有人问过这个问题。我可能错过了一些基本的东西,因为对此相对较新。
任何有关此事的文件也将受到欢迎。
答案1
通常没有什么会禁止您在同一系统上混合使用不同的包管理器(尽管发行版通常会修改打包的外部包管理器,以便它们无法安装外部包),尽管通常情况下,除非您真正知道自己在做什么,否则这会让人非常不悦。以下是这可能是一个非常糟糕的主意的大部分原因:
- 包管理器负责并承担管理文件系统的概念,并在自己的数据库中跟踪它。混合不同的包管理器意味着每个包管理器都在不知道其他包管理器的情况下跟踪路径名,因此它们会很乐意忽略 f.ex。版本化依赖项要求和文件冲突,并最终覆盖其他包管理器的路径名,导致意外和隐藏的版本化依赖项不满足。
- 虽然包格式通常应该具有或多或少的功能奇偶性,但它们仍然可能具有显着的语义差异。它们也不仅仅是容器文件系统负载,它们还包含包元数据,包括依赖性信息、将执行设置、修复或清理操作、自动触发操作等的维护者脚本或 scriplet。
- 此外,发行版之间的巨大差异(即使在使用相同包管理器的同一系列中)来自于它们的策略以及事物如何集成在一起(例如将内容放置在文件系统上的位置、在何处以及如何注册内容等) ),在许多情况下使用特定于发行版或特定于包管理器的接口(如
dpkg-divert
)、默认构建标志、打包粒度(如何以及在何处将上游项目拆分为发行版包)、要启用的上游功能、如何启用以及启用多少与上游分歧(如果有的话,例如,某些发行版具有 0 分歧政策,而其他发行版如果上游破坏了其 ABI,则很乐意使用共享库 SONAME,但不会为此发布修复程序)。 - 没有什么可以保证发行版 A 中的名称与发行版 B 中的上游项目相同,命名空间是独立的,甚至版本空间也是如此。上游存在并且已经存在许多相互冲突的命名空间冲突,并且不容易普遍表示,因此即使使用依赖项元数据,在跨越发行版边界时也可能没有意义。当涉及到版本空间时,发行版在不同的时间点或出于不同的原因使用诸如版本纪元(如果他们有这个概念)之类的功能,或者版本恢复技巧,例如
1.0really2.0
避免不必要的纪元使用。 - 与上述观点和发行版分歧相关,因为某些发行版修补了上游,无法保证程序或共享库或其他接口将兼容 API 或 ABI,更不用说诸如不同的默认构建标志之类的东西了。
那么,总而言之,您可以在同一系统上混合和匹配包管理器吗?如果你确定f.ex。他们将管理完全独立的文件系统层次结构,然后可能工作,比如通过他们自己的 chroot 或通过一个 f.ex。管理 / 和其他 /opt。否则,最好的选择是转换包格式(如 say 中提到的alien
)并使用它来尝试将这些外部包导入到本机包系统中,但即使这样也不能保证成功。但除此之外,我强烈建议不要这种做法。我什至建议不要将 Ubuntu 软件包安装到 Debian 系统中(前者是后者的衍生品),因为dpkg
我真的想让它拒绝这些并需要一个新的强制选项,例如--force-vendor
或类似的。
对于上游应该如何处理这种多样性的问题,我首选和推荐的解决方案是他们遵循上游最佳实践,以便他们的项目变得容易被各种发行版打包(参见 f.ex.https://wiki.debian.org/UpstreamGuide),然后要么参与其中,要么让发行版包装商处理这些问题。除非最好使用被认为是“通用”的各种容器格式之一,尽管当然已经有几种竞争格式(例如snap
、flatpak
、appimage
等),所以您将再次必须决定。我认为上游通常要么不处理打包,要么选择几种主流格式专门关注这些(例如.deb
和.rpm
)。