[squeak-dev] MCMcmUpdater update map name
Chris Muller
asqueaker at gmail.com
Wed Apr 29 16:11:59 UTC 2015
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..
More information about the Squeak-dev
mailing list
|