On Oct 14, 2009, at 10:12 PM, Tobias Gerschner wrote:
Triggers will fire whenever the trigger condition is met. That may
or may
not
be only once on upgrade. Just make sure the trigger body is prepared
to create symlinks iff the symlink does not already exist. Running a
trigger isn't particularly expensive, and the trigger condition
should
be tuned (by adding version comparison) to limit the trigger
condition.
hth
73 de Jeff
Did you mean to say, that running triggers is an expensive operation ?
Why else would you tune to limit it's occurrence ?
Mostly just muttering about rpm devel on HEAD out loud ...
Triggers are potentially very costly because all added packages
get crossed against all installed packages 4 times while installing.
But the overhead is basically a database lookup, which almost always
finds nothing to do.
About a year ago, I generalized triggers to fire not just on package
Name,
but also Provides, and directories and files and using glob patterns.
That _STILL_ is a tolerable overhead, looking up a key in a database
just isn't that expensive, and there just aren't that many triggers
in use.
The overhead of the new trigger implementation has been checked with
callgrind.
The effects are visible, but tolerable.
However, watching the spewage from triggers hitting 4 indices 4 times
for all files
directories and trigger tokens in packages is starting to drive me
batty.
The short term fix will be to add a Bloom filter on the indices to
avoid hitting an rpmdb
unnecessarily. Basically that avoids the debugging spewage, and saves
my tired old eyes.
But the eventual fix will be to redesign the access to optimize away
the overhead
entirely. But that will require larger changes, including a rpmdb
schema change,
as well as consolidating the 4 rpmdb hits into a single pass operation
to
pull out just those triggers that need to be run ...
None of the above has anything to do with the rpm that you are using,
nor is there significant performance degradation in rpm-5.1.7 and later
with the new trigger implementation.
The ability to trigger on not only package Name: but also
Provides: and directories and files and with patterns is a useful
generalization, has
recently appeared on the OpenSUSE RPM summit roadmap (but is already
implemented @rpm5.org).
But what I was really trying to point out to you is that triggers fire
when the trigger condition is met. If you write the trigger condition
too loosely,
the triggers may fire where you are not expecting. You did say you
expected triggers
to fire only once during upgrade ...
hth
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
User Communication List rpm-users@rpm5.org
