我们正在托管 debian jessie 存储库的一个分支，其中包含自定义、向后移植和修补的软件包。每个产品版本都会从此存储库创建一个 ISO 安装程序。我们现在注意到，从几个月前的版本到本月的版本之间的升级失败了。出现此问题的原因是自定义包在 /etc/sysctl.d/ 下的配置文件不正确。这会导致升级过程中 systemd（由于 procps）配置失败。自定义包已修复，但在升级过程中，此包的配置发生在 systemd 配置之后。
一种可能是修补 systemd 并将我们的自定义包添加为依赖项......
另一个想法是在 debian/control 文件中使用替换/冲突，但我似乎找不到任何有关升级顺序的文档。 apt-get Upgrade 是否从替换软件包开始，然后继续升级其他软件包？
还有其他想法如何在 systemd 之前配置自定义包吗？ （在开始全面升级之前无需自己手动安装）
答案1
在开始全面升级之前，无需我们自己手动安装
这很难，因为 apt 没有这样的设施。
通常，当您进行升级时，会调用 dpkg 来安装所有下载的软件包，并将它们分成有意义的组，将它们全部解压然后配置它们（这非常简单，实际上它做得更多），并且每当包配置失败，它会尝试配置其他包，直到没有配置为止。因此，您可以进行双重升级，第一个升级期望 dpkg 退出，第二个升级则完成该过程。
但是，我不相信这一点，推荐的方法是独立升级相关包（使用install package）并执行升级。您还可以先使用 删除软件包upgrade package-，因为删除操作通常优先，然后再安装。
一种可能是修补 systemd 并将我们的自定义包添加为依赖项
这是另一个选项，如果您附加到 systemd Depends: package >= version， dpkg 将首先安装此软件包。除此之外，我认为不建议这样做。
答案2
因此，您有一个旧的自定义包，当由于配置文件错误而升级 systemd 时，该包会触发错误。
给定维护者脚本的执行顺序，新版本的包可以干预的最早时间是步骤preinst upgrade，它发生在新包解压之前，远远早于postinst configure步骤。您可以让新文件preinst upgrade修复有问题的文件或将其移开，然后使用postinst configure脚本来修复任何遗留问题。
仅当 APT 决定在同一运行中升级您的软件包和 systemd 时，这才有效。根据它还要做的事情，我认为 APT 可能会决定完全升级 systemd，然后升级你的软件包。您可以通过声明 systemd 对新版本软件包的依赖关系来避免这种情况（Depends:将确保您的postinst configure软件包首先运行。您还应该声明一个Breaks:systemd 与旧版本软件包的关系；事实上，我认为Breaks:如果所涉及的所有内容都是官方的 Debian 软件包，那就会是这样。问题是您必须修改新的 systemd 软件包（或旧版本的软件包，但为时已晚）。