我知道 -f 是--fix-broken手册中的意思，它试图解决软件包的问题，但到底是做什么的呢？它如何决定如何修复这些包或者是否需要修复以及修复的方法？为什么有时会失败？
答案1
, --fix-brokenor-f只是将APT::Get::Fix-Broken选项设置为 true，但这不是有趣的部分。每当APT::Get::Fix-Broken是真的它设置一个布尔值调用FixBrokentrue 哪个在 apt-get 上启用更多逻辑。这个逻辑做了两件事：它调用pkgFixBroken位于算法.cc 文件中的函数，该函数应该返回 false 并验证BrokenCount()函数返回 0。后者很明显，如果 BrokenCount 不等于 0，那么我们就有损坏的包并出现问题，但这里的相关部分是一个pkgFixBroken类的实例，它被初始化，然后用函数调用Resolve()。
修复软件包的方法pkgFixBroken很简单，将所有已安装的软件包标记为可升级，并将没有可下载版本的软件包标记为可供修复。一旦完成，它就会调用pkgProblemResolver函数（或者看起来是什么），这使得事情变得有点复杂，但是有一条注释或多或少地解释了发生了什么：
该例程通过计算每个包的分数来工作。通过考虑包的优先级和所有反向依赖项来得出分数，该整数给出一个整数，该整数反映了调整包将造成的损坏量。
它从最高分到最低分通过保留或删除依赖包来纠正所有中断。如果失败，那么它会删除包本身并继续。该例程应该能够智能地从任何损坏状态转变为固定状态。
BrokenFix 标志启用一种算法尝试升级包以避免出现问题的模式。
这或多或少解释了一些事情。它分配分数并尝试从较高分数的包中解决所有包的依赖关系。
这似乎足以解决大部分问题，除非它不能解决问题。原因是“修复损坏”不会尝试“修复”包，而只是确保所有包的依赖关系都得到满足。换句话说，如果 A 依赖于 B 和 C，则确保 B 和 C 在 A 之前安装，并且没有其他的。
失败的通常原因不是因为依赖关系不满足，即所有软件包都存在并且理论上都可以安装，而是因为有另一个测试的 dpkg 失败了。在这些情况下dpkg --audit，dpkg --configure -a可能会比 apt 为您提供更多信息。
我建议您阅读所有注释，如果您有 C++ 背景，请尝试阅读代码，以防您需要对其功能进行更周到的解释。