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: [email protected]
> 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
