#700: seemingly too liberal behaviour on overlapping dependency constraints across packages ---------------------------------+------------------------------------------ Reporter: kowey | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by duncan): The very short answer is no, you cannot rely on the behaviour you want. The long answer is, that it depends on the method you use. Yes, "cabal install darcs" will always ensure that a single version of shared dependencies is used. If you use the lower level "runghc Setup configure" interface then it will pick the latest `mmap` rather than the one used by `hashed-storage`. It will however warn that it is indirectly using two versions of the same package. If you use "cabal configure" then it will usually pick the same version of `mmap` as used by `hashed-storage` however this may not possible without e.g. rebuilding one or other of the packages to get consistent deps. If it was not possible then "cabal configure" will also just pick the latest version of `mmap` and issue a warning. The "cabal install" command is in a position to rebuild dependencies so as to achieve consistent deps and indeed it cannot produce solutions that use inconsistent deps (many people see this as a limitation in the dependency resolver). In general, in future you should not expect cabal to always pick the same versions of shared dependencies, in particular where those dependencies are "private" dependencies (that is where no types from the private dep are exposed through the public interface). The ability to pick different versions of private dependencies in different places is actually important from the point of view of encapsulation. On the other hand, for public dependencies the `cabal` tool will continue to pick common shared versions. The reason the other commands allow you to pick inconsistent dependencies is as follows. The reason we try to pick consistent dependencies is to avoid compilation failure, not to avoid runtime failure as in your case. Since picking consistent deps is a conservative approximation it is important occasionally for user to be able to indicate that they want inconsistent dependencies because they happen to know it will work. Your example is pretty much the worst case, the compilation worked but for some reason using two versions, or at least the wrong version. We should make sure we understand the reasons for the mmap failure. We should distinguish whether the problem was using the wrong version, or if the problem was using a different version. If we feel we need to be stricter about using common versions then perhaps we should make the commands that currently do allow inconsistent deps do so only with a special override flag. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/700#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects