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-220.127.116.11-18.el5 and will ask on the rpm.org list as well, but thought you might have some ideas, and you did.
If rpm-18.104.22.168 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-22.214.171.124 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