On Sep 20, 2008, at 1:37 PM, Jeff Johnson wrote:

> Since there appears to be interest in using triggers in production,
> here are 2 limitations that need solving immediately imho.
>
> 1) only one trigger fires between any pair of package headers.
>
> 	When a trigger is attempted, only a single trigger firing is  
> permitted.
> 	This basically means that you cannot have triggers in both packages
> 	that fire on each other, and also means that you cannot have multiple
> 	triggers with different, possibly overlapping, conditions in a  
> single package.
>
> 	The generalization to permit multiple triggers to fire between two  
> packages at
> 	a given point in the install state machine is needed.
>
> 2) triggers fire on RPMTAG_NAME, not RPMTAG_PROVIDENAME or  
> RPMTAG_BASENAMES.
>
> 	The generalization to fire triggers on the set of  
> RPMTAG_PROVIDENAME elements is
> 	half implemented, based on the fact that every package provides  
> its own name. The
> 	other half of the implementation involves another loop over the  
> set of provided names.
>
> 	Extending to RPMTAG_BASENAMES (or RPMTAG_DIRNAMES) is  
> straightforward once
> 	the loop over RPMTAG_PROVIDENAME is implemented, its just a  
> different index that
> 	needs to be searched when the key starts with '/'.
>
> 	There's the additional wrinkle of handling
> 		Provides: /path/to/file
> 	which muddles the implementation further, because 2 indices need  
> to be searched.
>
> 	Personally, I think its way past time to prohibit file paths in  
> the Providename index. A second source
> 	for paths adds a huge amount of complexity to all application  
> accesses, not just rpm, of an rpmdb for
> 	very little benefit other than that packagers and vendors get to  
> pretend that file paths in the Providename
> 	index is some sort of cool and useful feature.
>
> 	From an engineering POV, paths in the Providename index just  
> doubles the amount of work needed
> 	to ensure whether a path is present (or not).
>
> I'll attempt an implementation to solve these two issues in the  
> next week or so.
>

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;

The existing logic works fine for single trigger matches between  
packages however, which is all that
rpm has ever supported until now. The fix is pretty easy now that  
dependency sets rather
than headers can be used, I'll replace the any-to-any comparison with  
symmetric
one-to-many comparisons this week.

Next will be looking at firing triggers on paths, directories,  
patterns, other tag content,
using external trigger scripts, with negated compound logic, and  
filling in %posttrans
from ONETIME triggers.

There's a couple levels of rewrites still to do as well, the trigger  
code ain't been touched since
like rpm-3.0.2, and so the code extracts trigger tags more often than  
is necessary.

73 de Jeff