[users] relocateable packages

[Jeff Johnson]

On May 30, 2007, at 10:35 AM, Neal A. Lucier wrote:

> I'm a little new to rpm and the various repositories out there for  
> RHEL as I have historically been a Solaris admin.  The two repos I  
> have used extensively are Fink and Blastwave.  Both of these repos  
> build packages that install with a prefix other than "/"; /sw, and / 
> opt/csw/ respectively.  This feature is extremely useful as I only  
> install repos on the file server and share them via NFS.
>
> From the following two URLs I have gleaned that even if packages  
> are created with a prefix of "/" I should be able relocate them (if  
> they are relocatable).
>
> http://www.rpm.org/max-rpm/s1-rpm-install-additional- 
> options.html#S2-RPM-INSTALL-PREFIX
>
> http://www.wideopen.com/archives/rpm-list/2001-December/msg00012.html
>
> Which leads me to my question:  Are all the rpmforge packages  
> created as relocateable packages?  And if yes, is there an  
> automated way to make all rpm's installed via yum, apt, etc.  
> relocate to say /opt/rpmforge?
>
> I only examined the package kile-1.8-2.el4.rf.x86_64.rpm and it  
> appears to not be relocateable.
>

All full paths in all packages since rpm-3.0 have been relocateable  
using
(possibly multiple times)
     --relocate /old/path=/new/path

All that Prefix: (and there can be multiple Prefix:'s since rpm-3.0)
does is signify that certain paths are known to be relocateable.

The issue is that rpm makes no attempt to relocate within content,
will only relocate the path itself. So if you have a config file that
mentions a path, and you relocate the path, then the program
*will* break.

The Prefix: tag in spec files is used to signify that there are no  
problems with
relocating a path, automagically disabling a error check.

If you are going to relocate any/all paths in packages, watchout for  
paths mentioned
within content (as I described). You will also need to add --badreloc

Also watchout for upgrades. Relocated packages must be upgraded with  
--relocate,
there is no "stickiness" (i.e. persistence) to remember and  
automagically
reapply the arguments on upgrade.

There is no autorelocate mechanism for yum that I'm aware of, mainly  
because
of the lack of "stickiness" of a previously applied relocate option.

hth

73 de Jeff