[opensuse-packaging] -Uvh different from -e followed by -ivh?
I have an rpm to maintain. Because it used to have some files that were owned by more than one package, I changed it so that the files would be installed under a second hierarchy, and copied to the original hierarchy via %post. 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? Thanks! --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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 I guess that is causing the behaviour you see? I don't understand what you are trying to do though. Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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
On 2008-01-24 11:04:21 -0700, Bart Whiteley wrote:
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]"
ugh really. using rpms for modifying configs from other packages is _wrong_. we got so many nice tools for automatic deploy: - kiwi - autoyast - systeminstaller no need to abuse rpm for that. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, Jan 24, 2008 at 09:27:32AM -0800, Dan Stromberg wrote:
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.
Hmm, IMHO it's not undefined but "last one wins". And having the filed shared in rpm seems to be the cleanest solution to me. What file in /etc are you talking about? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Michael Schroeder wrote:
On Thu, Jan 24, 2008 at 09:27:32AM -0800, Dan Stromberg wrote:
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.
Hmm, IMHO it's not undefined but "last one wins". And having the filed shared in rpm seems to be the cleanest solution to me.
Last one removed wins, or last one still on the system wins? Whether there's undefined behavior or not, needing to specify --replacefiles was not ideal.
What file in /etc are you talking about?
bash.bashrc, inittab, ssh config files, ntp.conf, securetty, security/limits.conf, sysctl.conf, sudoers, perhaps others. Needless to say, we don't want bad things to happen to these files. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, Jan 25, 2008 at 09:07:45AM -0800, Dan Stromberg wrote:
Hmm, IMHO it's not undefined but "last one wins". And having the filed shared in rpm seems to be the cleanest solution to me.
Last one removed wins, or last one still on the system wins?
Last installed wins. Files don't get removed if they are shared with other rpms.
Whether there's undefined behavior or not, needing to specify --replacefiles was not ideal.
Yeah, that's true. Hmm, maybe you can %ghost the file so that rpm knows it is shared and change it in the %post section. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Michael Schroeder wrote:
On Fri, Jan 25, 2008 at 09:07:45AM -0800, Dan Stromberg wrote
Whether there's undefined behavior or not, needing to specify --replacefiles was not ideal.
Yeah, that's true. Hmm, maybe you can %ghost the file so that rpm knows it is shared and change it in the %post section.
This is the first I'd heard of the %ghost directive. It's interesting, but I'm not sure it's what we are looking for in this case. It's sounds good for files that need to be cleaned up but don't have any particular initial value (like log files), but we have something that's kind of the reverse: We have files with particular initial values that we want to be careful Not to clean up, at least not unless the relevant OS rpm is removed. It seems like what we want is a %post that just copies the files from one place to another. Hmmmm... Now what'd be cool... We have a workaround for adding back files that are cleaned up that shouldn't have been (by extracting the %post and piping it into sh), but that workaround requires people to know they're going from an old style rpm (with the double ownerships) to a new style rpm (with a copy from %post) - what might be nicer is if there's a way of "adjusting" the rpm database to think that an rpm no longer owns a file? That might help us get through this transition a little more proactively, since we have access to all the machines the old rpm's are installed on. Does anyone know a way of taking an rpm database that has n files that are owned by 2n rpms, and changing the rpm database so that the n files are owned by just n rpms? (assuming you know which rpms should keep the files, and which rpms should give them up?) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (5)
-
Bart Whiteley -
Dan Stromberg -
Marcus Rueckert -
Michael Schroeder -
Wolfgang Rosenauer