Debian和Gentoo包管理机制比较及延伸

　　如果你现在想安装一套Linux，又不想随着Linux发行版本的版本号，不停的格式化系统，重新安装，或者升级安装。那么，最适合你的只有LFS、Debian和Gentoo。

　　本文尝试对Debian、Gentoo的包管理机制进行比较，并由此得出了几个有趣的结论。本文对于Debian、Gentoo的包管理，主要谈缺陷和不足，并且尝试提出解决方法。最后，本人水平有限，失误、不足之处在所难免，还望大家批评指正。

　　Debian是老牌的发行版本，有人甚至认为Debian就是GNU/Linux本身，但是，据Debian自己的了解。它只是碰巧通过Linux实现了而已。（Debian，似乎是一种思想？一种生活方式？）

　　Gentoo是新生的，成长迅速的发行版本。说他成长迅速，不仅在于它提供了主流和非主流的基于各种硬件的Linux的实现，更在于，它还同时提供*bsd、MacOSX、Sun Solaris（就在Sun开放Solaris之后不久）版本的portage。（最初认识Gentoo，是在QQ上与OpenQ的创始人PuzzleBird聊天，他把Gentoo形容成是下一代的Debian。于是偶相信了，开始了艰难的安装。 不过，还是感谢PuzzleBird，是他让我看到rpm之外的世界，之前偶都是用基于rpm版本的发行版的）

　　典型的Debian提供一种基于i386编译的二进制deb包，采用了一套完整有效的工具指令集来保证整个系统软件包的完整、清洁和有效。

　　Gentoo的传统上，虽然也提供二进制包，但是，大家意义上的Gentoo，更在于通过源码编译属于自己的系统。通过USE的各个级别（配置文件级别、命令行级别）的设置，Gentoo能够让你轻松得到完全属于自己的，独一无二的Linux系统。

　　比较：由于软件包提供的格式不同（一种是二进制文件，一种是源码）。Debian与Gentoo相比，有着更快的系统安装效率。同样的网络情况下，安装Debian要比Gentoo节省更多的时间，通常只需要几个小时，你就可以得到一套完成的Debian系统（包含KDE等等完整的桌面环境）。但是，在我看来，Debian的缺点在于，Debian基于deb的依赖性审查过于严格。也许是因为直接提供的二进制包的缘故。Debian对于同一套软件的细微不同版，也认为是完全不同的。

　　ibqt3-mt-dev对下面两个有依赖，可是下面两个已经有firefly补丁的版本了。

　　提示：
　　libfreetype6-dev: Depends: libfreetype6 (= 2.1.7-2.3)
　　but 2.1.7-2.3firefly is to be installed
　　libxft-dev: Depends: libxft2 (= 2.1.2-6)
　　but 2.1.2-6firefly is to be installed
　　Depends: libfontconfig1-dev but it is not going to be installed

　　同样的一个软件包，只是由于编译时的小补丁的不同，就完全不能满足Debian要求的依赖关系。只能推倒，重建系统。

　　同样的情况，在Gentoo中完全可以通过同一套源码，配置不同USE来实现。也就是说，在Gentoo中，由于个人USE的设置的不同，上面的Debian的两个包，在Gentoo看来就是一个包，只是配置时候的打了不同的补丁。因此，没有所谓的因为依赖而不能安装的问题。

　　举例：假设该软件包有两个不同USE，一个是common，一个是firefly，那么对于Gentoo，只要你设定了是采用USE="common"编译，还是采用USE="common, firefly"编译，系统在编译软件包的时候，就会自动决定究竟是否打上firefly的patch。也就是说，在Gentoo中，允许同时存在来自同一源码的，编译时配置不同的二进制文件的存在，而Gentoo在处理依赖时候，除非是的确找不到依赖的文件。否则，Gentoo不会提示出依赖错误（因为确实没有错误）。而Debian在这一点上是过于严格了。

　　Gentoo的包管理的主要缺点在于采用源码编译，不能够满足快速安装系统的需要。同时，一旦系统的基准USE发生了变化（这经常发生，尤其是你还是Gentoo新手的时候，你很可能因为不知道哪个软件包采用那种USE才好，而在基准中加入了过多的USE），虽然可以采用emerge --new-use world进行对新USE的编译，但是，这时的Gentoo的依赖的包的编译顺序有时会有问题，而导致编译失败。（这个其实是一个依赖的问题，明明正常是1、2、3的顺序可以编译成功的，但是--new-use之后，emerge可能会错误的安排成了2、1、3的顺序，而导致编译失败）。

　　综上，Debian的问题在于依赖的过于严格。对于依赖的问题，可以采用的方法主要有。

　　1 强制安装。这是最下策，也是最麻烦的方法。（因为下次遇到同类的问题，还得强制安装，尤其是升级的时候）。

　　2 修改依赖关系。虽然我不知道debian的依赖要在哪里改，但是这的确是一条路。不过，这个也不轻松，因为每次都需要手工修改依赖关系。

　　3 欺骗Debian，直接将修改过的软件包，以debian原名的形式发布，这样可以解决依赖问题。但是，如果采用了debian的source.list中，如果开启了安全站点检验，这一步就无法通过。

　　4 系统推倒重建，安装Debian的官方版本。OK，如果你对中文显示要求不高，可以采用这个办法。不过，这样的话，就没有中文的粗体和斜体，同时，我觉得看起来也不怎么舒服。

　　5 就用非官方的版本，不轻易升级。本着够用就好的原则，期待别人解决问题。我，无语。（Hiweed用户适用。向Hiweed致敬）。

　　6 构建一套大系统，包含了所有由于补丁的问题所造成的问题的补丁。也就是大量的非官方的补丁。例如构建一套超大的，可以解决所有依赖问题的中文Debian，不妨叫大Hiweed。费时，费力，难与官方发布同步。

　　7 为什么不直接将中文补丁提交到Debian官方，或者对应软件开发的官方，这样软件就是Native Chinese Support。岂不是很好？（强烈赞同这个观点，这个应该是最终的解决之道）。

　　8 当然，也可以建议Debian修改它的依赖的检测方式。提供一些的灵活的，tiny的版本号，认为也是同样兼容的。

　　Gentoo的解决之道：
　　Gentoo虽然依赖的问题解决得很好，但是，Gentoo编译时间太长。虽然，你可以采用某些方法（比如，设定最简单的系统，设定复杂的USE，去除编译多余的Locale）来确保系统不编译多余的东西。也可以采用打开ccache的方法，建立数据库来加速c程序的编译。但是，Gentoo的安装时间长（通常桌面是几天，采用kde或gnome的情况），频繁升级的话，更是费时费力。

　　虽然我们不能解决升级时的编译问题。但是，我们至少可以解决安装的时间过长的问题。我们的希望来自教主的homeking的ibox，ibox采用livecd的方式，提供给大家一套完整的Gentoo中文解决方案。新版本的ibox将采用kde做为默认，同时提供迅速的安装到硬盘功能。

　　Gentoo的未来，在于随着计算机系统性能的不断提高，从源码编译软件的时间成本将会原来越低。同时，如果你有多台电脑，gentoo支持多台电脑采用并行的方式为同一台电脑编译软件。这也可以大大加快编译的时间。

　　有人认为Gentoo编译的系统，要比Debian要快。我觉得这不是一个事实。因为大多数的Gentoo的用户不懂得如何去最优化自己的系统。因此，编译出来的系统，优化也是有限的。这就给了Debian很大的机会。另外，USE参数设置的过多，也使得自己的系统多了好多自己不需要的功能。这也是一个原因。

　　Debian还有一个缺点，就是虽然Debian安装之后很小。但是如果你需要编译程序的时候，你就会发现Debian还要安装各种各样的headers或source，这些，对于Gentoo则是不需要的，因为Gentoo本身就是从源码编译过来的。不缺少那些东西。