On Mon, 2010-05-31 at 14:12 -0700, Don Stewart wrote:
erik:
Hi,
I've found an annoying problem with cabal install 0.6 and data-accessor 0.2.1.3. This version of cabal-install fails to parse the tested-with property in the cabal file of data-accessor 0.2.1.3. This means that *any* package depending on data-accessor (any version) will fail to build (at least here it does). The error is:
cabal: Couldn't read cabal file "./data-accessor/0.2.1.3/data-accessor.cabal"
When unpacking and configuring data-accessor-0.2.1.3, I get:
cabal-0.6: data-accessor.cabal:67: Parse of field 'tested-with' failed.
The tested-with field reads:
Tested-With: GHC==6.4.1 && ==6.8.2 && ==6.10.4, JHC==0.7.3
Ohhh. I'd not realised that when we extended the version range parser that this would affect the "tested-with" field too. It's obvious in retrospect of course. So we need to add a QA check for that. At the same time we should check that the tested-with makes any sense. In particular we should check that the version constraints are not self-inconsistent. The value "GHC==6.4.1 && ==6.8.2 && ==6.10.4" is not consistent. You meant "GHC==6.4.1, GHC==6.8.2, GHC==6.10.4"
The versions are: cabal-install version 0.6.2, using version 1.6.0.3 of the Cabal library, and GHC 6.10.3. Version 0.8 of cabal-install doesn't have this problem.
I don't think a new version of data-accessor can fix this problem, since cabal install will still also try to parse the cabal file for the old one. That's why I'm also CC-ing Don: perhaps the offending line can somehow be removed on hackage to stop this problem from occurring?
I don't think it will try to parse the old one, will it? Only if someone explicitly asks to look at the old versions?
I think the resolver may need to look at all versions of a package to decide which one to pick. As I said in the recent thread "The case for tweaking .cabal files of existing uploaded packages" what I'd like to do is just edit the .cabal files in the index on the server. The motivation is exactly to help with cases like this that slip past our QA filters. In fact this is another instance of the same problem as I highlighted in that thread. Since people seemed to think that was a reasonable idea I've gone ahead as an experiment and edited data-accessor/0.2.1.3/data-accessor.cabal in the hackage archive. This file will get put into the 00-index.tar.gz next time it is updated. So we should be able to see soon if this works as I expect and hope. Lets keep an eye on it. I'll also have a go at adding the QA checks so this does not happen again. Duncan