Re: Binary relocatability

Thanks for all these helpful replies by the way :)

> The LSB, like many good standards bodies, has tended to codify
> existing practice, not invent stuff.  IMHO the thing to do is
> just get out there and get people to fix apps to be relocatable
> at install time.  (Montavista has been doing this to the gnu
> tools, I think.)  Once there's some momentum, then the LSB can
> consider requiring all packages to be relocatable, or something like that.

Yeah, I'm aware of that. However as part of the packaging effort,
inventing stuff is now allowed :)

The main problem is a catch 22 one. Given the lack of any widely
accepted API for doing this stuff, it'd be easier to get buy in if it
was given the seal of approval by a recognised authority. That doesn't
mean standardised, it just means "the LSB thinks this API is a good
idea" type agreement.

One other problem is obviously, how do you know what the prefix actually
is? We're looking it up in a database, but how does an app know if it
was installed via rpm/deb/emerge/autopackage/foo-installer, and how can
we abstract this information?

Is building such a library even a good idea? Maybe this would be better
addressed at a lower level, maybe setting an environment variable or
something when a file is executed, so bypassing package managers
entirely.

> BTW, there has been some talk about relocation on the RPM list
> lately.  It seems rpm's package relocation stuff was broken
> until recently.  Since the rpm crowd is starting to get
> relocation religion, maybe that's a place to start.
> You could e.g. get rpmfind.net to list the relocatability
> of each package in their list and/or start a Hall of Shame
> for nonrelocatable packages :-)

Thanks, I'll go investigate that :)
-mike