Application Directories and an alternative system

Most software packages need to install a large number of files to work -- binaries, images, documentation, etc. Until now, this has been done by providing an install script (possibly in a Makefile or an RPM spec file) which puts each file in its correct location. If you're lucky, there may also be an uninstaller to get rid of them again. Both must be run as root, which is awkward and has security issues. In this article, I present an alternative system.

This system, which has already been used by a number of applications, is faster, easier (both for the user and the distributor), and doesn't require root access. It's also simpler, safer, and less error prone.

Directories are used to group files and allow them to be found and manipulated easily. A good directory structure will make common operations easier. I'd like you to look at the next two operations carefully, and decide which you think is more common:

I want some documentation in "man" format, but I don't know which package I need help with.
I want the documentation for the GIMP, but I don't know what format it's in.

Now try these two:

I want to delete all binaries from my system, but leave the info pages.
I want to delete all files belonging to Netscape, but leave other programs alone.
I'm guessing you answered (2) to both of those. So why do we have "bin/gimp" and not "gimp/bin"?

People seem to be aware that installing and uninstalling software is a problem, but the solution isn't ever-more-complicated package managers!

An application directory contains all the files needed by an application -- its help files (in a subdirectory called "Help"), an executable to run when the application is invoked ("AppRun") and, optionally, a graphical icon to represent it. (See the full details on this page).

The elegance of this scheme really came home to me when I tried to package System, a little program that shows a bar graph of processes and their memory usage. I'd created it as an application directory, and was running it myself by clicking on it in a filer window. I wanted to make source code and binaries available for other people.

I'd already had some experience of packaging with RPM -- you have to create a "spec" file containing instructions to unpack, compile, install, etc. -- a major headache! And then the Debian users complain that they want debs, so you need to make source RPMs and debs, plus both binary RPMs and debs for every platform. And then users without packaging systems want binary tarballs to "make install" -- a real nightmare!

Here's how I made the source release of System:

I moved the binary out of the System directory, and did a "make clean" in the "src" directory (to save space).
I dragged System to the archiver to create the source archive.
Here's how I made the Linux-x86 binary release:

I moved the "src" directory out of System and stripped the binary (both just to make the archive smaller).
I dragged System to the archiver to create the binary archive.
Wow. That was quite a lot easier!

When someone wants to use System, they extract the archive and click on the System icon which appears. The binary version will simply run; the source version will bring up an xterm and compile itself (the first time), and then run.

The ease of this scheme from the user's side didn't really affect me until I tried using an application provided by someone else. It was a little load monitor for the panel. Here's how I installed it:

I clicked on the Load.tgz file to extract it. The "Load" application appeared, complete with its own little icon.
I dragged it to the panel and it ran (there was a brief delay while it automatically compiled itself in an xterm).
Compare those instructions to "Open a terminal, cd to the right directory, run configure, run make, su to root, then do make install." If that still sounds pretty easy, imagine you're explaining this to your parents. If it still seems too easy, imagine they don't know the root password.

To summarize the advantages of application directories:

You can use the same actions to run an application, whether it's a binary or a source archive.
There's no need to run any scripts as root. This is much safer and allows users to install software themselves. It also means that the software admin doesn't need to be root to install software.
You can install software wherever you want (just move the directory) and install a new version of some software simply by putting it somewhere else or giving it a different name; there are no conflicts with shared files.
You can uninstall by deleting the directory. You know where it is because it's the thing you click on to run it. This is very useful if you don't use a package manager.
You may be worried about supporting multiple architectures. That's why we separate "bin" from "share", right? So we can mount them remotely, the correct directory for each platform?

With application directories, this is even easier! The AppRun file is usually a shell script which loads a binary for the current platform, compiling a new one if it's missing. So, just share the same application to every client machine, and it will pick the right binary when you run it!

I hope I've convinced you that application directories are an easy way to distribute software, and I eagerly await support from the various file managers and shells out there!