Multiple dependencies on the same package (was discussion on #haskell)

[Duncan Coutts]

On Thu, 2006-08-10 at 19:31 +0300, Einar Karttunen wrote:
> Hello
> 
> There was a discussion about the semantics of the package
> dependencies on #haskell. Continuing here for clarity.
> 
> build-depends: foo > 1 && < 3
> vs
> build-depends: foo > 1, foo < 3
> 
> and the same with configuration stuff:
> 
> packages(foo >1 && < 3)
> vs
> packages(foo > 1) && packages(foo < 3)
> 
> 
> Current Cabal and the configurations patch interpret these as:
> * "packages(foo >1 && < 3)"
> *  there exists a package foo such that the version is >1 and <3
> 
> * "packages(foo > 1) && packages(foo < 3)"
> * there exists a package foo such that the version is >1 *and*
> * there exists a package foo such that the version is <3
> 
> This means that the semantics are very simple, each package
> and depend can be handled in isolation. This has not caused
> problems but should be documented more clearly.
> 
> The alternative solution is to make package names have
> per-configuration and per-build-depend-line specific scope
> and add an environment to the semantics. This would eliminate
> a class of errors, but on the other hand make reasoning
> about the semantics harder.

Isn't the semantics quite simple:

for each package mentioned in build depends, a candidate package must
satisfy all constraints.

for the current implemented semantics it's:
for each dependency there must exist a candidate package that satisfies
it.

So "build-depends: foo > 1, foo < 3" means linking with foo twice (and
possibly different versions)! This seems like nonsense. If that's what
it means then it should be an error condition with a helpful message to
use "build-depends: foo > 1 && < 3" instead.

Similarly if we go with "packages(foo >1 && < 3)" meaning something
different from "packages(foo > 1) && packages(foo < 3)" then is the
latter not simply an error?

Duncan