Installing GHC manually is not hard, the website even provides pre-compiled binaries. I started doing it for different reasons, but was surprised how painless the process was. After doing it multiple times, I wrote together a file that guides me through the process, which you can find here: https://github.com/quchen/articles/blob/master/install_haske...
Tons of advantages to doing it that way, including the ability to easily maintain multiple versions of both GHC and Platform on the same system and swap between them with a single command. Also doesn't clutter up /usr/local/ with binaries not managed by apt or dpkg.
More generally, update-alternatives is a godsend for Stable users. It's like RVM or RBENV in the Ruby world - lets you install and manage multiple versions of the same platform and easily swap between them with a single command, including the system version from repos if you want. It frees you from out of date software in the repos while still providing a system to manage the complexities of it all.
What are the problems of making Haskell from source? (I did it recently, and it takes a long time, and you have to install a bunch of other random things... But at least it works in the end. I guess that sucks for devops?)
I run into far more version conflicts installing Haskell software through Cabal than any other language environment. Fortunately there is a solution: cabal-dev gives you per-directory package repositories.
> Cabal is a package manager that by default compiles packages either to a system database (if invoked as root/admin) or a per-user database. Since Haskell code is very often fussy about exact version numbers, and because Cabal offers essentially no way to uninstall packages, this is very painful. Cabal-dev is a front-end to Cabal that gives you per-directory repositories: suddenly conflicts go away, and you can remove packages by deleting the directory's repository and reinstalling everything again. It's a kludge, but it is very helpful.
> I would say, "You should never mutate your user or global package database" and recommend using cabal-dev. The way cabal-install does destructive updates is evil. In particular, it likes to mutate your global or user package database. You run the risk of building something and then breaking it later by mutating its dependencies.
If it's your local machine, you may be able to pull it from experimental when it comes out. If it's a server, can't you just compile everything statically and deploy the resulting executable?
