我看过很多关于如何修复多个发行版中损坏的包的答案，这似乎非常有帮助并解决了问题。但是，我很好奇包裹是如何损坏的。
我正在对使用命令的管道进行故障排除apt-get install，并且无法安装某些依赖项。经过几次重试，我能够使管道正常工作。但是通过搜索解决方案，我发现 apt-get 有一个非常有用的--fix-broken标志，它解决了我的问题。但问题仍然存在，问题是什么？ 我不清楚如何找到--fix-broken为我解决的确切问题。
浏览它的手册页，有一些关于以下内容的通用信息：
Fix; attempt to correct a system with broken dependencies in place. This option, when
used with install/remove, can omit any packages to permit APT to deduce a likely
solution. If packages are specified, these have to completely correct the problem. The
option is sometimes necessary when running APT for the first time; APT itself does not
allow broken package dependencies to exist on a system. It is possible that a system's
dependency structure can be so corrupt as to require manual intervention.
就管道而言，其系统此时已实例化，导致其损坏的包可能发生了什么？有人能更深入地了解这个标志是如何工作的吗？最具体地说，包裹是如何损坏的？
答案1
解决的典型问题apt install --fix-broken是缺少依赖项。通常的方式那发生的是使用dpkg直接安装包：dpkg将知道依赖项是否丢失，但无法检索丢失的依赖项，因此包最终将部分安装（已安装但未配置）。apt install --fix-broken解决损坏的依赖项并安装任何所需的包，或者如果无法解决其依赖项，则删除完全损坏的包。
如果你是直接使用dpkg，通常更好apt install- 您可以将其指向本地包，它将在安装过程中解决其依赖关系。
答案2
包只是一个具有依赖项列表的软件。如果您的系统有一些非标准安装（例如，从源代码构建），或者如果您已固定软件包的特定版本（使用“dpkghold”或“dnf --exclude”）以避免破坏某些其他安装，然后尝试安装需要所有这些依赖包的不同状态的包将会失败，从而导致包“损坏”。
请务必注意，软件包或系统状态可能没有任何问题。原始包可能适合您的手工编译（无论如何），但因为它不是预期的它被视为已损坏。