On Wed, Apr 9, 2014 at 10:37 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
Yeah. I think the real solution lies with cabal better knowing what libs ghc was baked/built with vs which can safely usually have a conflicting version in the user package db.
Aside: cabal already knows something about GHC packages. More precisely it knows that base and ghc-prim are not upgradable and will thus never try to upgrade those.
This would be a nice use case for cabal / ghc-pkg better understanding private vs public dependencies too! (Eg user ByteString vs ghc ByteString )
This is starting to sound like a bunch of good ideas to try on cabal! :-)
There are lots of good ideas to try, especially when it comes to better tooling. The problem is to actually get someone to write the code. -- Johan