Category: linux

Upgrading Haskell Platform on openSUSE

New version of Haskell Platform has been released just a few days ago. It ships with the latest stable version of GHC (7.4.1). Here you can find release notes describing changes made to the compiler. The list is long and I haven’t read all of it but among the most important changes are:

  • the possibility of entering any top-level declarations in GHCi;
  • Num type class no longer has Eq and Show as its superclass;
  • Data Parallel Haskell has been improved

Three months ago I wrote about installing Haskell Platform on openSUSE. I recommended that GHC be installed from precompiled binaries and the platform be installed from sources, instead of using packages from repository. Now that the new version is out this post needs an addendum about updating the platform. If the Platform was installed from the repo using a package manager everything would be simple1 . An update of packages would be enough, providing that they were updated by the maintainers of the repository (at the moment packages for openSUSE still contain older version of the platform). With manual installation this process is a bit more difficult.

First step is to remove the old installation. I figured out that it would be good to first remove all the packages installed with cabal and then remove GHC. There’s a problem though. Cabal doesn’t have uninstallation feature. This means that each package has to be manually unregistered using ghc-pkg and then all the files belonging to that package have to be removed. After spending about 30 minutes trying to figure out why I can remove one package using

ghc-pkg list | grep -v "^/" | sed -e "s/[ {}]//g" | head -n 1 | xargs ghc-pkg --force unregister

but can’t remove all the packages using

ghc-pkg list | grep -v "^/" | sed -e "s/[ {}]//g" | xargs ghc-pkg --force unregister

I gave up and decided to simply remove all of GHC files. This wasn’t easy since they were scattered all over /usr/local/{bin,lib,share,doc}, but in the end I managed to remove everything.

I noticed that there is a lot of discussion in the community whether packages installed with cabal should go to /usr/local or to user’s home directory. Surprisingly to me it seems that most people follow the home directory approach. This approach doesn’t suit me completely. I have a separate home partition used only to store settings and email – which I’ve been told is a “complex partition setup” :-o  – and all the software is kept on / partition, with all programs not installed from the packages being placed in /usr/local (BTW. it would be nice to have a separate partition for that one directory). This approach certainly wouldn’t work in a multi-user environment and I guess it could be problematic if I developed many projects, each with different dependencies (cabal-dev aims to solve that problem). As a side note, it seems to me that with hundreds of packages available from Hackage and a management tool with rather limited capabilities (cabal can’t even automatically update installed packages!) Haskell community is in a place where Linux community was over ten years ago. The dependency hell, now gone from Linux, looms over Haskell world and if cabal won’t be enhanced I see this as a very huge problem hindering large Haskell projects. It seems that Yesod team is particularly concerned about this – see here and here.

Anyway, I decided to place my new installation of the platform in /usr/local, but this time I was smarter by placing everything in a dedicated directory. Both GHC and the platform can be installed within a specific path. This is done by passing --prefix=/some/path to configure script. The only trick is that after installation of the platform ~/.cabal/config file in the /root directory has to be edited to point to the directory in which installed packages are to be placed. Of course, you have to also add the /your/haskell/platform/directory/bin to the path, so that GHC executables are visible. Now, when the new platform comes out I can simply remove the directory with the platform and install the new version. I can also easily control the disk space used by the installation. This tends to be rather huge. GHC, Platform and packages required by EclipseFP use 1,8GB of disk space. I also noticed that binaries for programs written in Haskell are rather large. The biggest one I have, buildwrapper, is over 50MB. This is caused by the inclusion of RTS (Run Time System) into the binary but I wonder what else gets included (or is the RTS that large?).

  1. Read this post, if you’re wondering why I decided not to use the package repository. []

Installing GHC on openSUSE Linux

The first thing you do when starting out with a new programming language is of course installing a compiler and an IDE. Although this first step should be easy, it took me a lot of work to get Haskell running on my openSUSE Linux. The solution to my problems turned out to be obvious, as all solutions are when you already know them. Nevertheless, 5 hours of my life went to waste and all I can hope for right know is saving others from repeating my mistakes.

There are two main Haskell compilers: GHC (Glasgow Haskell Compiler) and Hugs. I decided to use GHC, as it seems to be the more popular one. As a Linux user you have three options of installing GHC:

  1. Use the package repository
  2. Install precompiled binaries
  3. Compile from source

The third option is not really a sane option – GHC is written in Haskell so you would need working Haskell compiler to compile it. The first option seems to be the most natural for Linux user. Don’t we like to have our software managed from one central package management application? Good news: there is Haskell repository for openSUSE. However, after I installed GHC and some libraries from this repo it turned out the the compiler doesn’t recognize the libraries. Solution: for each library install both the normal and the devel package. Obvious, isn’t it? Well, it wasn’t obvious to me at first and I still think it’s a bit tricky. You install the compiler (which means that you most likely want to compile programs), YaST resolves the dependencies by installing additional GHC libraries, but compiler doesn’t have access to these libraries (since devel packages were not installed) and in the end GHC is totally useless. Where’s the logic?

There is one more catch with the repo. Haskell community offers a web repository of additional Haskell packages called Hackage. Not every package available via Hackage is also available in the openSUSE repository. Most notably Leksah, the Haskell IDE, is not available. So what now? Luckily with Haskell comes Cabal (Common Architecture for Building Applications and Libraries). Cabal is a package manager that manages packages available to GHC. It resolves package dependencies, downloads packages from the web, compiles and installs them. This however leads you to mixing two ways of managing GHC libraries. Some libraries will be managed by Cabal and some by YaST (or other rpm/deb management tool if you’re using different brand of Linux). This, at some point, may cause problems which leads us to the last of three installation option: using precompiled binaries. If you choose this option, carefully to chose which GHC version to download. The most obvious choice is using the latest available version, right? Wrong! You see, there is a thing called The Haskell Platform, which is a set of basic Haskell libraries required for development. New versions of Haskell Platform are released twice a year and each version is compatible with a particular version of GHC (most likely not the latest one). At this moment the latest version of GHC is 7.4.1, but the latest Haskell Platform supports GHC 7.0.4. If you’re a newbie, just like me, it is very reasonable to set up your basic Haskell environment by installing the Haskell Platform.

So, my advice on installing GHC on openSUSE (and other Linux distros) is: don’t use the repo, use the precompiled binaries. Instead, get the Haskell Platform, get the supported GHC version, install GHC, install Platform and then fell free to use Cabal to install any additional libraries from Hackage.

UPDATE (06/06/2012): The installation method described above can be enhanced. Read this follow-up for more information.

Staypressed theme by Themocracy