[arch-haskell] Issues with cabal2arch/AUR packages

[Peter Simons]

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