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
Analysis: 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. Strategy: 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 * diverting. */ The for loop should be modified so that it satisfies this modified description: /* 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 PROTECTED]>
