This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]