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!) -- Andrew Ferrier web: http://www.new-destiny.co.uk/andrew/ email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
