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.

73 de Jeff