> This is also in the context of Kabungu. I think that this is
> important to learn from the errors or practices of others.

hi Stephane, and thanks for forwarding the lineups link. My impression
is that lineups & mcConfig do not address the core issue of
dependencies: what happens when a user wants to load 2 different
packages which have overlapping dependencies. Ie what happens if the
lineup/mcConfig of package A announces a dependency on C.1 and the
lineup for package B declares a dependency on C.2?

(This impression comes from reading some of the code and the
blog/mailing list discussions - so please correct me if it is wrong.)

In other words, lineups/mcConfig only deals with the case of
installing single (set of) packages that the developer controls. Which
is pretty much useless to the user. What is relevant to the user is:

  I have these 15 packages coming from different places and all
  developped for the "same platform" (eg. all for Squeak 3.7) - what
  else should I install so that I can install these 15 packages?

Addressing that requires addressing the issue of overlapping and
possibly conflicting dependencies. 

How do you do that? There are various ways, but the simplest seems to
be to declare which version of your dependencies you DON'T like.
Eg. "A requires C, but doesn't like C.1". The dependency engine can
use that to infer a version that probably satisfies everyone. That's
pretty much what eg. Debian does. (Note that a declaration such as
"package A.7 requires C>=7" should not be read as an assertion about
future versions of C, but rather as "package A.7 requires C, but
cannot live with C<7", and hence which version of C are NOT good for
A.7)

So the content of linups/mcConfigs is only partially useful: they
declare which packages are required (good) but only give one set of
version of these requirement which they like (not good). If on the
other hand you live in a world where you entirely control all
packages, mcConfig/lineups are perfect.

Michal