什么是阴谋集团地狱？

Question

我在阅读《阴谋集团地狱》时有点困惑，因为这个词已经超载了。我猜最初 Cabal Hell 提到了菱形依赖问题，这是通过限制构建计划在每个构建计划中只有一个版本的任何包来解决的（一个包的两个不同版本不能存在于一个构建计划中）如answer 中所述。

但是，该术语也用于各种其他情况。例如破坏性的重新安装、不正确的包依赖边界（低/高版本边界）、不一致的环境……（或 Cabal 报告的任何其他错误）。

尤其是其中，我对 1) 破坏性的重新安装和 2) 不一致的环境感到困惑？它们是什么意思，cabal new-build 如何解决这些问题（它只是像cabal sandbox 这样的沙盒）？ ghc-pkg 在这里扮演什么角色？

非常感谢任何可以重现这些问题的参考资料或简单示例。

关于“破坏性重新安装”：如果我没记错的话，GHC 有自己的包管理器 (ghc-pkg)，并且这些包被安装为动态可链接库，即：base 依赖于ghc-prim，所以如果ghc-prim 被删除，它会破坏base，对吗？而且由于 GHC 只允许具有相同版本的包的一个实例，cabal install 可能会注册相同(package, version) 的更新版本，这样它就会破坏未注册包的依赖项。如果上述关于“破坏性重新安装”的理解是正确的； cabal new-build 对此有何帮助？

Answer 1

该术语唯一有意义的用法是链接答案中给出的那个。相关的是全局数据库中存在大量不同包的后续问题，这可能会使遇到钻石依赖关系更加常见，需要破坏性重新安装才能解决，等等。

该术语的其他用法没有帮助，仅表示“以某种方式涉及阴谋集团的问题”。

也就是说，让我回答你的其他问题。

1) ghc-pkg 不是包管理器，而是管理 ghc 包数据库的工具。 cabal 使用它来将包注册到数据库中，最终用户可以使用它来检查数据库的内容。将其视为 ghc 提供的底层底层的一部分，而不是竞争工具。

2) new-build 完全消除并替换了 packagedb 的标准概念。不是说数据库由包和版本组成，每对最多一个，而是一个数据库由任何给定版本的包的潜在多个副本组成，每个包可能具有其依赖项的不同版本，所有这些都在部分通过哈希寻址，因此由唯一的“指纹”标记。这称为store。当您new-build 时，cabal 会从头开始计算构建计划，而不考虑任何先前安装的依赖项。如果存储中已经存在特定指纹（由包、版本及其所有依赖项的版本、某些标志等组成），则它会使用它。如果没有，它会计算它。

因此，唯一可能发生的“钻石依赖”是真正无法解决的，而不是由于过早修复（由于已安装的 deps）某些部分而导致的依赖树。

tldr;你写“因为 GHC 只允许具有相同版本的包的一个实例”但是 new-build 部分解除了store 中的这一限制，这允许求解器更频繁地生成更好、更可重复的计划。