[EROS-Arch] Installers

[Constantine Plotnikov]

----- Original Message -----
From: "Jonathan S. Shapiro" <shap@eros-os.org>
To: <eros-arch@eros-os.org>
Sent: Sunday, March 25, 2001 10:29 PM
Subject: Re: [EROS-Arch] Installers


> 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?
>
J2EE-like resource descriptors could provide an way here.
Application provide an description of namespace that
should be passed to it. Description could be passed as
XML file.

Namespace descriptor consists from resource descriptors.
Resource descriptor has name, class of interfaces and
set of properties for interfaces.

Value of property may be string, integer or other resource
that is described in that directory. These properties are set
at installation time and could not be changed by application.
During installation the namespace descriptor is implemented.

Critical interfaces could be marked by extenstion some marker
interfaces.

Application could provide an output namespace that is created
during installation. The contents of that name space is descibed
in resource descriptor and created from resources supplied
during installation.

Similar process is for user installation. User installation
uses output namspace of main installation and per user
resource descriptor to create runnable code. User could
link capabilities from output namespace to other places.

Running instance is invocation of some capability that have
been put to output directory during user installation.

ctx.lookup("Quake8")<-run(desktop3d);

BTW There could be something like getopt description that
specify translation of command line parameter to capabilities
for sytem that runs above untrusted systems like E. For example
command line configuration file for C compiler could be like
following:

<command_line name="cc">
  <parameter name="o" description="output executable file">
     <resource interface="system.io.FileOutputStreamFactory">
        <property name="use_once">true</property>
        <property name="ifExists">replace</property>
        <property name="ifNotExists">create</property>
     </resource>
  </parameter>
  <parameter name="-W" description="generate warnings">
     <resource interface="system.Boolean/>
  </parameter>
  <parameter name="-L" description="warnings level">
     <resource interface="system.Int32/>
  </parameter>
  <parameter name="i" description="input file set">
     <resource interface="system.io.FileSet>
         <property name="restriction">
            <resource interface="system.io.FileInputStreamFactory">
              <property name="use_once">true</property>
              <property name="provide_name">true</property> <!-- makes name
of file avaialble from  that binding -->
         </property>
    </resource>
  </parameter>
<command_line>

Then c compiler could be invoked as following.

cc -i fileset(*.c, read|name) -o file

Constantine