Multiple compilers of the same version confuse Cabal

[guest]

It often happens that two or more copies of the same version of the same compiler are installed on a system. For example, the compiler can be installed with an installation package, or be built from the source tarball, or from darcs, or using MacPorts?.

If a package is installed for each of these copies of the compiler while allowing Cabal to use the default installation location each time, Cabal will always use the exact same folder. This leads to mayhem and anarchy.

Proposed solution:

Cabal should also use the base path of the compiler when it constructs the directory name for the package, not just the compiler name and version.

For example: If I install a package foo-1.2.3.4 --with-compiler=/opt/local/bin/ghc-6.8.2 and the installation base path is /usr/local, then Cabal should install the package into /usr/local/lib/foo-1.2.3.4/opt_local_ghc-6.8.2

[guest]

Sorry, of course that should be /usr/local/lib/foo-1.2.3.4/opt_local_ghc-6.8.2

[duncan]

Personally my inclination is not to include the location by default.

I wonder if there is a way of detecting if we're mixing things. The problem is not that we're corrupting the current ghc's package db but that we're overwriting the package that is registered with another ghc's package db. There is currently no way to map back to which package db it's registered in. Indeed it's not impossible for it to be registered in multiple package dbs. Still it might be useful to keep some pointer pack to which package db we think the package is registered in. Then if we were overwriting the files and registering into a different db then we'd know we were breaking the other db.

If we ever go for a hashing system (to allow multiple instances of the same package built against different versions of their dependencies) then this would no longer be a problem since the package hashes would be different, and if they were the same then their content would also be the same so it'd also be ok.

[duncan]

Note that with ghc-6.12 this problem is less significant because ghc+cabal will detect the inconsistency before there is a chance of segfaults. This is because the package ABI hashes are now tracked. If in future we install with the ABI hash as part of the install directory then the problem would be fully solved.