GHC does not shadow -package-name/-this-package-key

Steps to reproduce:

1. Install a package named a with these contents:

**a.cabal**

name:                a
version:             0.1.0.0
cabal-version:       >=1.10

library
  exposed-modules:     A
  build-depends:       base

• *A.hs**

module A where
data A = A String

Note what unit ID/package key/package name the package installs as. On GHC 7.8 it will be something like a-0.1.0.0, on GHC 7.10 it will be something like a_LKCPrTJwOTOLk4OU37YmeN, on GHC 8.0 it will be something like a-0.1.0.0-LKCPrTJwOTOLk4OU37Yme.

1. Install a package named b with these contents:

**b.cabal**

name:                b
version:             0.1.0.0
cabal-version:       >=1.10

library
  exposed-modules:     B
  build-depends:       base, a

• *b.hs**

module B where
import A
b = A "foo"

1. Go back to a, and load A.hs in GHCi with ghci A.hs -package-name a-0.1.0.0 -package-db ../db. Notice that we can import B from this GHCi session:

ezyang@sabre:~/Dev/labs/ii/a$ ghci A.hs -package-name a-0.1.0.0 -package-db ../db
GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling A                ( A.hs, interpreted )
Ok, modules loaded: A.
*A> import B
*A B> b
Loading package a-0.1.0.0 ... linking ... done.
Loading package b-0.1.0.0 ... linking ... done.
A "asdfsdf"
*A B> 
Leaving GHCi.

1. Edit A.hs so that now contains:

module A where
data A = A Int

1. Load in GHCi again:

ezyang@sabre:~/Dev/labs/ii/a$ ghci A.hs -package-name a-0.1.0.0 -package-db ../db
GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling A                ( A.hs, interpreted )
Ok, modules loaded: A.
*A> import B
*A B> b
Loading package a-0.1.0.0 ... linking ... done.
Loading package b-0.1.0.0 ... linking ... done.
A 3458765062984598387

Disaster!

Actually, this bug is relatively harmless:

1. If you try to actually reinstall package a, that's a "dangerous" reinstall and it's known that reinstalls can break things.
2. It's hard to convince Cabal to trigger this, since importing B requires b in the build-depends, and that would constitute a circular package dependency. (You can't separate it out because of (1))
3. If you don't specify -package-name (or similar) the local A and the remote A will have different identities, no problem.
4. When you do specify -package-name, you can't build a main executable (so the only way to run is by loading into GHCi, as shown above.)
5. Sometimes, GHCi will notice that something is amiss if it tries to load the object file for both the remote A and the local A.

But the fix seems simple: if a user specifies -package-name, it should be AS IF they also specified -ignore-package.

Trac metadata

Trac field	Value
Version	7.11
Type	Bug
TypeOfFailure	OtherFailure
Priority	low
Resolution	Unresolved
Component	Package system
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture