我最近接到了一项任务，负责维护和移植一个内部 .deb 包到 Trusty，该包会--force-overwrite使用自定义版本覆盖（使用）其他包的配置文件，然后apt-get install -f -y运行安装一堆列为依赖项的相关包，其中一些是这些配置文件的合法所有者（请保留您的讽刺评论和恐怖尖叫）。请注意，此包将配置文件标记为配置文件，而不是常规文件。
在尝试清理过程中，我发现如果apt-get传递了-o Dpkg::Options::="--force-confold"，那么来自我们自定义包的配置文件将被依赖项的版本覆盖，而如果-o Dpkg::Options::="--force-confnew"使用，我们的包的文件将保留在最后。
然而，手册dpkg页状态：
confnew：如果 conffile 已被修改并且包中的版本确实发生了变化，则始终在不提示的情况下安装新版本，除非--force-confdef还指定了，在这种情况下优先采用默认操作。
confold：如果修改了 conffile 并且包中的版本确实发生了变化，则始终保留旧版本而不提示，除非--force-confdef还指定了，在这种情况下优先采用默认操作。
因为“新版本”已安装而“旧版本”保存，这似乎意味着“新版本”始终是当时正在安装的软件包中的版本，因此传递-o Dpkg::Options::="--force-confnew"给apt-get应该会导致依赖项的配置文件覆盖我们的软件包之前安装的配置文件。为什么情况并非如此？“新版本”的实际含义实际上是基于时间戳吗（这只会引发更多问题）？这是文档和/或实现中的错误吗dpkg？这是否只是由两个软件包声称使用相同的配置文件而引起的棘手的边缘情况，而dpkg开发人员认为没有人会疯狂到偶然发现这种情况？什么？
答案1
我相信我已经弄清楚了发生了什么：由于自定义包的依赖项在dpkg -i运行时未安装，因此该包已在包系统中注册，并且当时它及其配置文件均未安装。apt-get install -f运行时，依赖项已安装，并且然后软件包本身已安装，此时配置文件已安装，--force-conf*传递给的策略apt-get也已生效。因此，在使用 安装缺乏依赖关系的软件包时，事件顺序并不是问题--force-confnew。dpkg