deb 与 rpm 的优缺点是什么？

Question

无论出于何种原因，我一直使用基于 RPM 的发行版（Fedora、Centos 和当前的 openSUSE）。我经常听到有人说 deb 比 rpm 好，但是当被问到为什么时，从来没有得到一个连贯的答案（通常会得到一些狂热的咆哮和大量的唾沫）。

我知道可能有一些历史原因，但是对于使用两种不同打包方法的现代发行版，有人可以给出一种与另一种的技术（或其他）优点吗？

Answer 1

很多人将安装软件与apt-getto进行比较rpm -i，因此说 DEB 更好。然而，这与 DEB 文件格式无关。真正的比较是dpkgvsrpm和aptitude/ apt-*vs zypper/ yum。

从用户的角度来看，这些工具没有太大区别。RPM 和 DEB 格式都只是存档文件，附加了一些元数据。它们都同样神秘，有硬编码的安装路径（糟糕！），只是在细微的细节上有所不同。双方dpkg -i并rpm -i没有搞清楚如何安装依赖，除非他们碰巧在命令行上指定的方式。

在这些工具之上，还有apt-...或zypper/形式的存储库管理yum。这些工具下载存储库、跟踪所有元数据并自动下载依赖项。每个单个包的最终安装都交给低级工具。

很长一段时间以来，apt-get在处理大量元数据方面非常快速，而yum需要很长时间才能做到这一点。RPM 也受到像 rpmfind 这样的网站的影响，在那里你会发现 10 多个不同发行版的不兼容包。Apt完全隐藏了 DEB 包的这个问题，因为所有包都是从同一个源安装的。

在我看来，zypper现在确实缩小了差距，apt并且没有理由为使用基于 RPM 的发行版而感到羞耻。如果不是更容易与手头的 openSUSE 构建服务一起使用以获得巨大的兼容包索引，它也同样好。

Answer 2

包维护者（我认为在 Debian 行话中是“开发者”）的主要区别在于包元数据和随附脚本的结合方式。

在 RPM 世界中，您所有的包（您维护的 RPM）都位于类似~/rpmbuild. 在下面，有SPEC您的规范文件SOURCES目录、源 tarball目录RPMS和SRPMS用于放置新创建的 RPM 和 SRPM 的目录，以及其他一些现在不相关的内容。

一切具有与将要创建的RPM如何在规范文件做：将应用哪些补丁，可以前，后脚本，元数据，更新日志，应有尽有。所有源 tarball 和所有包的所有补丁都在 SOURCES 中。

现在，就我个人而言，我喜欢这样一个事实，即所有内容都包含在规范文件中，并且规范文件与源 tarball 是一个单独的实体，但我并不太热衷于将所有源都放在 SOURCES 中。恕我直言，SOURCES 很快就会变得混乱，你往往会忘记里面的内容。然而，意见不一。

对于 RPM，重要的是使用与上游项目发布的完全相同的tarball，直到时间戳。一般来说，这条规则没有例外。Debian 软件包也需要与上游相同的 tarball，尽管 Debian 政策要求重新打包一些 tarball（谢谢，Umang）。

Debian 软件包采用不同的方法。（请原谅这里的任何错误：我对 deb 的经验比使用 RPM 的经验要少得多。）Debian 软件包的开发文件包含在每个软件包的目录中。

我（认为）喜欢这种方法的事实是，所有内容都包含在一个目录中。

在 Debian 世界中，在（尚未）上游的包中携带补丁更容易被接受。在 RPM 世界中（至少在 Red Hat 衍生产品中）这是不受欢迎的。请参阅“FedoraProject：与上游项目保持密切联系”。

此外，Debian 有大量的脚本，可以自动化创建软件包的很大一部分。例如，创建一个安装工具的 Python 程序的简单包，就像创建几个元数据文件并运行debuild. 也就是说，这种 RPM 格式的包的规范文件会很短，而且在 RPM 世界中，如今也有很多自动化的东西。

Answer 3

从系统管理员的角度来看，我发现了一些细微的差异，主要是 dpkg/rpm 工具集而不是包格式。

• dpkg-divert可以让您自己的文件替换来自包的文件。当您的程序在/usr或中查找文件/lib并且不接受/usr/local答案时，它可以成为救命稻草。这个想法已经提出了，但据我所知没有采纳，在rpm。

• 当我上次管理基于 rpm 的系统时（诚然是几年前，也许情况有所改善），rpm 总是会覆盖修改后的配置文件并将我的自定义移动到*.rpmsave(IIRC) 中。这使我的系统至少无法启动一次。dpkg 询问我该怎么做，并将我的自定义设置为默认设置。

• rpm 二进制包可以声明对文件而不是包的依赖关系，这允许比 deb 包更精细的控制。

• 您不能在具有 N-1 版 rpm 工具的系统上安装 N 版 rpm 软件包。这也可能适用于 dpkg，只是格式不会经常改变。

• dpkg 数据库由文本文件组成。rpm 数据库是二进制的。这使得 dpkg 数据库易于调查和修复。另一方面，只要没有问题，rpm 可以快很多（安装 deb 需要读取数千个小文件）。

• deb 包使用标准格式 ( ar, tar, gzip)，因此您可以轻松检查 deb 包，并进行调整。Rpm 包几乎没有那么友好。

Answer 4

转速：

• “标准化”（并不是说没有 deb 规范）
• 被许多不同的发行版使用（但一个包不一定适用于另一个）
• IIRC 允许依赖文件，而不仅仅是包

德比：

• 越来越受欢迎
• 允许推荐和建议（可能较新的 RPM 也允许）

可能更重要的问题是包管理器（dpkg 与 yum 与 aptitude 等）而不是包格式（因为两者具有可比性）。

Answer 5

正如几位响应者所说，并不是某种封装格式明显优越。从技术上讲，它们可能或多或少具有可比性。从我的角度来看，很多差异，以及为什么人们更喜欢一个而不是另一个，与：

• 原包装设计理念和目标受众
• 社区规模，以及存储库的质量和丰富性

哲学：

在 Ubuntu/Debian/Mint/... 世界中，用户希望已安装的软件包在安装后“正常工作”。这意味着在安装过程中，软件包需要处理实际使它们运行良好所需的一切，包括但不限于：

• 设置需要或可选的 cron 作业
• 设置替代品/别名
• 设置启动/关闭脚本
• 包括所有需要的配置文件和有意义的默认值
• 保留旧版本的库并将正确的版本符号链接添加到库 (.so's) 以实现向后兼容性
• 对同一台机器上的多架构（32 位和 64 位）二进制文件的干净支持等等。

在 rpm 世界中——诚然，这是几年前的情况，从那时起可能有所改善——我发现自己必须运行额外的步骤（例如 chkconfig，启用 cron 作业）才能真正使包真正工作。这对于系统管理员或了解 Unix 的人来说可能没问题，但它会使新手体验受到影响。请注意，并不是 RPM 包格式本身阻止了这种情况的发生，只是从新手的角度来看，许多包实际上并未“完全完成”。

社区规模、参与度和存储库的丰富性：

由于ubuntu/debian/mint/...社区更大，参与打包测试软件的人也更多。我发现存储库的丰富性和质量非常出色。在 ubuntu 中，我很少（如果有的话）需要下载源代码并从中构建。当我在家里从 Red Hat 切换到 Ubuntu 时，典型的 RHEL 存储库中有大约 3000 个包，而同时，ubuntu+universe+multiverse 都可以直接从任何 Canonical 镜像获得，有大约 30000 个包（大约 10 倍）。我正在寻找的大多数 RPM 格式的软件包都不容易通过简单的搜索和在软件包管理器中单击来访问。他们需要切换到备用存储库，搜索 rpmfind 服务网站等。在大多数情况下，这不是解决问题，而是 由于未能限制可以或不能正确升级哪些依赖项而破坏了我的安装。我遇到了“依赖地狱”现象，正如上面 Shawn J. Goff 所描述的那样。

相比之下，在 Ubuntu/Debian 中，我发现我几乎不需要从源代码构建。也是因为：

• Ubuntu 快速（6 个月）发布周期
• 存在开箱即用的完全兼容的PPA
• 单一源存储库（均由 Canonical 托管）无需搜索替代/补充存储库
• 从点击到运行的无缝用户体验

我从来不必对我关心的旧版本软件包妥协，即使它们不是由官方（规范）开发人员维护的。我不必离开我最喜欢的友好 GUI 包管理器来按关键字进行方便的搜索，找到并安装我想要的任何包。此外，有几次我在 Ubuntu 上安装了 debian（非规范）软件包，它们运行得很好，尽管这种兼容性没有得到官方保证。

请注意，这并不是要开始一场激烈的战争，它只是分享我多年来并行使用这两个世界（工作与家庭）的经验。

Answer 6

我认为偏差不是来自包格式，而是来自 RedHat 存储库中过去存在的不一致。

当 RedHat 还是一个发行版时（在 RHEL、Fedora 和 Fedora Core 之前），人们有时会发现自己处于“RPM 地狱”或“依赖地狱”。当存储库最终得到一个具有相互排斥的依赖关系（通常有几层深）的包时，就会发生这种情况。或者当两个不同的包有两个互斥的依赖关系时就会出现。这是存储库状态的问题，而不是包格式的问题。“RPM 地狱”在一些被该问题困扰的 Linux 用户群体中留下了对 RPM 系统的厌恶。

Answer 7

还有一个“哲学”差异，您可以在 Debian 软件包中提出问题，从而阻止安装过程。不好的一面是有些软件包会阻止您的升级，直到您回复为止。这样做的好处是，也作为哲学上的差异，在基于 Debian 的系统上，当安装软件包时，它会被配置（并不总是如您所愿）并运行。不是在基于 Redhat 的系统上，您需要从 /usr/share/doc/* 创建/复制默认/模板配置文件。

Answer 8

其他答案都没有触及这三个基本差异并产生真正的后果：

1. deb文件基本上只是ar包含两个压缩 tarball 的档案
2. deb软件包和dpkg系统将您的维护者脚本存储为单独的文件
3. dpkg并rpm在升级期间以不同的顺序运行维护者脚本。

总之，这些差异使我更容易修复由不良软件包引起的问题，并使软件包按照我需要的方式运行，在deb基于 的系统上比在rpm基于 的系统上，无论是作为系统管理员还是打包者。

由于#1，如果我需要更改文件，我可以使用大多数系统上存在的标准工具deb轻松地将其打开，进行任何我想要的更改，然后重新打包它。

这包括更改/添加/删除任何依赖项、任何包文件、任何维护者脚本，或者更改包版本或名称。

由于#2，如果已安装的软件包安装的“删除”脚本存在问题，我可以使用任何系统上存在的标准工具轻松修复它。

由于＃3，我只需发布软件包的新版本即可完成其中一些修复，因为在升级过程中，在“删除后”脚本之前dpkg运行新版本软件包的“预安装”脚本旧版本。

这意味着包中违反“可恢复性原则”的表面积更小deb：包的早期版本中的更多错误可以通过新版本来恢复。

而且由于修改包非常容易 - 实际的特定于包的摆弄和知识开销很小 - 它可以被更多的人访问，并且通过deb文件花费更少的时间和精力。

Answer 9

我喜欢 RPM 的一件事是（最近？）增加了增量 RPM。这允许更容易的更新，减少所需的带宽。

DEB 是标准的 ar 文件（里面有更多的标准档案），RPM 是“专有的”二进制文件。我个人认为前者更方便。

我能想到的只有两件事。两者非常具有可比性。两者都有出色的包装工具。我不认为一个比另一个有这么多优点，反之亦然。

Answer 10

Debian 软件包可以包含一个已安装的 size，但我认为 RPM 没有等效的字段。它可以根据包中包含的文件计算，但也不能依赖，因为可以在安装前/安装后脚本中执行操作。

这是一个非常好的参考，用于比较每种特定包装格式可用的一些特定功能：http : //debian-br.sourceforge.net/txt/alien.htm（根据网络服务器，该文档相当旧: Last-Modified: Sun, 15 Oct 2000所以这可能不是最好的参考。）

Answer 11

openSUSE Build Service (OBS) 和 zypper 是从打包者和用户的角度来看，我更喜欢 RPM 而不是 deb 的几个原因。Zypper 已经走了很长一段路，而且速度非常快。OBS，虽然它可以处理 debs，但在为 openSUSE、SLE、RHEL、centos、fedora、mandriva 等各种平台打包 rpms 时真的很棒。