But these issues should go away one we migrate trunk to the spur branch ?
Another big change like that is not yet on the horizon as far as I know.

Karl

On Wed, Apr 29, 2015 at 6:11 PM, Chris Muller <asqueaker at gmail.com> wrote:

> On Tue, Apr 28, 2015 at 10:32 PM, David T. Lewis <lewis at mail.msen.com>
> 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..
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150429/4b75b7c2/attachment.htm