Yeah, but I think we want what versions of things are installed to be checked into the trunk so that they're guaranteed to work with the release the image is based on. With SM we don't get that.  

On Jul 13, 2010, at 6:09 PM, Colin Putney <cputney at wiresong.ca> wrote:

> 
> On 2010-07-13, at 5:41 PM, Andreas Raab wrote:
> 
>> On 7/13/2010 5:35 PM, Casey Ransberger wrote:
>>> So I guess what I'm wondering is, does what we have support this approach with a bit of extra work, or do we need to scrap it and implement something else, which knows to load (for example) Metacello when loading up Seaside? I doubt we really want to load Seaside differently than the Seaside developers do... Right?
>> 
>> Right. The "current approach" (which is really more like "the initial proposal") was to include the Metacello configurations verbatim in the configuration package. What I'm proposing as a refinement is an indirection before that - instead of a Metacello configuration in the image you have "something else" which provides enough information to display and install the desired features.
>> 
>> What exactly the "something else" might be is open for debate but I think I'd like to drive it from the UI side, i.e., what do you want to see and specify when you install a piece of software? (think app store)
>> 
>> This approach doesn't invalidate the work that has been done; it puts a (hopefully) prettier face in front of it to make it easier and more obvious what you're about to get.
> 
> Well, in that case, we're effectively talking about SqueakMap, right? Maybe implemented differently, but basically a catalog of things you can install, with some metadata about how to actually perform the install, using a method appropriate to the package.
> 
> Colin