Package: dpkg Version: 1.20.9 Severity: normal X-Debbugs-Cc: Niels Thykier <ni...@thykier.net>
Hi, the new remove-on-upgrade logic from #822462 breaks the use-case of replacing a conffile by a non-conffile version. In postgresql-common, I'm trying to remove /etc/apt/apt.conf.d/01autoremove-postgresql as a conffile, while still generating that file from the package postinst. That worked[*] since debian/postgresql-common.maintscript knows in which previous package versions to trigger the logic, and the logic fires only once. The same workflow happens for everyone moving from conffile to ucf. The new logic does not know on which previous package versions to trigger, and triggers always instead, and worse, it even triggers if the file is no longer a conffile, but has been properly regenerated. That means, on each package installation, I'm seeing this: Setting up postgresql-common (229) ... Obsolete conffile '/etc/apt/apt.conf.d/01autoremove-postgresql' has been modified by you. Saving as /etc/apt/apt.conf.d/01autoremove-postgresql.dpkg-old ... Is the answer here that I should keep the conffile flag around even if the package isn't shipping the file anymore? Users tend to complain if a file is in that state. Christoph [*] The full truth is there was a typo in debian/postgresql-common.maintscript which made it remove apt's /etc/apt/apt.conf.d/01autoremove instead. Oops.
