[Hackage] #700: seemingly too liberal behaviour on overlapping dependency constraints across packages

[Hackage]

#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