How to influence order of package upgrade (apt-get upgrade/dist-upgrade)

aptdpkg

We are hosting a branch of the debian jessie repository with custom, backported and patched packages. Every product release an ISO installer is created from this repo. We now noticed that an upgrade between a release from a couple of months ago to the release of this month fails.
The problem occurs thanks to a custom package which had an incorrect configuration file under /etc/sysctl.d/. This results in systemd (because of procps) configuration failure during the upgrade. The custom package has been fixed, but during an upgrade the configuration of this package happens after the configuration of systemd.

A possiblity is to patch systemd and add our custom package as a dependency …

Another idea was to work with Replace/Conflicts in the debian/control file, but I cannot seem to find any documentation about the upgrade order. Does apt-get upgrade start by replacing packages and then continue by upgrading the other packages?

Any other ideas how to get the custom package configured before systemd? (without installing it manually ourselves before starting the full upgrade)

Best Answer

So you have an old custom package which triggers an error when systemd is upgraded due to a bad configuration file.

Given the order in which maintainer scripts are executed, the earliest time at which the new version of your package can intervene is the preinst upgrade step, which happens before the new package is unpacked, well before the postinst configure steps. You can make your new preinst upgrade repair the problematic file or move it out of the way, and use the postinst configure script to fix any lingering issue.

This will only work if APT decides to upgrade your package and systemd in the same run. Depending on what else it has to do, I think APT could decide to fully upgrade systemd, then upgrade your package. You can avoid this by declaring a dependency from systemd to the new version of your package (Depends: will ensure that your postinst configure runs first. You should also declare a Breaks: relationship from systemd to the old version of your package; in fact I think Breaks: is how it would be done if everything involved was an official Debian package. The problem with that is that you'd have to modify the new systemd package (or the old version of your package, but it's too late for that).

Related Question