在阅读关于阴谋地狱的消息时，我有点困惑，因为该术语超载了。我猜最初是Cabal Hell提到了菱形依赖问题，此问题通过限制构建计划以使每个构建计划中的任何软件包都只有一个版本来解决（单个构建计划中不能存在两个不同版本的软件包）如此答案所述。
但是，该术语还用于其他各种情况。例如破坏性的重新安装，不正确的软件包依赖项边界（较低/较高版本边界），不一致的环境……（或Cabal报告的任何其他错误）。
其中，我特别困惑于1）破坏性的重新安装和2）不一致的环境？它们是什么意思，以及如何cabal new-build解决这些问题（就像sandbox一样cabal sandbox）？和什么样的作用ghc-pkg在这方面发挥？
可以重现这些问题的任何参考文献或简单示例，将不胜感激。
关于“破坏性的重新安装”：如果我没看错，GHC本身就有一个软件包管理器（ghc-pkg），并且这些软件包安装为可动态链接的库，即：base依靠ghc-prim，因此，如果ghc-prim将其删除，它将中断base，对吗？并且由于GHC仅允许使用相同版本的软件包的一个实例，因此cabal install可能会注册相同版本的更新版本(package, version)，从而破坏未注册软件包的依赖项。如果以上关于“破坏性重新安装”的理解是正确的；如何做cabal new-build帮助在这里？
该术语的唯一有意义的用法是链接答案中给出的用法。与此相关的是全局数据库中具有许多不同软件包的后续问题，这些问题可能使遇到钻石的依赖关系更加常见，需要进行破坏性的重新安装才能解决等问题。
该术语的其他用法无济于事，仅表示“以某种方式涉及阴谋集团的问题”。
就是说，让我回答您的其他问题。
1）ghc-pkg不是软件包管理器，而是用于管理ghc软件包数据库的工具。cabal使用它来将软件包注册到数据库中，并且最终用户可以使用它来检查数据库的内容。可以将其视为ghc提供的基础衬底的一部分，而不是竞争工具。
2）完全new-build消除和替代packagedb的标准概念。db并不是说db由软件包和版本组成，每对最多有一个，而是db由任何给定版本的软件包的许多副本组成，每个副本都有其依赖关系的潜在版本，所有这些都在以下位置管理通过散列寻址来区分，因此具有唯一的“指纹”标记。这称为store。当您使用时new-build，cabal会从头开始计算构建计划，而与先前安装的任何依赖项无关。如果商店中已经存在特定的指纹（包括软件包，版本及其所有依赖项的版本，某些标志等），则它将使用该指纹。如果没有，它将进行计算。
这样，唯一可能发生的“钻石依赖关系”是真正无法解决的依赖关系，而不是由于过早地固定依赖关系树的某些部分（由于已经安装了dep）而引起的。
tldr; 您写了“因为GHC只允许一个版本相同的软件包实例”，但是新建版本部分地解除了此限制，store从而使求解器可以更频繁地生成更好，更可重复的计划。