[V3dot9] Re: New PI with postscripts/preamble etc

[goran at krampe.se]

Hi!


=?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
> On 16 août 06, at 00:59, goran at krampe.se wrote:
> > Hi!
> >
> > Ok, I have no idea how I got pulled into this but I just spent an hour
> > or two carefully merging the latest PackageInfo code from Squeaksource
> > with the kinda odd lineage of PackageInfo that is currently in  
> > 7054. The
> > extensive MC version note tells most of the story. It sits in the 3.9
> > inbox of course.
> 
> Thanks
> Do you mean that you merge PackageInfo-al.6 with the latest version?

No. :) as the version note (don't you read them?) says I used the newest
I found at the 3.9 repo from Marcus (which was not yet in the image) and
merged that with the newest I found from Squeaksource (from Avi):

"Careful (as best I could) merge (based on md-8 for 3.9 loaded into
7054) with the latest avi.20 version from Squeaksource.com/PackageInfo
which includes preamble/postscript support."
	
> > PPS. There are numerous versions of packages in current 3.9 that needs
> > to get fed "upstream".
> 
> I do not understand what you mean. That should be loaded in the image  
> or upgraded to
> SM?

"upstream" typically refers to the "source" of the package, which in
this case would be the package maintainers.
Depending on the package the actual "feeding" can be done differently.
The actual effect we want is for package maintainers to pick up and
integrate the changes you have made.

If they do not do this - then bad things will happen when the users
start installing newer versions from upstream sources - your
fixes/changes will typically get lost and things will break.

> > By that I mean for example SMBase and SMLoader -
> > my packages. The loader is a fixed version of my latest published -  
> > easy
> > for me to fold in and make a new release. Same with SMBase. But what
> > about the others? SUnit for example is way newer than the one  
> > currently
> > on SM, and the loader lists 3.1.6 as installed (this is all SM knows)
> > but of course in fact the installed version is a derivative from  
> > 3.1.22.
> 
> What is the loader?

SqueakMap Package Loader. Since SqueakMap maintains its own "memory" of
what versions of what packages are installed - going directly to the
source using Monticello for those packages will put the loader in a
stale state.

> > Since it has been installed using Monticello directly SM still  
> > thinks it
> > is 3.1.6 that is installed. It also offers no new version because all
> > versions on SM lack 3.9 as category - so SM does not think there  
> > are any
> > newer versions to install (otherwise it would have looked like
> > (3.1.6->3.1.22).
> 
> So what can I do?

Well... good question. :)

1. The problem of the loader showing the "wrong version installed" is of
course that Monticello does not talk to SM when loading versions - so SM
sits around with old state. SM could be "smarter" though, I might try
something there.

2. For the 3.9 release we can do this:
	2.1 Make sure that the packages that are on SM *and* are in the 3.9
release image are updated in SM. For SUnit as an example this would mean
registering a new release of SUnit in SM that is categorized for 3.9 and
that refers to the MC version that is installed in the image. That would
make the loader show the truth - at least until the user starts loading
new versions with Monticello again. :)

	2.2 "Trick" the loader so that it thinks it has installed this version
from SM. This is done using a doit like this:
		SMSqueakMap default noteInstalledPackageNamed: 'SUnit' autoVersion:
'13'

Note: the autoVersion number can be seen on SM like here:
http://map.squeak.org/packagebyname/sunit/autoversion/12

Marcus owns SUnit so he can easily do #2.1 above. Then someone needs to
execute the 2.2 doit in the image.


And then of course, there may be other packages that are on SM *and* are
in the 3.9 release image that needs the above treatment to show the
truth in the loader.

Any questions? :) :)

regards, Göran