70 packages on SqueakMap!

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Sun Dec 1 14:12:33 UTC 2002


Julian Fitzell <julian at beta4.com> wrote:
> goran.hultgren at bluefish.se wrote:
> > Julian Fitzell <julian at beta4.com> wrote:
> > [SNIP]
> > 
> >>I didn't say SqueakMap depended on SARInstaller.  I meant that packages 
> >>that are packaged as SARs depend on SARInstaller.  So when you try to 
> >>install a SAR package and don't have SARInstaller, it will get installed 
> >>first since it is a dependency.
> > 
> > 
> > Duh. Ok, sorry - didn't read careful enough. Yes, this would be neat.
> > But... hmmm. Interesting. It wouldn't work at all with the current
> > architecture - nor the one I am aiming for in 1.1. Hmmmm.
> 
> I'm curious why it doesn't work with what you're planning.  Isn't it 
> just a simple matter of giving the package a dependency on the 
> installer?  Presumably all the dependencies are installed prior to the 
> package itsself?
> 
> I'm guessing I'm missing something obvious.

Well, there are two issues at play here:

1. The service architecture for finding the "actions" that you can do
with a package. Today each subclass of SMInstaller is queried if it
would like to handle package x and the first one that says yes gets to
supply "download" and/or "install". So if you don't have the installer
already installed - how does it raise its hand and say "Yes, I can
handle this package!". The future architecture that I have started
fiddling with collects services from registered "package handler
objects" instead - the services can be anything and there may be
services from multiple handlers. Anyway, the problem is still the same.

2. When thinking more this is actually not a normal dependency. In the
planned SM 1.1+ people will register "package configurations" with the
dependencies for *using* package x. Not the dependencies for
*installing* it. I think these two things are different - for example -
the installer can easily be uninstalled after it has done its work - a
"normal" dependency can't be.

So, what do we do? Well, after thinking about 20 seconds I am not sure I
would like to use "normal" dependencies for this. And it does feel like
overkill to introduce some other dependency structure just to handle
installation. I think perhaps we should be a bit more strict when it
comes to "Package type" - perhaps making it mandatory. And given this we
could perhaps map to at least a default installer package. I am not
sure..

I need to get a new revision of SM out - if you have any bright ideas
regarding the above I am listening.

regards, Göran




More information about the Squeak-dev mailing list