[lsb-discuss] Packaging

Michael Sweet 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
>> trap.
> 
> 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
user directories.

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
directory...

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
overkill...

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 mailing list