On Sat, 27 Dec 2008 23:54:56 -0600 Steve Langasek wrote: > - the release of the dpkg lock does not guarantee that the upgrade > completed; any number of other packages could cause dpkg to exit before > all of libpam-runtime's deps have been unpacked, leading to the same > problem when the upgrade is continued. (this is an issue in > https://bugs.launchpad.net/ubuntu/+source/pam/+bug/256238, a failure that > involves dependencies on new symbols in libc6 rather than libpam0g - while > that particular problem hasn't been reported in Debian yet, AFAICS it also > applies to etch->lenny upgrades
right, i figured that this wouldn't be sufficient. version checking could possibly be added -- check whether $(pam --version) and $(xscreensaver --version) are sufficiently up to date. > - calling set +e is ugly, and stylistically unnecessary; that block is > equivalent to: > > while ! xscreensaver-command -restart; do > : > done ok, good suggestion > - I have no idea why this loop is here, anyway. Why would the -restart > command ever fail? "-restart" will fail whenever a screensaver is active. this allows the process to wait for the user to unlock the screen before proceeding with the upgrade. > - spawning persistent subshells from a maintainer script that are left > running until the postinst is *very* ugly; I'm not sure if this works at > all, really, but if it does it probably has subtle and nasty side-effects. i know, its ugly. > - The script, as written, also doesn't take into account the need to check > for multiple instances of xscreensaver running on multiple displays. "-restart" will fail if there are any xscreensaver instances running, so i think this is handled. > - Also, the -deactivate command will not unlock a screen that has been > locked; so any screen that manages to be locked (perhaps by a direct user > action) would still end up locking the user out. agreed. this doesn't prevent the user from screwing up the process. perhaps another "-restart" check could be added to determine whether the user had locked the screen again. > But as I said, I don't think this is the way we should solve this anyway. ok. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
