An annoyance with Debian postinstall scripts during package upgrades

January 6, 2022

Both RPMs and Debian packages have broadly the same high level features, which isn't surprising because they're facing (and solving) the same problems. For example, both have postinstall scripts. However, the details and the social customs that result are different between the two, and so every so often I find something that irritates me about one or the other (usually Debian). Today's irritation is in postinstall scripts.

In RPM, postinstall scripts can tell if they're being run during a package upgrade instead of during a package's first installation. In Fedora, as far as I know the social custom for postinst scripts is that they should detect upgrades and skip re-doing work and re-running commands that are only applicable for the first install. This is true even if the commands theoretically do nothing if re-run.

In Debian packages, as far as I can tell, postinstall scripts don't get told whether this is a first install or an upgrade. Certainly the social custom for package postinstall scripts is that they don't try to tell; whether they're installing or upgrading, they'll (re-)run the same commands. It's up to your system and the commands to do nothing if they're re-run.

Unfortunately this can create a situation where a Debian or Ubuntu package is properly installed and working fine, but something changes in the system so that the commands in its postinstall script will be unhappy if they're rerun. If a package upgrade is released and you apply it, your system will kind of blow up. The package's postinst script will get run, it will repeat all of the actions that are only relevant at install time, a command will find something it doesn't like, and now you have postinst script failure and a problem:

dpkg: error processing package systemd (--configure):
 installed systemd package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1) 

This will give you one or more packages in an odd state and you're going to have to fix that to make your package system happy, despite the fact that the package itself is correctly installed and fully functional. And everything would have been fine if the postinst script could have easily told an install from an upgrade and not done the install-time work at upgrade time too.

PS: If you look in /var/lib/dpkg/info, you'll probably discover that you have more postinst scripts than you might have thought and they do more than you expect. It's nice that the Debian package format makes package scripts more visible and accessible with standard Unix tools than the RPM format does; in RPM, all of this information is locked up inside a database and has to be pried out with magic.

Written on 06 January 2022.
« Some things about Dovecot, its index files, and the IMAP SELECT command
In practice, Debian (and Ubuntu) have fixed minimum system UIDs and GIDs »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jan 6 22:14:01 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.