当前位置 博文首页 > zy010101博客:Linux下软件的依赖问题
Linux软件的依赖关系是非常复杂的,通常的Linux都是依靠软件包管理工具来自动解决依赖关系的。以经常出现的Debian和Redhat这两大类来说,无论是deb包,还是rpm,都存在很严重的依赖问题。反观这个问题在Windows和Unix系统中就比较少见。当然Windows有时候遇见缺少某个动态链接库的时候,但是非常少,即使这种情况出现了,在Windows下一般可以比较容易的解决,例如安装某个版本的VC++库。OS X(Mac OS,苹果系统算是商业Unix系统)中,这个问题也不算严重。
经过在QQ群中的一些讨论,参考了一些问答网站的回答,得出比较合理的结论就是“这是Linux社区惧怕冗余所带来的结果”。就是说他们希望所有的库在系统里只有一份,听起来好像没什么毛病。但是换个角度看这个问题,就不一样了。假设某个库需要被30个软件依赖,那么如果这个库出问题了,那这30个软件都无法正常运行或者是缺少某部分功能。这就像是一个串联电路一样,一个坏了其它的也不能正常工作。一个典型的例子就是Glibc这个库。Glibc是Linux系统中最底层的API,几乎其它任何运行库都会依赖于Glibc。一旦它出问题,那么系统必将瘫痪。回想起来,当年的我也给Glibc做过大版本升级,现在想想是真的年轻,胆子大(其实就是蠢)。值得一提的是,有一些人会卸载Linux系统上一些自带的软件,然后系统就崩了。最典型的莫过于卸载系统自带的Python。百度一下就会发现,非常多的年轻人,胆子大的很。这个行为和我当年升级Glibc差不多。
Linux上这个问题其实是发行版的开发者在软件包上做了二次封装。玩起来了包依赖管理这样的套路。在我看来有时候冗余并不是一件坏事,一味的追求全局依赖是不可取的。
这里引用知乎上一个回答“用好Linux的经验之谈就是不要试图用一个Linux系统做许多事情。一个Linux尽量只做一件事,很多事情用很多Linux来做。至于怎么弄出很多Linux,docker也好KVM也罢,方法很多。”? ?感触颇深,确实,就目前的情况来看,主流的Linux发行版系统主要还是在服务器领域,专事专用也确实可以。
我写这篇文章的原因就是因为有个客户想升级openssh7.2到openssh7.4。我尝试着折腾了一下,发现这个问题无解。openssh7.4需要升级openssl到1.1.0以后的版本,这个我试着进行了安装,发现openssl可以顺利安装,没有问题。经过测试openssl用起来也没问题。解决了这个问题以后,发现还需要升级Glibc,当时系统已安装的Glibc是32位的,openssh7.4需要升级Glibc到64位版本。然后我就陷入了沉思了。后来经过到处查阅资料,以及和QQ群里的大佬讨论。得出的了下面的经验之谈。
接着说上面的openssh升级问题,这根本没法升级。所以我就问了客户为什么要升级?客户说是几个发现了几个CVE,然后openssh7.4版本解决了。他就想升级。然后我看了一下哪几个CVE,参考了网上的更改配置文件就基本解决了安全问题。
?
最后,还想说的是有的人的系统里既有deb包,也有rpm包。这也不太好,因为这可能会导致冲突,从而引起包管理混乱,然后系统就挂了。
snap是目前Ubuntu大力推广的方式,但是这个东西看起来是Ubuntu的一个阴谋。Ubuntu和Redhat的确推动了开源软件的发展,但是他们现在渐行渐远,快成了开源的敌人。Ubuntu想让snap成为唯一的应用商店,这样它就掌握了软件分发渠道。
参考资料:
https://www.zhihu.com/question/291606128
https://www.zhihu.com/question/20443067
https://blog.csdn.net/zhangxuehui1991/article/details/78111930
?