Articles / Application Directories

Application Directories

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.

What directories are for

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:

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

Now try these two:

  1. I want to delete all binaries from my system, but leave the info pages.
  2. 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"?

Introducing self-contained applications

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:

  1. I moved the binary out of the System directory, and did a "make clean" in the "src" directory (to save space).
  2. I dragged System to the archiver to create the source archive.

Here's how I made the Linux-x86 binary release:

  1. I moved the "src" directory out of System and stripped the binary (both just to make the archive smaller).
  2. 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:

  1. I clicked on the Load.tgz file to extract it. The "Load" application appeared, complete with its own little icon.
  2. 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.

Conclusion

To summarize the advantages of application directories:

  1. You can use the same actions to run an application, whether it's a binary or a source archive.
  2. 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.
  3. 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.
  4. 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!

If you want to see application directories in action, take a look at ROX-Filer.

Recent comments

04 Jul 2004 12:39 Avatar jcast

Re: A folder hierarchy suggestion


>

> % IMHO, final users (=parents) shouldn't

> have to build

> % applications, but they should be able

> to install

> % binary packages. These packages should

> be easy

> % to install and uninstall without

> getting the system

> % filled with unused files from previous

> installs.

> % Furthermore, the

> "curious-but-not-geek" user

> % should be able to find everything

> (doc, binaries,data) about

> % an application easily.

> Absolutely :-)> I like the idea of

> application folders but don't want to

> > bloat the PATH variable.Don't worry

> - they don't.

> bash will find the app directory in PATH

> just as if it was

> an executable. Then, discovering that

> it's a directory, it runs the

> AppRun file inside it. Assuming bash

> supported them...

And you think bash is the only place PATH variables (note the plural!) are used? You have to modify bash, tcsh, ksh, python, perl, and execp, but also things like ld.so, gcc, cpp, man, info, whatever other documentation systems we come up with, autoconf (yeah, I know, databases will make autoconf obsolete, I'll believe that when every Windows program in existence cleans the registry on uninstall), emacs, python, perl (perl actually has a couple of PATH-likes of its own), web2c (which has an entire program kpathsea to search for texmf files (lucky you, imagine having to modify TeX, Metafont, and Metapost separately)). Also, the locale library supports (according to man 5 environ) a couple of environment variables which may be PATH-likes but aren't documented in man 5 locale, and I'm sure there are other examples I can't find. Changing bash alone is not going to solve your problems with PATH.

19 Jun 2001 12:21 Avatar Meatpopsicle

Re: A newbies perspective

> I like this idea.
>
> First I must say that I am a Windows
> user by default (sorry), and I only

I know this probably sounds really dumb at first, but why doesn't *nix have a registry? How hard would it be to use Postgress or mySQL for a database of all application entries -- then you could have an actual path and a "common path" mapping

-- this would solve the problem with RH always putting things wherever it dang well pleases instead of in the path that every other version of *nix uses.

--this would also end the age old debate of /bin/gimp vs. gimp/bin because it wouldn't matter - the system would look for gimp in the database and find the real path, and if I typed /bin/gimp in a telnet session, the system would be smart enough to say "oh, on this sytem that's really at /gimp/bin" or vice-versa

--this would also make things much easier for large software developers that need to program install/uninstall scripts. Instead of seaching in n! places for a lib or mod, simply run a query against the database -- "does this system have c++ headers?" | select _location from _headers where _application ='c++'

The really nice part about this scheme would be that for _every_ task, you simply run a query - whether it's finding _where_ something is, or if it exists, or what version it is, or if it has it's source code installed or not, etc, etc, etc -- no matter what, you're just running queries. this could potentially be a good thing

--would this really be that hard to do? Can we afford NOT to do it?

19 May 2001 05:57 Avatar dalen

Re: umm

> I'm confortable with the /bin, /sbin,
> /usr/bin, /usr/sbin scheme. Users who
> can't cope with that should go use
> Windows and BeOS or something. There is
> GNU Stow which does what you're saying.
> I'm using instmon && installwatch to
> install/remove source packages. We
> shouldn't complicate the
> compilation/install procedure more as
> it's already overcomplicated

Well, this wouldn't complicate the install procedure. It would simplify the install procedure. You'd just have to move the app directory into the directory containing all your apps. That's why a newbie mac user can use MacOS X which also uses application directories.

17 May 2001 01:35 Avatar AbInitio

Re: Auto completion

> Ok, I want to start Gimp. So I enter
> gi<tab>, wait
> half an hour until bash has searched
> thru my
> harddrive until in finds all matching
> binaries and
> I can pick the right one.

Dunno what takes you so long. I got 47 entries in just short of 1/2 second (my guess). Sounds like time for you to add updatedb to your cron file, eh?

08 May 2001 23:08 Avatar atavus

Re: UNIX FAQ, Anyone?
Well, under linux you can look at /proc/pid/exe which is a symlink to the executable.

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.