On Oct 14, 2009, at 10:12 PM, Tobias Gerschner wrote:
>> Triggers will fire whenever the trigger condition is met. That may
>> or may
>> 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
>> be tuned (by adding version comparison) to limit the trigger
>> 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
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
The overhead of the new trigger implementation has been checked with
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
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
entirely. But that will require larger changes, including a rpmdb
as well as consolidating the 4 rpmdb hits into a single pass operation
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
recently appeared on the OpenSUSE RPM summit roadmap (but is already
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
the triggers may fire where you are not expecting. You did say you
to fire only once during upgrade ...
73 de Jeff
Received on Thu Oct 15 05:28:07 2009