APT 使用什么依赖性解析器？

APT 早于依赖性解析的想法，它是系统的一个有趣的属性，可以独立于执行依赖性解析的程序进行研究，因此 APT 的依赖性解析算法基本上是：“无论APT 的源代码发生了什么”。

特别是，APT 是第一个提供依赖性解析的包管理器，因此没有理由独立于 APT 讨论其算法，例如将其与 RPM 进行比较，因为 RPM 没有有依赖解析。

当然，现在 APT 的开发者不仅仅是随机编码的，但我的观点是：该算法没有名称，因为在当时，它是唯一的，所以没有理由谈论算法而不谈论APT，反之亦然。

自述文件部分中有一些关于调试的信息：

依赖解析

APT 在其内部解析器中分两个阶段工作：首先访问所有包并标记为安装、保留或删除。选项Debug::pkgDepCache::Marker显示了这一点。这也决定了要安装哪些包来满足依赖关系，这可以通过Debug::pkgDepCache::AutoInstall. 完成此操作后，我们可能会遇到这样的情况：想要安装两个包，但只能安装其中一个。的工作是pkgProblemResolver决定两个包中的哪一个“获胜”，从而决定必须发生什么。您可以通过 来查看竞争者以及他们的战斗以及由此产生的解决方案Debug::pkgProblemResolver。

这是源代码中的一个有趣的小评论：

/* ######################################################################

   Algorithms - A set of misc algorithms

   The pkgProblemResolver class has become insanely complex and
   very sophisticated, it handles every test case I have thrown at it
   to my satisfaction. Understanding exactly why all the steps the class
   does are required is difficult and changing though not very risky
   may result in other cases not working.
   
   ##################################################################### */

Rinzwind 评论中的博客文章Debian APT 依赖解析器提供了更多详细信息。它是由一位包维护人员编写的，他对包中发生的奇怪事情感到困惑，并深入研究了算法的微小细节。