[EROS-Arch] Installers

[Joerg Bornschein]

On Sun, Mar 25, 2001 at 10:29:07AM -0500, Jonathan S. Shapiro wrote:

Hello,

> 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.

To me it seems a) and d) are talking about exactly the same procedure: finding
constructors which provide a needed service: resolving dependencies.

Why should there be a distinction between "base system software" and
"additional software" at dependency resolution time? 

> 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".

I dont think is is necessary to have executable installers:

I assume by "pickled" image you think of a data page containig the code segment
and maybe some metadata. This way one can be sure there are no holes...

Now lets assume we are talking about easy installable software, so there
are no exceptional capabilities handled to this software's installer -- just
a capability to available system-software/"libraries".
In this case the executable installer isn't necessary; obviously it
can be replaced by a system wide installer interpreting 
 "i want a capability to a factory X in my constituents slot Y"

If the installation procedure is more complex, that means the executable
installer needs exceptional capabilities, IMHO it should be handled 
exactly like any other application. In fact, is *is* a application.

So it seems we are forced to implement two application startup proceures:
 - One for normal, already installed appliations. 
 - a second one implementing the same features but specialized to 
   installation constructors.

IMHO not very clever.

> 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.

So why allow executable installers in step 1)? If theres something more complex
than "put cap. for factory X in my constituents slot Y" to do, it should be
done by this configuration application in step 2.


  joerg

-- 
 The known is finite; the unknown infinite.    Intellectually we stand on 
  an islet in the midst of an illimitable ocean of inexplicability. Our
  business in every generation is to reclaim a little more land..
 						    	     --T.H. Huxley