Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com Date: Sun, 31 Mar 2002 17:42:33 -0500 From: Christopher Faylor To: cygwin-apps AT cygwin DOT com Subject: Re: upset2 improvement for automatic /usr/info/dir generation Message-ID: <20020331224233.GA27053@redhat.com> Reply-To: cygwin-apps AT cygwin DOT com Mail-Followup-To: cygwin-apps AT cygwin DOT com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23.1i On Mon, Apr 01, 2002 at 07:48:32AM +1000, Robert Collins (as predicted) wrote: >> -----Original Message----- >> From: Christopher Faylor [mailto:cgf AT redhat DOT com] >> Sent: Monday, April 01, 2002 7:25 AM > >>Anyway, I'll be implementing this in the next couple of days. This is >>just a heads up. This means that special "generate info file" logic >>can safely be removed from setup, I think. > >There isn't any in setup right now :}. I like the regex approach, I >don't like the triggered download of this package. I meant special logic that people had added to their own packages, obviously. >IMO it would be better to spit the dummy and reject the package if it >doesn't have some other well-known file (ie if it has any .info file, >it ust have a /etc/setup/postinstall/foo.sh that includes a call to >install-info) Or are you saying that it is safe to assume that the existence of an install-info means that the .info files are being generated? I can't rely on that since I would like people to *start* relying on the fact that info files are generated automatically. So, the existence of a postinstall file won't necessarily mean that .info files are already being generated. The alternative is to parse the contents of foo.sh file for occurrences of install-info. I can conceive of a setup.hint syntax which would allow that: autodep: usr/include/\*\.info && !contains(install-info, etc/postinstall/.*) but I think that's really overkill for this problem. The other alternative is to put this in individual setup.hint files. noautodep: update-info-files That's much easier. However, running over all of the files in /usr/info takes 8 seconds on my Pentium 233 laptop running NT 4.0 SP6, so I don't think this is really a huge issue. That's one of the reasons I abandoned the logic of trying to figure out what info files had changed and only updating those. It actually required two passes over the info files and it really wasn't any faster. cgf