mike at easysw.com
Fri Oct 27 08:27:20 PDT 2006
Fabian Groffen wrote:
> On 27-10-2006 10:12:26 -0400, Michael Sweet wrote:
>> 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
> If you don't want to crash your system, you better not touch
> LD_LIBRARY_PATH, DYLD_LYBRARY_PATH, SHLB_LIBS, etc.
There is certainly the potential for this, but LD_LIBRARY_PATH can
be initialized to look in the system directories first, then the
Regardless, setting LD_LIBRARY_PATH will not crash the system, it
just may interfere with a user login session. To allow recovery,
a "failsafe" login session should not set LD_LIBRARY_PATH, nor
should a root login.
>> FWIW, the Mozilla and OpenOffice.org apps have a long history of
>> using LD_LIBRARY_PATH on Linux and other OS's...
> They wrap it in scripts which is way more controlled than setting it
> global. Also including the system library paths before the offset ones
> is not an option, because the sole purpose of the offset usually is to
> override those of the host system.
> Food for thoughts?
Well, there are two separate issues:
1. How to get applications to use the user-installed shared
libraries, when necessary.
2. How to handle conflicts between system-installed and user-
installed shared libraries.
For #1, I think LD_LIBRARY_PATH is sufficient, already supported,
and similar to how Mac OS X sets its DYLD_* environment variables
when running an application bundle.
For #2, I think the issue primarily affects standard system libraries
like your jpeg library example. Disallowing user installation of
LSB-defined libraries is certainly one way to handle this, although
that might make the user package manager very complicated...
If we focus on user applications and not user-installed system
services like CUPS, X11, etc., an alternative would be to
standardize on an application directory structure like Apple
does for application bundles. Something like this:
/opt/foo - Application root (Prefix: is /opt)
/opt/foo/applications - Application .desktop files
/opt/foo/bin - Binaries
/opt/foo/etc - Configuration files
/opt/foo/icons - Icon images (in subdirs)
/opt/foo/lib - Libraries
/opt/foo/mimelnk - File type .desktop files
/opt/foo/share - Data files
/opt/foo/*.app - Wrapper script that sets LD_LIBRARY_PATH
and runs binary in the bin subdir.
The *.app files can be a very simple (and common) script and will
allow direct usage from the command-line. We could use .app
directories like Apple, but you'd need a separate command to
"open" .app directories and be limited to 1 application per
The desktop environment can have a MIME type for *.app files which
knows to register the /opt/foo/applications, /opt/foo/icons, and
/opt/foo/mimelnk files (probably via symlinking) when the user
first runs the application or when using a standard "install
app" Portland API.
The advantage of this approach is that user/application packages
could be provided as archives (tar.gz, tar.bz2, zip, etc.), mountable
disk images (.iso), and/or (relocatable) RPM packages as desired.
Since removal of the application package would amount to deleting
the directory, the use of RPM for this case would seem to be
I guess it comes down to defining what we want user installable
packages for - just self-contained applications, or ???
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