Re: RPM DB locked(?)/Access to Update Release Info?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christian.Rohrmeier@xxxxxxxxxxx wrote:

Hello All,

I am writing an RPM for RHEL 2.1. In it, I need to take actions in the
%post script depending on the Update Release (e.g. RHEL 2.1 WS Update 3).

The two ways I have tried to find this information has been: [ ... ]



2) Reading the redhat-release package information. Technically this
contains the information (albeit in a peculiar form):

RHEL 2.1 WS Update 5:
# rpm -qa | grep redhat-release
redhat-release-ws-2.1WS-18

RHEL 2.1 WS Update 6:
# rpm -qa | grep redhat-release
redhat-release-ws-2.1WS-20

I guess Update 5 is release "18" and Update 6 is release "20". Okay, fine
by me.

I need this information in my %post script. However, under RHEL 2.1, here's
what happens when my %postscript contains the following line:
INFO=`rpm -qa | grep redhat-release`

# rpm -ivh test-1.0-1.noarch.rpm
Preparing...                ###########################################
[100%]
error: cannot get shared lock on /var/lib/rpm/Packages
error: cannot open Packages index using db3 - Operation not permitted (1)

This works with RHEL 3 and 4 however.

So, here's my primary question:
How do I find out the Update Release of an RHEL 2.1 System, in a form that
I can use in an RPM %post script?
Good question...

Further, how indeed do I get access to any RPM database information from
with an RPM %post script?
I believe that it simply cannot be done. At least, "rpm -q" won't do anything if it finds that another rpm command is about to update the setup. *Maybe* you are allowed to access the database if you do so directly from an application of your own (possibly linked with librpm.) Also, rpm -q may actually be allowed with newer rpm releases, but that won't help you a lot.

Seeing as how the whole idea of RPM is to take appropriate action based on
the versions of other installed software packages, there must be a way to
access such information on RHEL 2.1.
The only way I can think of right now to do what you want, is to use the rpm trigger mechanism, i.e. add something like

%triggerin -- redhat-release-ws = 2.1WS-18
<do the job for update 5>

%triggerin -- redhat-release-ws = 2.1WS-20
<update 6 commands>

this would have the added benefit that the appropriate actions also are taken if you upgrade the system without re-installing your package.

- Toralf


_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux