[EROS-Arch] Installers

[Jonathan S. Shapiro]

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

Only for the following reasons:

1. You want to have a "standard" set of software that you know is present,
and you want to know that if you build your tools to this software it will
be guaranteed to install.

2. You don't want to pollute that namespace, for the same reason that you
don't want to pollute any other centrally administered namespaces.

A hierarchical namespace would work here, but I think it's better to have
seperate capabilities for separate namespaces. We're teetering on the edge
of the same problem that Java class names have, and no solution leaps out at
me.

>  I dont think is is necessary to have executable installers.

The software has to initialize some time. The issue here isn't the need to
bind to standard stuff. It's the need for the software to perform enough
initialization to be ready to run.

I agree that you don't need to execute the software to achieve binding
(though it simplifies things if you do), but the point is that given
confinement there is no reason *not* to allow active installation.

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

Yes, but other applications routinely get to run startup code. Why should
newly installed code be any different?

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

No no. Installation constructors require no special privelege at all.

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

There is a scoping problem here. There may exist initialization that needs
to be done per-machine rather than per-user. Your design precludes such
initialization.