On Thu, 2009-06-11 at 00:36 +1200, Stephen Blackheath [to cabal-devel] wrote:
All,
I'm getting a lot of this kind of problem now that a new major version of QuickCheck has come out...
blackh@amentet:~/src/projectx$ cabal install Resolving dependencies... cabal: dependencies conflict: Crypto-4.2.0.1 requires QuickCheck ==1.2.0.0 however QuickCheck-1.2.0.0 was excluded because QuickCheck-2.1.0.1 was selected instead QuickCheck-1.2.0.0 was excluded because test-framework-quickcheck2-0.2.2 requires QuickCheck >=2.1.0.0 QuickCheck-1.2.0.0 was excluded because ProjectX-0.1 requires QuickCheck
=2.1
It isn't practical to fix this properly - That would require lots of work upgrading quickcheck on all dependent packages. (Crypto-4.2.0.1 is my hacked version of Crypto-4.2.0 with a closed upper version limit to prevent it forcing QuickCheck-2.* which won't compile.)
Is there a better solution to this problem?
I think the Haskell Platform should help with this. The next major release will almost certainly specify version 2.x. Another solution is to allow private build dependencies. If the package uses QC but does not export any QC types or QC class instances then its use of it is effectively private and it would definitely be safe to allow that private version to be different from some other version of QC used elsewhere in the package dep graph. Currently Cabal/cabal-install does not have enough information to know which dependencies are private. It'd probably require a separate build-depends field, and of course it'd then have to be properly enforced.
Should a package maintainer have the right to choose an old version of QuickCheck, or should cabal's policy force all package maintainers to upgrade (preferably all on the same day)?
I don't think Cabal itself can or should do anything about it. Trying to coordinate people is more the purview of the platform. Duncan