MCMcmUpdater update map name

On Tue, Apr 28, 2015 at 10:32 PM, David T. Lewis <[hidden email]> wrote:
> In MCMcmUpdater, the UpdateMapName is initialized from a preference. This
> is 'update.spur' for the Spur image, and 'update' otherwise. This supports
> the parallel update streams for Spur and non-Spur images.
>
> A side effect is that certain packages (e.g. head branch for OSProcess)
> cannot be loaded from SqueakMap because the loader does this:
>
>         MCMcmUpdater updateFromRepositories: #('http://www.squeaksource.com/OSProcess')
>
> which does not work when UpdateMapName is set to 'update.spur' because the
> OSProcess repository has only update maps named 'update' (and there would be
> no difference between Spur and non-Spur anyway).

Hmm, this bug is a show-stopper for the release; no one will be able
to load "head" versions of any packages into Spur..

> MCMcmUpdater is a collection of class-side methods, and this is making me
> think that it may be time to have it be instance based, so that different
> updaters (one for OSProcess, another for Squeak trunk) could know what update
> map files to look for.

Sounds reasonable.

> I am not entirely clear on how the update stream (or streams?) for trunk
> will work after we move to the Spur image in 5.0/4.6, but it seems desirable
> that an external package (OSProcess, VMMaker, others) should be able to
> specify the name of its own update maps independent of the Squeak trunk
> update preferences.

+1

> How should this work? Does it make sense to move the logic for MCMcmUpdater
> into instance side methods so that more than one instance of MCMcmUpdater
> can exist?

That might lead to a solution.  Would be nice if we could find a
simpler way to hack our way out of this since we're so close to the
release..

> Or maybe it is sufficient to find a way to implement this:
>
>     MCMcmUpdater class>>updateFromRepositories:updateMapName:
>
> so that a SqueakMap package loader could override the default preferences
> for trunk?

Yes, that would be another option.

And, yet another, is the newer ability by Installer to #merge:
packages.  So, for your "head" release of OSProcess, you could change
it to:

    Installer new merge: #osProcess

However, this just avoids the problem rather than solves it.  We
should solve it..