X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=ABJ9AiCKZd29esmo5U6/ejm8+Jb61lcT0nc4mHEQ3Kr
	pCe0ddzaWNBFifMGs+Mi6IQpBKFmoVL+4BB3JN3L10gYDiUH3KmF8t9LNAUeFeuJ
	a0BwPXSQqC8JyYasF563QQpJRE8FWkeuGVVhp9fx7xxVWZbBI44xx+SsrOYNB3lc
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=fuH6MucMtTJC79GEMtf9BNiT9VE=; b=oTKn0wNrv+iiHERJ3
	17PCsiKv9cpIgR5YFchTAkSdqkZSVgZBJkReKKa2RaaHlFAUhVSrw30/Ht2DIZpK
	CoFMjwNhDaC2dk5cCg2+MlI7Eb1+sTBSgZzhxDoDawHFnoHwET+cTVoV45+HUb9K
	FuXHS6vgPhSJwAsKsLAT9QH6X8=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,T_FILL_THIS_FORM_SHORT autolearn=ham version=3.3.2
X-HELO: limerock03.mail.cornell.edu
X-CornellRouted: This message has been Routed already.
Message-ID: <54629DBF.60303@cornell.edu>
Date: Tue, 11 Nov 2014 18:37:35 -0500
From: Ken Brown <kbrown AT cornell DOT edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Setup 2.774 texlive postinstall takes 10+ hours
References: <1414708038168-112334 DOT post AT n5 DOT nabble DOT com>	<54567198 DOT 8000504 AT cornell DOT edu>	<20141103102515 DOT GS14051 AT calimero DOT vinschen DOT de>	<87a948kvpw DOT fsf AT Rainer DOT invalid>	<20141104085958 DOT GA4932 AT calimero DOT vinschen DOT de>	<54618F4C DOT 6000107 AT cygwin DOT com> <546191B0 DOT 4050808 AT cygwin DOT com>	<20141111115343 DOT GQ2782 AT calimero DOT vinschen DOT de>	<546219A9 DOT 2070103 AT cornell DOT edu> <54622517 DOT 7030302 AT cornell DOT edu>	<20141111160239 DOT GS2782 AT calimero DOT vinschen DOT de> <87ppctu0ks DOT fsf AT Rainer DOT invalid>
In-Reply-To: <87ppctu0ks.fsf@Rainer.invalid>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

On 11/11/2014 12:08 PM, Achim Gratz wrote:
> Corinna Vinschen writes:
>> On Nov 11 10:02, Ken Brown wrote:
>>> Of course, this still doesn't solve the problem of making sure that the
>>> _autorebase postinstall script runs whenever the user installs a package
>>> containing DLLs.  I wonder if we should reconsider Achim's proposal.  If I
>>> understand correctly, it is something like this (oversimplified):
>>>
>>> 1. Change autorebase.bat to do an incremental rebase instead of trying to do
>>> a full rebase.
>>>
>>> 2. Arrange for autorebase.bat to never be marked as "done".
>>>
>>> Achim, please correct me if my oversimplification distorts your suggestion
>>> too much.
>>
>> Achim, can you give a management summary how your proposal works?
>
> As Ken already correctly summarized, the autorebase postinstall script
> will never be marked as done by setup.exe, so it will be run on each
> install or update.  The incremental part ensures that this step doesn't
> take too much time if there's nothing to do.  Currently this is based on
> the name of that script, but it could be done differently.  The other
> part is that all "perpetual" postinstall scripts are run before any
> normal postinstall scripts, so these can assume to run in a correctly
> rebased environment.

This seems like a very simple solution to the problem.  I like it a lot.

> A slightly modified variant of the same mechanism could be used for
> those infodir, icon cache and fontconfig updates, which should probably
> be run after the normal postinstall scripts.  I think I've sent Ken a
> sketch doing this from within a postinstall script for the texlive
> packages, but providing some support from setup.ini and setup.exe for
> stratified postinstalls (pre-post and post-post :-) would make this much
> more robust.  I haven't yet coded up anything in that direction, though.
>
> If you're wondering what happens when you've just installed a fresh
> Cygwin: the perpetual rebase postinstall scripts detects the situation
> and bails out, while the normal postinstall script does the initial
> rebase (and is marked "done").  Which means we have to fix the
> dependency problem anyway.
>
> Incremental autorebase packages and patched setup.exe available on
> request.

I'd like to see them.  Thanks.

Ken


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