> 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.
Okay, that makes sense, although that raises an additional question:
wouldn't preferences be considered local configuration, and hence should
only be removed on purge? (This would be future work for pam-auth-update,
of course, not something that could be fixed right away.)
Steve Langasek <email address hidden> writes:
> 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.
Okay, that makes sense, although that raises an additional question:
wouldn't preferences be considered local configuration, and hence should
only be removed on purge? (This would be future work for pam-auth-update,
of course, not something that could be fixed right away.)
-- www.eyrie. org/~eagle/>
Russ Allbery (<email address hidden>) <http://