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
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
