deb vs. rpm的优缺点是什么？

#1 楼

软件包维护者的主要区别（在Debian术语中，我认为应该是“开发者”）是软件包元数据和随附脚本结合在一起的方式。

在RPM世界中，所有软件包（您维护的RPM）位于~/rpmbuild之类的位置。在下面，您的规格文件有一个SPEC目录，一个用于源tarball的SOURCES目录，用于将新创建的RPM和SRPM放入其中的RPMS和SRPMS目录，以及一些现在不相关的东西。

与如何创建RPM有关的一切都在spec文件中：将应用哪些补丁，可能的前脚本和后脚本，元数据，changelog等。所有源压缩包和所有软件包的所有修补程序都在SOURCES中。

现在，我个人很喜欢所有东西都放入spec文件中，并且spec文件是一个独立于实体的事实。源代码包，但我对在SOURCES中拥有所有源代码并不太热心。恕我直言，来源很快就会混乱不堪，您往往会迷失其中的内容。但是，意见不同。

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

Debian软件包采用了不同的方法。 （在这里避免犯任何错误：我对Rb的经验与deb无关。）Debian软件包的开发文件包含在每个软件包的目录中。

我（想）喜欢的是这种方法是将所有内容都包含在一个目录中。

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

此外，Debian拥有大量脚本，这些脚本能够自动执行创建软件包的很大一部分。例如，创建一个由setuptooled处理的Python程序的简单包，就像创建几个元数据文件并运行debuild一样简单。也就是说，RPM格式的此类软件包的规范文件非常短，在RPM世界中，如今也有很多东西是自动化的。

#2 楼

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

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

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

长期以来，apt-get在处理大量元数据方面一直非常出色，能够真正快速地处理大量元数据，而yum则需要很长时间才能完成它。 RPM还受rpmfind之类的网站的困扰，您会在其中找到10多个不兼容的软件包以用于不同的发行版。 Apt对于DEB软件包完全隐藏了此问题，因为所有软件包都是从同一来源安装的。

我认为，zypper确实缩小了与apt的差距，因此没有理由为使用RPM感到羞耻这些天基于分布。与手头的openSUSE构建服务一起使用对于获得巨大的兼容包索引来说同样好，即使不是更容易。

#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 楼

RPM：


“标准化”（不是没有deb规范）
由许多不同的发行版使用（但是来自一个发行版的软件包不一定能在另一个发行版上工作）
IIRC允许依赖文件，而不仅依赖于包

DEB：


日益流行
允许提出建议和建议（可能较新的RPM允许

也许更重要的问题是软件包管理器（dpkg vs. yum vs. aptitude等），而不是软件包格式（因为两者是可比较的）。

#5 楼

正如一些响应者所说，某种包装格式显然是优越的。从技术上讲，它们或多或少具有可比性。从我的角度来看，很多差异以及为什么人们偏爱另一个差异与以下原因有关：



原始包装设计和目标受众的哲学
社区的规模，以及由此扩展的存储库的质量和丰富性

哲学：

在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服务网站等。在大多数情况下，这不能解决问题，但是由于无法限制可以正确升级或不能正确升级的依赖项而中断了我的安装。如上所述，我遇到了Shawn J. Goff所说的“依赖性地狱”现象。

与Ubuntu / Debian相反，我发现我几乎不需要从源代码进行构建。同样是因为：


Ubuntu快速（6个月）发布周期
存在完全兼容的PPA，这些PPA可以开箱即用地工作
单一源存储库（全部由Canonical托管），无需搜索其他/互补的存储库。
从点击运行即可获得无缝的用户体验

我从来不必妥协我关心的旧版本的软件包，即使它们不是由官方（规范）开发人员维护的。我从不需要离开我最喜欢的友好GUI软件包管理器来通过关键字执行便捷的搜索，以查找并安装我想要的任何软件包。另外，有几次我在Ubuntu上安装了debian（非Canonical）程序包，尽管没有正式保证这种兼容性，但它们仍然可以正常工作。

请注意，这并不是要引发一场火焰大战，它只是分享了我同时使用两个世界（工作与家庭）的经验。

#6 楼

我认为偏差不是来自软件包格式，而是来自RedHat存储库中曾经存在的不一致之处。

回到RedHat发行时（在RHEL，Fedora和Fedora Core出现之前） ，人们有时会发现自己处于“ RPM地狱”或“依赖地狱”状态。发生这种情况时，存储库将最终获得一个包，该包具有相互排斥的依赖项（通常是几层）。或者，当两个不同的程序包具有两个互斥的依赖项时，就会出现这种情况。这是存储库状态的问题，而不是包格式的问题。 “ RPM地狱”使RPM系统对一些被该问题困扰的Linux用户感到不快。

#7 楼

还有一个“哲学上的”区别，在Debian软件包中，您可以提出问题，从而阻止安装过程。
不好的一面是，某些软件包会阻止您的升级，直到您答复为止。从哲学上来说，这样做的好处是，在基于Debian的系统上，安装了软件包后，便会对其进行配置（并非总是按您的意愿）并运行。不是在需要从/ usr / share / doc / *创建/复制默认/模板配置文件的基于Redhat的系统上。

#8 楼

我喜欢RPM的一件事是（最近？）增加了增量RPM。这样可以更轻松地进行更新，减少所需的带宽。

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

我可以想到两件事。两者非常可比。两者都有出色的包装工具。我认为一个优点没有另一个优点，反之亦然。

#9 楼

从打包程序和用户的角度来看，openSUSE Build Service（OBS）和zypper是我更喜欢RPM而不是deb的两个原因。 Zypper已经走了很长一段路，而且还挺快的。 OBS虽然可以处理deb，但在打包各种平台（例如openSUSE，SLE，RHEL，centos，fedora，mandriva等）的rpm时确实非常好。

#10 楼

Debian软件包可以包括已安装的大小，但是我不认为RPM具有等效的字段。它可以基于软件包中包含的文件进行计算，但由于可以在安装前/安装后脚本中执行操作，因此也不能依赖。

此处提供了相当不错的参考每种特定包装格式可用的某些特定功能的比较：http://debian-br.sourceforge.net/txt/alien.htm（根据网络服务器，该文档相当老：最后修改时间：Sun， 2000年10月15日，因此这可能不是最佳参考。）

#11 楼

对于Debian软件包，有大量的帮助程序脚本，一致的策略手册以及至少一种完成几乎所有事情的方式。依赖关系处理得很好，并且可以以非常好的粒度进行定义。使用debian软件包可以很容易地重建软件包，并且可以得到可用工具的大力支持。

#12 楼

其他答案都没有涉及以下三个基本差异如何产生实际后果：



deb文件基本上只是包含两个压缩tarball的ar档案文件

deb软件包和dpkg系统将您的维护者脚本存储为单独的文件

dpkg和rpm在升级过程中以不同的顺序运行维护者脚本。

在一起，这些区别在一起与基于deb的系统相比，无论是作为系统管理员还是打包程序，我都可以更轻松地解决由错误的软件包引起的问题，并使软件包按照我需要的方式运行，而与基于rpm的系统相比。 />
由于＃1，如果我需要更改deb文件，则可以使用大多数系统上存在的标准工具，将其微不足道地将其打开，进行所需的任何更改，然后重新打包。

这包括更改/添加/删除任何依赖项，任何软件包文件或维护脚本的任何一个，或更改程序包的版本或名称。

由于＃2，如果已经安装的程序包安装的“删除”脚本中存在问题，则可以使用任何系统上都存在的标准工具对其进行修复。

由于＃3，我可以通过发布软件包的新版本来进行一些修复，因为在升级过程中，dpkg运行“新版本的软件包的pre-install脚本位于旧版本的“ post-remove”脚本之前。这意味着在deb中，违反“可恢复性原理”的表面积较小。软件包：可以使用新版本从早期版本的软件包中恢复更多错误。

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