#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I wouldn't even care if it was `text` or `directory`. I have a pretty clear stance on this to prevent hampering our ability to make progress in the future. If you have a technical merit for the reasons you don't like `^>=` than that is something we would listen to. However because you don't see the use of it doesn't mean it's wrong to use it. Using `^>=` has a clear benefit, and maintainers are free to use any features that's in the cabal file. Secondly like `refold` said, `integer-gmp` is a special build-in in that it requires build system support for systems using in-tree gmp. So there is a number of configurations that would break if you were to try to install the `integer-gmp` package. If you follow the dependency chain you'll notice it depends on `GHC-prim` which is compiler specific, which further depends on the `rts` package, which will soon also be a cabal package. Their presence on Hackage as far as I am aware are only for resolvers. You can't actually install them short of getting a new GHC version. Because of this, it is perfectly reasonable to use new bleeding edge features in these packages. As they are literally tied to GHC, and you should not be swapping them out/mixing and matching them. We don't guarantee ABI stability for them at all. I think we should learn from this experience. There was a non backwards compatible change in the cabal format. It may have been the first, but it won't be the last. Let's constructively find a way to prevent things from breaking in the future. Arguing about whether a library is allowed to use the bleeding edge isn't useful, the tools should handle this gracefully. and unless I'm mistaken, don't both `stack` and `cabal-install` do this now? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler