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