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