On Oct 15 20: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.  Actually, considering that the info files are stored in just a
single well-known directory, /usr/share/info(*), and further considering
that updated files are rewritten when overwritten, shouldn't it be entirely
sufficient if the update_info_dir script performs a simple test like this:

- Does /usr/share/info/dirs exist?

  No -> run install-info

  Yes -> Is /usr/share/info/dirs mtime < /usr/share/info mtime?

         No -> Do nothing

	 Yes -> run install-info

?


(*) We should drop the check for /usr/info, imho.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat