From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63338 invoked by alias); 23 Sep 2015 17:17:53 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 63297 invoked by uid 89); 23 Sep 2015 17:17:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: out2-smtp.messagingengine.com Received: from out2-smtp.messagingengine.com (HELO out2-smtp.messagingengine.com) (66.111.4.26) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 23 Sep 2015 17:17:50 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A321320714 for ; Wed, 23 Sep 2015 13:17:48 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 23 Sep 2015 13:17:48 -0400 Received: from [192.168.1.102] (host31-51-205-230.range31-51.btcentralplus.com [31.51.205.230]) by mail.messagingengine.com (Postfix) with ESMTPA id 49C2F6801C0 for ; Wed, 23 Sep 2015 13:17:48 -0400 (EDT) Subject: Re: [PATCH setup 0/3] Setup replacement for incver_ifdep To: cygwin-apps@cygwin.com References: <1442937170-17580-1-git-send-email-jon.turney@dronecode.org.uk> <87mvwegy0r.fsf@Rainer.invalid> From: Jon Turney Message-ID: <5602DEBA.9080601@dronecode.org.uk> Date: Wed, 23 Sep 2015 17:17:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <87mvwegy0r.fsf@Rainer.invalid> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-09/txt/msg00039.txt.bz2 [replying to the right list, this time] On 22/09/2015 18:32, Achim Gratz wrote: > Jon Turney writes: >> Since we now have scripts which run on every setup run, a package which requires >> another package to do some work after it is installed or uninstalled can create >> a file to act as a trigger for that to happen. > > There aren't any stratified scripts for pre-remove, so a lot of the > things that you might wish for don't work anyway. So again it would > need to be fixed without getting a trigger or setup would need to be > made a lot smarter than it is today. I thought that permanent postinstall scripts run even when no packages are being installed, or only packages are being removed, so they they are effectively run every time setup is? >> Unfortunately, it's not very practical to change to doing that for the all >> packages which contain info files, so I am suggesting this approach. > > So just do it unconditionally; I was planning to change _update-info-dir > accordingly, but haven't found the time yet. I do the same with mandb > locally already and I haven't looked back. Tempting, but I don't believe that is a good solution, since it adds the time it takes to rebuild the info directory to every setup run. > $ time /etc/postinstall/update-info-dir.sh.done > > real 0m18.169s > user 0m3.261s > sys 0m5.703s I also don't think it sets a good example. Any other packages which require update scripts to run (which may take even longer) when packages are installed/removed, should not be doing that every time setup is run, if avoidable.