Control: clone -1 -2 Control: retitle -1 autopkgtest: installation stalls if newly-built deb causes a conffile prompt Control: retitle -2 adduser: dpkg conffile prompt for adduser.conf even though unmodified Control: severity -2 serious Control: reassign -2 adduser 3.125
On Tue, 02 Aug 2022 at 19:27:55 +0200, Marc Haber wrote: > adduser.conf suddenly becoming a dpkg-conffile causes dpkg to emit a > conffile prompt in every case of adduser <= 3.123 being updated to > adduse >= 3.125. This sounds like autopkgtest has accidentally detected a genuine bug in adduser. Packages are generally expected not to prompt a user to merge changes to a conffile that they never actually edited: the Policy wording is that they "must not ask unnecessary questions (particularly during upgrades)" (ยง10.7.3). piuparts detects this (https://piuparts.debian.org/sid2experimental/conffile_prompt_error.html lists adduser/experimental) and this class of bugs is considered to be RC. I can reproduce this in a bullseye test VM by upgrading adduser from 3.118 (the version in bullseye) to 3.125 (from experimental), making this a very high-visibility issue, since it would affect basically all bullseye users when they upgrade to bookworm. As a short-term answer, please revert this change before uploading to unstable. In the longer term, I'm not an expert on the finer points of conffiles, but one solution might be to record the hashes of known unmodified versions of adduser.conf (at least the versions in stable and testing, ideally all versions between those endpoints), and in preinst, if adduser.conf matches the hash corresponding to the *old-version* that was passed to the preinst, move it out of the way so that dpkg can unpack the new conffile over it. > Is this autopkgtest's intended behavior? If not, would passing > --force-confnew to dpkg solve this issue? If autopkgtest is going to do anything to work around unwanted conffile prompts, a more likely answer would be to set DEBIAN_FRONTEND=noninteractive (it already does in various places, but perhaps not this one), which will have an effect more similar to dpkg --force-confdef --force-confold. Perhaps we should deliberately not work around this, in order to be able to detect this class of bug; or perhaps we should work around it and leave piuparts to detect this class of bug instead; or perhaps autopkgtest should work around this, but then look for /etc/**.dpkg-new with names corresponding to files owned by a package under test, and treat them like a failed test. smcv
