最后，我处理了打算使用dpkg进行部署的软件。.deb程序包在测试环境中可以正常工作，但在暂存时失败。两者都运行相同版本的Ubuntu，但是我不确定其余配置的100％。如何进一步调试此dpkg问题？
安装失败，如下所示：
sudo dpkg -i --debug=7337 package.deb
D000010: ensure_pathname_nonexisting `/var/lib/dpkg/tmp.ci'
(Reading database ... 201812 files and directories currently installed.)
Unpacking myProprietarySoftware (from package.deb) ...
D000001: process_archive oldversionstatus=not installed
D000002: fork/exec /var/lib/dpkg/tmp.ci/preinst ( install )
dpkg: error processing package.deb (--install):
subprocess new pre-installation script returned error exit status 1
D000002: maintainer_script_new nonexistent postrm `/var/lib/dpkg/tmp.ci/postrm'
D000010: ensure_pathname_nonexisting `/var/lib/dpkg/tmp.ci'
D000010: ensure_pathname_nonexisting running rm -rf
D000010: ensure_pathname_nonexisting `/var/lib/dpkg/reassemble.deb'
Errors were encountered while processing:
package.deb
软件包的.preinst脚本由于某种原因而失败。
要找出原因，请检查中的脚本 /var/lib/dpkg/info/PACKAGENAME.preinst
如果要确切查看脚本失败的行，请编辑.preinst脚本并set -x在该#!行之后立即添加。这将打开脚本中的执行跟踪。
注意：这假定.preinst脚本是Shell脚本（posix sh或bash）。几乎所有.preinst（和.postinst，.prerm和.postrm）脚本都是shell脚本，但不一定必须如此，它们可以是任何可执行文件。例如，在安装了9104软件包的主台式机上，有14个是perl脚本，有1个是已编译的可执行文件（bash的preinst-它不能假定已经安装了有效的shell），其余的都是shell脚本... 9041是POSIX Shell脚本，63是bash脚本。如果.preinst是perl或python或其他名称，则必须弄清楚如何启用调试或执行跟踪模式或使用该语言的类似模式。
然后运行dpkg --configure --pending。
这将导致dpkg尝试配置半安装的软件包。不要使用重新安装它dpkg -i，这将用.deb软件包中的版本覆盖您编辑过的.preinst脚本。
这可能会给您足够的信息来解决问题。它可能很简单，例如程序的意外或未捕获的退出代码（大多数.preinst etc脚本具有set -e，使它们在出现第一个错误时终止），或者假定目录已经存在（这可能是由于未声明的依赖性）在软件包的debian / control文件中-即它应该取决于foo，但不依赖。无论如何都要安装foo）
修复后，dpkg --configure --pending再次运行，该软件包应正确安装。
如果.preinst脚本有错误，那么.postinst（和/或.prerm和.postrm）脚本也很有可能也会出现。您可能还需要修复它们。
别忘了向开发包的任何人提交错误报告，以便他们进行修复。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句