[lsb-discuss] Packaging

[Michael Sweet]

I got an email from Michael Leibowitz pointing out the packaging
discussion here.  My apologies for the length of this post...

Some background: I'm an ISV and packaging software developer.  My
company has been producing cross-platform software (read: all of the
commercial UNIX's, *BSD for a short time, Linux, Mac OS X, and
Windows) for a little over 12 years now.  Some of you may have even
heard of or used my EPM software (http://www.easysw.com/epm/) to make
software packages.


THE ISV VIEW
------------

 From an ISV perspective, we've had a long (and sometimes painful! :)
education in packaging software for all of these operating systems.
The #1 problem has been with shared libraries, namely that you a)
have to be careful about which libraries you depend on, and b) some
vendors are not careful about maintaining ABI compatibility between
OS releases.  In the distant past we had problems on Solaris with
Motif and CDE compatibility issues, and more recently we've had to
deal with changes to the C++ ABI and various support libraries on
Linux - DBUS, libpng, and openssl are good examples of this.

In most cases, our solution has been to avoid using any shared
libraries we can't depend on and statically link in the bits we
need.  Aside from the wasted disk space and memory, this also means
that we need to quickly release updates whenever a security issue is
found in one of the libraries we use.  Clearly this is not an optimal
solution...

Long-term, we'd like to see a larger core set of LSB APIs.  IMHO, the
LSB can adopt more standard APIs from the pool of generally-available
open source libraries on Linux to make things easier for core and
desktop apps, specifically:

     ALSA (Desktop)
     Cairo (Desktop)
     SDL (Desktop)
     OpenSSL (Core)
     Xft (Desktop)
     Xinerama (Desktop)

ALSA and SDL are big for games, Cairo and Xft for third-party
toolkits (like FLTK), and Xinerama is useful for applications that
need to know about the screen configuration (games, presentation
apps, etc.)  All of these are included on the various desktop
Linux distributions already.

In addition, it would be really useful to work with some of the
emerging standards (DBUS, Portland, etc.) with the focus being
guidance on developing stable APIs that can be extended in the
future without breaking ABI compatibility.  This need not be a one-
on-one relationship, but could be managed with a Wiki on best
practices and a mailing list for developers to get advice from
other developers specifically on API design.

In short, as an ISV I want stability and enough APIs to support the
kind of apps I may distribute.  And I want to distribute binaries
because most of my customers don't know how to compile their own
software or don't want to because they are busy doing their own
stuff.  The current LSB (3.1) is really close...


THE SOFTWARE PACKAGING VIEW
---------------------------

There are three basic kinds of packages we are concerned with:

     1. System-wide packages that are installed once and shared
        by all users on the system; this is by far the most
        prevalent use case for a business or home environment,
        and is what I recommend to our EPM customers when they
        developing packages for complex software.

     2. Local packages that are installed in a user's home
        directory; you'll see this sometimes for plug-ins and
        applications like Firefox and OpenOffice, and is useful
        for trying out a program before installing it system-wide.
        I see this most on shared systems where the user does not
        have administrative privileges...

     3. Self-contained applications; these are programs that are
        distributed as-is (just the executable) or in an archive
        or "disk image" that can be downloaded and run without an
        installer.  This type of package or distribution is great
        for demos, games, etc. where installation is not required.

For #1, I don't think installer technology is a real problem on
Linux.  ISVs have plenty of choices, and quite frankly I think that
requiring RPM support and adopting a GUI installer API (a la
Portland) that accepts a list of RPMs or a directory and allows the
user to do installs is all the LSB needs to do to support system-
wide installs.

For #2, a variation of the system-wide install standard might work.
Locally-installed applications could be placed in a ~/.apps directory
(which would have the full usr, var, etc. directory structure), and
RPM could be updated to have a user install mode that set the install
prefix to the user's home directory (~/.apps or whatever) and use
both the system-wide and user RPM databases to resolve dependencies.
Administrators could the find the user-installed packages simply by
looking at the RPM databases in each home directory, probably with
assistance from RPM or some other support GUI.  The trickiest part
would probably be in the applications themselves - they'd need to
handle being installed in different directories...

For #3, klik and other similar tools are promising.  Dependencies
should be limited to bundled or LSB libraries.  The Mac OS X
model is also worth looking at...

On Mac OS X, applications are placed in bundles.  Bundles contain
all of the resources (including the executable, icon, meta data,
application shared libraries, message catalogs, data files, etc.)
needed to run them, and the Finder (essentially the window manager
and file browser for those of you not familiar with Mac OS X)
handles running these applications and setting up the shared library
paths, displaying the appropriate icons, and so forth.  Applications
use Apple-supplied APIs to find their resource directory, thus they
can access their data files no matter where they are located.

This design has led to the common package format often just being
a disk image (think compressed ISO file) which can be downloaded
and opened (often automatically by the web browser) allowing the
user to double-click on the application to run it, drag the icon to
the user's Applications folder to do a user mode install, or drag the
icon to the system Application fold to do a system-wide install.

Icons and file associations specified in the bundle are "installed"
in the user's home directory (~/Library/Preferences) when these
applications are run the first time.  This then allows the user to
open document files without running the application first, e.g. run
Gimp and you can then double-click on XCF files to open them...

This method is not suitable for all types of applications, but
certainly for *desktop* applications it has the potential to
dramatically change how users work on Linux.  Klik is conceptually
similar, but I think we need a broader approach on the LSB desktop
so that applications don't depend on optional OS features and so that
the desktop environment is updated as needed (icons, file type
associations, etc.)

I don't know whether this kind of application delivery needs to be
standardized by the LSB, or if it is a job for the Freedesktop folks,
or maybe some combination.  However, I think we'll see more desktop
apps on Linux once we make it easier to provide desktop apps for
Linux.

In short, installers should only be used for complex or "core"
software components.  Ordinary applications should be usable without
an installer, and should integrate cleanly with the desktop upon their
first use.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com