Hey Stephan, I enjoyed reading this.  By all means continue to explore
in this direction and to refine your essay, so that people new to the
topic can get going quickly!

Here are a few quick thoughts on it.

First, if I'm not mistaken, your capabilities model seems to boil down,
for each package, to this form:

	(cap1 AND cap2 AND cap3)  IMPLIES  (cap4 AND cap5)
	(cap6 AND cap7)  IMPLIES  (cap8 AND cap9 AND cap10)
	
Is this correct?  You'd ask the installer tool to find a way to get you
cap10, and then it would trace backwards through all the packages to
know about to see if it can satisfy this.
	

Do you have any concrete examples where these transformers would be
useful, Stephan?  It would help in thinking about them.

One aspect of baking in dependencies into version numbers is that people
may well end up not wanting to use the dependency-accurate version
numbers as their normal version numbers.  If am working on Chuck II Son
of Chuck(y), then I just want version numbers that go 2.0, 2.1, 2.2,
etc., but those will not capture the dependency information accurately. 
This makes me wary of capturing *accurate* dependency information in the
versions, though it may still be that the *intent* of the dependencies
can still be encoded in them.


Along these lines, note that a conflict can be detected after the
version number has already been decided.  What happens in that case?  If
the version number only captures intent then there is no problem.  If it
is supposed to be accurate, then that seems impossible.



>- The package name combined with the major number could
> be seen as the - technically and socially - needed new name.

You beat me to it.  For packaging purposes, it gives you a small
simplification if Chuck1 and Chuck2 are simply different packages if
they are in fact incompatible.  Additionally, putting them in separate
packages means that you can arrange for *both* of them to be installed
simultaneously....



> ('WebBrowserStandard_2.2', "minor release"
>             'WebBrowserStandard_2.2.1',
>             'WebBrowserStandard_2.2.1.1',
>            'WebBrowserStandard_2.2.1.1.1')."

Keep in mind, everyone, that accurate dependencies require extra work to
happen somewhere.  I hope stuff like the above does not need to be
maintained by humans!  And anyway, it makes me wonder in a lot of cases
if it is not simpler to *fix* a conflict between two packages and upload
a new version of the package, as opposed to trying to accurately report
that Chuck 1.28 is incompatible with RB 2.11.  Note that we have to deal
with bugs anyway, and that an incompatibility can often be considered
simply a bug.


> But here again: we *need* a versioning policy, which people are following!

Yes, that sounds right to me.  Bugfixes happen, and we should have a
system that can deal rationally with them.  Versioning policies would
let you easily (hopefully) express the claims about compatibility that
people often have mentally.


. Since we are faced with a
> combinatorial explosion here, hints regarding
> stable/unstable/bleedingEdge/etc. from the package maintainers would be
> helpful though...

I suggest we solve this through the idea of package universes.  You
simply live in a bleeding edge universe or a stable one.  I don't see
how you can combine a bleeding edge package and a stable package and get
something meaningful.  The result is not stable, for sure.

There's no explosion in practice.  The simple "Stable" versus "Unstable"
goes a long way.



> There also may be a logical package WebBrowser which just
> depends on one of them. But who makes the choice? This is similar to the
> question, who decides which stuff is worth enough to come into the
> official distribution.

Exactly!!  There is no one answer to this.  A package universe can be
viewed as *one* answer to the question "what packages exist?"




> It would be nice to have a detection of class extension conflicts.

This sounds like a job for the package loader and unloader, and if I'm
not mistaken Monticello will do this already.




> Don't try to be too perfect: KISS!
> I have to admit that KISS seams to be quite complex in this domain...

I am not convinced.  If we restrict attention to individual package
universes, then simple unversioned dependencies seem to be sufficient. 
It is worth trying to improve on them, but I don't see why we *have* to
improve on them.  How much talking *about* our packages do we really
want to be doing, as opposed to actually improving the packages
themselves?  :)



-Lex


PS -- There is a non-trivial UVersion in the Universes prototype I
posted, but it is way shy of the kind of stuff you are talking about.  I
have made -- KISS remember  :) -- the assumption that incompatible
packages have different names, and that newer versions of packages are
prefered even if someone asked for an older version of the package.  Oh,
and UVersion's are a total order; there are no branches.  But Universes
is supposed to be a playground.  Feel free to put together an alternate
universe browser that follows whatever dependency rules you like!!