Comment 19 for bug 275169

On Fri, Jan 09, 2009 at 05:06:41AM -0000, Russ Allbery wrote:
> The only question I had, and this is just another iteration of the typical
> "how do maintainer scripts get called in errors?" question, is that the
> prerm is limited to only the remove case. Wouldn't you also want to
> remove the pam-krb5 configuration on deconfigure as well? (I think that
> since libpam-krb5 will continue to be installed, it doesn't make sense to
> remove it on either upgrade or failed-upgrade.)

That's a good question. The purpose of the prerm "pam-auth-update --remove"
call is to ensure that the named profile is removed from the active config
before the files disappear from disk, rather than after, to reduce the
chances that this will result in a broken stack (or a log-spammy stack).
However, deconfiguration can happen as part of a dist-upgrade; in extreme
cases, it would be possible for all the PAM modules to be deconfigured at
the same time as a result, so having the modules be removed from the config
on deconfigure would *also* result in a broken stack.

It would certainly be wrong for libpam-modules to call pam-auth-update
--remove on deconfigure. OTOH, so far I've assumed that as a dependency of
(Essential: yes) login, libpam-modules will never be removed, so I don't
call pam-auth-update --remove /at all/ for that package. For other packages
it may make more sense to call --remove on deconfigure -- but not with the
current pam-auth-update implementation, since --remove also wipes the
preferences for whether the named config is enabled or disabled, and we
don't want to lose this information every time a package is deconfigured.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>