On Sep 19, 2008, at 3:25 PM, Alexey Tourbin wrote:

> On Fri, Sep 19, 2008 at 12:40:55PM -0400, Jeff Johnson wrote:
>>> On Fri, Sep 19, 2008 at 04:21:50PM +0000, Alexey Tourbin wrote:
>>>> Technically there's no piping, only a file duplicated on stdin.   
>>>> And
>>>> "filetriggers" are run only once, at the end of transaction  
>>>> (they're
>>>> actually "posttrans filetriggers"), which saves consecutive  
>>>> ldconfig,
>>>> gtk-update-icon-cache, or whatever calls.
>>>
>>> Uh, but can that work? A Prereq to another package basically says
>>> that the package must be fully configured before installation,
>>> so all triggers must be run. Post-transaction is a bit late...
>>>
>>
>> There's need for a IMMEDIATE as well as a ONETIME (as in delayed)
>> trigger attribute.
>>
>> The ONETIME mechanism can be handled by appending to existing
>> %posttrans, the IMMEDIATE attribute is essentially the existing  
>> trigger
>> mechanism(s).
>
> Okay, with DIRNAMES patterns and "posttrans" trigger flag,
> you can implement something like "posttrans filetriggers" on
> behalf of specfile/rpmdb.
>
> There are still issues.
>
> 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?!?

FWIW, a literal path that includes '*' and other glob characters  
certainly
matches the trigger glob pattern. And so trigger will fire, exactly as
one would expect.

> 2)
> %triggerin --posttrans -- /usr/share/icons/hicolor/*/*/
> gtk-update-icon-cache /usr/share/icons/hicolor
> %triggerun --posttrans -- /usr/share/icons/hicolor/*/*/
> gtk-update-icon-cache /usr/share/icons/hicolor
>
> How do you pass "$2" argument to these triggers?  What is "$2"?  If  
> you
> pass different "$2" for in/un, you can no longer fold basically the  
> same
> in/un triggers (and they run twice).  Or you do not pass "$2" at all.
> Anway, doing just something about "$2" is weired.
>

The $2 argument to triggers is poorly designed and insanely
arcane. Choose a value for "dunno", like -1, pass that instead.

%triggerFu --posttrans is new stuff, feel free to define as needed.

Already there are 4 trigger types, not all of them need to permit -- 
posttrans.

Alternatively, a 5th triggertype instead of --posttrans could be defined
for a ONETIME or delayed trigger instead.

My comment re IMMEDIATE or ONETIME as an attribute was based
on folding %post into a "self-triggered" scriptlet execution. ATM there
are two (or more) possible script invocations. All that is really needed
is a single execution, with $1/$2 set in-between.

Each script could be run in a sub-shell if you worry about  
contamination.
The code (and state machine) within rpmlib gets simpler combining
scripts instead of running separately.

(aside) Note that rpm has __NEVER__ promised running, say, %post
immediately after installing a header. All %post scripts could (in  
principle)
be combined and run in %posttrans without violating any rpm promised  
guarantee.
There are in fact reasons to bundle scripts if/when --rollback is used.

> And this is still not enough.
>
> 3) There's a dozen of icon themes, and their gtk2 icon cache is  
> specific
> to gtk2.  The above triggers imply that I process "hicolor" theme
> specially.  However, I do not.  I want gtk2 to update caches for  
> all its
> themes as needed.
>
> Here is gtk-icon-cache.filtrigger for gtk2 pacakge as (presumably)
> implemented for ALT Linux:
>
> #!/bin/sh
> egrep -o '^/usr/share/icons/[^/]+/' |sort -u |
> # doing /usr/share/icons/*/ directories
> while read -r dir; do
> 	if [ -f "$dir"/index.theme ]; then
> 		# something changed for this theme
> 		gtk-update-icon-cache "$dir"
> 	elif [ -f "$dir"/icon-theme.cache ]; then
> 		# theme was removed, nuke stale cache
> 		rm -f "$dir"/icon-theme.cache
> 		rmdir --ignore-fail-on-non-empty "$dir"
> 	fi
> done
>

I'd say that gtk-update-icon-cache needs to be smartened up
to clean up its mess. I see no reason why a package script should
undertake "theme was removed, nuke stale cache" in a scriptlet.

E.g. whether a package is installed (or not) can be tested by
checking existence of /var/cache/hrmib/N-V-R.A within gtk-update-icon- 
cache.

But your question is/was
    How does the trigger "know" the directory that triggered?

Multiple triggers, one for each directory path, could certainly be used.
Its not like there are thousands of directories, your previous msg  
indicated
156 directories, and 156 triggers is not an enormous overhead, for  
either performance
or maintenance.

Another approach is to use a shell environment with pre/post sections
that map macros to envvar's. That's already being done for build
scriptlets, and rpm-5.0 is expanding scriptlet bodies. With a little  
thought,
the triggered directory could be pushed onto a macro stack, and the  
stack
convered to a list that is stored in an envvar.

> Now you cannot implement this with glob-dirname triggers, because
> you need to know the name of icon theme dir.
>
> gtk2.spec:
> %triggerin -- /usr/share/icons/*/*/*/
> # cannot deduce /usr/share/icons/hicolor/ prefix

But do something else if you want. I see lots of reasons to
generalize existing triggers to include dirnames and glob patterns
no matter what.

But if you wish to "dupe file paths to stdin" and implement differently
in ALT, then have at!

73 de Jeff