#4072: Local package DB doesn't take preference over global DB
---------------------------------+------------------------------------------
Reporter: tibbe | Owner: simonmar
Type: bug | Status: new
Priority: normal | Milestone: 6.12.3
Component: Package system | Version: 6.12.1
Keywords: | Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonmar):
Replying to [comment:1 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.
Yes, all true.
> 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.
This isn't the case. The idea is supposed to be that packages from the
user DB shadow packages from the system DB, and then we throw away any
packages that are broken because their dependencies were shadowed.
Unfortunately we broke the ordering at some point, so the shadowing was
happening the wrong way around sometimes, and due to a quirk of fate our
test case didn't pick it up.
> 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.
It does have some undesirable properties, but this bug report is just a
bug :-)
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4072#comment:7>
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
