[arch-haskell] Issues with cabal2arch/AUR packages

[Mathew de Detrich]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/arch-haskell/attachments/20131012/c4d9ba29/attachment.html>