Bug#47267: Fixing a 7-year-old bug
Summary of the problem:
* Install A with conffile F
* Remove A
* Install B with conffile F -- B "adopts" F
* Purge A -- BUG: F is deleted
When B adopts F, should F be removed from A's list of files?
If so then the bug is probably in the code that removes F
from A's list of files.
Or should F be left on A's list of files, and the purge routine
should, before deleting F, check to make sure that F does not
belong to any package besides A?
If so then the bug is probably in the code that deletes F.
I think that the purge code should _in any case_ be modified
so that it refrains from deleting F if F belongs to other
packages. Even if the bug is really in the remove-F-from-A's-list
code, the modification described here will solve the problem and
will make dpkg resistant to that kind of bug. Caveat: I don't
know what kind of performance impact this would have.
If the bug is in the remove-F-from-A's-list code then that bug
should also be fixed, of course.
Rolling up sleeves:
I don't know the dpkg code base well enough to provide a patch
that I would be sure was a complete solution and which didn't
cause unpleasant side effects.
Having said that, it looks to me as if we need to make a change
to the for loop beginning at line 402 in main/remove.c. The
loop begins with a comment:
/* Remove from our list any conffiles that aren't ours any more or
* are involved in diversions, except if we are the package doing the
The for loop should be modified so that it satisfies this modified
/* Remove from our list any conffiles
* that aren't ours any more, or
* that are involved in diversions (unless we are the diverter), or
* that also belong to other packages.
Someone please help me with this so that we can close these nine
merged severity-important bug reports, the oldest of which has been
open for almost seven years!
Thomas Hood <email@example.com>