This is an old thread that I have a new twist on. I just got bit by a purge that removed a file I really wouldn't have liked it to, but I think the packages involved were doing what they should have been doing according to current policy. I think there's a deficiency in our conception of file ownership by packages that this is pointing up.
But firstly I'll describe the situation, maybe there's a better way for the packages to be handling this that I'm missing. libfoo1 has a config file, but it's rarely edited and possible to set up almost automatically, so the postinst creates it based on a couple questions. Because it's altered by the postinst it's not considered a "configfile" by dpkg nor is it in the package contents. Now a new version of foo comes out, and a new package libfoo2 is released but it uses the same configuration file as libfoo1. However when libfoo1 is no longer needed and it's removed since there are no "configfiles" the postrm is run with the "purge" argument which dutifully removes any files that were created by the installation process. Now libfoo2 no longer has its config file. How should this situation have been handled? The only consistent way I can see is having a libfoo-config package that contained just the single configuration that both packages need. That seems like way overkill for a single file though. The only alternative I see is allowing files to be owned by multiple packages and keeping track of when they're no longer needed by any package. That seems like a lot of work though. -- greg
