An Impatient Developer’s Guide to Debian Maintenance (Installation) Scripts and Package Diverts
The people involved in coming up with the dpkg scheme for installing / upgrading / downgrading / removing packages are very clever. While unintuitive to the uninitiated, the scheme is mostly logical and reasonable, though there are some points where I feel a little more effort and consideration could have made a world of difference.
“The evil that men do lives on and on” — Iron Maiden
In addition to regular installation behaviour, I needed to wrap my head around “package diverts”, which is a very clever system for enabling packages to handle file conflicts. Except that it doesn’t handle what I would consider to be a very basic use case:
- Install an initial version of our package.
- Discover that our package needs to overwrite a file that’s installed by an upstream dependency.
- Create a new version of our package that includes the file and configures a “package divert” to safely stow the dependency’s version.
- Remove the “package divert” on the file if the newer version of the package is uninstalled or downgraded to the previous version that doesn’t include it.
That last part, in italics? That’s the kicker right there. Read on to understand why.
Debian Installation Script Logic In Plain English
After poring over the Debian maintainer scripts flowcharts, I felt I had a pretty good handle on things but there’re a couple of little “gotcha”s, so I feel like it’s worth providing a brief summary of the general flow in common English.
Debian maintenance scripts are run by apt and dpkg at specific points in the installation process:
- If the package is being removed or upgraded (meaning that a different version is being installed, “upgraded” also means “downgraded” to Debian maintainers), the previously installed version’s prerm script is called.
- If the package is being…