On 31 July 2013 03:18, Chris Muller <asqueaker at gmail.com> wrote:
> Frank, this is so great.  Everyone wants a smaller image for server
> processing but keeping "rich" images for clients and development.  I
> love the methodical way you've come about to producing both, leaning
> on the systems own tests to ensure quality is maintained every step of
> the way.  Kudos!

Thank you kindly, Chris! I'm working very hard at keeping the
stripping-down as painless as possible for consumers, because
historically this has been the biggest stumbling blocks to minimalism.

>> ... snip ...
>> Sure! Questions are always welcome!
>
> Chris Cunningham posed an excellent question -- does anyone know
> whether we could take a SqueakTrunk (core) image, load selective
> packages into it but still keep up-to-date with trunk?

Yes. Unless you say say `MCMcmUpdater updateMissingPackages: true`,
you _won't_ receive updates for stripped packages (see the (*) below),
but you _will_ receive updates for all the packages you have in your
image.

> >From what we've learned from Levente about the update-#; it's the sum
> total of all version numbers across all loaded packages and the trunk
> update uses that number to determine what updates are needed to move
> the image forward.

The system version - the update number - is calculated in Utilities
class >> #setSystemVersionFromConfig: (+). Given the MC configuration
parameter, it sums the version numbers in that configuration to yield
the update number.

I might be completely wrong, but _as I understand it_ this means that
the Squeak4.5.image in the squeak-ci repo (in other words, the
semi-hand-rolled "minimal" base from which we work) will
_under-report_ its update number. It doesn't have, say, the Nebraska
package. Let's say Nebraska's currently at version 10, and the update
number's 100. If someone pushes a new Nebraska package with version 11
to trunk (*), the configuration remains unchanged. The minimal image
says "don't update stripped packages" so won't update Nebraska, and
its update number stays at 100. Someone running a "full fat" image
updates, and pulls in Nebraska 11. Her image is now at update number
101.

frank

(+) I've submitted a pair of commits to the Inbox to move this stuff
to MCMcmUpdater. Critiques welcome, even if they're just "+1".
(*) They really shouldn't. In Frank's Happy Land the versions of
Nebraska already present in the trunk update stream stay there, but
new versions go to the Nebraska repository, and you treat Nebraska
like any 3rd party application: it should have its own SM entry,
ConfigurationOf/Installer script, and so on.

> With packages unloaded the trunk update process would seem to break
> down for that image, is that right?
>
> If we can't update a core/custom images, it creates a trade-off
> situation right off the bat.  A smaller image, yes, but one that can
> only be manually patched.  Is there any way to maintain the best of
> both worlds?
>