how do we proceed for packages?

Doug Way dway at mailcan.com
Mon Apr 4 03:48:01 UTC 2005


On Mar 30, 2005, at 7:00 AM, stéphane ducasse wrote:

> I would like to know how we can push some packages like omnibrowser in 
> 3.9
> I think that this is important that omnibrowser gets used by people 
> because
> it is a bit sluggish right now and only pushing it in the stream can 
> make that it gets
> improved by the pressure of users.
>
> So what are the practices?

Well, this is the right place to ask. ;)

In this case, we are talking about adding a package to Basic.  The 
Package team should be discussing the nuts and bolts of how a package 
is defined within the Basic image.  (Basically, via PackageInfo 
w/enhancements.)  And there is general agreement that OmniBrowser 
should go into Basic so that it can eventually replace Browser.

Okay, I think I see what you're getting at... The big question is if 
it's added to Basic, via the update stream, should the master copy 
still be on SqueakMap (maintained there), or should the master copy be 
in the image (maintained via the update stream)?  Sigh.  This is a hard 
problem that hasn't really been resolved, I'd say.  For Full packages, 
it's easy enough to just remove them from the Basic image and keep them 
on SqueakMap and maintain them there.  But with Basic packages, they 
really need to be "in" the image.  (Yes, we'll also have a Minimal 
image one day, but the update stream really needs to follow Basic.)

So, the options are something like this:

1. Add OmniBrowser to the Basic image via the update stream, and 
maintain it in the image via the update stream from then on. (e.g. 
Colin would have access to update it via the update stream)  But still 
keep it clearly defined as a PI package.

2. Add OmniBrowser to the Basic image via the update stream, but still 
maintain the master copy on SqueakMap.  When significant changes are 
made, a new version is added to the update stream from SM.  This is 
kind of what we're doing with the SqueakMap package itself.  It's kind 
of clunky... I don't like this. :)

3. Do not add it to the Basic image.  (Which will probably mean it will 
never effectively replace Browser.)

4. Wait for some sort of magical dependency scheme to come around to 
solve these problems... ;)

Maybe once the image is partitioned into packages (which are not 
removed from the image), and better tools are developed for handling 
these packages, it may become more obvious how to handle this...

- Doug




More information about the V3dot9 mailing list