On Jun 15, 2007, at 11:07 AM, tony.chamberlain@xxxxxxxxx wrote:
Hi
I have several RPMs that need to be installed together to make up a
system. There are also two different flavors of these (call them
CDMA and GSM).
I made two "container" rpms which simply themselves do rpms. Since
you can't do an rpm inside an rpm
technically (you can't obtain the lock) I put them in the %post
like this inside my install.rpm:
%post GSM
(
sleep 2
rpm -Uvh x.rpm
rpm -Uvh y.rpm
rpm -Uvh z.rpm
) &
This executes in the background and makes sure that install.rpm
finishes before the other RPMs are done.
Ick.
Running asynchronously in background assumes that you can guess the
necessary
time to wait, which you will never be able to do successfully.
You are attempting what I call a "package bundle".
What you are fighting is a exclusive fcntl transaction lock. The lock
will stop a chiild rpm process
from performing installs/upgrades from a scriptlet.
The location of the transaction file lock is configurable, and there
have been some path changes,
but the usual conventional location these days is /var/lib/rpm/__db.000.
So get rid of the background sub-shell and the sleep, and add
rm -f /var/lib/rpm/__db.000
instead. This will (or should) permit you to install packages from a
another
packages %post scriptlet.
Note that you should match the install/upgrade in %post with equivalent
erasures in %preun.
Now these packages have many common RPMS (let's say common1.rpm,
common2.rpm, common3.rpm,
common4.rpm) and only maybe 1 or 2 separate ones (like gsm.rpm and
cdma.rpm).
The only difference between my %post GSM and %post CDMA is that one
file (gsm.rpm or cdma.rpm).
I originally gave the packages inside install conflicts. For
instance install-CDMA conflicts with install-GSM and with
gsm, and vv.
However, if I do an rpm -Uvh install-cdma.rpm and then later rpm -
e cdma so I can try the gsm, I can't
do rpm -Uvh gsm.rpm because it will conflict with install-cdma even
though the cdma part is removed.
Does anyone else do something similar where you have RPMs inside
RPMs and you need to make some conflict?
I wouldn't want to have to rpm -e an entire install rpm and then
rpm the new one. That would be a lot of waste.
Don't use Conflicts:, use Obsoletes: instead, is the best approach.
Conflicts: always come full stop, and you already know what the proper
solution is, the two packages are mutually exclusive.
hth
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
