Thanks for your response Scot, that clears up quite a bit. It sounds like it is indeed a *mild* oversight based on your response. Cleary if the product supports relocation in the first release of the product, it's very highly likely that the following versions will support the same relocation. Yes, not all files need be relocatable -- and that's covered easily by having the beginning of their path not match the designated Prefix. (Or perhaps there's a more official way, I don't know.) It seems a easy improvement to RPM would be to at least to have a --repeat-reloc or somesuch if using -U or -F. -bc > I was a bit surprised to find out that rpm -U doesn't know if the > previous version of the RPM had been relocated, i.e., w/o using > a --prefix on the -U it will be installed according to its > internal Prefix: instead of relocated to where the previous RPM > was installed to. > > Is this just a gross oversight? Or was it intentional for some > reason? Its not a gross oversight, think about it...You are upgrading a peice of software, the new location might be important to the software working properly. RPM has no way of knowing whether stuff will work in another prefix or whether paths are hard paths. Sometimes the software is relocatable but a configuration file or two is not, there are several reasons why an RPM should be installed in the default location by default, you can always override it if you wish the same way you overrode the original installation. If the software is relocatable, then the software packager will likely make it relocatable, if its not then likely the packager will not make it relocatable. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
