我见过好几次有未满足依赖关系的人, apt-get 并不能直接告诉问题出在哪里,就像这样:
The following packages have unmet dependencies:
libgl1-mesa-dri:i386 : Depends: libdrm-intel1:i386 (>= 2.4.38) but it is not going to be installed
Depends: libdrm-nouveau2:i386 (>= 2.4.38) but it is not going to be installed
Depends: libdrm-radeon1:i386 (>= 2.4.31) but it is not going to be installed
Depends: libdrm2:i386 (>= 2.4.38) but it is not going to be installed
Depends: libglapi-mesa:i386 but it is not going to be installed
libgl1-mesa-glx:i386 : Depends: libdrm2:i386 (>= 2.3.1) but it is not going to be installed
Depends: libglapi-mesa:i386 (= 9.2.1-1ubuntu3) but it is not going to be installed
Depends: libx11-6:i386 (>= 2:1.4.99.1) but it is not going to be installed
Depends: libxcb-dri2-0:i386 (>= 1.8) but it is not going to be installed
Depends: libxcb-glx0:i386 (>= 1.8) but it is not going to be installed
Depends: libxcb1:i386 but it is not going to be installed
Depends: libxdamage1:i386 (>= 1:1.1) but it is not going to be installed
Depends: libxext6:i386 but it is not going to be installed
Depends: libxfixes3:i386 but it is not going to be installed
Depends: libxxf86vm1:i386 but it is not going to be installed
我知道遍历所有依赖项apt-get install libgl1-mesa-dri:i386 libdrm-intel1:i386
直到找到可用的东西,但在这种情况下,由于包的数量,这将是一项痛苦的工作。有没有更简单的方法来做到这一点?
答案1
合理的第一件事是询问 apt 为什么要做它正在做的事情。这可以通过选项来完成-o Debug::pkgProblemResolver=yes
。例如
apt-get -o Debug::pkgProblemResolver=yes install libgl1-mesa-dri:i386 libdrm-intel1:i386
如果没有出现 apt,调试此类问题的标准方法是检查错误消息中提到的每个包的可用版本的优先级编号。这通常使用 来完成apt-cache policy
。
例如,要仅使用错误消息的第一部分,您应该运行
apt-cache policy libgl1-mesa-dri:i386 libdrm-intel1:i386 libdrm-nouveau2:i386 libdrm-radeon1:i386 libdrm2:i386 libglapi-mesa:i386
接下来如何进行取决于这表明了什么。仅运行通常也很有用
apt-cache policy
这将显示所有可用的包源及其优先级编号。该信息通常在/etc/apt/sources.list
或之一或两者中指定/etc/apt/sources.list.d
。
试图在这里获得帮助的人应该首先发布这些命令的结果在他们的问题中。这可能足以确定问题的信息。
现实生活中的问题示例:
使用向后移植存储库后未满足的依赖关系:用户包含了 的源
www.deb-multimedia.org
,但没有将其固定为较低优先级。切勿包含第三方来源而不将其固定为较低优先级。请注意,对于为默认版本提供软件包的行为良好的存储库来说,这不是必需的,但www.deb-multimedia.org
众所周知,它与 Debian 不兼容,并且一般来说,您不应该信任未知来源。更一般地说,如果您知道存储库不适用于您的系统,请将其固定在较低的优先级。例如,在 Debian 稳定版上测试/不稳定源
。未满足的依赖关系:用户以某种方式设法安装了不是系统上默认版本的 python 版本。自然地,一切都乱了套。这个故事的寓意是,确保您只安装适合您的系统的软件包版本。上面
apt-cache policy pkgname
就告诉你了。dpkg / apt-get 想要安装并覆盖不同的包:用户尝试安装软件包,即使他的底层
dpkg
数据库已损坏。道德上,如果您看到来自dpkg
您的包裹有问题的消息,在这种情况下0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. 2 not fully installed or removed.
您的包数据库有问题。在尝试安装其他任何东西之前,请先修复它们。如果
apt-get -f install
不起作用,您可能需要进行操作dpkg
来修复问题。
答案2
有很多信息可以帮助您:
- 首先包含导致问题的完整命令。
包括有关以下内容的软件包的信息:
apt-cache policy name-of-packages-involved
所以,在你的情况下是最小值的输出
apt-cache policy libgl1-mesa-dri:i386 libdrm-intel1:i386 libgl1-mesa-glx:i386 libdrm-nouveau2:i386
。的输出
sudo apt-get check
也可能sudo dpkg -C
提高了你拥有的机会。sudo apt-get update
和 的完整输出cat /etc/apt/sources.list{,.d/*.list}
在某些情况下会有所帮助。如果您尝试安装软件包,可以通过 aptitudewhy-not
命令的输出轻松弄清楚:aptitude why-not sysvinit-core i A systemd-sysv Breaks sysvinit-core
当寻求有关解决此问题的帮助时,请始终包括完整的输出对于所有提出的问题,这将加快问题的解决。