Bug#47267: Bug #47267 in pam-apps?

[Thomas Hood <jdthood@yahoo.co.uk>]

(This is information for #47267, but I am cc:ing #163183
since I make reference to it below.)

On Thu, 2002-10-03 at 15:23, Ben Collins wrote:
> On Thu, Oct 03, 2002 at 02:19:55PM +0200, Thomas Hood wrote:
> > I have a strong suspicion that the fault here lies with the
> > pam-apps package -- specifically, with its prerm or postrm.
> > Unfortunately, as pam-apps is obsolete and I can't find a copy
> > of the package anywhere, I can't confirm my suspicion.
> > 
> > The hypothesis is that the pam-apps postrm deleted /etc/pam.d/su
> > on remove or purge.  Other packages' postrms have been caught
> > doing the same (wrong) thing.
> 
> You're suspicion is incorrect.

How do you know?

> Most likely the case is that if pam-apps removed (not purged) and a
> newer login was installed that replaced /etc/pam.d/su, then latter
> pam-apps was "purged", removing the config files.

This does not happen.

I just tested your hypothesis on two packages that
share a conffile, the second Conflicts:ing with the
first (as login Conflicts: with pam-apps):
    1. Install #1 (which installs the conffile)
    2. Install #2 (which removes #1 and takes over the conffile)
    3. Purge #1
The last step did *not* delete the conffile.

It *is* a shortcoming of dpkg that at step 2, when the
second package is installed, the conffile is taken over
silently, *even if the conffile has been changed*,
without reporting anything or asking any questions.
This bug has been reported in #163183.

But dpkg does not seem to have the bug of deleting
conffiles that no longer belong to the package being purged.

I think this report should be closed, since the original
situation (involving pam-apps) can not be reproduced.

--
Thomas