it-swarm.cn

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

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

我知道可能有一些历史原因,但是对于使用两种不同包装方式进行现代发行的公司,有人能提供一种与另一种相比的技术(或其他)优点吗?

173
Evan

软件包维护者的主要区别(我认为在Debian语言中将是“开发者”)是软件包元数据和随附脚本结合在一起的方式。

在RPM世界中,所有软件包(您维护的RPM)都位于~/rpmbuild。在下面,是用于规范文件的SPEC目录,一个用于源tarball的SOURCES目录,RPMSSRPMS目录,用于放置新创建的RPM和SRPM和其他一些现在不相关的东西。

与RPM如何创建有关的一切位于spec文件中:将应用哪些补丁,可能的前脚本和后脚本,元数据,变更日志以及所有内容。所有源tarball和所有软件包的所有补丁都在SOURCES中。

现在,个人而言,我喜欢这样的事实:所有内容都进入了规范文件,并且规范文件是与源tarball分开的实体,但是我对并不太热心源中的所有源。恕我直言,来源很快就会变得混乱不堪,您往往会迷失其中的内容。但是,意见不同。

对于RPM,使用精确相同的tarball与上游项目发布的tarball一样重要,直到时间戳记为止。通常,此规则没有例外。 Debian软件包也需要与上游相同的tarball,尽管Debian策略要求将一些tarball重新打包(谢谢,Umang)。

Debian软件包采用了不同的方法。 (请原谅任何错误:对于Deb,我的经验要少得多,而对RPM则经验不足。)Debian软件包的开发文件包含在每个软件包的目录中。

我(想)喜欢这种方法的事实是,所有内容都包含在一个目录中。

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

同样,Debian有大量的脚本,能够自动执行创建软件包的很大一部分。例如,创建一个setuptool'ed Python程序)的简单包,就像创建几个元数据文件并运行debuild一样简单。 RPM格式的此类软件包的规范文件非常短,在RPM世界中,如今也有很多自动化的东西。

87
wzzrd

很多人将apt-getrpm -i的安装软件进行比较,因此说DEB更好。但是,这与DEB文件格式无关。实际比较是dpkgrpmaptitude/apt-*zypper/yum

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

在这些工具之上,以apt-...zypper/_yum的形式进行存储库管理。这些工具下载存储库,跟踪所有元数据并自动下载依赖项。每个单个软件包的最终安装将移交给低级工具。

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

在我看来,zypper确实弥合了与apt的鸿沟,而如今没有理由为使用基于RPM的发行版感到羞耻。与手头的openSUSE构建服务一起使用,对于庞大的兼容软件包索引来说,即使不是更容易使用,也一样好。

97
vdboor

从系统管理员的角度来看,我发现了一些细微的差异,主要是在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软件包使用标准格式(artargzip),因此您可以轻松检查一下deb软件包。 RPM软件包并不那么友好。

40

千次曝光收益:

  • “标准化”(不是没有deb规范)
  • 由许多不同的发行版使用(但是来自一个发行版的软件包不一定适用于另一个发行版)
  • IIRC允许依赖于文件,而不仅依赖于包

DEB:

  • 越来越受欢迎
  • 允许提出建议和建议(也可能是较新的RPM允许)

可能更重要的问题是软件包管理器(dpkg,yum和aptitude等),而不是软件包格式(因为两者是可比较的)。

19
Maciej Piechotka

正如几个响应者所说,某种包format显然不是更好。从技术上讲,它们或多或少具有可比性。从我的角度来看,许多差异以及人们为什么偏爱一个差异的原因与以下方面有关:

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

哲学:

在Ubuntu/Debian/Mint/...的世界中,用户希望安装的软件包在安装后能够“正常工作”。这意味着在安装过程中,期望软件包能够处理使它们正常运行所需的一切,包括但不限于:

  • 设置所需或可选的cron作业
  • 设置替代/别名
  • 设置启动/关闭脚本
  • 包括所有需要的配置文件以及有意义的默认值
  • 保留旧版本的库,并向库(.so)添加正确版本的符号链接,以实现向后兼容
  • 完全支持同一台计算机上的多Arch(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的存在
  • 单一源存储库(均由Canonical托管)无需搜索替代/互补存储库
  • 从点击到运行的无缝用户体验

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

请注意,这并不是要引发一场火焰大战,它只是分享我在两个环境中并行使用几年(工作与家庭)的经验。

15
arielf

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

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

12
Shawn J. Goff

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

8
Luc Stepniewski

我喜欢RPM的一件事是(最近?)增加了增量RPM。这样可以更轻松地更新,减少所需的带宽。

DEB是标准ar文件(内部带有更多标准档案),RPM是“专有”二进制文件。我个人认为前者更方便。

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

6
johansson

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

这是比较每种特定包装格式可用的某些特定功能的很好参考: http://debian-br.sourceforge.net/txt/alien.htm (根据网络服务器,该文档相当旧:最后修改时间:2000年10月15日,星期日,所以这可能不是最佳参考。)

5
Mike Gray

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

5
decriptor

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

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

总而言之,这些差异使我在基于deb的系统上解决了由错误的程序包引起的问题,并使程序包按照我需要它们的方式运行时,容易得多基于rpm的系统,两者作为系统管理员作为打包程序。

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

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

由于#2,如果软件包安装的“删除”脚本中存在问题已安装,我可以使用使用任何系统上存在的标准工具来对其进行简单修复)

由于#3,我可以仅通过发布软件包的新版本来进行一些修复,因为在升级过程中,dpkg运行软件包新版本的“预安装”脚本之前旧版本的“删除后”脚本。

这意味着在deb软件包中违反“可恢复性原理”的表面积较小:可以从新版本中恢复较早版本的软件包中的更多错误。

而且,由于修改软件包非常容易-特定于软件包的实际摆弄和知识开销很小-使用deb文件可以为更多的人使用,并且花费的时间和精力更少。

4
mtraceur

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

4
tex

前往Google搜索

  1. rpm重复软件包
  2. dpkg重复软件包

阅读返回的页面。很好的说,您可以在混乱的RPM数据库中包含重复的软件包,而dpkg不会发生这种情况。

2
user2472