Hi,a small update from my side. With the usual Breaks/Replaces the conffile is really taken over (the file stays in place with the local modifications in it, and the new package inherits the recorded hash), but the old package keeps the bogus "obsolete" entry forever, which is precisely the problem reported here.
I have just found something that looks like a workaround on the packaging side: the remove-on-upgrade flag of DEBIAN/conffiles (dpkg 1.20.6), set in the binary package that no longer ships the conffile, through a debian/<package>.conffiles file that dh_installdeb merges with the auto-detected conffiles. Unlike rm_conffile it does not eat the file shipped by the new package, because dpkg skips the removal when another package owns the path (src/main/unpack.c, pkg_remove_conffile_on_upgrade(): "owned by other ..., remove-on-upgrade ignored"; the guard is present in 1.20.13, 1.21.23, 1.22.22 and 1.23.11).
It is important to be clear that this is a removal, not a move: in the upload that actually moves the conffile, the old package is necessarily unpacked first (that is what the Breaks is for), so a conffile modified by the user is saved as .dpkg-old and replaced by the one shipped by the new package. Deferring the flag to a later upload avoids that only for the users who went through the intermediate version.
This was only a quick test with a couple of throw-away packages on sid and trixie, so please take it as a hint rather than as a recipe. I will look into it more carefully the next time I actually have to move a conffile, which happens rarely enough that it may not be soon.
A fix in dpkg itself, dropping the entry when another package takes the conffile over, would still be a much better outcome.
OpenPGP_signature.asc
Description: OpenPGP digital signature
