6 Sep
2013
6 Sep
'13
9:42 a.m.
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.