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 it’s 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.

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.