The way I am thinking of it is this. In "Simon's proposal" in http://web.mit.edu/~ezyang/Public/ghc-cabal-refactor.pdf the ghc-db library is simply a Haskell library that gives a programmatic way to interact with GHC's installed package database(s). GHC needs that. ghc-pkg needs that. cabal needs that. There should be one thing that supplies it. Cabal currently shells out to ghc-pkg, which in turn mandates a special file format (the .conf file) that Cabal uses to communicate its wishes to ghc-pkg. This needs syntax, a parser, a pretty printer, and is, to all intents and purposes just as stable, or unstable, as a Haskell API to ghc-db would be. To me it seems simple and obvious! Why are we going round the houses to do something so simple? Simon | -----Original Message----- | From: cabal-devel [mailto:cabal-devel-bounces@haskell.org] On Behalf Of | Joachim Breitner | Sent: 24 July 2014 15:07 | To: ghc-devs@haskell.org | Cc: cabal-devel | Subject: Re: Removing GHC's dependency on Cabal | | Hi, | | | Am Donnerstag, den 24.07.2014, 14:56 +0100 schrieb Edward Z.Yang: | > We were wondering if there was any reason to prefer the former | > situation over the latter. | | One way to decide that is to ask “What is the more stable interface”? | I.e. under what circumstances will upgrading Cabal require upgrading | packages depended upon by ghc. | | So while Duncan’s Proposal has no such dependency, in Simon’s proposal | there is one. Will ghc-db’s interface be stable enough that the Cabal | developers will be happy to build against a very old version of it? | | Greetings, | Joachim | | | -- | Joachim “nomeata” Breitner | mail@joachim-breitner.de • http://www.joachim-breitner.de/ | Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F | Debian Developer: nomeata@debian.org