无论出于何种原因，我一直使用基于 RPM 的发行版（Fedora、Centos 和当前的 openSUSE）。我经常听到有人说 deb 比 rpm 更好，但当被问及为什么时，却始终无法得到连贯的答案（通常会得到一些热心的咆哮和大量的唾沫）。
我知道可能存在一些历史原因，但是对于使用两种不同包装方法的现代发行版，任何人都可以给出一种与另一种的技术（或其他）优点吗？
答案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 构建服务一起使用以获得巨大的兼容包索引，即使不是更容易，也同样好。
答案2
对于软件包维护者（我认为 Debian 行话中的“开发人员”）来说，主要区别在于软件包元数据和随附脚本结合在一起的方式。
在 RPM 世界中，您的所有软件包（您维护的 RPM）都位于类似~/rpmbuild.下面是SPEC您的规范文件的目录、SOURCES源 tarball 的目录、RPMS用于SRPMS放置新创建的 RPM 和 SRPM 的目录，以及一些其他现在不相关的内容。
一切与如何创建 RPM 有关的内容在规范文件中：将应用哪些补丁、可能的前脚本和后脚本、元数据、变更日志等等。所有源 tarball 和所有补丁你所有的包裹在来源中。
现在，就我个人而言，我喜欢这样一个事实：所有内容都放入规范文件中，并且规范文件是与源 tarball 分开的实体，但我并不太热衷于拥有全部来源中的来源。恕我直言，来源很快就会变得混乱，你往往会忘记其中的内容。然而，意见不同。
对于 RPM，使用精确的与上游项目发布的压缩包相同，直至时间戳。一般来说，这条规则没有例外。 Debian 软件包也需要与上游相同的 tarball，尽管 Debian 政策要求重新打包一些 tarball（谢谢，Umang）。
Debian 软件包采用了不同的方法。 （请原谅这里的任何错误：我对 deb 的经验比对 RPM 的经验要少得多。） Debian 软件包的开发文件包含在每个软件包的一个目录中。
我（认为）喜欢这种方法的原因是所有内容都包含在一个目录中。
在 Debian 世界中，在（尚未）上游的软件包中携带补丁更容易被接受。在 RPM 领域（至少在 Red Hat 衍生产品中），这是不受欢迎的。看“FedoraProject：与上游项目保持密切联系”。
此外，Debian 拥有大量脚本，能够自动完成创建软件包的大部分工作。例如，创建一个经过 setuptool 处理的 Python 程序的简单包，就像创建几个元数据文件并运行debuild.也就是说，RPM 格式的此类包的规范文件会非常短，而且在 RPM 世界中，现在也有很多东西是自动化的。
答案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 软件包就没有那么友好了。
答案4
正如几位回复者所说，与其说某个包格式显然是优越的。从技术上讲，它们可能或多或少具有可比性。从我的角度来看，许多差异以及为什么人们更喜欢其中一种而不是另一种，与以下因素有关：
- 原创包装设计理念和目标受众
- 社区规模，以及存储库的质量和丰富度
哲学：
在 Ubuntu/Debian/Mint/... 世界中，用户期望安装的软件包一旦安装就可以“正常工作”。这意味着在安装过程中，软件包应该处理实际运行良好所需的一切，包括但不限于：
- 设置所需或可选的 cron 作业
- 设置替代品/别名
- 设置启动/关闭脚本
- 包括所有需要的配置文件以及有意义的默认值
- 保留旧版本的库并将正确版本的符号链接添加到库（.so）以实现向后兼容性
- 对同一台机器上的多架构（32 和 64 位）二进制文件的干净支持等等。
在 rpm 世界中——诚然，这是几年前的情况，从那时起它可能已经有所改善——我发现自己必须运行额外的步骤（例如 chkconfig，启用 cron 作业）才能真正使包真正工作。这对于系统管理员或了解 Unix 的人来说可能没问题，但它会让新手体验受到影响。请注意，并不是 RPM 包格式本身阻止了这种情况的发生，只是许多包实际上并没有阻止这种情况发生。“完全完成”从一个新手的角度来看。
社区规模、参与度和存储库的丰富度：
由于ubuntu/debian/mint/...社区规模更大，参与打包和测试软件的人也更多。我发现存储库的丰富性和质量非常出色。在 ubuntu 中，我很少（如果有的话）需要下载源代码并从中构建。当我在家从 Red Hat 切换到 Ubuntu 时，典型的 RHEL 存储库中有约 3000 个软件包，而同时，可直接从任何 Canonical 镜像获得的 ubuntu+universe+multiverse 中有约 30,000 个软件包（大约是 10 倍）。我正在寻找的大多数 RPM 格式的软件包无法通过简单的搜索并单击软件包管理器轻松访问。他们需要切换到备用存储库、搜索 rpmfind 服务网站等。在大多数情况下，这并不能解决问题，而是无法限制哪些依赖项可以或不能正确升级，从而破坏了我的安装。正如肖恩·J·戈夫（Shawn J. Goff）的回答中所描述的那样，我遇到了“依赖地狱”现象。
相比之下，在 Ubuntu/Debian 中我发现我几乎不需要从源代码构建。还因为：
- Ubuntu 快速（6 个月）发布周期
- 的存在完全兼容开箱即用的 PPA
- 单一源存储库（全部由 Canonical 托管）无需搜索替代/补充存储库
- 从点击到运行的无缝用户体验
我从来不必在我关心的旧版本软件包上做出妥协，即使它们不是由官方（规范）开发人员维护的。我从来不需要离开我最喜欢的友好的 GUI 包管理器来通过关键字执行方便的搜索，找到并安装我想要的任何包。另外，有几次我在 Ubuntu 上安装了 debian（非 Canonical）软件包，它们工作得很好，尽管这种兼容性没有得到官方保证。
请注意，这并不是为了引发一场激烈的战争，它只是分享我多年来并行使用两个世界（工作与家庭）的经验。