软件系统的开发通常采用一种迭代的方式来进行，此时就会出现软件包间的依赖问题。
这个依赖关系可能是闭包的，传递的。我不会尝试版本依赖做一个精确的定义，而是
最近思考的两种技术有一些共同点，偶有所感，列出它们的处理方式，并记录下自己的 思考过程
Spring包依赖管理
spring boot被Pivotal公司定义为改变游戏规则的脚手架，真的是很方便。
在下载某些开源工具时，进行源代码编译会出现一些前提要求（Prerequisites）
如：Ambari的主页会有：
编译环境需要各种处理版本兼容问题，spring boot的starter将一组依赖集合全部下载。因此
在maven或者gradle等构建工具中，只需要几行配置文件就可以了。这个处理非常好，它将
一组依赖抽象为应用类型比如：JPA,WEB,SECURITY等。
Linux采用的包依赖管理方式类似，不过抽象为一个软件名称，这是一个更为简洁的
方式。
Linux软件安装包管理
Liunx软件安装包间的依赖和Spring项目的组件间依赖关系概念是相同的。
Linux抽象了软件依赖包下载过程，在Ubuntu或CentOS下安装vim,只需要
类似下面的shell命令
$> apt install vim-xx
这个过程会从网络上的软件源获得软件安装的解决方案。一般Linux都将软件源（称为repository）的网址硬编码到配置文件里，ubuntu下在/etc/apt/sources.list .
版本依赖管理概念提取
假如在一个软件版本依赖错综复杂的环境下，尤其作为框架的工具，一定要将单元依赖处理为
一键式解决，本人深受其苦。Ambari配置失败我并无多少沮丧，因为要配置本地源，部分资源被墙了。
依赖关系：
组件A版本x.x.x依赖于组件Bx.x.x要将一系列关于其依赖的连接置于组件A x.x.x的配置文件里。
例如：
A version 1.2.1
—B 被依赖方B兼容版本列表
- 2.3.6 库源链接
- 2.3.5 库源链接
- xxxx
亦或者为了节省存储空间将组件A版本x.x.x所兼容的最新版本做链接且更新本地镜像以防
止官方停止维持的现象。就如CentOS以前的小版本7.2，7.3，7.4镜像都已经找不到了，而ambari现只支持这两个版本，因此必要对依赖环境做本地镜像以为组件用户服务
传递依赖关系：
依赖关系会变得稍微有点复杂，当组件A x.x.x依赖B x.x.x,而B x.x.x依赖于C x.x.x,这个传递依赖
需要一些技巧去管理。
闭包依赖关系
组件间的依赖关系是可以成环的，因为组件A和依赖于组件B的某一个某块，但宏观上看，组件A是依赖于组件B的。尤其在协作组件间，这个现象比较常见。
必要的时候，企业真的需要构建自己业务相应的依赖解决方案，这对于后面的维护很重要。