I had thought of an issue of the breaks/replaces and tested with the first ppa build.
Indeed old mail-stack-delivery postrm being triggered would mean a restoration of the cofig before it's installation. This is not how we want it to be transitioned-out.
Therefore case 11 of https://wiki.debian.org/PackageTransition does not apply (as that would remove it).
Instead approach #2 would be to add an empty transitional that we will keep until 20.04 to catch all upgrades dropping it without modifying the configuration.
I tested an old install with mail-stack-delivery upgrading to the new version.
a) with breaks/replaces
triggers the unwanted remove as expected
b) with a transitional package
This does what we want
- turn it into an empty package
- does not rebuild the assumed old config
- the transitional can be removed without wreaking havok
I had thought of an issue of the breaks/replaces and tested with the first ppa build. /wiki.debian. org/PackageTran sition does not apply (as that would remove it).
Indeed old mail-stack-delivery postrm being triggered would mean a restoration of the cofig before it's installation. This is not how we want it to be transitioned-out.
Therefore case 11 of https:/
Instead approach #2 would be to add an empty transitional that we will keep until 20.04 to catch all upgrades dropping it without modifying the configuration.
I tested an old install with mail-stack-delivery upgrading to the new version.
a) with breaks/replaces
triggers the unwanted remove as expected
b) with a transitional package
This does what we want
- turn it into an empty package
- does not rebuild the assumed old config
- the transitional can be removed without wreaking havok
Going on with B then ...