[E-Lang] Thoughts on Installers

[Wesley Felter]

I've done a lot of thinking about installers, but nobody ever seemed to
care so I didn't write it down. Until now.

One ideal wrt installation is to put each application in a single file or
at most a single folder, so that "installing" it is merely a matter of
unpacking an archive and copying the result to anywhere that the user
deems convenient. See many Mac and BeOS apps (and Mojo Nation for Linux)
for examples. Unfortunately this won't help you if the app depends on
some component that isn't included in the base OS unless you include a
copy of all (transitively) dependent components with every app (which MS
seems to be planning to do to solve their DLL Hell problems).

So if we want to save disk space and (perhaps more importantly) resident
memory, we need some solution for managing dependencies between components
(where I consider an app just another component that nothing else depends
on). Installers are one way to do this, but not the best way. Besides the
obvious security yuckiness of not being able to install a component
without essentially giving unlimited priviledge to the chunk of foreign
code that guards it (its installer), installers are a waste of bandwidth
(because almost everyone uses one of a small number of brands of
meta-installers, which insert essentially the same biolerplate code in
every installer). Yet another problem is that it seems hopeless to
maintain any reasonable policy if it is enforced piecemeal by each
installer instead of at some central point. (e.g. On a Windows system it
is almost impossible to maintain a policy as simple as "don't overwrite a
DLL with an older version of itself", because the only way to maintain
such a policy would require *every* installer to abide by it, and the
people who write these installers just don't care.)

That situation leaves us with a single installer that comes bundled with
the OS, is mostly trusted by users, and installs declaratively packaged
components. I suppose on this list I do not need to make the arguments for
enforcing policies in one place. The Linux distributions are the leaders
in this area with tools like RPM, Apt, and Red Carpet, although I still
find some aspects lacking. For example, pervasive Unix assumptions about
"globalness" (for lack of a better expression) are present in these tools,
which in many cases will only run as root, will only install each package
in one place (e.g. /usr, but not /home/wmf), and assume that all users
see the same view of what components are installed. This is a real
problem, because I have yet to find a way to install anything nontrivial
on my Unix account at school without involving the local BOFHs.

Perhaps a better place to look for ideas about installation in capability
systems is the new QNX installer that uses Plan 9-like local namespace
features.

http://qdn.qnx.com/articles/jan1101/fs-pkg.html
http://qdn.qnx.com/articles/feb0201/index.html

Wesley Felter - wesley@felter.org - http://felter.org/wesley/