Hi,
I'm currently sitting on a pile of cruft filter file updates. The
reason I'm sitting on it is that I don't know what to do with them. I
already asked a similar question about this some time ago but got no
answer.
At first sight it would seem logical to simply send a bug report
against cruft with all the updates but I think it would actually make
much more sense to send bug reports against each package so that *they*
and not cruft include these filter files. Here's why.
First, what do the filter files contain? They contain a list of files
(file patterns more precisely) that belong to a specific package
although they are not listed in as such. These files are typically files
that are generated at run time like sendmail's spool files, squid's
cache or, more and more frequently I believe, debconf-generated
configuration files.
Now let's assume we have package A which in version 1 put some files
in /usr/lib/whatever, and in version 2 has moved this file to
/var/lib/whatever (there are many such cases, not necessarily between
usr and var).
If the filter file for package A is delivered with cruft, what should
it contain?
* neither of the above: this is typically the current situation since
th efile is missing altogether. This means cruft will complain about
both files which adds up to thousands of files (only slightly
exagerating here)
* include only /usr/lib/whatever
Then users of version 1 are happy but not users of version 2
* include /var/lib/whatever
Then it's users of version 2 that are happy while users of version 1
complain. But at least this is correct in the long run (well, at least
until version 3 moves the file yet to another place)
* include both
Nobody complains, but nobody notices that the upgrade left the
outdated /usr/lib/whatever file behind (well, this is more typical with
'not-empty' directories). I.e., cruft does not detect cruft anymore.
If the filter file is delivered with package A then the right version
of the filter file can be shipped with it. Plus the maintainance of the
filter file will be done by the package maintainer who just happens to
be the person who knows best which files are supposed to be around and
which are not (any longer). Plus it distributes the burden of
maintaining the filter files among all maintainers which makes it
actually feasible (how would the cruft maintainer be able to keep track
of more than 7000 packages)?
So I'm very inclined to file a bug report for each package for which
I wrote a new filter file. But I want to know about the community's
feelings before I do that.
The alternative would be to file one bug report against cruft per
package for which I have a new filter file, and to copy that package's
maintainer (using X-Debbugs), since I really want each maintainer to
check the validity of my filter files.
I attached my current cruft filter files so that you can have a look
at them. It contains both the new files and updates to existing files in
unified diff format. If we go with shipping the cruft filter files with
packages then there will also be the question of migrating them from the
cruft package to each individual package...
--
Francois Gouget fgouget@free.fr http://fgouget.free.fr/
The greatest programming project of all took six days; on the seventh day the
programmer rested. We've been trying to debug the *&^%$#@ thing ever since.
Moral: design before you implement.
Attachment:
cruft-filters.txt.gz
Description: cruft-filters.txt.gz