Problem with package consistency on Hackage
Folks, I'm not sure who to email about this, but hopefully someone on the cafe knows: On the machine which builds the Hackage packages the 'binary' package is built against 'bytestring-0.9.1.2', however the package I just uploaded gets built against 'bytestring-0.9.1.3' which leades to typecheck failures (the ByteStrings I get from the 'binary' package are not the same as all the other ByteStrings). See: http://hackage.haskell.org/packages/archive/uuid/1.0.0/logs/failure/ghc-6.8 If I wait will Hackage eventually become consistent? How does this work? Thanks, Antoine
Antoine Latter wrote:
Folks,
I'm not sure who to email about this, but hopefully someone on the cafe knows:
On the machine which builds the Hackage packages the 'binary' package is built against 'bytestring-0.9.1.2', however the package I just uploaded gets built against 'bytestring-0.9.1.3' which leades to typecheck failures (the ByteStrings I get from the 'binary' package are not the same as all the other ByteStrings). See:
http://hackage.haskell.org/packages/archive/uuid/1.0.0/logs/failure/ghc-6.8
If I wait will Hackage eventually become consistent? How does this work?
You can re-compile parsec and binary to depend on bytestring-0.9.1.3. Alternatively, use cabal-install which knows how to rebuild things to avoid consistency problems like this. Cheers, Simon
On Fri, 2008-10-10 at 08:31 -0500, Antoine Latter wrote:
Folks,
I'm not sure who to email about this, but hopefully someone on the cafe knows:
On the machine which builds the Hackage packages the 'binary' package is built against 'bytestring-0.9.1.2', however the package I just uploaded gets built against 'bytestring-0.9.1.3' which leades to typecheck failures (the ByteStrings I get from the 'binary' package are not the same as all the other ByteStrings). See:
http://hackage.haskell.org/packages/archive/uuid/1.0.0/logs/failure/ghc-6.8
If I wait will Hackage eventually become consistent? How does this work?
It's not a problem for users who use cabal-install because it has a dep planner specifically designed to avoid this problem. The current automated builds on hackage are not nearly so clever and thus hit this problem regularly. The solution in future will be not to do builds on hackage at all but let users and automated build clients upload results of build outcomes. That way they can use tools like cabal-install to generate consistent install plans. Duncan
participants (3)
-
Antoine Latter -
Duncan Coutts -
Simon Marlow