[EROS-Arch] Installers

[Joerg Bornschein]

On Mon, Mar 26, 2001 at 10:01:33PM -0500, Jonathan S. Shapiro wrote:

Hello,

> > Why should there be a distinction between "base system software" and
> > "additional software" at dependency resolution time?
> 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.

ACK -- that's IMHO a good point.


> >  I dont think is is necessary to have executable installers.
>
> [..]
> 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.

I'm not sure if it really simplifies things: It would be nice to 
inspect all dependencies without executing the installation constructor.
Just to be more informed about the software i'm going to install. Or, maybe
i don't even want to install it....(a software distribution server which
likes to know about the software it distributes; maybe different arch.)

Another reason: let's take the case where two versions of a constructor
somebody depends on are available. 
Should the installation constructor get access to both constructors and
decide on its own? I don't think so -- somebody or something more trusted 
(based on a policy -- e.g. "hand out latest compatible version") should 
do this.

In effect, the installation constructor gets exactly the capabilities
it needs to install into the new constructor. 

I agree that there is no reason not to allow active installation as long
as all relevant informtion are available without executing something
"foreign".
But in turn, at this point of the installation, i dont see any benefit
executable installers could provide.

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

Oh, maybe i did not express myself well: the application build in phase 1
could be a system wide configuration program which in turn builds 
constructors inteded for users. 

What i wanted to express: an initialization application, let it be per-user
or per-system, is a application. And there should be no exemptions just
because a application claims to be an "installer".

  joerg