On Wed, Jul 31, 2013 at 12:26 AM, Frank Shearar <frank.shearar at gmail.com>wrote:

> 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!
> Yes!
>


> 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?
>
> 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.


> 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.
>
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.

>
> > >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.
>
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)?
Or is that too big a nest of worms?

>
> > 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?
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130731/ebfe63a5/attachment.htm