Julian Fitzell <julian at beta4.com> wrote:
> lex at cc.gatech.edu wrote:
> > Sure, keeping the information is fine, and there are probably exciting
> > things you can do with it.  Just don't use it as dependencies.
> 
> Goran's plan has always been to use the information (combined with an 
> indication on a release of its level of compatibility) as a guideline, 
> not as a strict dependency.  I can't tell if it's the strictness (which 
> has never been the intention) or something else that is bothering you.
> 

Okay, we are back on the same page I think.  Let me rephrase my request:
please let us have non-versioned dependencies that are convenient in the
UI's.

And as a small request, please don't call these versioned thingies
"dependencies".  A dependency is a directional relationship where one
item *must* or *probably must* have the other.  Something like "A 1.3
works with B 1.2" is not directional and does not imply any necessity. 
This is more like a "configuration", or perhaps a fragment of a
configuration, plus a rubber stamp of approval.


> I'm not saying it's necessarily perfect or easy, but I like it quite a 
> bit more than what you seem to be describing and I'd give it a fighting 
> chance of working. 

Wait, now you're making it sound like they are in conflict again....  I
hope that is just an unfortunate turn of phrase.

As a thought experiment, though, did you try tracing through the example
I posted?  I immediately got hung up with just 3 packages being
considered; after several steps I could still not upgrade any of the
packages without breaking the considerations.  The only ways out were to
ignore the "dependencies" or to make all the packages move together in
lockstep.  Why don't you try tracing through an example of your own
and see how it goes?


-Lex