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.