在服务器环境中 rpm 优于 deb？

Question

这个相关的问题deb 与 rpm 的优缺点是什么？似乎更专注于个人电脑，但在服务器的上下文中，为什么大多数服务器运行的是RedHat/CentOS或SUSE？

rpm 相对于 deb 有什么显着改进吗？还是仅仅因为它们是公司而非社区提供的产品？

Answer 1

deb 和 rpm 包格式是同时单独开发的，以解决相同的基本问题。大多数服务器运行 RHEL 只是因为历史上它是最受欢迎的发行版，并且在它出现时采用了新技术，这使耐心的人们能够在他们知道的发行版上露营。我想说的是，如果您计划进行企业部署，请使用 RHEL/CentOS，因为它会更容易找到和配备有该特定发行版经验的人员（不是因为包管理器）。Canonical 提供 Ubuntu 的企业版，但他们的支持基础设施（作为一家公司）没有 SuSE 或 Red Hat 开发得那么好，它仍然是企业 Linux 中的一个小众技能集。

格式本身是不同的，因为他们每个人都试图在不咨询对方的情况下解决问题，而一种存在于另一种中。这有点像左侧驾驶和右侧驾驶的国家。只要您始终如一地应用规则，任何一个都没有错。出于同样的原因，人们几乎没有统一两种解决方案的动力：这不是真正的问题。这两个解决方案在功能上具有竞争力，并且不能保证基于 RPM 的发行版和基于 dpkg 的发行版之间广泛的 ABI 兼容性（意味着通过共享包管理器软件没有什么好处）。

管理员可能对他们喜欢apt-getvs 之类的东西有多少个人偏好，yum但仅此而已，个人偏好。

但是，就您选择的包而言，您希望专注于“企业”与“社区”风格的包开发，但仍然不是文件格式。

社区打包通常有非常松散的 QA 要求，社区发行版有强烈的动机提供一切，以便每个人都可以找到他们需要的包。企业包提供了一定的保证，包括主要版本内部的 ABI 兼容性、包选择和新功能的引入，所有这些都是为了稳定性。

• 在ABI保证-应用程序二进制接口，允许用户进行系统更新，只需要重新启动独立程序，针对替代得到任何链接（库，可执行文件等）。如果上游修复了与发送给您的版本相关的某些内容，您的 EL 发行版提供商应该出去寻找一种方法，以不破坏其他任何内容的方式将修复程序反向移植到他们正在发送的版本中。这也有助于平台本身获得您可能需要运行的 ISV 产品的产品认证。

• 受限制的软件包选择使提供软件包的公司能够更广泛地对您在寻找问题解决方案时可能看到的软件进行质量检查。这与 Fedora 之类的东西相反，其中软件包只需要不被无望地破坏，并且在它被包含之前看起来对某人有用。

• 新功能显然会引入错误，并且会不断变化和弃用。延迟功能采用是 EL 发行版保护企业用户免受这种混乱影响的方式，但也有助于确保 ABI 兼容性要求。

可能比您想要的更多信息，但是您去了。