fbpx
维基百科

相依性地狱

相依性地狱(英语:dependency hell),又称依赖地狱,是指在操作系统中由于软件之间的依赖性不能被满足而引发的问题。

一个软件包依赖于其它必要的软件包(且版本要符合要求),使得软件包系统形成了复杂的依赖关系网络,并可能引发一系列问题。一些软件包可能因为依赖性无法满足,需要安装大量软件包;另一方面,一个软件包的卸载可能引发数量众多的软件包无法工作。

目前,GNU/Linux通过高级软件包管理机制,一定程度上解决了相依性地狱问题。较著名的有Debian阵营的APT[1]Redhat阵营的Yum,及 Yum 的后继包管理工具 DNF[2]

问题由来 编辑

相较“另起炉灶”的做法,现代软件往往会利用一些已有的组件(如库、程序、多媒体文件)进行开发。这些组件可能是某个软件,也可能是专门为其他软件使用而设计()。程序开发者根据特定版本的组件来设计自己的软件。这种方式减少了开发的工作量,使得程序比较轻便。但是该软件要正确运行,必须安装了指定版本的某些组件。

做一个比喻:你在建造一所房子,而并不生产门窗。由于门洞和窗口的尺寸要和门窗配合,因此你不得不寻找了一家门窗厂商,以他们生产的门窗作为标准,来建造合适的房子。你建造的房屋必须依赖于这家门窗厂商所生产的特定型号的门。

这便是相依性的产生过程。

若只有简单的相依性,则比较容易解决。如A软件依赖e、z软件包,而e、z软件包没有依赖,只需要安装e、z软件包,再安装A软件即可。就如建造商与门窗商的依赖关系,简单明了。

而当依赖性过多,且具有多级结构,形成错综复杂的网络,依赖性的解析就会变得异常困难,甚至出现无法解析的致命错误

  • 由于软件包更新迅速,且互相不同步,依赖性所要求的版本条件可能很快便不存在。
  • 当多个软件包同时依赖于一个软件包,但所要求的版本不同。如A软件包依赖gcc-4.6及以上而B软件依赖gcc-4.5,那么就会产生相依性冲突。这种情况下,两个软件包A、B无法同时满足依赖性,无法同时安装或运行。
  • 当一个软件包依赖多个软件包,解析依赖性的难度会加大。如A软件包依赖40个软件包,而这40个软件包每个又都有自身的依赖关系,依赖关系深达3-5层。这样的计算,靠人力有时是难以完成的,必须借助软件包管理器进行自动解析。同时,安装组件的数量也会由于依赖性过多而增长。
  • 当两个软件包不共存的时候,可能会对整个体系造成巨大冲击。若是两个底层软件包,则影响会更大。由依赖关系形成的网络会断裂为不共存的两部分。在建立软件包体系的过程中,要尽量避免这种情况发生,尤其是底层软件包的不共存问题。
  • 在特殊情况下还会产生不可解的依赖关系,如依赖死循环

问题类型 编辑

依赖过多 编辑

一个软件包可能依赖于众多的库,因此安装一个软件包的同时要安装几个甚至几十个库包。

多重依赖 编辑

指从所需软件包到最底层软件包之间的层级数过多。这会导致依赖性解析过于复杂,并且容易产生依赖冲突和环形依赖。

依赖冲突 编辑

即两个软件包无法共存的情况。除两个软件包包含内容直接冲突外,也可能因为其依赖的低层软件包互相冲突。因此,两个看似毫无关联的软件包也可能因为依赖性冲突而无法安装。

依赖循环 编辑

即依赖性关系形成一个闭合环路,最终导致:在安装A软件包之前,必须要安装A、B、C、D软件包,然而这是不可能的。

参考文献 编辑

引用
  1. ^ . [2018-04-03]. (原始内容存档于2008年12月4日). 
  2. ^ Fedora Wiki, Yum (页面存档备份,存于互联网档案馆(英文)

参见 编辑

相依性地狱, 英语, dependency, hell, 又称依赖地狱, 是指在操作系统中由于软件之间的依赖性不能被满足而引发的问题, 一个软件包依赖于其它必要的软件包, 且版本要符合要求, 使得软件包系统形成了复杂的依赖关系网络, 并可能引发一系列问题, 一些软件包可能因为依赖性无法满足, 需要安装大量软件包, 另一方面, 一个软件包的卸载可能引发数量众多的软件包无法工作, 目前, linux通过高级软件包管理机制, 一定程度上解决了问题, 较著名的有debian阵营的apt, 和redhat阵营的yum, 的后. 相依性地狱 英语 dependency hell 又称依赖地狱 是指在操作系统中由于软件之间的依赖性不能被满足而引发的问题 一个软件包依赖于其它必要的软件包 且版本要符合要求 使得软件包系统形成了复杂的依赖关系网络 并可能引发一系列问题 一些软件包可能因为依赖性无法满足 需要安装大量软件包 另一方面 一个软件包的卸载可能引发数量众多的软件包无法工作 目前 GNU Linux通过高级软件包管理机制 一定程度上解决了相依性地狱问题 较著名的有Debian阵营的APT 1 和Redhat阵营的Yum 及 Yum 的后继包管理工具 DNF 2 目录 1 问题由来 2 问题类型 2 1 依赖过多 2 2 多重依赖 2 3 依赖冲突 2 4 依赖循环 3 参考文献 4 参见问题由来 编辑相较 另起炉灶 的做法 现代软件往往会利用一些已有的组件 如库 程序 多媒体文件 进行开发 这些组件可能是某个软件 也可能是专门为其他软件使用而设计 库 程序开发者根据特定版本的组件来设计自己的软件 这种方式减少了开发的工作量 使得程序比较轻便 但是该软件要正确运行 必须安装了指定版本的某些组件 做一个比喻 你在建造一所房子 而并不生产门窗 由于门洞和窗口的尺寸要和门窗配合 因此你不得不寻找了一家门窗厂商 以他们生产的门窗作为标准 来建造合适的房子 你建造的房屋必须依赖于这家门窗厂商所生产的特定型号的门 这便是相依性的产生过程 若只有简单的相依性 则比较容易解决 如A软件依赖e z软件包 而e z软件包没有依赖 只需要安装e z软件包 再安装A软件即可 就如建造商与门窗商的依赖关系 简单明了 而当依赖性过多 且具有多级结构 形成错综复杂的网络 依赖性的解析就会变得异常困难 甚至出现无法解析的致命错误 由于软件包更新迅速 且互相不同步 依赖性所要求的版本条件可能很快便不存在 当多个软件包同时依赖于一个软件包 但所要求的版本不同 如A软件包依赖gcc 4 6及以上而B软件依赖gcc 4 5 那么就会产生相依性冲突 这种情况下 两个软件包A B无法同时满足依赖性 无法同时安装或运行 当一个软件包依赖多个软件包 解析依赖性的难度会加大 如A软件包依赖40个软件包 而这40个软件包每个又都有自身的依赖关系 依赖关系深达3 5层 这样的计算 靠人力有时是难以完成的 必须借助软件包管理器进行自动解析 同时 安装组件的数量也会由于依赖性过多而增长 当两个软件包不共存的时候 可能会对整个体系造成巨大冲击 若是两个底层软件包 则影响会更大 由依赖关系形成的网络会断裂为不共存的两部分 在建立软件包体系的过程中 要尽量避免这种情况发生 尤其是底层软件包的不共存问题 在特殊情况下还会产生不可解的依赖关系 如依赖死循环 问题类型 编辑依赖过多 编辑 一个软件包可能依赖于众多的库 因此安装一个软件包的同时要安装几个甚至几十个库包 多重依赖 编辑 指从所需软件包到最底层软件包之间的层级数过多 这会导致依赖性解析过于复杂 并且容易产生依赖冲突和环形依赖 依赖冲突 编辑 即两个软件包无法共存的情况 除两个软件包包含内容直接冲突外 也可能因为其依赖的低层软件包互相冲突 因此 两个看似毫无关联的软件包也可能因为依赖性冲突而无法安装 依赖循环 编辑 即依赖性关系形成一个闭合环路 最终导致 在安装A软件包之前 必须要安装A B C D软件包 然而这是不可能的 参考文献 编辑引用 DebianPackageManagement 2018 04 03 原始内容存档于2008年12月4日 Fedora Wiki Yum 页面存档备份 存于互联网档案馆 英文 参见 编辑高级包装工具 DLL地狱 PBI Yellow Dog Updater Modified 取自 https zh wikipedia org w index php title 相依性地狱 amp oldid 74413464, 维基百科,wiki,书籍,书籍,图书馆,

文章

,阅读,下载,免费,免费下载,mp3,视频,mp4,3gp, jpg,jpeg,gif,png,图片,音乐,歌曲,电影,书籍,游戏,游戏。