Dan Stromberg wrote:
Bart Whiteley wrote:
Wolfgang Rosenauer wrote:
Hi,
Dan Stromberg schrieb:
However, now I'm finding that I can repeatably:
1) Install 3.1.0.0 of the rpm 2) -Uvh 3.1.0.3 of the rpm 3) The files under the original hierarchy disappear. The files under the secondary hierarchy become present. My %post that copies files from the secondary hierarchy to the original hierarchy doesn't seem to be getting run 4) -ivh 3.1.0.3 of the rpm 5) The files under the original hierarchy become present. It seems that my %post is getting run
It seems like %post is only happening on -ivh, not on -Uvh, even though the maximum rpm book says that -Uvh is basically just a -e and -ivh.
Has anyone seen anything like this before? Is there a fix?
rpm -U is not the same as rpm -e and rpm -i.
That is what's done with -U:
* Run %pre of new package * Install new files * Run %post of new package * Run %preun of old package * Delete any old files not overwritten by newer ones * Run %postun of old package
Wolfgang is correct. In your %preun and/or %postun, you need to check the value of $1 to determine if rpm was called with -e or -U. This is a good resource: http://www.ibm.com/developerworks/library/l-rpm3.html
Thanks folks, this is really informative.
One of our rpm's needs (sort of :) to be able to replace some files in /etc. Rather than have two rpm's owning the same files, I chose (based on input from this list) to make this rpm put the files in /susev3_etc, and then have a %post copy the files from /susev3_etc to /etc. This was done because having two rpm's owning the same file yields undefined behavior.
But we have systems in the field that still have files going directly into /etc from an rpm of the same name but older versions.
I now suspect that what's happening is, when going from an old version of this rpm to a contemporary version: 1) the new rpm's files are installed 2) the new rpm copies from /susev3_etc to /etc 3) the old rpm's files are installed, _taking_the_copies_under_/etc_from_/susev3_etc_with_them_
...and I further suspect that once we get all our systems moved to the new /susev3_etc way of getting files under /etc, that these /etc files won't disappear anymore. It seems like it's just when moving from the old way of handling /etc to the new way, that we lose these /etc files - not when moving from a new-way rpm to a newer new-way rpm. But I haven't tested that.
I wonder if I could have this rpm "foo" use a "%triggerun -- foo" scriptlet so that I get a chance to put back those files when the old version of the rpm is deleted. It appears that triggers are usually done to catch when some _other _rpm is uninstalled (for example) - I'd be using it for when some other version of the _same_ rpm is uninstalled.
Comments?
I've had to resort to that exact solution once before. Use %triggerpostun instead of %triggerun. ("%triggerpostun -- foo" in foo.spec). Since %preun and %postun of the old package run after %pre and %post of the new package, it's really the only way to compensate for a bad %preun or %postun script that is already out in the wild. You'll probably want to add a version: "%triggerpostun -- foo < [the new version]" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org