[Hackage] #471: check for ambigious module names

[Hackage]

#471: check for ambigious module names
---------------------------------+------------------------------------------
  Reporter:  duncan              |        Owner:         
      Type:  defect              |       Status:  new    
  Priority:  normal              |    Milestone:         
 Component:  cabal-install tool  |      Version:  1.6.0.1
  Severity:  normal              |   Resolution:         
  Keywords:                      |   Difficulty:  unknown
Ghcversion:                      |     Platform:         
---------------------------------+------------------------------------------
Old description:

> Consider an example:
>
> {{{
> build-depends:
>   base, extensible-exceptions
> }}}
>
> The package `base-4.0.0.0` and `extensible-exceptions-0.1.1.0` both
> provide the module `Control.Exception`. This means it is impossible to
> pick both packages as direct dependencies of any single package.
>
> We should check for this situation at configure time and/or in cabal-
> install when planning an installation plan.
>
> Actually trying to avoid this situation may be rather tricky and it is
> not expected to occur often. So a simple check may be sufficient. If it
> starts to occur often in practice then we could consider trying to get
> the constraint solver to avoid the situation (perhaps by adding it to the
> checks for if a package is installable at all, see #420).

New description:

 Consider a example:

 {{{
 build-depends:
   base, bytestring
 }}}

 The package `base-2.1.x` and `bytestring-0.9.x` both provide the module
 `Data.ByteString`. This means it is impossible to pick both packages as
 direct dependencies of any single package.

 We should check for this situation at configure time and/or in cabal-
 install when planning an installation plan.

 Actually trying to avoid this situation may be rather tricky and it is not
 expected to occur often. So a simple check may be sufficient. If it starts
 to occur often in practice then we could consider trying to get the
 constraint solver to avoid the situation (perhaps by adding it to the
 checks for if a package is installable at all, see #420).

Comment (by duncan):

 Changed description to pick a true example.

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/471#comment:1>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects