mike at easysw.com
Fri Oct 27 07:12:26 PDT 2006
Wichmann, Mats D wrote:
>> OK, some questions for discussion, with my answers in-line:
>> 1. Do we continue using the RPM format for user installs?
>> Mike Sweet: I think so, the format supports relocation
> Supports, but for a variety of reasons, does not make
> it easy.
Right, the application must also support relocation, and IIRC RPM
allows you to specify whether the package may be relocated via the
Prefix tag. No prefix tag means the package is only system-
installable. The default is no prefix tag, so by default packages
are not relocatable.
> To begin with, it's not that easy to make a a relocatable
> package - we've seen a number of failures when people
> forget that there can be no hard-wired paths to other
> components of your software package.
I agree. The issue right now is not the application support for
finding where you've been installed, but rather how to support
user installs. Once we define how user installs are done (and
where things go), standardizing application access to user install
files should be easy to define and then applications can choose
if they want to support user installs.
> Most particularly, the fact that there is no way for a
> package to portably (well, in a standards-specified way)
> set things up to find new shared libraries, the use of
> rpath to point to application-supplied shared libraries
> is implicitly suggested; and this means those cannot
> easily be relocated at install time.
Actually, I'd suggest initializing LD_LIBRARY_PATH (on Linux anyways)
in the default login environment to point to the user install root.
That will cover all user installed library files and avoid the rpath
FWIW, the Mozilla and OpenOffice.org apps have a long history of
using LD_LIBRARY_PATH on Linux and other OS's...
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
More information about the lsb-discuss