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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
