3.9alpha update stream (was Re: source.squeakfoundation.org)

Andreas Raab andreas.raab at gmx.de
Thu Jun 30 04:41:50 UTC 2005

Hi -

Some more comments:
>>> Note that after I do these steps, the list of packages in the Monticello
>>> browser is somewhat different than in the Squeak3.8-Packages image, this
>>> may need some cleanup?  Not sure where Connectors and some of the other
>>> packages came from.  See attached screenshot.
>> I think those come from cs #4, right?  Do we need to run that?  I'm
>> not sure we want all of those automatically created packages in there.

Depends on whether you wanted to have the system fully packagized or 
not. This is a key question - I have no interest whatsover in another 
"partially packaged" system. We have this already.

If you *are* interested in a fully packagized system then you need to 
make sure you know what every last line of code belongs to. The doIt 
does that by touching every method in the system and therefore pointing 
out (!) places that need to be fixed.

That's what this doIt is good for - it's NOT intended to perform proper 
packagizing it is intended to show which parts of the system are not 
included in your current package set and therefore need to be dealt with.

Since I did the work a while ago it is quite possible that later changes 
have done some modifications that I was unaware about when I did the 
work. I suggest you just reclassify these classes/methods too so that 
you have a fully packagized system.

> Yes, but I thought cs #4 did all of the other PI-creation as well, so I 
> assume it is necessary.  I.e. it creates the Kernel, Collections, etc MC 
> packages from the class categories.  Installing MC doesn't do this, does 
> it?  The Reorg cs does not do it, it only shuffles class categories around.

The doIt "sort of" does this but *not* properly. To do it properly you 
want both, a repository that the package resides on and a version of the 
package. Here is how to do this:

a) Send out the Reorg.cs just to get things in order for people out 
there (this includes any additional modifications that need to be made)
b) Do whatever is necessary to get Monticello/MCConfs to the people out 
there (e.g., put them into the update stream or so)
c) Post versions to the 3.9 repository that include all packages which 
should then be in a basic image
d) Post a configuration that people out there get via update stream

If you do this, here is what will happen for a 3.9 user:
* They get the ReOrg.cs
* They a configuration map
* This will force them to download the versions from the repository
* Since the repository version will be equivalent to what is in the 
system, no changes will be made

In other words, the above is a recipe to get the packages to the users 
at the expense of having to download all of these packages from the 
repository - which will take some time but it also means that (for once 
;-) you know that people have precisely the versions that are in the 

> Anyway, I can go through the steps again with my image tomorrow (which I 
> don't have with me at the moment), and see where these extra packages 
> are coming from... I should be able to figure this out.

Almost always they are method extensions which originally belonged to 
some package but where posted with other fixes.

>>> Hopefully we can do all of this cleanup through updates, so that people
>>> can continue to follow the update stream from a 3.8 final image if they
>>> want.  Otherwise, we'll have to just tell everyone to download a new
>>> 3.9alpha partitioned image, which wouldn't be the end of the world, but
>>> it'd be nice to avoid that.

See above. The only issue is that everyone will have to download the 
packages so you guys better get that server in shape ;-)

>> The other thing we'll need to generate will be a changeset that
>> provides the ancestry metadata for all of the initial package
>> versions, so that the MC working copies will be in the same state as
>> they would have been if all the packages had been loaded from the
>> repository (which will take a long time and we don't want to put
>> people through if we don't have to).
> Ok, that would be good.  Mm, any suggestions on how I should do this? 
> :-)  Of course, most of the packages are really the "initial" package 
> versions as you say, so they don't really have any "ancestry", right?  
> E.g. we would have Kernel version 1.  But there may be something missing 
> that I should add in any case... as if it were loaded from the 
> repository, I agree.

No! Please, no! Not "as if" - make it the real thing! What is the 
problem with just downloading the package and installing it? If people 
don't want to wait they can always just grab a preloaded image.

   - Andreas

More information about the Packages mailing list