前几天在SUSE LINUX裸机上面搭MYSQL+TRAC的环境时，被依赖关系整的头昏脑胀，搜到一个帖子，整理如下：
- 减少重复开发，节省了程序员开发的时间
- 提高资源利用率，实现相同功能，占用的资源要少非常多。如某仁兄说的：
你知道如果用Qt写一个几百行代码的小程序如果要直接放到windows下运行要多大嘛?我编译加可执行文件最大压缩后都有5M...或许你觉得不大,但是你没发觉没多软件的库其实都有重复的吗?windwos下的软件你知道装了多少其他的东西吗?现在的C++库很多,不见的就都用c#和win32API吧,再说C#你要是XP的话还得装.net呢... - 不需要被强奸安装巨大的IDE和库：确实，LINUX下面，各种硬件不同的BSD，经常是找不到合适的二进制RPM文件直安装的，这时，只能编译源码来生成安装包。而编译本身是比较繁琐的，解决依赖关系其实就是解决编译环境和库，但是通常LINUX环境下需要下载的文件都不是是太大。与此相比，win下面的开发，是有一整套工具提供的，但工具一般非常大，形象地说，就是要被强奸安装巨大的ide和全套的开发库，而且，一般是付费的，不想付费就得花更多时间找破解资源，更麻烦。
- 某些支持包管理的软件，例如trac，可以借助easy_install等包管理工具等，自动解决依赖关系。
- 依赖关系下，对于维护也有利有弊，第一，若某个被依赖的软件出现bug或者漏洞，这时候就只需要维护一个软件，可以不动依赖它的上层软件，而win下面，（除了系统的api），安装包都被打成静态包了，这时候如果有个bug，那每个软件都需要打补丁；其二，简化了安装，无须判断其他需要链接的软件的位置。
- 当然，弊端也有，同样是某哥的原话：
一般来说依赖关系可以使得软件较小并且某个lib修复bug以后所有被依赖的软件都能得到好处。
不过lz说的也有些道理，有些时候依赖关系也确实有点烦人。
我上次碰到一个例子：
我安装的是gentoo，并且安装了docky这个软件，而docky依赖于mono。
有一次我在做emerge -Dup world的时候提示我mono有更新，从2.2更新到2.8了，但是docky还没有。
于是我就emerge --update --deep world把这个mono更新了。
之后发现docky就无法启动了。
从命令行启动docky以后就发现原来依赖于mono的某个api函数被删除了... 囧死。
google了一下发现新版本的docky已经修复了这个问题，但是emerge --sync的时候发现新的ebuild还没有进去。
没办法只好找gentoo bug，里面发现了一个ebuild（当然自己写ebuild也简单的很），down下来以后再次emere docky, 终于搞定了。
幸好docky并不是什么重要的软件，但即便如此，仍然让人感觉不爽。
当然这更多的是portage系统的问题，因为ebuild一般对于依赖关系会指定>=某个版本的软件，而很少用=某个版本的软件。
然而>=才是合理的，这样才能保证被依赖的软件也能得到升级。所以此问题几乎不可避免。
依赖问题的关键在于，开发软件A的人员，很少会顾及，甚至未必知道还有个软件B依赖于它，所以想改就改了，虽然大部分情况下，软件能做到向后兼容，但是仍然有意外的时候。
参考链接
