I guess I am creating this thread due to the frustrations of using cabal2arch/AUR for haskell packages (instead of using the standard cabal install). I previously had issues, mainly with having to manually update AUR installed cabal packages due to them not updating (which was recently fixed by forcing the update through ghc) This however seemed didn't seem to solve the issue completely, although it will update fine through a yaourt -Syu --aur (or clyde -Syu --aur or whatever package helper you use), it still ends up breaking GHC because all the hashes for the packages change and it was a forced update I unfortunately don't have the output message, since I was in a rush to get things working (due to my job), I just ended up doing a clyde -R --cascade ghc and just installing my package through cabal). The package in question was basically yesod (which pushes around 20 or 30 packages on a fresh install) and the updates had to do with some components of yesod being updated In fact I think that yesod is a perfect example in showing the issues when trying to integrate archlinux package with cabal package management, since there are a lot of packages in yesod (like authenticate/cookie) which cannot use the latest version of the package on AUR, where as there are upgrades with the other packages. As I mentioned earlier, I just ended up giving up. Right now I only have ghc installed (through official arch repository) and any package I need to install, I do so with cabal. The problems with this are obvious however, but right now its not an issue. The main issue being installing haskell binaries that are on AUR which has the issue of duplication if that binary depends on a library that is already installed through cabal install. In my opinion the main issue seems to be that the granularity of cabal package system is a lot finer then Arch's (cabal was purpously designed for this, and its great for haskell packages), and unlike with other languages, the situation where you have a single package that depends on a lot of both updated and outdated packages is very common, along with GHC's runtime system updates forcing recompilation of libraries every haskell-platform release. This isn't so much of an issue now regarding binaries (because to be honest, we don't have that many heavily used haskell based binaries apart from xmonad), but in the future should haskell "break through" and become a much more widely used language, this can create a pain, especially for haskell-binaries (and its already painful with haskell-libraries) Of course, trying to force archlinux package management to have the same granularity as arch's is out of the question, which I guess made me come with my second idea. Wouldn't it just be smarter to have the archlinux haskell environment set up like this. Archlinux's package management is one that makes some sacrifices (in regards to having a rolling release system thats always up to date at the cost of granularity in certain areas) - ghc is an official package in the official repository - haskell-platform will be the same as it is currently (uses GHC, and cabal2arch packages from both the official repository and AUR). This is fine since the point of haskell-platform is the standard packages it uses are frozen for half a year. So the only haskell libraries on AUR would be the ones in haskell-platform (and arguably these should be in the official repository, as well as the base haskell-platform package) - All other libraries users would just install/update with cabal install and not through AUR/cabal2arch/bauerbill etc etc. - Haskell packages that provide binaries would check for their dependencies using cabal/ghc-pkg, and if a haskell binary can't find a package it can install it in a temp directory/and or install it automatically through cabal install (depends if its an updated/outdated/etc etc). If the library will be built to a temp section, then it will just be linked to GHC manually when building that binary (the PKGBUILD will cover this). This also allows building of packages that use outdated packages (such as leksah as an example, its not possible to build this package if you have newest haskell-gtk install, you have to manually do dependency tracking). Just like with cabal2arch PKGBUILD generator, someone can easily create a program which will create PKGBUILDS out of hackagedb binaries, the actual PKBUILD will search for dependancies through cabal (and not the PKGBUILD "depends"). Binaries that statically link libraries (which is the case for almost all haskell binaries at this point) do not actually require the libraries they depend on to build to be installed after the executable has been built, so doing temp library installs to build a binary will not be an issue (C/C++ binaries already do this in circumstances, and its something that can easily be automated through hackagedb) I am just saying this, because my experience of using cabal2arch/AUR hackagedb packages have just been a massive pain for years (I was basically forced to do manual package dependency management), and as my haskell colleges/friends have (rightly) stated, just use cabal. This of course isn't really an issue if you don't need to install haskell binaries through AUR, of which that many currently don't really exist (or just the occasional one like xmonad), and using cabal just *works*, even if it feels dirty ;) Of course this suggestion may have issues with shared libraries, which will probably need to be managed in their own way Thanks