5

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)

Improve this question
0

2 Answers 2

Reset to default
2

without installing it manually ourselves before starting the full upgrade

That's difficult, because apt doesn't have such facilities.

Normally, when you do an upgrade, dpkg is called to install all the downloaded packages and it separates them in groups that makes sense, unpacking them all to then configuring them all (this is very simplified, it actually does more), and whenever a package fails to configure, it tries to configure the others until none is left. So, you can do a double upgrade, first one expecting dpkg to bail out, and the second to complete the process.

But, I wouldn't trust this, the recommended way is to upgrade the relevant package independently (with a install package) and the perform the upgrade. You can also remove the package first with upgrade package-, because remove operations normally take precedence and then install it.

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

This is another option, if you append to systemd Depends: package >= version, dpkg would install this package first. Other than those, I don't think it would be advisable to do.

Improve this answer
3
  • On another note, a CI system to detect these problems early may be advisable.
    – Braiam
    Commented Aug 10, 2015 at 15:53
  • Can you use a pre-depends to influence ordering / what's done at once?
    – Peter Cordes
    Commented Aug 10, 2015 at 20:23
  • @PeterCordes on systemd package? yes. But you may just use depends instead.
    – Braiam
    Commented Aug 10, 2015 at 21:12
0

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).

Improve this answer
3
  • First off, thanks for the answers! The custom package already takes care of the faulty config file in the preinst stage, so the problem of systemd occurs also in the preinst stage, so nothing we can do about that. Patching systemd seems like a no go as far as maintenance goes. Since we need to keep patching systemd every time a new version is available in jessie... I guess we will need to adjust the upgrade procedure by upgrading our custom package before doing the full dist-upgrade.
    – Sander
    Commented Aug 11, 2015 at 11:44
  • @Sander There may be a feature of APT that I'm not aware of, but I doubt it. I think Ubuntu recommends the use of their upgrade tool rather than a straight apt-get dist-upgrade precisely for this reason: to add constraints on the order of upgrades that can't be expressed with dependencies without major pain.
    – Gilles 'SO- stop being evil'
    Commented Aug 11, 2015 at 13:08
  • Ok, so I've patched systemd with Breaks and the specific version of our custom package which is working out as expected. Adjusting the upgrade procedure was not possible since that meant modifying our previous release (weird that these obvious things skip your mind sometimes ;) ). The upgrade procedure will in the future be a separate package which will upgrade itself before starting the actual upgrade to avoid situations like the one we are in now.
    – Sander
    Commented Aug 13, 2015 at 8:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .