SqueakSource issues (was Re: New 3.9alpha image is ready! (sort of))

[Doug Way]

Alright, that all makes sense below.  I'm trying to create a 
#loadLatestMCPackages method along the lines of what you describe.

Earlier this week, as a test, I tried to run 
MCConfiguration>>updateFromRepositories on the MCConfiguration defined 
in update #6676.  It hung, and I didn't have time to look into it 
further earlier, but I have a bit more time  now. :)

So, the main problem here is that it tries to load an .mcd file for the 
Kernel package: Kernel-md.5(dew.1).mcd, which doesn't exist.  Both the 
original Kernel-dew. and the newer Kernel-md.5 versions are in the 39a 
repository.  (Marcus has been porting a few fixes to the new 3.9a 
packages, thus the new versions... cool stuff!)

There are two sub-problems here:

1. It just hangs when it tries to get a file which doesn't exist on 
SqueakSource.  It should return some sort of not found error instead.  
(You mention this exact problem in your 7/12 email... apparently the 
impara.de SqueakSource server doesn't have this problem.)  Help from 
Avi/Cees or a SqueakSource guy? :-)

2. The .mcd file does not exist.  How is this intended to work?
   A. Is the SqueakSource server supposed to generate the .mcd file on 
the fly, or maybe upon the saving of a new version?  (Makes sense, 
that's a lot less bandwidth for these big packages.)
   B. Should the MCConfig code in the image not be trying to download 
.mcd files?
   C. Do we need to be saving .mcd files and not .mcz when we save new 
versions to the repository?

(I'm pretty sure the answer isn't C, that would be dumb.  I'm guessing 
A.)

Anyway, once we get this working, I'll create a #loadLatestMCPackages 
method and incorporate that as part of the Utilities>>updateFromServer 
code, and issue that as a new update.  Then we should be ready to go!

(I'll probably do something like the class-side #initialize containing 
the configuration, so that it gets overwritten after an update, and 
then test it for equality, which you mentioned earlier.)

Mmm, I may just put this "configuration" in the System package for now 
(where the rest of the updating code is), since it's really just a 
non-version-specific load order which would not change often.  If that 
becomes an issue we can move it into its own package.

(Speaking of non-version-specific, it might be nice to be able to 
define a non-version-specific MCConfiguration for this purpose, so that 
it's clear in the method that the version numbers aren't meant to be 
used.  E.g. map _ MCConfiguration fromArray: #(repository 
('http://source.squeakfoundation.org/39a') dependency ('Kernel') 
dependency ('Collections') ... etc.  Although perhaps the initial 
versions or uuid's are needed for ancestry info?  Anyway, not a big 
deal.)

- Doug


On Jul 10, 2005, at 5:40 AM, Bert Freudenberg wrote:

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