Skip to content

Multiple compilers of the same version confuse Cabal #256

Closed
bos opened this Issue May 24, 2012 · 4 comments

2 participants

@bos
Haskell member
bos commented May 24, 2012

(Imported from Trac #263, reported by guest on 2008-03-25)

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

@bos
Haskell member
bos commented May 24, 2012

(Imported comment by guest on 2008-03-25)

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

@bos
Haskell member
bos commented May 24, 2012

(Imported comment by @dcoutts on 2008-03-25)

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.

@bos
Haskell member
bos commented May 24, 2012

(Imported comment by @dcoutts on 2008-03-25)

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.

@tibbe
Haskell member
tibbe commented May 5, 2014

Closing as there's been no activity in years.

We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.

@tibbe tibbe closed this May 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.