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
The generalization to permit multiple triggers to fire between two
a given point in the install state machine is needed.
2) triggers fire on RPMTAG_NAME, not RPMTAG_PROVIDENAME or
The generalization to fire triggers on the set of RPMTAG_PROVIDENAME
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
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
which muddles the implementation further, because 2 indices need to
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
Received on Sat Sep 20 19:38:16 2008