On Sat, Dec 13, 2008 at 04:18:41PM -0500, Sam Hartman wrote: > So, I've been thinking about this issue. I'm not sure I have great > solutions for the etch->lenny case. However it seems like we could do > better for the future.
> Here's a possibility. When libpam failes to be able to dlopen a > module, it could look at a version epoch stored somewhere in s/etc. > If the epoch is different than the epoch it was started with, then it > could indicate to an application that a restart is required. We could > potentially even call exit(1) although that's probably more excessive > than we might want. > Does this seem like a reasonable approach? This assumes the application is fixed to be able to handle this restart indicator from libpam. If we're assuming changes to how the applications interact with PAM, the applications that are the focus of this bug could also be fixed by launching the PAM dialog in a subprocess - this is what gnome-screensaver already does, which is why that screensaver application is unaffected by the bug. That avoids the need for spec'ing out new PAM return codes, and I don't think it loses anything in terms of elegance, so I think we should prefer that approach as long as we're modifying the apps. -- 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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
