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


171

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

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

Answers:


86

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

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

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

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

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

Debian软件包采用了不同的方法。(在这里避免出现任何错误:我对Deb的经验远不如对RPM的经验。)Debian软件包的开发文件包含在每个软件包的目录中。

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

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

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


9
为了纠正您对Debian打包的问题,​​该debian目录存在于上游源提取到的目录中,并且Debian确实非常重视原始上游源tarball的概念。生成源软件包时,将有三个文件(对于本机软件包为两个),这些文件一起称为源软件包:上游tarball(最好是原始的,Debian策略要求重新打包某些项目),debian目录的tarball用于新的3.0格式(旧的1.0格式的差异)和.dsc。
Umang 2010年

8
debian目录不会进入上游tarball,而是保留在源软件包的.diff.gz.debian.tar.gz文件中,尽管debian提取源软件包时该目录位于源树中。顺便说一句:当策略不需要重新打包时,压缩包的MD5必须与上游压缩包的MD5相匹配。另外,为澄清起见,我作为上游源维护者的补丁存储在debian目录(源格式3.0)和.diff.gz(格式1.0)中。
Umang 2010年

乌曼,谢谢你的指正。我将删除有关更改上游压缩包的部分,以确保没有人得到错误的想法。
wzzrd

2
现在看起来不错,除了您还有“对于RPM,重要的是,使用与上游项目发布的tarball完全相同的tarball,直到时间戳记。” 由于我完全缺乏RPM的经验,我不知道政策上的差异是否很大,但是就像我说的那样,除非上游tarball违反Debian政策并且需要重新包装。
乌曼格2010年

7
@wzzrd,通过在〜/ .rpmmacros文件中定义%_specdir和%_sourcedir,将源文件放到每个软件包的目录中实际上很容易。
mattdm 2010年

94

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

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

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

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

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


@Tshepang:已修复
vdboor 2010年

12
我认为,出于您提到的确切原因,我鄙视RPM:“ RPM也遭受rpmfind之类的网站的困扰,在那里您会发现10个以上不兼容的软件包用于不同的发行版。” 另外,我发现为我需要的软件找到RPM过于困难。而对于DEB:“ APT完全隐藏了DEB软件包的此问题,因为所有软件包都是从同一源安装的。” 真的很容易找到和使用。而且,DEB似乎总是可以更好地找到并安装依赖项,而RPM似乎总是让我垂涎...经过15年的使用,我的观点!
Jeach

2
我相信这个答案从消费者的角度解决了这个问题,与@wzzrd的问题完全以开发人员/打包人员为中心。同样,关于水平分离也很清楚。
GnP 2014年

1
您的文本已被复制到WikiVS,似乎已正确分配了属性。
Martin Ueding 2014年

1
从用户的角度来看,这是最佳答案。而且我要补充一点,使用PPA比添加新的yum存储库要简单得多。
Marco Sulla 2014年

39

从系统管理员的角度来看,我发现了一些细微的差异,主要是在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软件包并不那么友好。


2
看起来这些天它保存新的配置文件*.rpmnew而不是破坏修改过的文件-至少在openSUSE上。
埃文(Evan)2010年

1
两者都已完成,因此您会分散rpmsave和rpmnew文件。
Burhan Ali 2012年

4
您对RPM不使用标准格式不正确。RPMS将CPIO用于数据部分-这是一种标准的存档格式。其他部分主要是标题。您可以使用工具rpm2cpio仅提取RPM的数据部分,并提取rpm中包含的文件。例如:rpm2cpio foobar.rpm | cpio -idmv
Tuxdude 2012年

...还有rpm2cpio.sh那些倾向。
Michael Shigorin 2015年

deb我记得格式唯一的重大变化是在何时data.tar.gz成为data.tar.xz,那时较旧的版本dpkg不再能够打开新软件包。
mtraceur

19

千次曝光收益:

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

DEB:

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

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


6
难道不是“越来越受欢迎”基本上是“ Ubuntu是基于Debian的,所以,知道了吗?”
mattdm 2010年

“ dpkg vs yum”的比较是错误的比较,因为前者软件包管理器,而后者不是(就像apt / aptitude是存储库级别的管理器,而不仅仅是“软件包”)。
Michael Shigorin

13

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

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

哲学:

在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
  • 单一源存储库(均由Canonical托管)无需搜索替代/互补存储库
  • 从点击到运行的无缝用户体验

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

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


这与“ redhat vs canonical”(规范地了解debian过去二十年来所做的事情)有关,而不是与“ rpm vs deb”有关-我作为ALT Linux小组成员告诉我。
Michael Shigorin 2015年

是的,正好。说得好。
arielf

12

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

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


8

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


6

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

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

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


7
将RPM称为“专有”有点强。还有其他一些标头,但RPM的核心是gzip压缩的cpio归档文件。RPM附带有一个名为rpm2cpio的工具,您可以提取该内核,以便像使用.deb文件一样使用它。
沃伦·杨

4
垃圾。RPM不是专有的二进制文件。它们以前是围绕cpio构建的(这是旧的,是的,但不是专有的),而较新版本的RPM使用xz,xz也可以作为开源使用。
wzzrd

是的,我引用了它,因为它当然不是真正的专有,这恰恰是我的意思:其他标头等,因此它不是像deb那样简单的ar文件。没什么大不了的,只是一件小事。
johansson

5
也许您应该将“专有二进制文件”替换为“已添加非标准标头的存档文件”。
瑞安·汤普森

有兴趣的人可以找到rpm2cpio.sh脚本。
Michael Shigorin

5

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


恕我直言,openSUSE Build Service是很长时间以来最酷的事情。他们真的做对了。
Archie 2010年

尽管这是关于deb vs rpm的,但您是正确的zypper很棒,具有优先级的支持存储库,以及出色的SAT求解器。
drahnr 2012年

5

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

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


1
嗨@MikeGray。链接断开。请您更新一下吗?
olibre

4

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


所有这些情况对于例如为Fedora打包的RPM都是正确的。
mattdm 2013年

1
Debian的依赖关系生成工具几乎不存在,我们在ALT Linux(使用APT的基于RPM的发行版)方面领先几年。
Michael Shigorin

3

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

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

总之,这些差异使人们更容易为我解决不好造成的封装问题,并提出包的行为,我需要他们的样子,就deb不是基于系统rpm的系统上,两者作为一个系统管理员,并作为一个打包。

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

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

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

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

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

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.