XPost: linux.debian.bugs.dist
From:
guillem@debian.org
Hi!
On Wed, 2024-10-16 at 22:34:34 +0200, Nis Martensen wrote:
Package: dpkg
Version: 1.22.11
Severity: wishlist
X-Debbugs-Cc: nis.martensen@web.de
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
Ah, if this was due to the remove-on-upgrade, that is only documented
by proxy in deb-conffiles(5).
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?
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.
I'm wondering if reportbug should be changed to notice when the remove-on-upgrade flag is printed and then ignore the corresponding line.
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?
Clarification or advice is appreciated. Would the deb-conffiles man page
be a good place to add clarifying documentation? Thanks!
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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)