Package dependencies are modelled by a relation "A depends-on B". Shouldn't this in fact be two relations: API-depends-on and implementation-depends-on? (meaning that A API-depends-on B iff some type of B is visible to the user of A) So what we currently have is implementation-depends-on and API-depends-on is a sub-relation of that. The point being the following: assume * A implementation-depends-on B.1 * not (A API-depends-on B.1), * U implementation-depends-on A * U implementation-depends-on B >= 2 Then U (indirectly) implementation-depends on two versions of B but it should still be safe? (e.g., I can install B.3, re-compile U, but keep A) Example: A = template-haskell, B = containers (at least I don't see any mention of Data.Map/Set in th's API, I think the only dependency is in the implementation of PprM http://hackage.haskell.org/packages/archive/template-haskell/2.8.0.0/doc/htm... ) or in general, A (and B.1) are baked into ghc, but there is some B.2/B.3 out there which U wants to use. Or is this what already happens? (ghc would notice that B.1.foo is different from B.2.foo. cabal-install would warn, but proceed? Then the effect of the proposal would just be to switch off these warnings in some cases?) - J.W.