On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote: > The right solution, imho, is to review these dependencies and move > the low level ones out into a separate package that is shared by both > ghc and cabal and that will rarely change. The direct side effect of > this is that ghc would not be tied directly to a specific cabal > version and you would not have to deal with this issue.
This sounds very right to me. There should be something that describes what a GHC package database is, as minimally as possible (perhaps even only the data types). In the end, ghc is the defining side here - cabal is only a tool that builds on top of these definitions. Then ghc could finally be decoupled from Cabal. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
