Re: application of path-exclude/include to "dpkg --list"

[Guillem Jover <guillem@debian.org>]

Hi!

On Sat, 2011-04-02 at 11:20:00 +0100, Marcin Owsiany wrote:
> It seems that currently the path-exclude/path-include options
> specified in /etc/dpkg/dpkg.cfg* are not taken into account in the dpkg
> --list output.

Right, that was on purpose, the idea is that those paths might have
as well been removed by the admin, or by external packages like
localepurge which are outside of dpkg control. And it's more useful
for dpkg to consistently track which files should be there.

> The "cruft" program uses dpkg --list to discover what files dpkg has
> installed. Thus in some cases it it expects files to be present while
> they were omitted by dpkg during unpack.
> 
> I have a bug (http://bugs.debian.org/619086) against the "cruft" package
> to respect the path-exclude/path-include options specified in
> /etc/dpkg/dpkg.cfg* 
> 
> However I think that this would be best implemented within the dpkg
> package (either in dpkg proper - possibly as an option, or in a helper
> filter program) because it already contains all the code to parse
> options files and apply the filters to individual files. Please let me
> know what you think? Please keep the bug in CC for the record.

I've a counter-proposal, something I'd like to see in general is
moving external functionality currently in other tools merged back
where they belong (dpkg, apt, etc, for the dpkg relevant bits this
is part of our roadmap [0]).

  [0] <http://wiki.debian.org/Teams/Dpkg/RoadMap>

In this case, at least to honour the name (cruft), it would seem the
program should only be paying attention to excess files.

So the file system auditing part would be implemented in dpkg, which
as you mention already knows about those path exclusions. This would
complement the debsums integration and the file metadata tracking too.
This would be similar (in spirit) to “rpm --verify” option (AFAIK).

thanks,
guillem