[arch-haskell] Issues with cabal2arch/AUR packages

Sat Oct 12 07:39:08 UTC 2013

My understanding of current arch-haskell is to support the largest subset of
packages that can be installed together.  This may mean some dependencies
are not always at the latest versions.

Haskell Platform should be directly installable from the [extra] Arch Linux
repository.  Many others should be installable from AUR, from HABS[1], or
more conveniently from its binary repo.  I'll add yesod back in there in a
couple days, unless someone else gets to it first.
If there's issues with existing packages or packages you'd like to see
added, please let us know.

Arch Haskell library packages are being hard-coded to specific versions of
their dependencies these days.  This, along with bumping the PKGREL of
packages when one of their decencies gets changed, should cause an update to
be installed by your package management tool (i.e. yaourt).

Packages that are only an executable and not a library should just have
their decencies listed as makedepends, not as run-time depends (being that
they're statically linked at present).  The set of these that don't build
against the current set of package versions in HABS should hopefully be
rather small.  If you're using Arch packages to manage your cabal packages
(instead of using cabal by itself), and want to use a package like this that
won't build against the versions in HABS, there might be an older binary
package built in HABS you could install.

I've been using yaourt to manage all my Haskell packages for a while now.
 Having to re-install all my Haskell packages when upgrading GHC is
annoying, but I'm used to it.  It sometimes requires more messing-with than
cabal-install, and doesn't support multiple versions of a package being
installed at once, but the binary repo of pre-compiled packages is quite
convenient, and having multiple package versions installed can present its
own difficulties...

-Leif Warner

[1] http://github.com/archhaskell/habs

On Mon, Mar 28, 2011 at 2:27 AM, Mathew de Detrich <deteego at gmail.com>wrote:

> 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
>
> _______________________________________________
> arch-haskell mailing list
> arch-haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/arch-haskell
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/arch-haskell/attachments/20131012/ad8f84b9/attachment.html>