On Sep 19, 2008, at 4:32 PM, Alexey Tourbin wrote:

> On Fri, Sep 19, 2008 at 04:01:13PM -0400, Jeff Johnson wrote:
>>> 1)
>>> %triggerin --posttrans -- /usr/share/icons/hicolor/*/*/
>>> gtk-update-icon-cache /usr/share/icons/hicolor
>>>
>>> This trigger can be triggered/folded/called either by dirname or by
>>> glob pattern itself.  Since there is no way to pass the matching
>>> dirname, which is limitation by itself, the only sane possibility
>>> is that DIRNAMES triggers are triggered/folded/called by glob
>>> patterns.
>>
>> You're worried about a package that has __LITERALLY__ a path
>> that includes glob characters?!?
>
> No-no-no.  I mean something else.  Driname triggers are called *per
> what*?  They should be called *per matching dirname*.  On the other
> hand, using glob patterns, there is no way to pass the dirname to the
> trigger, so we fold matching dirnames *by dirname patterns*.
>
> E.g. for
> %triggerin --posttrans -- /usr/share/icons/hicolor/*/*/
> ...
>
> Possibility #1) when dirname matches, call the trigger;
> so the trigger gets called multiple times for e.g.
> /usr/share/icons/hicolor/a/b/
> /usr/share/icons/hicolor/a/c/
> /usr/share/icons/hicolor/a/d/
> etc.
>
> Possibility #2) getting sober: no way to know which dirnames really
> matched; call once for all matching dirnames.
>
> My point was that, with glob-dirname triggers (which is what you
> propose), I still cannot do what I need (actually what *they* need).
> Triggers simply cannot have any specail "arguments" "that matched",
> at least not now.
>

got it.

> [... I need some time to study other points ...]


The existing trigger mechanism is called once-per-package, and so
I'd suggest continuing the same semantic rather than generalizing
to once per-directory.

I know the gtk icon needs less well than /sbin/ldconfig invocation.

With ldconfig, ideally one would like to add -n /usr/lib or -n /lib to  
minimize
the work involved. That seems to be similar to what you wish with
knowing which directopry matched.

Personally, I'd just add more triggers, one per-directory, if necessary.

In practice, there are so few packages that need ONETIME triggers
that I hardly think its worth the effort of trying to come up with a  
compact
and parameterized implementation immediately. Getting the pattern
matching into triggers, and getting some experience with the  
implementation,
would be useful first.

I don't know of any objectively credible measurements of the time  
saving.

Usually complaints of "ldconfig is S-L-O-O-W!" just mean that the SuSE  
patch
has (temporarily) dropped out of glibc again again again.

73 de Jeff