Re: : Question regarding actions to take on --purge of a package.

[Greg Stark <gsstark@mit.edu>]

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