Quoting Steve Langasek ([EMAIL PROTECTED]): > The one thing I would note is that, in the rare case that there are no > system-level daemons running on your system that use PAM, the message will > not be shown. Michael, before the screensaver locked up on you, did you see > the debconf warning that Christian quotes above? If not, what services do
My fear is that, indeed, some users will anyway leave the system unattended as soon as it enters the moment where packages are unpacked, or debconf questions asked..... But, there, xscreensaver should lock before it is itself upgraded. > you have installed on your system? (Even at, cron, cups, gdm, or samba > should trigger display of this message.) And what debconf settings did you > use when running the upgrade? I'd bet 'non-interactive'.... > There's also another possible explanation: > > - xscreensaver is running and has the old libpam loaded > - libpam0g is unpacked > - libpam-modules is unpacked > - libpam0g is configured, triggering the display of the debconf question - > but the screen is already locked and can't be unlocked because > libpam-modules is now broken, needing symbols from a newer libpam than the > one loaded by xscreensaver > > If this is the cause of the problem, then we could address that by either: > > - having libpam-modules pre-depend on libpam0g (>= 0.99.7.1), forcing the > question to be displayed before libpam-modules is unpacked > > or > > - adding a separate debconf question about screensavers only, shown in the > package preinst advising the user to disable their screen lock for the > duration of the upgrade. > > Christian, what's your opinion? That last option could help....except if the problem Michael ran into was that he was using debconf in non-interactive more. In such case, the debconf note will not help. Another option is to mention this in the release notes and advise against running the etch->lenny upgrade if xscreensaver is running.
signature.asc
Description: Digital signature
