Bug#146167: apt: No way to purge record of package without purging config files
On 2002-05-10 at 04:49, Anthony Towns wrote:
> > > I realise that. That wasn't the feature I was describing. The
> > > problem arises when two packages share the same config files
> > > (e.g. exim and exim-tls): with both installed, it is impossible
> > > to purge one and remove it from the dpkg database entirely
> > > without removing the config files for the other (because they
> > > are the same config files).
> > This is a dpkg problem. I suggest you deal with it there, not for apt.
> That's nifty. Policy says:
> ] 11.7.4. Sharing configuration files
> ] -----------------------------------
> ] Packages which specify the same file as a `conffile' must be tagged
> ] as _conflicting_ with each other.
> ...but clearly that's not actually enough, since conflicts aren't taken into
> account when a package is removed-but-not-purged.
> Perhaps if you have a conffile <foo> mentioned by removed-but-not-purged
> package <bar>, and also by newly-installed-package <baz> ownership of the
> conffile should be automatically transferred to <baz> (and possibly <bar>
> should "disappear" if appropriate)?
Yes, that would be ideal solution I think because it would
ensure that dpkg is responsible for keeping it's database
consistent --- obviously it wouldn't do what you've just
suggested (i.e. automagically purge a package from the
database) unless another package owned the same config. files.
But another solution, which would probably be easier to
implement, if not as neat, would be simply to provide the user
of dpkg an option to force removal/purging from the database
without deleting the config. files.
Don't know which one the dpkg developers prefer the sound of
but I hope you agree this is a problem --- I think it is (if
purely just one of neatness of the database!)
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org