This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: upset2 improvement for automatic /usr/info/dir generation


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]