Dear Guillem, Reportbug uses `dpkg --status $package` to collect information about a package, including the list of configuration files. It assumes that the output in each line under Conffiles is always a space-separated tuple of filename and md5sum. However, this is not always true, as indicated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080336 What should users of the dpkg --status output expect regarding the conffiles list? E.g., how many fields can there be on each line? Why are non-existent files sometimes included in the list? See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085130 for an example of confusion. When can removed configuration files be expected to no longer be listed? I'm wondering if reportbug should be changed to notice when the remove-on-upgrade flag is printed and then ignore the corresponding line. Clarification or advice is appreciated. Would the deb-conffiles man page be a good place to add clarifying documentation? Thanks!
Hi! Ah, if this was due to the remove-on-upgrade, that is only documented by proxy in deb-conffiles(5). Right, there is missing documentation for this. The entries always have at least two elements separated by a space, the filename and its md5sum from the .deb (or «newconffile» if the file was not present on the .deb). The entries can have an optional flag element that can be either «obsolete» or «remove-on-upgrade». The conffiles can be missing because they have been cleaned up by a maintscript, or removed during upgrade due to the «remove-on-upgrade» flag, but can also be missing because the local admin has removed them (which counts as a normal user modification to be preserved), so programs should not error out if a conffile is missing (dpkg does not). Currently there might be entries for obsolete conffiles left behind, but those will be "garbage collected" the next time a package is configured and the conffiles are not on disk anymore. It should never error out on missing conffiles. It might be nice to still print that the file is not present (with a nicer error than ENOENT) though. For obsolete and remove-on-upgrade it might make sense to print the conffiles in case they are present (as an abnormality) and otherwise not even present them at all? I don't think deb-conffiles(5) would be the correct place. Probably adding a section for some of the internal dpkg fields into dpkg-query(1), before the description of the virtual fields might make sense. So I'll try to do that. Thanks, Guillem
Thanks. I'm wondering what "garbage collected" means here. So procps has removed /etc/sysctl.conf from the package and added the «remove-on-upgrade» flag to procps.conffiles. `dpkg --status procps` on current sid now includes this line: /etc/sysctl.conf 72b7c827a9636cda7b3b371091ff2dce remove-on-upgrade After running `apt install --reinstall procps` the corresponding line in the `dpkg --status procps` output looks like this: /etc/sysctl.conf newconffile remove-on-upgrade Does it mean the conffile will always be listed in the output as long as it is listed in DEBIAN/conffiles, even if the «remove-on-upgrade» flag has been present across several package upgrades? Or does the line only not get dropped here because what I did was a reinstall and not an upgrade? Thanks, Nis
qaa:~> dpkg -s procps Package: procps Status: install ok installed Priority: important Section: admin Installed-Size: 2395 Maintainer: Craig Small <csmall@debian.org> Architecture: amd64 Multi-Arch: foreign Version: 2:4.0.4-8 [...] Conffiles: /etc/sysctl.conf newconffile remove-on-upgrade /etc/init.d/procps f9903aa0d9f2f10714269befb4cdba8f /etc/sysctl.d/README.sysctl 93eda3f215e9d29316f5597cb4551082 [...] IMHO, this is a bug, whether the package has been reinstalled or upgraded. There is no point to output such a line for a conffile that definitively no longer exists. About this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085130