RPM Community Forums

Mailing List Message of <rpm-users>

Re: Clarification of the way triggers do work

From: Jeff Johnson <n3npq@mac.com>
Date: Thu 15 Oct 2009 - 05:27:25 CEST
Message-id: <0817142F-5FA8-41FF-879D-5E5D239F7A94@mac.com>

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
Received on Thu Oct 15 05:28:07 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.