Linux：恼人的依赖关系
apt 如果检测到什么包有损坏(未满足)的依赖关系，它会在升级系统时尝试修正，补充所有依赖包，如果解决不了，就会要求卸载这些包。由于开发者的编译环境不同，会引入对不同文件的依赖，因为依赖关系是在 ./configure 执行时自动引入的，它是“随遇而安”的。换句话说，根据系统当前有什么条件就地取材，如果缺少什么，只要不是很重要，也可以通过编译，无非是损失一点功能。编好的可执行文件换了地方，就可能因为找不到自己依赖的包而无法运行。
这就是为什么在不同系统下编译成的软件不能通用的原因。比如你的 mandrake 的 rpm 拿到 redhat 下试试，多半是不能安装的！除非强制不检验依赖关系。即便在相同系统的不同版本之间，常常也不能互换安装文件进行安装，比如 redhat 7.3 的 rpm 就基本不能在 redhat 9 下使用。
这称为二进制水平上的不兼容。甚至有些软件作者自己的同一软件的不同版本之间也是互不兼容的，例如 automake 各个版本之间就是互不兼容的。好在多数 linux 发行版在源代码级别上是互相兼容的。事实上，没有任何两个 linux 发行版是绝对兼容的。同样，win98 和 winxp 也是如此，不过 MS 由于是大型商业软件公司，有能力做到大致兼容，否则就是自己找麻烦。反倒是苦了那些程序员，要经过反复调试才能使自己的软件适应 windows 的多个版本，甚至被迫发布针对不同操作系统版本的版本。
linux 和 unix 由于开发者众多，同样是藩镇割据，四分五裂。这就是极度自由散漫的不良后果，尽管自由有它积极的一面。很多作者甚至不关心你能不能用、是否支持用户的语言、用户能否看懂他的说明，他们只是自我欣赏，或是自愉自乐，他们也不可能有足够的时间做自己感觉不重要的事情。SUN 可能公开 java 的源代码，但却禁止人们修改它，就是担心 java 四分五裂，互不兼容。用户群广泛的软件都有这种担忧，多个不同的派生产品也会使最终用户手足无措。
LSB (linux standard base，linux 标准基)标准试图规范开发者行为，解决二进制水平上的不兼容。不幸的是，几乎没有人真正遵守这一冗长、复杂的规范。 没有什么办法，只能尽量做到同一个发行版兼容就差不多了。 不是说大部分厂商还是遵守了 LSB 的么？
嘿嘿，看了 KDE 的贴终于明白为什么会删除软件包了，呵呵。 以后强制开发人员用ML来开发不就行了嘛～～为什么自己开发的东西都不用？ :?: 比如你的 mandrake 的 rpm 拿到 redhat 下试试，多半是不能安装的
多半是能安装的 只要能得到源码，我还是喜欢自己编译 :mrgreen: 以后强制开发人员用ML来开发不就行了嘛～～为什么自己开发的东西都不用？ :?:
但是硬件不同比如KanKer的硬盘是sata的，
MI的安装程序不支持，
只能从Fr2升级，会引入另外的依赖。 :mrgreen: cjx3501出钱给kanker买块硬盘，也算支持一下MGC了 即使是gentoo也存在这个问题。 用apt升级时，如何排除某个软件如：apt
我现在升级系统时，要升级apt,可是与现在的冲突，而无法升级，怎么跳过它，只升级其他的 还是用debian爽 :mrgreen::mrgreen: lfs最过瘾了 :mrgreen::mrgreen::mrgreen: :mrgreen: cjx3501出钱给kanker买块硬盘，也算支持一下MGC了
买块硬盘的钱总是有滴～～～少去一两次跟MM吃饭就能省下来了嘛，什么？英雄难过美人关？那就叫上我好了(我买单) :mrgreen::roll:
老兄，有源代码耶！一般编译一下都可以通过的。
找源代码编译吧 说句招人骂的话:还是 M$的方式好:函数都固定在那几个DLL里，不用那你就得另外给DLL
不过后来应用讨厌的ACTIVEX后DLL HELL就出现了
LINUX不近人情之一就是 lib hell
我下载了 anjuta,他要我装个 libzvt2.0以上，鬼知道里面是干什么用的。我的系统没libzvt都可以用啊
用天网搜，好，有.src.rpm
./ conufiure
make
OK
生成了一个libzvt目录
然后下一步就不知道要干什么了
把它的文件都复制到 /usr/share/lib
还是不能安装啊。