Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
Dave Korn wrote: And here is part 1. No comments then? I'll apply it sometime tonight or tomorrow if nobody objects. Well, you labeled it as part 1 and so I mentally said, okay, I'll take a look at this whenever it's complete. Meanwhile (here's the RFC part), my suggestion for part 2 is attached (merged into part 1). It's pretty crude: it disables and reenables the cancel button around each call to Installer::installOne(). This probably doesn't stop the user from pressing the cancel key or clicking the X close box, although I haven't tested that yet. I would be interested in hearing from anyone who reckons they do know the proper way to do this. Ick. I don't really like that. It seems to me that we simply don't support canceling in any sane way once the installation step has begun. Even if we are able to cancel cleanly at a point in between unpacking two packages, that still could leave the system in a horrid state -- missing dependencies, postinstalls not run, etc. We should disable the button for the entirety. Brian
RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On 26 February 2008 13:59, Brian Dessent wrote: Dave Korn wrote: And here is part 1. No comments then? I'll apply it sometime tonight or tomorrow if nobody objects. Well, you labeled it as part 1 and so I mentally said, okay, I'll take a look at this whenever it's complete. Ah, no, I intended to break out and submit the separate parts of the patch incrementally, sorry for any confusion. Meanwhile (here's the RFC part), my suggestion for part 2 is attached (merged into part 1). It's pretty crude: it disables and reenables the cancel button around each call to Installer::installOne(). This probably doesn't stop the user from pressing the cancel key or clicking the X close box, although I haven't tested that yet. I would be interested in hearing from anyone who reckons they do know the proper way to do this. Ick. I don't really like that. Just the reason why I wanted to keep the uncontroversial bits separate from the more obviously-correct bits! It seems to me that we simply don't support canceling in any sane way once the installation step has begun. Even if we are able to cancel cleanly at a point in between unpacking two packages, that still could leave the system in a horrid state -- missing dependencies, postinstalls not run, etc. We should disable the button for the entirety. Right, I'll rework part 2 on that approach. Meanwhile, part 1 OK for trunk? cheers, DaveK -- Can't think of a witty .sigline today
Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On Tue, 26 Feb 2008, Brian Dessent wrote: Dave Korn wrote: And here is part 1. No comments then? I'll apply it sometime tonight or tomorrow if nobody objects. Well, you labeled it as part 1 and so I mentally said, okay, I'll take a look at this whenever it's complete. Meanwhile (here's the RFC part), my suggestion for part 2 is attached (merged into part 1). It's pretty crude: it disables and reenables the cancel button around each call to Installer::installOne(). This probably doesn't stop the user from pressing the cancel key or clicking the X close box, although I haven't tested that yet. I would be interested in hearing from anyone who reckons they do know the proper way to do this. Ick. I don't really like that. It seems to me that we simply don't support canceling in any sane way once the installation step has begun. Even if we are able to cancel cleanly at a point in between unpacking two packages, that still could leave the system in a horrid state -- missing dependencies, postinstalls not run, etc. We should disable the button for the entirety. I don't like Dave's proposal either. However, simply disabling the Cancel button altogether is not the solution -- if the user is unable to interrupt the installation, she will just kill the process, with disastrous results. The question is: what kind of behavior do we really want in case of cancellation? If we want setup to stop whatever it's doing (dependences, etc, aside), but be able to resume at a later point to fix the state of the system, then Dave's part 1 is the right approach. If we want setup to always leave the system in a sane state, even when it's interrupted, then we should capture the exit message and figure out how to clean up the missing dependences. Keep in mind that processes can be killed in a way that isn't capturable, so setup *will* leave corrupt listing files and missing dependences in some cases. Making sure setup does not crash when restarted after such cases is probably the best we can do. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel
Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
Dave Korn wrote: Meanwhile, part 1 OK for trunk? Yes, I think making that dialog modal is good. Igor Peshansky wrote: I don't like Dave's proposal either. However, simply disabling the Cancel button altogether is not the solution -- if the user is unable to interrupt the installation, she will just kill the process, with disastrous results. Yes, but there will always be a way for the user to shoot themselves in the foot. The best we can do is try to make it harder to find the bullets. Right now it's quite easy to get into trouble since we allow arbitrarily stopping the install at any point. I think disabling the Cancel button (and the close 'X' button) for the entire install phase does put us at a better place than we're at now. Even if they look up the PID of setup and kill it that way, it's still no worse than what we have now. The sad fact is that we don't truly support canceling in any sane form, so we shouldn't advertise that ability in the UI. The fact that you can usually repair things by just rerunning setup (and especially so now that a corrupt .lst doesn't kill the party) is good, but it doesn't mean we should rely on this. To really do this right (e.g. how MSI can rollback to the starting state midway through a aborted install) is a tremendous amount of work that I don't think anyone here is prepared to take on. Brian
RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On 26 February 2008 14:55, Igor Peshansky wrote: The question is: what kind of behavior do we really want in case of cancellation? If we want setup to stop whatever it's doing (dependences, etc, aside), but be able to resume at a later point to fix the state of the system, then Dave's part 1 is the right approach. If we want setup to always leave the system in a sane state, even when it's interrupted, then we should capture the exit message and figure out how to clean up the missing dependences. You've somewhat missed the point. The justification for part 1 is that, entirely orthogonal to and regardless of whatever else we do, those dialog boxes should be modal and they aren't. It Is Just Plain Wrong. It is a fortuitous side-effect of making them correctly modal that it becomes slightly trickier to accidentally cancel an installation when you thought you were just cancelling an individual pop-up request. cheers, DaveK -- Can't think of a witty .sigline today
RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On 26 February 2008 15:24, Brian Dessent wrote: Dave Korn wrote: Meanwhile, part 1 OK for trunk? Yes, I think making that dialog modal is good. Thanks, will commit at a convenient moment. Igor Peshansky wrote: I don't like Dave's proposal either. However, simply disabling the Cancel button altogether is not the solution -- if the user is unable to interrupt the installation, she will just kill the process, with disastrous results. Yes, but there will always be a way for the user to shoot themselves in the foot. The best we can do is try to make it harder to find the bullets. Hear hear. I'm just focussed on helping the end-users avoid trouble to make the package friendlier. Right now it's quite easy to get into trouble since we allow arbitrarily stopping the install at any point. I think disabling the Cancel button (and the close 'X' button) for the entire install phase does put us at a better place than we're at now. Even if they look up the PID of setup and kill it that way, it's still no worse than what we have now. Anyone who's clever enough to attach a debugger to it, I don't need to help. The sad fact is that we don't truly support canceling in any sane form, so we shouldn't advertise that ability in the UI. Ditto. I just want to help people avoid unexpected consequences of what might seem like reasonable actions. cheers, DaveK -- Can't think of a witty .sigline today
RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On Tue, 26 Feb 2008, Dave Korn wrote: On 26 February 2008 14:55, Igor Peshansky wrote: The question is: what kind of behavior do we really want in case of cancellation? If we want setup to stop whatever it's doing (dependences, etc, aside), but be able to resume at a later point to fix the state of the system, then Dave's part 1 is the right approach. If we want setup to always leave the system in a sane state, even when it's interrupted, then we should capture the exit message and figure out how to clean up the missing dependences. You've somewhat missed the point. The justification for part 1 is that, entirely orthogonal to and regardless of whatever else we do, those dialog boxes should be modal and they aren't. It Is Just Plain Wrong. Sorry, I misspoke (mis-wrote?). I meant to say that your part 1 takes us towards that goal. Also, in my morning confusion, I referred to the fix for the corrupt lst.gz files as your part 1. There is no question that both were the right thing to do. It is a fortuitous side-effect of making them correctly modal that it becomes slightly trickier to accidentally cancel an installation when you thought you were just cancelling an individual pop-up request. An alternative would be to pop up a warning box on Cancel that says that this action may leave the system in an unstable state, and are you sure you want to cancel?. I'd still like to have the ability to cancel a long install (preferably with the ability to fix things later by rerunning setup). Incidentally, we already get an incremental install from the way setup is structured -- it will not re-download packages, and will rerun any postinstall scripts remaining from the previous run. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel
Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On Tue, 2008-02-26 at 07:24 -0800, Brian Dessent wrote: To really do this right (e.g. how MSI can rollback to the starting state midway through a aborted install) is a tremendous amount of work that I don't think anyone here is prepared to take on. FWIW this is why I started porting dpkg to cygwin, way back when - it was with the intent of getting a transaction packaging system without writing one from scratch. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part