RPM Community Forums

Mailing List Message of <rpm-users>

Re: Finding out triggered package version

From: Jeff Johnson <n3npq@mac.com>
Date: Thu 15 Jul 2010 - 03:53:59 CEST
Message-id: <ECEFDE13-1034-4308-9157-36C67AC36235@mac.com>

On Jul 14, 2010, at 9:42 PM, Jefferson Ogata wrote:

> On 2010-07-15 01:28, Jeff Johnson wrote:
>> On Jul 14, 2010, at 8:26 PM, Jefferson Ogata wrote:
>>> I'm trying to write a SPEC file for a package that will be triggered on kernel upgrades. Its trigger scriptlet will execute a script to install a kernel module. The script needs to know the version of the new kernel.
>>> 
>>> Is there any way for a trigger scriptlet to discover the version of the triggered package that is being installed?
>> I'm gonna assume rpm-5.x behavior (because different than @rpm.org).
>> There is a means iirc (but I can't remember offhand which of these methods "works")
> 
> Thanks for the detailed response. Actually using rpm-4.4.2.3-18.el5 and will ask on the rpm.org list as well, but thought you might have some ideas, and you did.
> 

If rpm-4.4.2.3 you do not have the macro expansion approach as
an available choice.

> Given that no matter what I do it seems a bit klugey, I'm leaning toward just enumerating all the installed kernels and making sure the target module is installed in each of them.
> 

On rpm-4.4.2.3 you also have the transaction lock
that you need to work around if attempting to invoke
an rpm --query from within a scriptlet.

Disabling is most easily done by renaming /var/lib/rpm/__db.000 before
invoking rpm -q, and then renaming back into place.

You can just remove /var/lib/rpm/__db.000 in the scriptlet if you are lazy. Removing
the file (and the fcntl lock contained within) opens a minor lock race window,
but the window is no worse than another window that rpm already has when reopening
the database from O_RDONLY -> O_RDWR.

The transaction lock isn't really useful or needed or protecting anything since
almost every application using rpmlib has its own separate
exclusive locking scheme. The transaction lock is "opt-in" @rpm5.org
and the default behavior is "disabled" for >3 years now,
its functionality is more annoying than useful imho.

73 de Jeff
Received on Thu Jul 15 03:54:35 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.