So would it make sense to create a patch that allowed rpm{,5} to be
installed into any random location and then it can just discover it's
path and work properly from there?  (I have some experience with this.)

The two issues are loading the shared libraries properly as well as the
rpmpopt file.  In the past I've dealt with the first by either
statically compiling RPM, or adding a small shell wrapper that discovers
it's path and setups LD_LIBRARY_PATH appropriately.

--Mark

Jeff Johnson wrote:
> 
> On May 27, 2007, at 5:22 AM, Ralf S. Engelschall wrote:
> 
>> On Sat, May 26, 2007, Jeff Johnson wrote:
>>
>>>  (from a #rpm conversation with rsc)
>>>
>>>  One very easy way to prepare drop-in parallel rpm packaging on
>>>  all platforms is to add "5" after all path collisions.
>>>
>>>  So
>>>      /usr/include/rpm5
>>>      /usr/lib/rpm5
>>>      /bin/rpm5
>>>      /usr/bin/rpmbuild5
>>>      /etc/rpm5
>>>  to name the most significant path collisions (libraries already have
>>> *-4.5*
>>>  instead).
>>
>> Sorry if I'm too heretic here, but that's IMHO just the hard-coded POV
>> of a usual Linux distribution where everything is merged together into
>> the same namespace starting at /.
>>
> ;-) You're no heretic.
> 
> I see the problem as giving the consumer what they want rather
> than explaining why something else is better.
> 
> In this case, linux people are used to everything merged together.
> 
> OTOH, the Mac OS X case is different for rpm because users wish
> autonomous prefix-based installations like /opt/local and /sw.
> 
> My answer for Mac OS X is likely a bit heretical as well. For a system
> wide installer like rpm to be effective, there must be a common
> shared database, and the path to the database doesn't really
> fit into a prefix based, executable/development path model.
> 
> So on Mac OS X I plan to stake a claim on the currently unused
> real estate of /bin/rpm and /var/lib/rpm; i.e. no prefix.
>