dpkg and configuration files
Recently on Debian-BSD ...
jeffsh@erols.com (Jeff Sheinberg) wrote on 23.12.99 in <14434.49305.64257.82821@eden-hda7.local>:
> Now, I will quote from "The Complete FreeBSD", 2nd edition, by
> Greg Lehey,
>
> Another problem with pkg_delete is that it might delete files
> of the same name which have been replaced by newer packages.
... which reminds me that there is still a problem in this area with dpkg.
Scenario:
Install the old dhcp-beta stuff.
Upgrade to the new dhcp stuff.
Decide to purge the old dhcp-beta packages.
Oops! Files really belonging to the new dhcp packages were removed.
Why is that? Because those files weren't mentioned in the .list file, but
were instead removed by the postinst, which did (of course) not know about
the new dhcp packages.
This is similar to the mess with the old base package.
What to do?
Well, it seems to me moving at least part of the "purge" functionality
from the postrm scripts to dpkg might solve most of this problem.
Say we have a new file listing files which should be removed for "purge".
It should probably allow simple wildcards.
Now dpkg can find out if other packages claim the same files. And it can
remove from that list when one package "replaces" another.
There are, of course, situations where even simple wildcards clashing
with, say, non-wildcard entries in another package are non-trivial to
resolve. IMO, just erroring out is good enough for these situations.
Of course, we still need the possibility to manually "purge" for cases too
complicated for this, but this should be complicated cases _only_.
Oh, and this way, dpkg --search will also find what package generated
files belong to. (dpkg --search exim.conf currently doesn't list any
package, for example.)
(Incidentally, does dpkg remove .dpkg* versions of config files on purge?
It probably should.)
MfG Kai
Reply to: