70 packages on SqueakMap!

Daniel Vainsencher danielv at netvision.net.il
Sun Dec 1 16:33:39 UTC 2002


I think I see what you mean. Let's see if I do:
There's a conflict between expecting the services architecture to
provide you with the correct installer for each package automatically,
and between using any external dependency mechanism to represent this
dependency.

I think a good enough solution is - 
1. The services architecture will not cause installation of anything,
but it will help expose any packages to all services already installed
in the image.
2. One of those services might use SqueakMap categories to find
appropriate installers, and offer that option (example later).

Example:
I want to install the RB package. It has the category PackageType\SAR.
All the SM services I have installed come forth and decide that they
cannot install SARs, because none of them is SARInstaller. However, one
of them is the Meta Installer (tm), and it detects that there's a
package in SM that has the category PackageService\Installer\SAR (which
happens to be called SARInstaller), and so offers to "install
SARInstaller" on the menu. After the user chooses that, he now has
SARInstaller, and will be able to install the RB.

This takes care of the light weight scenario, where it should be
straight forward for the user to install simple single packages, and
would solve our current problem. 

Another scenario is the image configuration scenario, and I see nothing
wrong in it loading first some installers, and then the needed packages.

Daniel Vainsencher


goran.hultgren at bluefish.se wrote:
> 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