<div dir="ltr">But these issues should go away one we migrate trunk to the spur branch ?<div>Another big change like that is not yet on the horizon as far as I know.</div><div><br></div><div>Karl</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 29, 2015 at 6:11 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Apr 28, 2015 at 10:32 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
> In MCMcmUpdater, the UpdateMapName is initialized from a preference. This<br>
> is 'update.spur' for the Spur image, and 'update' otherwise. This supports<br>
> the parallel update streams for Spur and non-Spur images.<br>
><br>
> A side effect is that certain packages (e.g. head branch for OSProcess)<br>
> cannot be loaded from SqueakMap because the loader does this:<br>
><br>
> MCMcmUpdater updateFromRepositories: #('<a href="http://www.squeaksource.com/OSProcess" target="_blank">http://www.squeaksource.com/OSProcess</a>')<br>
><br>
> which does not work when UpdateMapName is set to 'update.spur' because the<br>
> OSProcess repository has only update maps named 'update' (and there would be<br>
> no difference between Spur and non-Spur anyway).<br>
<br>
</span>Hmm, this bug is a show-stopper for the release; no one will be able<br>
to load "head" versions of any packages into Spur..<br>
<span class=""><br>
> MCMcmUpdater is a collection of class-side methods, and this is making me<br>
> think that it may be time to have it be instance based, so that different<br>
> updaters (one for OSProcess, another for Squeak trunk) could know what update<br>
> map files to look for.<br>
<br>
</span>Sounds reasonable.<br>
<span class=""><br>
> I am not entirely clear on how the update stream (or streams?) for trunk<br>
> will work after we move to the Spur image in 5.0/4.6, but it seems desirable<br>
> that an external package (OSProcess, VMMaker, others) should be able to<br>
> specify the name of its own update maps independent of the Squeak trunk<br>
> update preferences.<br>
<br>
</span>+1<br>
<span class=""><br>
> How should this work? Does it make sense to move the logic for MCMcmUpdater<br>
> into instance side methods so that more than one instance of MCMcmUpdater<br>
> can exist?<br>
<br>
</span>That might lead to a solution. Would be nice if we could find a<br>
simpler way to hack our way out of this since we're so close to the<br>
release..<br>
<span class=""><br>
> Or maybe it is sufficient to find a way to implement this:<br>
><br>
> MCMcmUpdater class>>updateFromRepositories:updateMapName:<br>
><br>
> so that a SqueakMap package loader could override the default preferences<br>
> for trunk?<br>
<br>
</span>Yes, that would be another option.<br>
<br>
And, yet another, is the newer ability by Installer to #merge:<br>
packages. So, for your "head" release of OSProcess, you could change<br>
it to:<br>
<br>
Installer new merge: #osProcess<br>
<br>
However, this just avoids the problem rather than solves it. We<br>
should solve it..<br>
<br>
</blockquote></div><br></div>