
On 10/12/12 16:02, Johan Tibell wrote:
On Sat, Dec 8, 2012 at 12:11 PM, Duncan Coutts
wrote: But yes it is true that the "real" API of a package is in the version number of the package itself, and the versions of all the packages which are "exposed" by that package (meaning packages that define types that are mentioned in the api of the exposing package). But it that has the property that I only notice changes in the types in those dependencies if I also depend on them directly myself. So we can get away with specifying local info, and not have to encode the full transative info (I think).
It's worse than that. The failure to build in my example above is a failure to find a valid install plan due to conflicting dependency ranges, not due to clashing symbols from different package versions. It happens even with private dependencies!
I'm a bit lost. The example from your mail that started this thread *does* compile, because Cabal finds a valid install plan by avoiding the new version of B. It's working exactly as intended, isn't it? Then you said that the user might get confused about why the new B wasn't being used, to which the response is that we need better diagnostics. What's the problem you're getting at above? Cheers, Simon