upset2 improvement for automatic /usr/info/dir generation

Christopher Faylor cgf@redhat.com
Sun Mar 31 14:42:00 GMT 2002


On Mon, Apr 01, 2002 at 07:48:32AM +1000, Robert Collins (as predicted) wrote:
>> -----Original Message-----
>> From: Christopher Faylor [mailto:cgf@redhat.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



More information about the Cygwin-apps mailing list