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 发行版了。