X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
From:	"Dave Korn" <dave DOT korn AT artimi DOT com>
To:	<cygwin AT cygwin DOT com>
References:	<loom DOT 20080904T183156-413 AT post DOT gmane DOT org> <48C0316C DOT F9E434A9 AT dessent DOT net> <00fc01c90f39$f4006970$9601a8c0 AT CAM DOT ARTIMI DOT COM> <loom DOT 20080910T172329-77 AT post DOT gmane DOT org>
Subject:	RE: setup.exe --quiet-mode
Date:	Wed, 10 Sep 2008 18:35:37 +0100
Message-ID:	<007101c9136b$a62b3e10$9601a8c0@CAM.ARTIMI.COM>
MIME-Version:	1.0
X-Mailer:	Microsoft Office Outlook 11
In-Reply-To:	<loom.20080910T172329-77@post.gmane.org>
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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/

- Raw text -