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 email@example.com 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.