RPM vs DEB的争论

这个论题也算是一个老坑了,我总是看到很多人说 debian 系统如何如何好使,apt 多么多么强。而 RPM 系统里面包依赖关系多么乱啥的。因此得出 DEB 这个包管理系统要比 RPM 这个包管理系统要强的结论。不过在我看来,这些问题要么不是问题,要么跟包管理系统一点关系都没有。

先说 DEB 派的几个论据

1: apt 系统用起来很方便
对, apt 系统用起来确实很方便,但这是在 rh9 时代的事情。现代基于 RPM 的系统,基本都有相对还不错的管理器,比如 fc 用的 yum, suse 用的 yast 等,虽然这些玩意可能也有点小毛病,比如 yum 相对 apt 来说要慢一些,但是总体来说,并不是致命的缺陷。只要有容量比较大的源,一样可以很爽的用。目前看来, FC 正在往 deb 的大源方向发展,FC 的官方源里面东西也相当的多了。
2: debian 系统比 redhat 系列的好使
这个说老实话,没有特别觉出来,当然这个跟使用习惯有关。倒是我觉得 debian 太过顽固,居然能跟 mozilla 打起来,搞的 firefox 都得改名成 iceweasel,导致一些网页上面的认 UA 的 javascript 不好使。相比之下,ubuntu 比起来 debian 这样的革命者就好不少,至少不会因为意识形态的问题跟人打架。
3: RPM 包的依赖关系比较混乱
这个我其实觉得跟 RPM 本身没有什么关系,倒是跟做 RPM 的人的习惯有关系。不知道是什么历史原因导致的,RPM 发行版的打包者通常很喜欢把一个包拆得很碎,连一个 snmp 都要拆成三个包,而 deb 系统在这方面就没有这么激进,通常就是一个软件拆成 base 和 dev ,只有比较大的包才会考虑分一下。这样就造成 RPM 发行版的依赖关系要更加复杂,这些依赖关系都是人手写的,维护代价上升很可能就造成一些混乱。这个确实是 RPM 发行版存在的问题,不过只要你自己会 build rpm, 那么基本依赖关系还是可以解决的。

下面说我自己感觉 RPM 系统优于 DEB 系统的地方

1: 打包容易。RPM 系统只需要写一个 .spec 文件就可以打包了,而 DEB 的我看了半天说明也还是没有找到门道。还要建一堆目录啥的,这对专门的打包者可能不是个问题,对我就是想临时 build 一下的人来说,就有点浪费了。
2: 有 rpmfind.net 这个好网站。deb 给我的感觉似乎是想把世上所有的软件都给吸纳进源,确实 debian 的源容量相当之大,很多奇怪的软件也都在 deb 源里面,但是经常还是有些东西找不到的,这时候 rpmfind 网站就很好用,我经常的用法是在上面找到 SRPM 然后下来自己改改 .spec build 一个适合自己系统的出来。 而 deb 似乎如果源里面没有而你不掌握打包技能,那么基本你就只能当 ./configure 一族了。
3: 配置文件拆分不那么激进。跟拆软件包的策略正好相反,保守的 deb 在拆配置文件上面下的力气,要比 rpm 系列大很多,拿 httpd 来说, Redhat 系列直接就拆成一个主的和一堆散的放在 conf.d 下面的就好了。而 debian 则是拆成了很多小的放在 mods-available 目录里面,需要什么,就 ln-s 到 mods-enabled 里面。这样看起来挺好,但是配置文件这东西哪里是那么好拆的,有些逻辑不好处理,于是他又搞出来一个 xxx.load 和 xxx.conf 的东西。最后搞到我都不知道他这个配置文件到底包含了什么。配置一个我本来会配置的东西,还要研究半天他怎么拆的这个配置,搞的很麻烦。当然这个我承认是个人喜好问题。但是我认为作网站运维的时候,应该使配置文件简单化,只完成够用的功能,而不应该为了扩展方便弄成这么一堆花儿,回头出问题了排查都麻烦。
4: 商业软件对 RPM 系统的支持更好一些
很多商业软件只有 rpm 版本的,或者安装脚本就是按照 RPM 风格的系统配置文件做的。deb 系统下面虽然有 alien 这个工具可以转 rpm ,但是并不能转里面软件对系统路径的依赖,很多软件都是到固定的地方去读取系统配置或者调用系统程序的。

基于以上原因,我在我维护的所有 Linux 系统上面都是采用基于 RPM 的系统。而且我见到的所有用 Linux 的大型网络公司,基本都是在用基于 RPM 的发行版跑服务。我想很多情况下原因也就是在于,在运维人员看来,rpm 和 deb 都差不多,都可以用得很爽,而 RPM 发行版在商业软件支持上有小小优势,就用 RPM 发行版了。