Well, this patch specifically does not put anything in ```~/.cabal``` or ```~/.ghc``` at build time like is usually the case. The problem though is that once the user starts installing stuff, e.g., ```cabal install foo```, the default location to put the contents (binaries, libs, data) is in ```~/.cabal```, and the package database in ```~/.ghc``` gets updated with a receipt.

IOW, we can prevent stuff being put there during this initial install, which I think is probably the right thing for us to do. But afterwards, not so much.

It would probably be possible to modify the cabal settings to _not_ use those locations but it wouldn't really solve the problem; there'd still be conflicts if ```~/.cabal``` were replaced with some location under ```/usr/local```.

I think the real problem here is that ```bootstrap.sh``` doesn't really have a notion of upgrading existing installations. I guess it just assumes everything will work out or that it's always a fresh installation or something. It might be possible to modify it to not misbehave but I'm not quite sure how that should work.

I suppose one approach might be to simply use ```ghc-pkg unregister``` to de-register all of the packages that ```bootstrap.sh``` relies on. This won't delete the files but it will force GHC to ignore them and download fresh ones.

I think it boils down to one of those two choices:

1) ```ghc-pkg deregister``` the packages ```bootstrap.sh``` relies on (not particularly invasive, since they could be re-instated)
2) Issue some kind of warning and quit unless the user removes ```~/.ghc``` themselves:

```ruby
  option 'force-install'

  if File.directory?('~/.ghc') and not build.include? 'force-install'
    opoo "Installation of #{name} will likely fail due to package conflicts unless
      ~/.ghc is removed first."
  end
```

(I suck at Ruby so I'm not sure that's valid code, but the idea should be clear)