“apt-get -f install”命令中的 -f 有什么作用？

Question

我知道 -f 的意思--fix-broken是手册中的意思，它试图解决包的问题，​​但究竟是什么？它如何决定如何修复包裹或是否需要修复以及修复方法？为什么有时会失败？

Answer 1

的--fix-broken，或-f仅设置APT::Get::Fix-Broken选项设置为true，但是这不是最有趣的部分。每当APT::Get::Fix-Broken为 true 时，它会将一个 bollean调用设置FixBroken为 true，从而在 apt-get 上启用更多逻辑。这个逻辑做了两件事：它调用了pkgFixBroken位于 algorithm.cc 文件中的函数，它应该返回 false 并验证BrokenCount()函数返回 0。后者很明显，如果 BrokenCount 与 0 不同，那么我们已经破坏了包并且有问题，但这里的相关部分是一个pkgFixBroken类的实例，它被初始化然后用Resolve()函数调用。

pkgFixBroken修复软件包的方法很简单，将所有已安装的软件包标记为可升级，并将没有可下载版本的软件包标记为可供修复。完成后，它会调用pkgProblemResolver函数（或它看起来是什么），这使事情变得有点复杂，但有一条评论或多或少地解释了正在发生的事情：

该例程通过计算每个包的分数来工作。该分数是通过考虑包的优先级和所有反向依赖项得出的，给出一个整数，反映调整包将造成的损坏量。

它从最高分到最低分，并通过保留或删除相关软件包来纠正所有中断。如果失败，那么它会删除包本身并继续。例程应该能够智能地从任何破坏状态转到固定状态。

BrokenFix 标志启用算法尝试升级包以避免出现问题的模式。

这或多或少地解释了一些事情。它分配分数并尝试从得分较高的包中进行评分，所有这些都解决了其依赖关系。

这似乎足以解决大多数问题，除非它没有。这样做的原因是 Fix Broken 不会尝试“修复”包，因为它只是确保所有包都满足其依赖关系。换句话说，如果 A 依赖于 B 和 C，它确保 B 和 C 安装在 A 之前，而不是其他任何东西。

失败的通常原因不是因为依赖项不满足，从理论上讲，所有包都在那里并且可以安装，而是因为 dpkg 有另一个测试失败了。在这些情况下dpkg --audit，dpkg --configure -a可能会比 apt 提供更多信息。

我建议您阅读所有评论，如果您有 C++ 背景，请尝试阅读代码，以防您需要对其功能进行更周到的解释。