On Wed, 2017-07-12 at 02:53 +0200, Florian Weimer wrote: > Odd. Could you check the contents of /var/lib/dpkg/status and what > is > listed there for the debsecan package? Lucky you... I have one system left where I didn't a manual cleanup (aka purge&reinstall):
The file has: Package: debsecan Status: install ok installed Priority: optional Section: admin Installed-Size: 111 Maintainer: Florian Weimer <f...@deneb.enyo.de> Architecture: all Version: 0.4.19 Depends: debconf (>= 0.5) | debconf-2.0, python (>= 2.3), python-apt, ca-certifi Recommends: cron, exim4 | mail-transport-agent Conffiles: /etc/default/debsecan 3a2aa7286725e2e5b29afae1081b2cde obsolete Description: Debian Security Analyzer debsecan is a tool to generate a list of vulnerabilities which affect a particular Debian installation. debsecan runs on the host which is to be checked, and downloads vulnerability information over the Internet. It can send mail to interested parties when new vulnerabilities are discovered or when security updates become available. Homepage: https://security-team.debian.org/security_tracker.html > I didn't expect the Conffile: entries to be sticky, and nothing in > the > documentation about conffile handling says they are. I don't know why it happens, guess because conffiles may only go away on purge... so unless you tell dpkg it goes it won't remove it There are many cases. Use dpkg-query -W -f='${Conffiles}\n' | grep 'obsolete$' to find out which are in some way considered obsolete. But not all of the cases I found on my systems (and there are many) have the same cause as the one here.. where a conffile->non-conffile replace was done. Some were simply dropped without using the maintainer scripts > I don't see anything in dpkg-maintscript-helper which would remove > the > Conffile: lines from /var/lib/dpkg/status, so if they are still there > on your system, this probably would not make a difference. Better ask at d-d how to do it properly... I think it's rm_conffile... That's why I said you'd need to backup the file first, and then move it back (once it's no longer a conffile...) but perhaps this is already automated with some other command, so better ask experts ;) Uhm... not sure but it might be a policy violation... so should be cleaned up I guess... also it could perhaps cause problems if dpkg thinks it still manages the file, while you do so already manually. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
