Jeff's suggestion to use new-%post to rename the content directory, and
new-%triggerpostun to rename it back - won't work because the new
%triggerpostun does not execute at all in this update chain.
According to "Packaging Software with RPM (part 3)" the ordering is:
new-%pre for new version of package being installed
... (all new files are installed)
new-%post for new version of package being installed
any-%triggerin (%triggerin from other packages set off by new install)
new-%triggerin
old-%triggerun
any-%triggerun (%triggerun from other packages set off by old
uninstall)
old-%preun for old version of package being removed
... (all old files are removed)
old-%postun for old version of package being removed
old-%triggerpostun
any-%triggerpostun (%triggerpostun from other packages set off by old
un
install)
So this means that if we rename the content directory using a new-%post
script, then there is no way to rename it AFTER the bad old %postun
script runs.
I found one ugly workaround using a preinstall scripts in the new
package to force complete removal of the old package then up2date of the
new one:
NVR=`rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}' myapp`
# check if we have either rhel3 or rhel4 package w/bad script
installed
if test "$NVR" = "myapp-1.2.3-1 " ; then
echo "Removing $NVR"
rm -f /var/lock/rpm/transaction # release lock
/bin/rpm -ve --nodeps myapp
/usr/bin/up2date -v myapp
Fi
~mnh
------------------------------------------------------------------------
-------------
Re: RE: workaround for broken postuninstall during upgrade?
* From: "Jeff Johnson" <n3npq jbj gmail com>
* To: "RPM Package Manager" <rpm-list redhat com>
* Subject: Re: RE: workaround for broken postuninstall during
upgrade?
* Date: Wed, 29 Nov 2006 16:11:04 -0500
On 11/29/06, Huttner, Michael N. <michael huttner gs com> wrote:
The broken rpm has a postuninstall script with "rm -rf
/opt/myapp-1.2.3/*" which removes everything under the install
prefix,
including all new content provided by updating with the new rpm
release.
The upgrade (via "up2date -u myapp")works perfectly, except we are
left
with an empty directory under the install prefix.
Got it, thanks.
Here's what I would do:
in %post of the new package, rename the directory to Something Else
<the old package erasure with busted %postun runs>
in %triggerpostun of the new package, rename the directory back to
its original name.
A bit hacky, but will upgrade.
Hint: check the old and new package manifests closely. Because of the
hackery, rpm will *NOT* remove any files that were contained in the old
package, but are not present in the new package. Replacements (i.e. new
package file replaces old package file) will be fine, additions as well,
its only deletions that you need to check for.
Hth 73 de Jeff
-----Original Message-----
From: Huttner, Michael N.
Sent: Wednesday, November 29, 2006 2:18 PM
To: 'RPM Package Manager'
Subject: RE: workaround for broken postuninstall during upgrade?
The broken rpm has a postuninstall script with "rm -rf
/opt/myapp-1.2.3/*" which removes everything under the install prefix,
including all new content provided by updating with the new rpm release.
The upgrade (via "up2date -u myapp")works perfectly, except we are left
with an empty directory under the install prefix.
-----Original Message-----
From: Jeff Johnson [mailto:n3npq.jbj@xxxxxxxxx]
Sent: Tuesday, November 28, 2006 8:09 PM
To: RPM Package Manager
Subject: Re: workaround for broken postuninstall during upgrade?
On 11/28/06, Huttner, Michael N. <michael.huttner@xxxxxx> wrote:
> I've got an rpm installed on a large number of machines. This package
has a
> defective postuninstall script (eg, "rm -f /myapp") which will remove
new
> payload content in an upgrade. We need to find a creative solution
which
> allows users to upgrade this broken rpm, ideally via "up2date -u
myapp". Is
> there any way to provide an upgrade, combination of new packages, or
trigger
> which can do this? I do not as yet know any way to prevent the bad
package
> postuninstall or force the bad package to completely uninstall itself
before
> upgrading with a new package.
>
If you meant literally that an already deployed package is failing to
upgrade because
"rm -f /myapp" is failing in %postun, then adding
touch /myapp
to the newer packages %post will create the missing ingredient that
the already deployed package needs in order to succeed.
Otherwise you need to supply more specific details of why %postun is
failing.
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
