Linux下软件的依赖问题
Linux软件的依赖关系是非常复杂的，通常的Linux都是依靠软件包管理工具来自动解决依赖关系的。以经常出现的Debian和Redhat这两大类来说，无论是deb包，还是rpm，都存在很严重的依赖问题。反观这个问题在Windows和Unix系统中就比较少见。当然Windows有时候遇见缺少某个动态链接库的时候，但是非常少，即使这种情况出现了，在Windows下一般可以比较容易的解决，例如安装某个版本的VC++库。OS X（Mac OS，苹果系统算是商业Unix系统）中，这个问题也不算严重。
那么为什么某些Linux发行版的这个问题就是如此的严重呢？
经过在QQ群中的一些讨论，参考了一些问答网站的回答，得出比较合理的结论就是“这是Linux社区惧怕冗余所带来的结果”。就是说他们希望所有的库在系统里只有一份，听起来好像没什么毛病。但是换个角度看这个问题，就不一样了。假设某个库需要被30个软件依赖，那么如果这个库出问题了，那这30个软件都无法正常运行或者是缺少某部分功能。这就像是一个串联电路一样，一个坏了其它的也不能正常工作。一个典型的例子就是Glibc这个库。Glibc是Linux系统中最底层的API，几乎其它任何运行库都会依赖于Glibc。一旦它出问题，那么系统必将瘫痪。回想起来，当年的我也给Glibc做过大版本升级，现在想想是真的年轻，胆子大（其实就是蠢）。值得一提的是，有一些人会卸载Linux系统上一些自带的软件，然后系统就崩了。最典型的莫过于卸载系统自带的Python。百度一下就会发现，非常多的年轻人，胆子大的很。这个行为和我当年升级Glibc差不多。
Linux上这个问题其实是发行版的开发者在软件包上做了二次封装。玩起来了包依赖管理这样的套路。在我看来有时候冗余并不是一件坏事，一味的追求全局依赖是不可取的。
这里引用知乎上一个回答“用好Linux的经验之谈就是不要试图用一个Linux系统做许多事情。一个Linux尽量只做一件事，很多事情用很多Linux来做。至于怎么弄出很多Linux，docker也好KVM也罢，方法很多。” 感触颇深，确实，就目前的情况来看，主流的Linux发行版系统主要还是在服务器领域，专事专用也确实可以。
如何解决Linux下如此复杂的以来问题？
我写这篇文章的原因就是因为有个客户想升级openssh7.2到openssh7.4。我尝试着折腾了一下，发现这个问题无解。openssh7.4需要升级openssl到1.1.0以后的版本，这个我试着进行了安装，发现openssl可以顺利安装，没有问题。经过测试openssl用起来也没问题。解决了这个问题以后，发现还需要升级Glibc，当时系统已安装的Glibc是32位的，openssh7.4需要升级Glibc到64位版本。然后我就陷入了沉思了。后来经过到处查阅资料，以及和QQ群里的大佬讨论。得出的了下面的经验之谈。
- 安装软件源上的软件，这听起来像是废话，但是大多数使用Centos的用户都应该或多或少导入过“野包”。你费尽心力导入野包，存在着导致系统不稳定的风险。应当尝试在软件源上寻找包。你所需要的包一般都能在软件源上找到。
- 使用Docker这样的容器，你想在Docker里干什么就干什么，这不会影响你的外部环境。
- 不要随意升级，降级软件。（当然安全更新除外，因为这是发行版官方已经解决了所有问题，你基本可以放心更新）
- 安装的不受发行版控制的软件包都自己进行统一管理。
- 使用appimage，snap以及Flatpaks。
接着说上面的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