Cabal install broken with GHC 6.10.1.* HEAD
Hi, I've just installed GHC 6.10.1.20090225 which has set base as 3.0.3.0, instead of the 3.0.2.0 which GHC 6.10.1 had (I think). This causes cabal install to break, as it implicitly adds base == 3.0.2.0 which nothing has so nothing installs. Could a new version of cabal install be released that fixes this? I'm totally hooked on cabal install and now having upgraded GHC I've lost it. The likely result is that I'll have to downgrade my GHC because cabal is just too useful! Thanks Neil
On Thu, 2009-02-26 at 11:13 +0000, Neil Mitchell wrote:
Hi,
I've just installed GHC 6.10.1.20090225 which has set base as 3.0.3.0, instead of the 3.0.2.0 which GHC 6.10.1 had (I think).
Note that both ghc-6.10.1 and the current darcs version of the ghc-6.10.x branch come with base 3.0.3.0. See: http://darcs.haskell.org/ghc-6.10/packages/base3-compat/base.cabal
This causes cabal install to break, as it implicitly adds base == 3.0.2.0 which nothing has so nothing installs.
There's something else going on. cabal-install does know about the base package but does not have any hard coded versions. The only constraint it places on base is that the dependency solver must pick an installed version of base (ie and not try to install from sources off hackage).
Could a new version of cabal install be released that fixes this?
We'll need more details to work out what the problem is. Could you describe the symptoms in more detail. See also if ghc-pkg check reports anything. Duncan
Hi Duncan, I'm afraid I had to roll back the GHC version - its my work computer and not being able to work on it turned out to be an issue...
This causes cabal install to break, as it implicitly adds base == 3.0.2.0 which nothing has so nothing installs.
There's something else going on. cabal-install does know about the base package but does not have any hard coded versions. The only constraint it places on base is that the dependency solver must pick an installed version of base (ie and not try to install from sources off hackage).
Hmm, weird. It was giving constraints such as base-any && == 3.0.2.0, which I assumed had come from hardcoding inside cabal. Given that isn't the issue, my problem was probably elsewhere.
Could a new version of cabal install be released that fixes this?
We'll need more details to work out what the problem is. Could you describe the symptoms in more detail. See also if ghc-pkg check reports anything.
The computer I was working on had many different versions of GHC on, each with different libraries. It's entirely possible something got confusing and used the wrong ghc-pkg/ghc combination or some other mess happened. I'd regard this as a hisen-bug, and if I get a chance next week I'll do the same things again and see if the same things happen. Thanks Neil
On Mon, 2009-03-02 at 11:13 +0000, Neil Mitchell wrote:
Hi Duncan,
I'm afraid I had to roll back the GHC version - its my work computer and not being able to work on it turned out to be an issue...
This causes cabal install to break, as it implicitly adds base == 3.0.2.0 which nothing has so nothing installs.
There's something else going on. cabal-install does know about the base package but does not have any hard coded versions. The only constraint it places on base is that the dependency solver must pick an installed version of base (ie and not try to install from sources off hackage).
Hmm, weird. It was giving constraints such as base-any && == 3.0.2.0, which I assumed had come from hardcoding inside cabal. Given that isn't the issue, my problem was probably elsewhere.
Could a new version of cabal install be released that fixes this?
We'll need more details to work out what the problem is. Could you describe the symptoms in more detail. See also if ghc-pkg check reports anything.
The computer I was working on had many different versions of GHC on, each with different libraries. It's entirely possible something got confusing and used the wrong ghc-pkg/ghc combination
Cabal checks that the version of ghc and ghc-pkg match up exactly.
or some other mess happened. I'd regard this as a hisen-bug, and if I get a chance next week I'll do the same things again and see if the same things happen.
Ok. I'm sure you'll let me know if you find anything. Duncan
participants (2)
-
Duncan Coutts -
Neil Mitchell