Re: Problem with cabal-install 0.6 and data-accessor 0.2.1.3
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
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?
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
On Tue, 2010-06-01 at 18:14 +0100, Duncan Coutts wrote:
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.
[..]
I'll also have a go at adding the QA checks so this does not happen again.
Done. $ cabal check The following errors will cause portability problems on other environments: * Invalid 'tested-with' version range: ghc ==6.4.1 && ==6.8.2 && ==6.10.4. To indicate that you have tested a package with multiple different versions of the same compiler use multiple entries, for example 'tested-with: GHC==6.10.4, GHC==6.12.3' and not 'tested-with: GHC==6.10.4 && ==6.12.3'. * The package uses full version-range expressions in a 'tested-with' field: ghc ==6.4.1 && ==6.8.2 && ==6.10.4. To use this new syntax the package needs to specify at least 'cabal-version: >= 1.8'. Hackage would reject this package. Ross, next time you have a moment for hackage work, we should probably try building the hackage scripts using the latest Cabal HEAD. I've not yet fixed the one about excess ()'s which also slipped past the QA filters. Duncan
On Tue, 1 Jun 2010, Duncan Coutts wrote:
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"
Sounds reasonable. However I remember weakly, that I tried some more logical variants first, and they were not accepted by a version of Cabal. It's hard to reproduce now.
participants (4)
-
Don Stewart -
Duncan Coutts -
Henning Thielemann -
Ross Paterson