Oooh,

Sake/Packages does virtual dependencies, but not conflicts, I hadn't 
thought of that...!

A problem S/P has with SM and Universes is going in the reverse 
direction Sake/Packages (subscribers can edit) to SM/Uni (only package 
publisher can edit).

Any ideas? Could SM hold two lots of metadata, and users pick either 
"author blessed" latest or "subscriber says is ok" latest.

Sake/Packages has several levels

Packages beta  "for the absolute latest package, if published"
Packages current "for the subscriber says is ok"
Packages universe "for the author published to the universe package"
Packages squeakmap "for the squeakmap published package"

How about a feedback facility in SM for users to report their experiences?

One problem we may have is that the list of "loaded packages" is managed 
several times over and they get out of sync. MCWorkingCopy, 
PackagesOrganizer, and in Sake/Packages class Packages>>#provided all 
have a list. I am also anticipating that MC2 will have another similar 
scheme.

So in the very latest alpha MC1.5 (not yet in LPF) I have moved towards 
a scheme whereby it expects PackagesOrganizer to hold the master list of 
"loaded packages", and PackageInfo instances are willing to hold 
meta-data on behalf of other client tools.

regards

Keith
> implementation for SqueakMap with support for explicit conflicts and
> virtual dependencies (depend on "web server" for example) etc etc.
>
> So... my goal is to get Kabungu fully integrated for OOPSLA this year
> (October). If anyone is interested in helping me with this - just mail
> me privately.
>
> ciao, Göran
>
> PS. Yep, about time right? :)
>
>
>