Hi!

Daniel Vainsencher <danielv at netvision.net.il> wrote:
> goran.krampe at bluefish.se wrote:
> > and I also refined the "installedPackages"
> > structure to have full history - do an explore on:
> > 
> > SMSqueakMap installedPackagesDictionary
> > 
> > That should make Brent and Daniel happy! :-)
> Yes, but it also reveals some deeper issues.
> 
> Specifically, this snippet produces the desired load order -
> orderProperty _ [:a | (a value detectMin: [:install | install third])
> third ].
> oc _ SMSqueakMap default installedPackagesDictionary associations
> asSortedCollection: [:a :b | 
> 	(orderProperty value: a)  < (orderProperty value: b)].
> 
> And this makes a readable list.
> oc collect: [:e | SMSqueakMap default cardWithId: e key asString]
> 
> Looking at which, I see several problems -
> 1. The order is wrong, because of things that were installed before this
> information was written down, and specifically, the packages that are
> bundled with the image, namely, SqueakMap and friends.

As you may see - the postscript of SqueakMap Base 1.06 converted the old
installedPackages Dictionary by simply scanning through it and giving it
an arbitrary order. I just realized. ;-)

That could of course be fixed if needed. As you may know the
#noteInstalled: also logs in the changelog so the proper order could be
found.

> 2. Load scripts - the list shows both the load script and everything it
> proceeded to install. This duplication will cause everything under a
> load script to be installed twice (not that big a deal, it should work).

Ah. Right. On the other hand - a load script, if *categorized* as such -
could be ignored. But the reverse is better - the loadscript could, in
some way, make sure that SM logs the packages it loads in some special
manner thus knowing they belong to that loadscript and should not be
installed on their own.

This latter approach seems best. Suggestions to how?
 
> So, practically speaking, I think when preparing the image (in the gamma
> stage) we can clear the stored information and then reinstall the
> to-be-included packages clean, resulting in a coherent image. 
> 
> More long term (definitely after SM1.1), I think we might want to
> rethink the mechanisms for knowing what packages are installed, and
> providing other services on top of that. Part of it is thinking about
> how this all combines with advanced loading mechanisms like Monticello
> provides.

Right. In SM1.1 we will not record packaged id + smartVersion. We will
only record packageRelease id. And I agree that we might need to take a
deep breath and think through if this should include other "ways" of
getting stuff into the image. Currently fileins not going through SM
leaves no trace and of course DVS/Monticello/Whatever-you-like also does
not.

> Daniel

regards, Göran