#4072: Local package DB doesn't take preference over global DB
---------------------------------+------------------------------------------
Reporter: tibbe | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 6.12.2 | Keywords:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by duncan):
The culprit here is the way ghc currently handles package database,
specifically how it merges them.
Currently, in ghc's package database, packages are identified by a package
id (which included the hash), however there is a constraint that each
package name/version pair be unique. That is, although we can distinguish
different instances of the same version of a package, ghc does not allow
more than one instance in each package db at once.
The problem arises when merging two package databases and are multiple
instances of a package version between the two dbs being merged. Merging
dbs is what happens when you specify `-package-conf`; you're merging the
global, user and the given specific package dbs.
The algorithm that ghc currently uses guarantees that the way packages
shadow each other gives a consistent package db, however it does not
guarantee that the shadowing happens in the order that users would expect.
That's what is happening in this instance.
The solution is to allow multiple instances of a package version in a
package db at once. However then we need a new mechanism to map flags
"-package foo" to a particular package instance. This needs more thought
and discussion. Possible solutions might involve selecting a "current"
instance of package, eg when installing/uninstalling. They would have to
be selected in such a way that guarantees consistency.
We discussed some possibilities before the release of ghc-6.12 but could
not come up with something obvious and simple in time for the release.
What we have now in 6.12 is an improvement but does have some undesirable
properties such as the one illustrated in this bug report.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4072#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
