Hi Ken.

(for some reason, I'm getting all your mails twice. Could you please
look into that?)

Your question is really not about SB specifically, it's about how
packages with multiple dependencies are managed. And I'll split it in
two -
* How should we package such code?
* How do we make the system smart enough to handle these dependencies
correctly?

First, as you're quite aware, nothing is yet complete that provides a
complete solution to this problem. Second, if you want a pointer to one
of Goran's inspirations when thinking of these issues (and mine too),
see www.debian.org. This is a linux distribution that's actually a
distributed project, handling >8000 packages on 11 architectures, that's
solved such problems as depedencies, libraries, multiple versions,
replacement of kernels.... it's a different situation, but we've
certainly alot to learn from it.

Now to your questions. Goran will probably answer soon, explaining about
SM1.1, which should add package versions. These and some other
enhancements should allow us to implement various tools on top of the SM
catalog, including tools that deal with dependencies. Some ideas about
how these should work have already been proposed, and I'm sure we'll see
some nice solutions come up after 1.1 is out.

Also as Ned said, the image is not a perfect unit of persistency. SM
allows you to install a list a of packages quite easily, so that
recreating your desired image with different installed packages is
something that can be automated into convinience..

Removing packages is not easy, but I think it's not impossible either.
It will require more thought than we've given so far to maintaining the
dependency constraints, though...

Daniel

Ken Causey <ken at kencausey.com> wrote:
> On Tue, 2003-01-21 at 13:17, Ned Konz wrote:
> > No, you're right.
> > 
> > However, Squeak's focus so far hasn't been on *un*installing things. 
> > This is a hard problem in general. We're instead trying to make an 
> > environment where a small image can be combined with selected 
> > packages to make the desired composite image.
> > 
> 
> Granted, I meant to make clear in my original message that I was looking
> ahead a bit.  Perhaps too much.
> 
> > My packaging of the SB add-ons has been done with this goal in mind: 
> > you should be able to come up with a list of packages you want in an 
> > image and load them in a well-defined order to get what you want.
> > 
> > Especially with packages and the additive nature of Squeak image 
> > building, I generally look at images as disposable. We have (various) 
> > other persistence schemes (projects, change sets, DVS, storage of 
> > categories in SB (don't remember if this works yet), etc.) to handle 
> > more long-lived artifacts.
> > 
> > When it's easy to build up new custom images I don't care about 
> > unloading packages.
> 
> Let's look at another example.  Forget removing packages.  If SBCeleste
> is packaged together with Star Browser and Star Browser is installed but
> Celeste is not then SBCeleste is not installed I believe.  What if the
> user later installs Celeste?  Is the user expected to reinstall Star
> Browser to get the SBCeleste functions?  How would the user even know
> that such exists?
> 
> I don't mean to imply that I consider this a major or pressing issue. 
> But I would like to figure out the appropriate place for SBJacaranda. 
> At this point it sounds like you or Roel need to pick it up.  Assuming
> it's of interest.
> 
> Ken