Comment 13 for bug 1820291

Yes it is Pierre, but that is the only way to do it right :-/

Review was great to make it more resilient, testing the new version (one more testcase) ...

- no modification -> move silently (ok)
- modified old file -> move with modification and place dpkg-new file (ok)
- old file removed -> old dir kept, new file not placed (to not enable what was menat to be disabled by removing before), dpkg-new file placed (ok)
- extra file placed in the old DIR -> behaves like the file removed case (ok)

We could think on fixing up the last case even more, but there is an arbitrary amount of even more special cases and we can't fix all.
The scripts are hardened to the extend that they won't fail/deny the upgrade which is important.
The user gets warnings if this happens to make him aware of the cleanup:
  rmdir: failed to remove '/etc/qemu/fsfreeze-hook': Directory not empty
  failed to remove /etc/qemu/fsfreeze-hook
  dpkg: warning: qemu-guest-agent: conffile '/etc/qemu/fsfreeze-hook' is not a plain file or symlink (= '/etc/qemu/fsfreeze-hook')

And then finally this didn't come up for ~12 months as an issue and we know it isn't th emost used feature. So we don't have to care for too arcane cases IMHO.

Overall the user visible messages improved as well with the last changes - e.g.:
"Preserving user changes to /etc/qemu/fsfreeze-hook (renamed from /etc/qemu/fsfreeze-hook/fsfreeze-hook)..." which makes more sense than what we had before.