>> - notion of optionalPackages and prerequisite, you tell in your
>> MyClassInfo which kind of prerequisite must be done, in an array
>> format : #('PackageRequired'
>> 'http://www.squeaksource.com/PackageRequired-xy.12.mcz')
>
> The notion is interesting. But having dependency information inside a
> package version is IMHO wrong.

Yeap

>> Kabungu:
>>
>> - lot of work done to handle dependencies issues, but as far as I
>>   understand the code, the dependencies are setting up in a
>>   centralized way. I personally think that it's wrong, each package
>>   must know what are its own dependencies, this should be not the  
>> role
>>   of a single package.
>
> Kabungu is a synthesis of ideas from the planned model in SM and Lex's
> Universes. After exchanging a bunch of emails with Michal I actually
> liked it a lot and decided to "just use it" as the model for SM  
> since I
> felt it was quite close to my planned model anyway. The idea was to
> leave the code for Michal to maintain. Then I think Michal decided to
> not work with me, but I am not sure. So that kinda hangs in the air
> right now. I might end up taking Kabungu and integrating it in SM
> myself, or perhaps using it in combination with my own ideas.

Goran would that mean that it would be integrated with PI?
For me I would like to get dependency to manage well packages at  
squeaksource level
and not only at map level.

>> SqueakMap2:
>>
>> - not clear for me how it handles dependencies right now, it seems
>>   that it's not possible yet, but guess that göran is working hard to
>>   get something on.
>
> Right. The latest release actually has some code in it - but nothing
> more than that.
>
>> Monticello is also managing dependencies, but is not 'url-oriented',
>> it put every dependencies on the same repositories to handle
>> dependencies. Since a lot of people are working with Monticello and
>> squeakmap, maybe the way of managing dependencies should converge  
>> in a
>> way or another. I noticed that PackageInfo seems to be the common
>> point of all these packages, so I'm wondering if we should agree to
>> use PackageInfo as the common platform to collaborate around the
>> dependencies issues ? Or is it not the right place ?
>>
>> Samir
>
> Mmmm, I don't think it is the "right place". But note that Monticello
> and SM has different needs.
>
> The dependency model that SM will end up with (Kabungu or mine or a
> synthesis or something else entirely) is meant for "published"  
> releases
> of packages. Monticello is much more fine granular being a development
> tool.
>
> But having said that it might very well end up merging together  
> somehow.
> For example, the MonticelloConfiguration files that people use more  
> and
> more should be added as a known package type in SM IMHO.

Indeed they serve as config files. May be this is a good way to do  
it. We do not use them to manage 3.9 since
we have to linearize the packages and sometimes this is not working  
(because of
circular dependencies and this shortcut MC loading power (all classes  
of a class bunch of packages are
loaded without taking take of package boundaries and this helps  
especially when
you have a tangled system like Squeak).

Stef