New 3.9alpha image is ready! (sort of)

[Bert Freudenberg]

Am 10.07.2005 um 06:17 schrieb Doug Way:

> This may become obvious when I look into it, but I assume this MC  
> configuration will load the very latest versions of each package,  
> not necessarily the specified versions?

No, installing always uses the version specified in the map:

MCConfiguration>>load loads exactly the versions specified in the  
configuration, overwriting even newer versions.

MCConfiguration>>merge merges exactly the versions specified in the  
configuration into the image.

MCConfiguration>>upgrade installs (*) exactly the versions specified  
in the configuration. However, it does not install a version if the  
one in the image is newer (that is, the version in the config map is  
an ancestor of the on in the image). (*) The preference  
#upgradeIsMerge governs the method for installing, that is, loading  
or merging. Normal users will want to use load, whereas system  
developers most surely do not want their local versions clobbered by  
an upgrade, so they'll enable that preference.

So if you look into a changeset installing a config map, it creates a  
config map and installs (using the #upgrade method) exactly those  
versions. You need that for various scenarios, just installing the  
latest packages when you are way behind would almost be guaranteed to  
not work.

> (That's what I was looking for... a simple "load order"  
> configuration and not a configuration that only loaded specific  
> versions.)  I think that's what the #upgrade does if I remember  
> right, but I'll have to try it.

MCConfiguration>>updateFromRepositories modifies the configuration to  
point to the latest version it can find in the repositories. That is,  
it takes the old load order and plugs in the newest version of each  
package. It does not install any version.

So, to use an existing config map specifying the load order, but load  
the newest stuff, you'ld do:

     map updateFromRepositories.
     map upgrade.

(incidentally, that's what the code below says ;-)

> I assume the CProjectBuilder class below is in a particular Tweak  
> package.  Meaning that if you wanted to change the list of packages  
> in #defaultConfiguration, the #defaultConfiguration method in that  
> package would be updated.  (In other words, that particular package  
> would sort of store the configuration.)

Yes, the class holding that should go into the "core" package or even  
into its own.

> But I guess it wouldn't change that often, if it was simply used  
> for the load order (and didn't have to be updated every time one  
> package in the list bumped versions).

Yes, it changes rather rarely.

> - Doug
>
>
>
>>
>>
>>> What we've done so far is to have a global which stores the  
>>> latest version of a configuration and then just works issuing a  
>>> "updateFromRepositories". It's very simple stuff - if you are  
>>> curious check out CProjectBuilder>>loadUpdates and  
>>> updateFromRepositories.
>>>
>>
>> Yep, this works nicely in Tweak. Pasting the methods below for  
>> easier reference. I stripped out the progress display and logging.
>>
>> loadUpdates
>>        TweakUpdateStreamManager loadUpdates. "from update stream"
>>        self updateFromRepositories.
>>
>> updateFromRepositories
>>     | map |
>>     map := self defaultConfiguration.
>>     [map updateFromRepositories.
>>     map upgrade.
>>     DefaultConfiguration == nil] whileTrue. "repeat if we have a  
>> new map"
>>
>> defaultConfiguration
>>     ^DefaultConfiguration ifNil: [
>>         DefaultConfiguration := MCConfiguration fromArray: #(
>>             ...
>>         )]
>>
>> There is a hook to set DefaultConfiguration to nil whenever the  
>> #defaultConfiguration method is recompiled (but this relies on  
>> Tweak semantics). Alternatively, you might have a class-side  
>> #initialize method that contains the new configuration, so it  
>> would automatically get overwritten after an update, and you test  
>> for map identity in #updateFromRepositories rather than testing  
>> for nil.
>>
>
>
>
>
>
>
>> The call to #updateFromRepositories in #loadUpdates might possibly  
>> be guarded by a "bleeding edge" preference. That way, normal users  
>> only would get the "stable" configuratons explicitly posted to the  
>> stream, while the system developers would get all the latest  
>> packages from the repository.
>

- Bert -