Re: Bug#619086: application of path-exclude/include to "dpkg --list"
On Sat, Apr 02, 2011 at 02:48:13PM +0200, Guillem Jover wrote:
> 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.
Sure, there's nothing wrong with listing them by default. Another reason
is that the exclusion might have been added after some package and files
had already been installed.
> And it's more useful
> for dpkg to consistently track which files should be there.
The point here is that after the administrator configured some
exclusions, he no longer wants these files to be there. So there should
exist a way to programatically determine whether a given path would be
installed by dpkg or not, given currently configured excludes/includes.
I guess what I'm asking is whether dpkg developers agree it's a good
idea :-)
> > 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.
I'm not sure I understand exactly what you mean, but here are a few
points:
- so far cruft does not do that that much auditing anyway - pretty much
the only attribute it looks at is "existence"
- I don't see any problem with deprecating the part of cruft's
functionality that deals with making sure that files that should
exist do exist, once dpkg supports this natively (and by the sound of
it, with more features too)
- to figure out what excess files are there cruft would still need to
discover the configured exclude/include state.
regards,
--
Marcin Owsiany <porridge@debian.org> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Reply to: