☰

APT 使用什么依赖关系解析器？

tag-icon • tag-icon apt package-management dependencies
APT 使用什么依赖关系解析器？

我注意到软件包的元数据中有版本限制（例如，git)。APT 使用什么算法来满足这些依赖关系？

例如，斯派克用途克林戈作为其依赖性解决器，Conda 和 Mamba 使用库库，点数使用其自己的自定义回溯求解器。

答案1

APT 的出现早于依赖解析这一概念，它是系统的一个有趣属性，可以独立于执行依赖解析的程序进行研究，因此 APT 的依赖解析算法基本上是：“无论APT 的源代码碰巧做了”。

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

当然，APT 的开发人员并没有随意地编写代码，但我的观点是：该算法没有名字，因为当时它是唯一的，因此没有理由只谈论算法而不谈论 APT，反之亦然。

有一点点README 部分中有关调试的信息：

依赖解析

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.
   
   ##################################################################### */

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

相关内容