[EROS-Arch] Installers

[Jonathan S. Shapiro]

First, I'm really glad to see the discussion on installers. It will soon be
apropos.

I think that part of the confusion is coming from the fact that we haven't
said what an installer does or articulated a model for the installation
process. Let me try to do that in rough form and then address some of the
issues that have come up here.

Installation proceeds in several phases, some of which may be skipped:

    1. Installing the software on a machine
    2. Customizing the software to a
       particular user
    3. Instantiating copies of the software
       to run (executing the code).

I have probably missed some.

The input to phase (1) is:

a) A directory of universally available constructors for common objects.
These objects can be thought of as the "base system software" on top of
which our new program is to be installed.
b) A list of additional ("somestring", some-capability) pairs authorized via
the installation tool by the system administrator. These are the exceptional
authorities that need to be explicitly authorized.
c) a certain amount of space
d) possibly, a set of (name, capability) pairs for previously installed
software (this is where dependencies come in, similar to RPM). I haven't
thought this part out, and I think it can be treated as a separate problem
from the rest.

Phase 1 should of course be turing complete as follows: what you load off of
the installation image is a "pickled" image to be installed into a
constructor. The constructor is built with this initial image, is handed any
exceptional capabilities, and is invoked *once* by the installer. It's yield
should be a capability that should be installed in some "directory of
installed software".

In many cases, that last capability that is yielded is a capability to the
constructor that individuals will invoke to customize the program for
personal use.

Phase 2 behaves similarly, but this time it is the user who provides
per-user authorities (if needed) to a confined subsystem produced in phase
1. The yield of this is yet another capability that the user can use to
instantiate new instances of the program.

Phase 3 is the one used to actually instantiate programs.

Note that by clever arrangement, phases (2) and (3) can be combined into
"install on first execute".

Also note that the entire process described above essentially mirrors the
way an EROS system image is built now. This isn't entirely an accident.


I think that the critical questions here are ones of categorization. How
should "special" capabilities be cataloged in a way that the human doing the
installation can readily find them and enable or disable them? Into what
namespace should newly installed programs go? To what degree should
dependency evaluation (program A depends on program B) be automated, and
which namespaces need to be known to the installer in order for this to
work?