什么是阴谋集团地狱？
What is Cabal Hell?
我在阅读有关 Cabal Hell 的内容时有点困惑，因为这个词太多了。我想最初 Cabal Hell 指的是钻石依赖问题，这是通过限制构建计划在每个构建计划中只有一个版本的任何包来解决的（单个构建计划中不能存在两个不同版本的包）如本 answer.
中所述
但是，该术语也用于其他各种上下文。例如破坏性的重新安装、不正确的包依赖边界（lower/upper 版本边界）、不一致的环境……（或 Cabal 报告的任何其他错误）。
特别是其中，我对 1) 破坏性的重新安装和 2) 不一致的环境感到困惑？它们是什么意思，cabal new-build 是如何解决这些问题的（是否只是像 cabal sandbox 那样的沙盒）？ ghc-pkg 在这里扮演什么角色？
任何可以重现这些问题的参考或简单示例将不胜感激。
关于 "destructive re-installations"：如果我没记错的话，GHC 有一个自己的包管理器 (ghc-pkg)，并且包作为动态可链接库安装，即：base 取决于在 ghc-prim 上，所以如果 ghc-prim 被删除，它将破坏 base，对吗？并且由于 GHC 只允许具有相同版本的包的一个实例，cabal install 可能会注册相同 (package, version) 的更新版本，这样它会破坏未注册包的依赖项。如果以上关于"destructive re-installations"的理解是正确的； cabal new-build 在这方面有何帮助？
该术语唯一有意义的用法是链接答案中给出的用法。相关的是在全局数据库中有许多不同的包的后续问题，这可能使遇到钻石依赖性更常见，需要破坏性的重新安装来解决等。
该术语的其他用法没有帮助，仅表示 "problems somehow involving cabal."
话虽如此，让我回答你的其他问题。
1) ghc-pkg 不是包管理器，而是管理 ghc 包数据库的工具。 cabal 使用它来将包注册到数据库中，最终用户可以使用它来检查数据库的内容。将其视为 ghc 提供的底层基础的一部分，而不是竞争工具。
2) new-build 完全消除并替换了 packagedb 的标准概念。与其说数据库由包和版本组成，每对最多有一个，不如说数据库由任何给定版本的包的潜在多个副本组成，每个副本可能具有其依赖项的不同版本，所有这些都在中进行管理部分通过哈希寻址，因此由唯一的 "fingerprint" 标记。这叫做store。当您 new-build 时，cabal 会从头开始计算构建计划，而不管之前安装的任何依赖项。如果特定的指纹（由包、版本及其所有依赖项的版本、某些标志等组成）已经存在于商店中，则它会使用它。如果没有，它会计算它。
因此，唯一可能发生的 "diamond dependencies" 是 真正 不可溶的，而不是由于过早修复而引起的（由于已经-安装 deps) 依赖关系树的一部分。
tldr；你写 "since GHC only allows one instance of a package with the same version" 但新建部分解除了 store 中的这个限制，它允许求解器更频繁地生成更好、更可重现的计划。
我在阅读有关 Cabal Hell 的内容时有点困惑，因为这个词太多了。我想最初 Cabal Hell 指的是钻石依赖问题，这是通过限制构建计划在每个构建计划中只有一个版本的任何包来解决的（单个构建计划中不能存在两个不同版本的包）如本 answer.
中所述但是，该术语也用于其他各种上下文。例如破坏性的重新安装、不正确的包依赖边界（lower/upper 版本边界）、不一致的环境……（或 Cabal 报告的任何其他错误）。
特别是其中，我对 1) 破坏性的重新安装和 2) 不一致的环境感到困惑？它们是什么意思，cabal new-build 是如何解决这些问题的（是否只是像 cabal sandbox 那样的沙盒）？ ghc-pkg 在这里扮演什么角色？
任何可以重现这些问题的参考或简单示例将不胜感激。
关于 "destructive re-installations"：如果我没记错的话，GHC 有一个自己的包管理器 (ghc-pkg)，并且包作为动态可链接库安装，即：base 取决于在 ghc-prim 上，所以如果 ghc-prim 被删除，它将破坏 base，对吗？并且由于 GHC 只允许具有相同版本的包的一个实例，cabal install 可能会注册相同 (package, version) 的更新版本，这样它会破坏未注册包的依赖项。如果以上关于"destructive re-installations"的理解是正确的； cabal new-build 在这方面有何帮助？
该术语唯一有意义的用法是链接答案中给出的用法。相关的是在全局数据库中有许多不同的包的后续问题，这可能使遇到钻石依赖性更常见，需要破坏性的重新安装来解决等。
该术语的其他用法没有帮助，仅表示 "problems somehow involving cabal."
话虽如此，让我回答你的其他问题。
1) ghc-pkg 不是包管理器，而是管理 ghc 包数据库的工具。 cabal 使用它来将包注册到数据库中，最终用户可以使用它来检查数据库的内容。将其视为 ghc 提供的底层基础的一部分，而不是竞争工具。
2) new-build 完全消除并替换了 packagedb 的标准概念。与其说数据库由包和版本组成，每对最多有一个，不如说数据库由任何给定版本的包的潜在多个副本组成，每个副本可能具有其依赖项的不同版本，所有这些都在中进行管理部分通过哈希寻址，因此由唯一的 "fingerprint" 标记。这叫做store。当您 new-build 时，cabal 会从头开始计算构建计划，而不管之前安装的任何依赖项。如果特定的指纹（由包、版本及其所有依赖项的版本、某些标志等组成）已经存在于商店中，则它会使用它。如果没有，它会计算它。
因此，唯一可能发生的 "diamond dependencies" 是 真正 不可溶的，而不是由于过早修复而引起的（由于已经-安装 deps) 依赖关系树的一部分。
tldr；你写 "since GHC only allows one instance of a package with the same version" 但新建部分解除了 store 中的这个限制，它允许求解器更频繁地生成更好、更可重现的计划。