On Sep 22, 2008, at 11:45 AM, Jeff Johnson wrote:

>
> On Sep 21, 2008, at 11:12 PM, Jeff Johnson wrote:
>
>>
>> There's false trigger firing(s) if a package contains multiple  
>> triggers and any
>> trigger matches because of this comparison in lib/psm.c:
>>
>>         /* XXX Trigger on any provided dependency, not just the  
>> package NEVR. */
>>         if (!rpmdsAnyMatchesDep(sourceH, trigger, 1))
>>             continue;
>>
>
> What I was seeing as "false firing" turns out to be from installing  
> the wrong package
> in my test script.
>
> On to firing triggers on file and directory paths next ...
>

In order to finish implementing triggers that file on file glob's,
a decision on how to apply patterns to primary key(s) needs
to happen.

ATM, paths are split into a Dirnames and a Basenames index.

So a file glob needs to applied to 2 primary keys, not just one, for
full generality.

There are two approaches:

1) Generate a table containing full file paths and apply patterns
to the primary keys in the table.

2) Attempt a join operation, with associated logic to split the glob  
into a Dirnames
and a Basenames pattern.

Since I don't think anyone is actually going to use file patterns for  
triggers
for another year or so, I'm going to create a new Filepaths table that
carries full absolute paths, and use that just like the existing  
Dirnames
table is being used for patterns that end with a '/'.

The more elegant join implementation can certainly be done any
time there is interest. Note that patterns in general cannot be split
quite so easily as a file glob might be split. Consider a patten that
matches "foo >= 1.2" which spans primary keys for two tables and
includes text that isn't in a string at all.

The remaining two items to finish with triggers fired by file glob  
patterns are

1) make trigger firing fully symmetric, only package -> rpmdb  
triggers, not
rpmdb -> package, triggers are implemented atm.

2) add a "one-shot" or "delay" flag to uniquely add a trigger to % 
posttrans
when pattern matches, skipping future attempts to trigger on the pattern
to minimize overhead.

There's the other detail of how to pass the plaintext which the  
pattern(s) matched
to the trigger script that cand be added as an enhancement if anyone  
actually
wants. I don't expect there to be much interest in pattern fired  
triggers for quite
some time. There are other issues wrto $1 and $2 passed to trigger  
scripts
that need to be solved first imho.

Note that file path triggers are already fully supported, and  
symmetric, the issues I mention
are solely with pattern fired triggers. I have no problems pushing  
the existing
implementation into rpm-5.1.5. OTOH, there's very little reason to do  
so.

73 de Jeff