RPM Community Forums

Mailing List Message of <rpm-users>

Re: replacing a rpm which has a preventing measure in its preun section

From: Jeff Johnson <n3npq@mac.com>
Date: Sat 13 Nov 2010 - 11:30:51 CET
Message-id: <203DDD51-C1BB-47A9-B9A3-A53AC103AC19@mac.com>

On Nov 13, 2010, at 3:45 AM, Oguz Yilmaz wrote:

> Hi,
> 
> I have a rpm named deployment which has a preun section like:
> 
> preuninstall scriptlet (using /bin/sh):
> echo "You should not uninstall this package"
> exit 1;
> 
> I have another rpm named "installrpm" which should replace "deployment"
> 
> A- I have added 
> 
> Provides: deployment
> Obsoletes: deployment
> 
> linesi n "installrpm" spec file.
> 
> However, because of the preun lines, installrpm can not replace deployment.
>  

Yes, that is the expected behavior.

(aside)
Technically, the "installrpm" package _HAS_ replaced the "deployment"
package at least for the common subset of files in each package.

What hasn't been done is to unregister the "deployment" package
and remove the files unique ti the "deployment" package.


> 
> B- I have tried to remove deplyment by hand in the post section of "installrpm". 
> 
> %post
> rpm -q deployment 2>&1 > /dev/null
> if [ $? -eq 0 ]; then
>         rpm -ev deployment --nodeps --noscripts
> fi
> 
> However this time, rpm db lock can not be obtained by inner "rpm -ev deployment --nodeps --noscripts" command.
> 

Running rpm in %post is one approach to trying to automate an upgrade.

Whether the approach will "work" I cannot say.

But you can avoid the deadlock by renaming the file that
has the fcntl lock before running rpm in %post, and then renaming
the file back after running rpm.

E.g. (assuming the transaction lock is /var/lib/rpm/__db.000,
LOCK envvar used solely for clarity)

%post
LOCK=/var/lib/rpm/__db.000
rpm -q deployment 2>&1 > /dev/null
if [ $? -eq 0 ]; then
        mv ${LOCK} ${LOCK}-SAVE
        rpm -ev deployment --nodeps --noscripts
        mv ${LOCK}-SAVE ${LOCK}
fi

> I have to put "installrpm" into a repository. So it should be working without manual intervention.
> 
> Do you have any recommendation?
> 

You can also add --nopreun (implied by --noscripts) and manually erase the package.

There is not automated way to erase packages with failing scripts
except by not running the script or by ignoring the exit code (but
that's a change needed in rpm itself).

Write the %preun script differently next time, and don't
prevent the packe from being removed.

The resaon fro preventing removal isn't clear; but changing the
packaging can likely add a dependency that effectively
stops erasing --nodeps is used.

But without knowing details of why %preun was written
to prevent the :deployment" package from being erased, I can only guess.

hth

73 de jeff

> Regards,
> 
> --
> Oguz YILMAZ
Received on Sat Nov 13 11:31:13 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.