On Tue, Jul 03, 2012 at 12:23:54AM +0200, Michael Biebl wrote: > >> This is probably from this line in /etc/pam.d/common-session: > >> | session optional pam_systemd.so
> > I suspect you have told pam that you want to manage common-session by > > hand, else this is a bug in pam-auth-update, since the postinst just > > says: > > if [ "$1" = "remove" ] ; then > > pam-auth-update --package --remove systemd > > fi > Right, the issue is, that we switched to multiarch paths in 44-3. What does this have to do with multiarch paths? The module path shouldn't have been embedded in the pam-auth-update profile anyway - was it? > I think pam-auth-update should handle that correctly, i.e. update the > paths in the pam configuration even if the pam-configs snippet hasn't > changed. There should be *no* paths in the configuration, therefore there should be nothing to update. You should use unqualified module names and trust pam's internal path - which AFAICS is what is done here. > Steve, can you confirm that this should work? > Is there an easy way to check if the pam configuration is managed > manually and not by pam-auth-update? I believe this is stored in debconf as libpam-runtime/override. -- 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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
