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
|