I used to fight with a combination of system and cabal installed packages
under debian testing.
Then, about a year ago, the frustration became too much and I switched to
using nix, intero in emacs, and stack with the nix resolver, all installed
with nix on my debian machine. Couldn't be happier.
cabal and stack, and in the case of stack, cabal new-build, and possibly
cabal sandboxes, you probably shouldn't be trying to uninstall.
And yes, the data lines are telling ghc what to compile / link with, not
files but command line inclusions. And this will be especially messy on OS
X because of
On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery wrote:
> This is something of a nasty problem, considering that storing uninstall
> information separately is not particularly robust. Perhaps ghc-pkg should,
> if it doesn't already, support extension fields that e.g. cabal can use to
> store unins
The problem is that the package db contains only what ghc needs to be able
to use the library; not the additional information needed to safely remove
it. (There are other package systems with this problem, notably Apple's.
Apple decided that instead of solving it, they would only support
applicatio
