Hi Mathew, thank you for sharing your thoughts and insights.
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).
Your frustration is quite understandable. A number of PKGBUILD files published on AUR don't actually work. Others do work, but they're significantly out-of-date, which effectively prevents other packages from being installed. Haskell support on ArchLinux is far from perfect.
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)
We have recently picked up the habit of bumping the $pkgrel field of every package that needs to be re-built because of an update of one of its dependencies, so this particular problem should be a thing of the past. The repository http://github.com/archhaskell/habs/ contains a set of packages that can be expected to be compile fine. Those packages are also fairly up-to-date, and we publish those files on AUR, too. Haskell packages outside of HABS, however, aren't maintained much, and they're probably not reliable. Is there any specific package currently not included in HABS that you would like to see supported?
[The] main issue seems to be that the granularity of cabal package system is a lot finer then Arch's.
Yes, exactly. In Cabal, a package can be installed in any number of different versions, and these just co-exist. Pacman, however, wasn't designed to do this. It does distinguish $pkgname and $pkgver, but only one version of $pkgname can be installed at a time. When we maintain packages in ArchLinux, we perform two tasks: 1) We convert Cabal to PKGBUILD, and we 2) figure out a conflict-free set of versions that can be installed at the same time. Unfortunately, part (2) is way more difficult than (1). :-)
Wouldn't it just be smarter to have the archlinux haskell environment set up like this.
- ghc is an official package in the official repository
- haskell-platform will be the same as it is currently [...].
- All other libraries users would just install/update with cabal install and not through AUR/cabal2arch/bauerbill etc etc.
Yes, I agree, and I think what we're actually doing is pretty close to your description. The complete Haskell Platform is part of [extra], and everything else can be installed through Cabal. Popular applications written in Haskell, like darcs, are also available from [extra], and these packages usually don't depend on GHC or any other Haskell package. On top of this, there is a community-driven binary repository accessible by adding the lines [haskell] Server = http://andromeda.kiwilight.com/$repo/$arch to /etc/pacman.conf, which adds another ~200 popular Haskell packages.
- Haskell packages that provide binaries [should build their dependencies on-the-fly via Cabal]. This allows building of packages that use outdated packages (such as leksah ...)
That is a great idea. As far as I know, no-one has ever tried doing that before. It would be interesting to know whether this approach works well in practice. One source of trouble could be that all dependencies have to be $makedepends, but some libraries cannot be $makedepends, because they need auxiliary data files installed at run-time. Problems such as this can be worked-around, no doubt, but it's likely to be some effort. Another drawback is that this scheme may perform redundant compilations, because intermediate packages aren't re-used in any way.
[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.
Yes, indeed, that is good advice. The installation can be managed with cabal-install just fine. For some users, Cabal is probably the superior choice, especially for those who have a deep understanding of the problems involved in dependency resolution, package management, etc. For other users, Cabal is not an option because their needs are different. For instance, large-scale binary package distribution cannot be done with Cabal, but Pacman can do it just fine. ;-) Take care, Peter