<div dir="ltr">On Wed, Jul 31, 2013 at 12:26 AM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 31 July 2013 03:18, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
> Frank, this is so great. Everyone wants a smaller image for server<br>
> processing but keeping "rich" images for clients and development. I<br>
> love the methodical way you've come about to producing both, leaning<br>
> on the systems own tests to ensure quality is maintained every step of<br>
> the way. Kudos!<br>
Yes!</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
</div>Thank you kindly, Chris! I'm working very hard at keeping the<br>
stripping-down as painless as possible for consumers, because<br>
historically this has been the biggest stumbling blocks to minimalism.<br>
<div class="im"><br>
>> ... snip ...<br>
>> Sure! Questions are always welcome!<br>
><br>
> Chris Cunningham posed an excellent question -- does anyone know<br>
> whether we could take a SqueakTrunk (core) image, load selective<br>
> packages into it but still keep up-to-date with trunk?<br>
<br></div></blockquote><div>Just for the record, I LIKE the way Frank has it working. I like the idea that when someone is changing some core part of the system, it is able to immediately give feedback that it might impact an unloadable part, and give you a chance to fix it right then and there. I do see the point of getting a more stripped down version and just updating it as well, it's just not what I'd want by default.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
</div>Yes. Unless you say say `MCMcmUpdater updateMissingPackages: true`,<br>
you _won't_ receive updates for stripped packages (see the (*) below),<br>
but you _will_ receive updates for all the packages you have in your<br>
image.<br></blockquote><div>If this is set and you rename a package (say, rename ST-80 to be MVC), will this keep the new MVC from updating as well? I would assume so.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> >From what we've learned from Levente about the update-#; it's the sum<br>
> total of all version numbers across all loaded packages and the trunk<br>
> update uses that number to determine what updates are needed to move<br>
> the image forward.<br>
<br>
</div>The system version - the update number - is calculated in Utilities<br>
class >> #setSystemVersionFromConfig: (+). Given the MC configuration<br>
parameter, it sums the version numbers in that configuration to yield<br>
the update number.<br>
<br>
I might be completely wrong, but _as I understand it_ this means that<br>
the Squeak4.5.image in the squeak-ci repo (in other words, the<br>
semi-hand-rolled "minimal" base from which we work) will<br>
_under-report_ its update number. It doesn't have, say, the Nebraska<br>
package. Let's say Nebraska's currently at version 10, and the update<br>
number's 100. If someone pushes a new Nebraska package with version 11<br>
to trunk (*), the configuration remains unchanged. The minimal image<br>
says "don't update stripped packages" so won't update Nebraska, and<br>
its update number stays at 100. Someone running a "full fat" image<br>
updates, and pulls in Nebraska 11. Her image is now at update number<br>
101.<br>
<br>
frank<br>
<br>
(+) I've submitted a pair of commits to the Inbox to move this stuff<br>
to MCMcmUpdater. Critiques welcome, even if they're just "+1".<br>
(*) They really shouldn't. In Frank's Happy Land the versions of<br>
Nebraska already present in the trunk update stream stay there, but<br>
new versions go to the Nebraska repository, and you treat Nebraska<br>
like any 3rd party application: it should have its own SM entry,<br>
ConfigurationOf/Installer script, and so on.<br></blockquote><div>Crazy thought - would it be possible to distribute Trunk out to other repositories as well? We have the core trunk repository, + a repository for unloadable parts (such as Nebraska) in it's own repository, but it would still fall under the Trunk umbrella (that is, and update from Trunk would also include updates in that repository as well - if the package is currently loaded)?</div>
<div>Or is that too big a nest of worms?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
> With packages unloaded the trunk update process would seem to break<br>
> down for that image, is that right?<br>
><br>
> If we can't update a core/custom images, it creates a trade-off<br>
> situation right off the bat. A smaller image, yes, but one that can<br>
> only be manually patched. Is there any way to maintain the best of<br>
> both worlds?<br>
><br>
<br>
</div></div></blockquote></div><br></div></div>