From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53584 invoked by alias); 23 Nov 2015 15:14:43 -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 53481 invoked by uid 89); 23 Nov 2015 15:14:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,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; Mon, 23 Nov 2015 15:14:42 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5B1DF2084E for ; Mon, 23 Nov 2015 10:14:40 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 23 Nov 2015 10:14:40 -0500 Received: from [192.168.1.102] (host86-141-129-50.range86-141.btcentralplus.com [86.141.129.50]) by mail.messagingengine.com (Postfix) with ESMTPA id F3344680110 for ; Mon, 23 Nov 2015 10:14:39 -0500 (EST) From: Jon Turney 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> <561BB2A4.2030009@dronecode.org.uk> <87lhb8htrh.fsf@Rainer.invalid> <561FA783.900@dronecode.org.uk> <87oag0qad3.fsf@Rainer.invalid> Message-ID: <56532D5C.1020103@dronecode.org.uk> Date: Mon, 23 Nov 2015 15:14:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <87oag0qad3.fsf@Rainer.invalid> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-11/txt/msg00061.txt.bz2 On 15/10/2015 19:01, Achim Gratz wrote: > Jon Turney writes: >>> I still don't think the triggers should be implemented or at least not >>> in the way you've been proposing. >> >> Can you explain the reason why? > > Triggers need to be coordinated among packages and we currently don't > have an infrastructure for that. And implementing just a single trigger > for info files is special-casing this thing too much. > >> I think that's more or less what I implemented. > > I'm talking about doing it with a perpetual postinstall script. > >>> But it would be possible to just add / >>> remove the corresponding entries with a bit more bookkeeping. I'll try >>> something of that, but not immediately. >> >> I guess that list of matching files added/removed could be written >> into or associated with the trigger file, but the benefit starts to >> look a bit marginal, (especially as this is not intended as a general >> solution, but only for use with _update-info-dir, and other future >> package-to-package triggers are written directly in the packages >> themselves) > > Again, I don't see why updating the info dir should be so special, it > can be done in postinstall without getting special-cased in setup: I agree. But I think the problem of coordination you mention can only be solved by (a) updating all ~155 packages which contain files in /usr/share/info, or (b) having something in setup or it's postinstall scripts which notices when a file is added/removed in that directory. I don't think (a) is practical at the moment, although I hope it is clear in my proposal that I am suggesting that ultimately all those packages should create the trigger file in their postinstall/preremove scripts. I still don't understand what alternative way to achieve (b) you are proposing.