dpkg --dry-run 选项未正确模拟安装

Question 1

要确定是否可以在不需要安装其他依赖项的情况下安装软件包，最好的选择是使用“模拟”模式apt：

apt -s install ./mysql-workbench_6.2.3+dfsg-7_armhf.deb

（注意./哪个很重要）。这将输出dpkg实际安装将执行的操作。软件包安装标有Inst;如果其中有多个，则无法单独安装该软件包。

现在，到了最重要的部分......你不能使用dpkg它，不是因为dpkg不知道依赖关系（它肯定知道），而是因为依赖关系不够强大。当一个包依赖于另一个包时，依赖关系不会阻止该包被已安装如果不满足，就会阻止它被满足配置好的。看Debian 政策第 7.2 节：

一个Depends字段生效仅有的当要配置包时。它不会阻止软件包在其依赖关系未得到满足的情况下处于未配置状态，并且可以将依赖关系得到满足且已正确安装的软件包替换为依赖关系未满足或无法满足的不同版本；完成此操作后，依赖包将保持未配置状态（因为尝试配置它会出现错误）并且无法正常运行。

您可以在自己的测试中看到这一点：该过程失败并显示

dpkg: dependency problems prevent configuration of mysql-workbench

注意“配置”，而不是“安装”。如果您查看的输出dpkg -l mysql-workbench，您应该会看到iU，这意味着该软件包已安装但尚未配置。

当您在中启用“模拟”模式时dpkg，它基本上以只读模式运行。它通过设置一个f_noact标志来做到这一点；你可以在源代码中查找这个。安装软件包时，模拟执行安装动作（不编写任何内容），然后进入配置阶段；但是那个只是假装成功，这是模拟可以做的唯一事情 - 配置涉及在包中运行维护者脚本，并且很难确保这些脚本没有进行更改，或者确保在不允许他们进行更改的情况下可以确定它们的成功变化。因此，在您的情况下，模拟会安装包，该包会成功（如您的非模拟测试中一样），并伪造配置。因此没有检测到错误...

Answer

要确定是否可以在不需要安装其他依赖项的情况下安装软件包，最好的选择是使用“模拟”模式apt：

apt -s install ./mysql-workbench_6.2.3+dfsg-7_armhf.deb

（注意./哪个很重要）。这将输出dpkg实际安装将执行的操作。软件包安装标有Inst;如果其中有多个，则无法单独安装该软件包。

现在，到了最重要的部分......你不能使用dpkg它，不是因为dpkg不知道依赖关系（它肯定知道），而是因为依赖关系不够强大。当一个包依赖于另一个包时，依赖关系不会阻止该包被已安装如果不满足，就会阻止它被满足配置好的。看Debian 政策第 7.2 节：

一个Depends字段生效仅有的当要配置包时。它不会阻止软件包在其依赖关系未得到满足的情况下处于未配置状态，并且可以将依赖关系得到满足且已正确安装的软件包替换为依赖关系未满足或无法满足的不同版本；完成此操作后，依赖包将保持未配置状态（因为尝试配置它会出现错误）并且无法正常运行。

您可以在自己的测试中看到这一点：该过程失败并显示

dpkg: dependency problems prevent configuration of mysql-workbench

注意“配置”，而不是“安装”。如果您查看的输出dpkg -l mysql-workbench，您应该会看到iU，这意味着该软件包已安装但尚未配置。

当您在中启用“模拟”模式时dpkg，它基本上以只读模式运行。它通过设置一个f_noact标志来做到这一点；你可以在源代码中查找这个。安装软件包时，模拟执行安装动作（不编写任何内容），然后进入配置阶段；但是那个只是假装成功，这是模拟可以做的唯一事情 - 配置涉及在包中运行维护者脚本，并且很难确保这些脚本没有进行更改，或者确保在不允许他们进行更改的情况下可以确定它们的成功变化。因此，在您的情况下，模拟会安装包，该包会成功（如您的非模拟测试中一样），并伪造配置。因此没有检测到错误...

Question 2

虽然这在技术上不是一个答案，但这是一个很好的问题。

如果我们查看 man dpkg，就会发现它是关于要测试的选项的内容。如果有真正的 Debian 专家能够提供更权威的答复，那就太好了。或者如果其中有错误，请编辑我的。

   --no-act, --dry-run, --simulate
          Do everything which is supposed to be done, but don't write any changes. This is used to see what would happen with the specified
          action, without actually modifying anything.

我相信，虽然我不确定，但本质上，dpkg 正在测试的只是该命令是否有任何缺陷。例如，如果您这样做：

#dpkg --dry-run -i nonexistent.deb || echo $?
dpkg: error: cannot access archive 'nonexistent.deb': No such file or directory
2

这就是结果。我注意到的一件事是，即使使用 --dry-run，dpkg 也需要 root 权限，它会抱怨无法使用日志文件，这意味着它--dry-run根本没有按照我们的预期执行操作。使用apt-get，您可以以普通用户身份使用 --simulate。

dpkg 是一个非常低级别的 apt 工具，正如您从测试结果中看到的那样，它在实际安装 .deb 文件之前并不知道 apt 数据库和依赖关系树。所以我会推断，dpkg --dry-run或--simulate等只是测试实际的文字命令数据，而不是依赖项等。

这表明，虽然它看起来是同一个命令，在 apt-get 中运行得相当不错，但并不完美，但事实上它根本不一样。人们必须阅读 dpkg --simulate 中的代码才能了解它实际上做了什么。

研究这个问题似乎证实了我所认为的情况：

https://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013049.html

如果有一项功能，是否有一种自动方法来检查 .deb 的依赖关系，而不是尝试dpkg -i它（并最终得到配置不足的包）或手动dpkg -f逐一检查依赖关系？

我正在寻找类似 dpkg-buildpackage 的“未满足的构建依赖项：...”检查，但针对 .debs。

有一个名为“gdebi”的新应用程序可用，网址为： http://people.ubuntu.com/~mvo/gdebi/

它应该能够直接解决deb包的依赖关系。它包含 gdebi-gtk 和 gdebi（以及 cli 版本）。这可能就是你想要的。如果没有，请告诉我，它可能会被添加:)如果您使用/测试它，非常感谢反馈（通过私人邮件）。

这是一个非常古老的线程，我确信您不是在寻找 gui 工具，但值得注意的是，这个问题在 2005 年就存在，有人制作了一个可以检查依赖关系的 gui 解决方案，这表明事实上 dpkg --模拟没有。我也不希望如此，我已经为 Debian apt 和 dpkg 编写了很多自动化脚本，并且两者的行为和表现非常不同。

使用 dpkg 确定依赖关系的各种选项

https://lists.debian.org/debian-user/2006/09/msg00292.html

这是关于同一问题的旧 Debian 线程，同样，您可以看到 dpkg --dry-run 一般不处理依赖关系。

https://lists.debian.org/debian-user/2006/09/msg00297.html

dpkg-deb -I package.deb

有建议吗。这表明与基本相同apt-cache show package-name。

所以至少你可以自己验证依赖关系。

 dpkg -I perl_5.26.0-8_i386.deb
 ....
 Pre-Depends: dpkg (>= 1.17.17)
 Depends: perl-base (= 5.26.0-8), perl-modules-5.26 (>= 5.26.0-8), libperl5.26 (= 5.26.0-8)
....

https://lists.debian.org/debian-user/2006/09/msg00312.html

如果您使用dpkg --control pkg_file，那么它将显示包的所有控制信息，包括依赖项。

我测试过，但它没有显示任何内容，它可能已经过时了，我不知道。

正如您所看到的，Debian 开发人员提出了一些建议，但没有一个建议表明有一种方法可以满足dpgk --dry-run您的需求。

结论

您有几个选项，一是手动确定依赖项，这肯定适用于您将来创建自己的 deb 的情况，然后使用脚本安装或任何您认为适合您的方式来安装这些依赖项，然后安装 .deb之后打包。

使用带有快照的虚拟机进行测试也是一个不错的选择。

Answer