Removing a file from a Debian package without removing the existing file on upgrade

Question

I have a Debian package that I've created that provides a certain file that I no longer want to include in the next version of this Debian package. However, I don't want to actually delete the file when the package is upgraded. The problem is that when the package is upgraded, the file is deleted when the previous version's files are removed. The file is not a conffile and is not in /etc (it's buried deep in /var).

What I'm thinking is that I can somehow have the new package copy this file to a temporary location before the previous version of the package is upgraded, then copy it back to its original location post-install.

However, I'm not sure how to add commands in the new package that run before the previous version's files are removed.

Does dpkg provide a hook at this point (run before previous version of package's files are removed)? All of the maintainer scripts are under my control I'm just not sure which one to use and which command line arguments to check for (assuming there is a hook).

If not, is there some other way to drop a file from a Debian package without deleting the file on upgrade?

I need to support Debian Buster, Bookworm, and Trixie, and Ubuntu 22.04 and 24.04.

Answer 1

Oh, I figured it out. I found these flowcharts of Debian maintainer scripts that I never saw before.

From the upgrading flowchart:

It looks like I can move the old file to a temporary location in the pre-install script of the new package when it receives the upgrade command line argument.

Then I can copy it back to where it needs to go later in the post-install script (when it receives the configure command line argument).

Answer 2

While the maintainer script approach you outlined works, it’s a bit messy for a couple of reasons.

A much cleaner approach would be to take the following steps:

1. In the next version of the package, split that file out to its own package, but list that package in the Depends of the existing package.
2. After publishing at least one version with that mandatory dependency (though ideally after a few versions with it), change the new package from a Depends to a Suggests.

This two-stage approach is needed if you go the split package approach because long-term you don’t want this file on new installs, but you do want it preserved for existing installs. Making the split package a mandatory dependency initially ensures that it gets installed automatically on an upgrade of the original package (Debian doesn’t auto-install newly added optional dependencies for a package when that package is updated) so that existing users continue to have the file. Switching it to Suggests after a few releases will then ensure it isn’t installed by default on new installs without automatically removing it for people who upgraded through one of the versions that had it listed as a mandatory dependency. This is why you ideally want a few releases before switching to Suggests, as that helps ensure that even people who skip a few versions are likely to end up with the compatibility package.

This approach ensures that:

• The file is still actually owned and managed by the package manager for users who had it already.
• If you aren’t already dealing with the hooks that would be required to manage it through maintainer scripts, you won’t need to add them for this, and if you are you won’t need any additional complexity in them for this.
• Users can clearly see through the package manager whether they have the compatibility files or not, and can manage them like any other compatibility package.