Mail Archives: cygwin-apps/2002/03/31/17:42:33

Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <>
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 <cgf AT redhat DOT com>
To: cygwin-apps AT cygwin DOT com
Subject: Re: upset2 improvement for automatic /usr/info/dir generation
Message-ID: <>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
References: <FC169E059D1A0442A04C40F86D9BA76008ABEE AT itdomain003 DOT itdomain DOT net DOT au>
Mime-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/

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,

>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/ that includes a call to

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 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.


- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019