很多人都说Debian的deb包比Redhat的rpm好，又说apt-get比yum好，简直是方便太多了。请问，到底apt好在哪里？
关注者
266
被浏览
75,449
25 个回答
我现在的工作和 yum/rpm 几乎天天和打交道（可不是简单的 yum update ），最大的问题就是——慢。所有操作都明显可以感觉比 apt 慢，更不用提臭名昭著的网络请求过程中 Ctrl-C 的问题了。如果再装一两个插件的话就更慢了。甚至单单只是 yum --help 一下都慢，装了高级补全之后仍然不怎么在 yum 里按 tab （不是不行，是不敢，太慢了）。这里大概很多是 Python 的锅。如果你的工作像我一样重度依赖 rpm 和 yum 的话，那这个问题真的是会让人不爽。
另一个传说中的问题，是上古时期（ yum 刚诞生的时候）， yum 的依赖解决算法不好，在一些非常规情况下会无法计算出方案或者弄坏本地环境。我现在手头没有当时查的资料，但记忆中这些“非常规”情况一般都是软件源中存在依赖环之类的 partly broken dependency ，而且很多时候是由于手动添加非官方软件源甚至是手动安装 rpm 包导致的。所以大概可以 argue 说应该在一开始就避免把软件源搞乱。另外其实 rpm 包的依赖关系粒度是比 deb 包更细的，也许也是导致其更“容易损害”的原因之一。
另外 yum 很多看似“必须”的功能却需要插件完成，比如 autoremove 、 yum-downloader 等。当然另一方面， yum 的插件的确很多很强大，插件系统比 apt 要好。 presto 其实是个很好的想法，尤其是在互联网上。
yum 自带的 history/transaction 功能也是很好用。另外期待新的 dnf 。
至于 rpm 和 deb ，其实是包括两个方面：包格式来说个人更喜欢 rpm ，包命令来说个人更喜欢 dpkg 。 rpm 包的 spec 灵活强大（多个 scriptlet 基本满足所有需求，宏都很丰富还能自定义，尤其适合公司定制自己的钩子）、易管理（主要的包构建信息集中在一个文件，生成SRPM、使用 rpmbuild 等等都很方便）。当然，也可能我对 deb 包不够熟悉，不了解。至于命令， rpm 是出了名的难用，甚至帮助也很难读……
最后， PKGBUILD/pacman 这套就是个玩具——“简单”就是因为功能少啊……个人用户还行，工业界很多需求无法实现。比如一句“我们不支持部分升级”就可以回避掉一堆复杂的问题。（利益相关：多年使用 ArchLinux 作为PC主系统。）
总结点题： no silver bullet 。两套世界上使用最广泛的包管理系统，都是久经考验，各有利弊；再加上很多时候包管理器之间的比较难免会牵扯到社区的打包风格和质量，所以其实真的很难说两者之中哪个就一定更好。尤其在工业界，都是综合多方面原因之后根据实际需要权衡做出的决定。
另一个传说中的问题，是上古时期（ yum 刚诞生的时候）， yum 的依赖解决算法不好，在一些非常规情况下会无法计算出方案或者弄坏本地环境。我现在手头没有当时查的资料，但记忆中这些“非常规”情况一般都是软件源中存在依赖环之类的 partly broken dependency ，而且很多时候是由于手动添加非官方软件源甚至是手动安装 rpm 包导致的。所以大概可以 argue 说应该在一开始就避免把软件源搞乱。另外其实 rpm 包的依赖关系粒度是比 deb 包更细的，也许也是导致其更“容易损害”的原因之一。
另外 yum 很多看似“必须”的功能却需要插件完成，比如 autoremove 、 yum-downloader 等。当然另一方面， yum 的插件的确很多很强大，插件系统比 apt 要好。 presto 其实是个很好的想法，尤其是在互联网上。
yum 自带的 history/transaction 功能也是很好用。另外期待新的 dnf 。
至于 rpm 和 deb ，其实是包括两个方面：包格式来说个人更喜欢 rpm ，包命令来说个人更喜欢 dpkg 。 rpm 包的 spec 灵活强大（多个 scriptlet 基本满足所有需求，宏都很丰富还能自定义，尤其适合公司定制自己的钩子）、易管理（主要的包构建信息集中在一个文件，生成SRPM、使用 rpmbuild 等等都很方便）。当然，也可能我对 deb 包不够熟悉，不了解。至于命令， rpm 是出了名的难用，甚至帮助也很难读……
最后， PKGBUILD/pacman 这套就是个玩具——“简单”就是因为功能少啊……个人用户还行，工业界很多需求无法实现。比如一句“我们不支持部分升级”就可以回避掉一堆复杂的问题。（利益相关：多年使用 ArchLinux 作为PC主系统。）
总结点题： no silver bullet 。两套世界上使用最广泛的包管理系统，都是久经考验，各有利弊；再加上很多时候包管理器之间的比较难免会牵扯到社区的打包风格和质量，所以其实真的很难说两者之中哪个就一定更好。尤其在工业界，都是综合多方面原因之后根据实际需要权衡做出的决定。
知乎用户
yum 以前真的很难用，这几年已经好多了。
要不是今天一个不小心把网络配错了，然后 yum update 的时候就悲愤地看着它一个源一个源的重试，按 ctrl-c 没效果，连 kill 进程都没效果，我都已经忘记它难用这件事情了
[Errno 14] PYCURL ERROR 6 - "Couldn't resolve host 'mirrors.pubyun.com'"
Trying other mirror.
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C http:// mirrors.sina.cn/centos/ 6.6/os/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 6 - "Couldn't resolve host 'mirrors.sina.cn'"
Trying other mirror.
http:// mirrors.yun-idc.com/cen tos/6.6/os/x86_64/repodata/repomd.xml : [Errno 14] PYCURL ERROR 6 - "Couldn't resolve host 'mirrors.yun-idc.com'"
Trying other mirror.
http:// mirrors.zju.edu.cn/cent os/6.6/os/x86_64/repodata/repomd.xml : [Errno 14] PYCURL ERROR 6 - "Couldn't resolve host 'mirrors.zju.edu.cn'"
Trying other mirror.
^C^C^C http:// centos.ustc.edu.cn/cent os/6.6/extras/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 6 - "Couldn't resolve host 'centos.ustc.edu.cn'"
Trying other mirror.
要不是今天一个不小心把网络配错了，然后 yum update 的时候就悲愤地看着它一个源一个源的重试，按 ctrl-c 没效果，连 kill 进程都没效果，我都已经忘记它难用这件事情了
[Errno 14] PYCURL ERROR 6 - "Couldn't resolve host 'mirrors.pubyun.com'"
Trying other mirror.
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C http:// mirrors.sina.cn/centos/ 6.6/os/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 6 - "Couldn't resolve host 'mirrors.sina.cn'"
Trying other mirror.
http:// mirrors.yun-idc.com/cen tos/6.6/os/x86_64/repodata/repomd.xml : [Errno 14] PYCURL ERROR 6 - "Couldn't resolve host 'mirrors.yun-idc.com'"
Trying other mirror.
http:// mirrors.zju.edu.cn/cent os/6.6/os/x86_64/repodata/repomd.xml : [Errno 14] PYCURL ERROR 6 - "Couldn't resolve host 'mirrors.zju.edu.cn'"
Trying other mirror.
^C^C^C http:// centos.ustc.edu.cn/cent os/6.6/extras/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 6 - "Couldn't resolve host 'centos.ustc.edu.cn'"
Trying other mirror.