This is the mail archive of the cygwin 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: setup.exe --quiet-mode


Rob wrote on 10 September 2008 18:24:

> Dave Korn <dave.korn <at> artimi.com> writes:
>>   It might be worth trying a snapshot of 2.602, I think we fixed this on
>> mainline: it should automatically choose the "ok" or "continue" option
>> in any dialogs that would be generated.
>> 
>> http://cygwin.com/setup/snapshots
> 
> Dave, I tried running this snapshot setup with the -q option, and it still
> halted when it encountered a dialog box. (in this case it was an "entry
> point not found error as explained below)

  Ah, well that wasn't setup.exe's dialog, so the unattended mode flag doesn't
directly affect it.  We may be able to do something to prevent spawned
processes popping up dialog boxes with the flags we use when calling
CreateProcess; it's just that nobody thought of it at the time (not having had
any such problems during development and testing the feature).

  On the plus side, that *does* mean that it silently chose the
"rename-on-reboot" option, as we would have hoped; it wouldn't have got to the
postinstall scripts if not.

> While running this test, I encountered an interesting race condition:
> If I am updating on a box that has "in use" files, and cygwin1.dll cannot
> be replaced, when postinstall scripts try to run they generate all kinds
> of errors because SOME of the new binaries DID install and when it tries
> to run them they FAIL because they are not supported by the CURRENT .dll.

  Err, that should never happen, unless you're updating from a
several-years-old DLL.  The Cygwin DLL is intended to be backwardly
compatible, and only rarely have their been ABI breaks.  So this aspect of
updating doesn't get tested very often.

> How do you get around this situation?

  Well, I don't, because it doesn't happen to me!

> I guess the obvious answer is to make sure NO cygwin related processes are
> running when you run setup. But I was hoping it would just schedule the
> files for replacement and do it on the next reboot.

  Well, yeh, it did do that.  But there's no mechanism to schedule all the
postinstall scripts to not be run until the next reboot, which IIUIC is what
would be needed here for them not to crash.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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