Roel Wuyts roel.wuyts@iam.unibe.ch wrote:

Maybe I missed it in one of the threads, but was there a decision on including the SAR-thingie by default? I got questions from people that want to use the StarBrowser and claim it is not there (since you only see it after you installed the SAR-thingie).

Well, perhaps I could post a "load script" for SqueakMap called "SqueakMap" and rename the current SqueakMap package to "SqueakMap base" or something. Then that script would typically load "SqueakMap base" and the others too.

I will see what I can do.

regards, Göran

Julian Fitzell julian@beta4.com wrote:

goran.hultgren@bluefish.se wrote:

...

Roel Wuyts roel.wuyts@iam.unibe.ch wrote:

...

Maybe I missed it in one of the threads, but was there a decision on including the SAR-thingie by default? I got questions from people that want to use the StarBrowser and claim it is not there (since you only see it after you installed the SAR-thingie).

Well, perhaps I could post a "load script" for SqueakMap called "SqueakMap" and rename the current SqueakMap package to "SqueakMap base" or something. Then that script would typically load "SqueakMap base" and the others too.

I will see what I can do.

regards, Göran

Or just get dependencies working and then the package can depend on the SARInstaller, and the SARInstaller will get installed automatically, first.

Working on it! Did a whole lot of work yesterday evening etc. But... This is actually *not* a dependency. SqueakMap works fine without SARInstaller. :-)

It is more like a "good extra addon to make SqueakMap even better". "Load scripts" are fine for that I think. Especially since a "load script" can ask the user "Hey, do you want all the installers too?" etc.

regards, Göran

On Friday, November 29, 2002, at 11:55 AM, Julian Fitzell wrote:

goran.hultgren@bluefish.se wrote:

...

Julian Fitzell julian@beta4.com wrote:

...

Or just get dependencies working and then the package can depend on the SARInstaller, and the SARInstaller will get installed automatically, first.

Working on it! Did a whole lot of work yesterday evening etc. But... This is actually *not* a dependency. SqueakMap works fine without SARInstaller. :-)

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.

Right, that might be a good way to handle it once the dependency stuff is in place.

However, I'm guessing it will be a while before the dependency stuff is working, so in the meantime, I agree that it would be good to simply install the SARInstaller as part of the SqueakMap install. (Which I guess would be done with a load script as Goran described.)

There are a number of packages on SqueakMap now which expect SAR to be available, such as Roel's, and people are starting to submit [BUG] reports about this problem (see Ross Boylan's message), so perhaps Goran will be able to add this soon. :-)

- Doug Way

goran.hultgren@bluefish.se wrote:

Julian Fitzell julian@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.

...

...

It is more like a "good extra addon to make SqueakMap even better". "Load scripts" are fine for that I think. Especially since a "load script" can ask the user "Hey, do you want all the installers too?" etc.

Yeah, but I don't think you ever need to install all the installers, you just install the ones you depend on when you need them.

True. Need to think about this...

regards, Göran

goran.hultgren@bluefish.se wrote:

Julian Fitzell julian@beta4.com wrote:

...

goran.hultgren@bluefish.se wrote:

...

Julian Fitzell julian@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.

Well, my initial reaction is to say that if you install the prerequisites *before* asking for an installer for the specified package, then the installer would be there by the time you asked the question. That said, however...

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.

You're right, it does seem a little different. It's sort of an implicit dependency. I wasn't thinking you'd want to list it as a dependency manually, I was thinking that the system would automatically add it as a dependency only while calculating what to install.

It is also made more complex by the ability to have more than one installer handle the package.

Ok, well.... how about it you ask the system if there is an installer that can handle the package. If so, great. If not, you add an implicit dependency to the default installer defined for the package type (how we determine this is of course the key issue), install all your dependents, and then try again.

As for being able to uninstall the installer, there's nothing preventing you from uninstalling any dependency at a later point so obviously you can physically remove it. And since the installer wouldn't actually be listed in the configuration (since it's implicit) it doesn't suggest to the user that they shouldn't be able to remove it.

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

That's about the best I can come up with at the moment. The only other solution would be to remove the ability to have multiple installers handle the package. This does seem appropriate to have though in an environment like Squeak where you might have written your own version of an installer that handle DVS packages, for example.

Julian