70 packages on SqueakMap!

Julian Fitzell julian at beta4.com
Sun Dec 1 19:01:00 UTC 2002


Daniel,

Are you suggesting this only for installers or for all dependencies? 
I'd hate to have to manually install the dependencies for a package. 
You might easily have a few levels of depth in your dependencies.

Julian

Daniel Vainsencher wrote:
> 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
> 
> 


-- 
julian at beta4.com
Beta4 Productions (http://www.beta4.com)




More information about the Squeak-dev mailing list