[arch-haskell] Simple, general template for cabal packages?

[Leif Warner]

pandoc, git-annex, and xmonad are available in [haskell-core]; no need to
compile anything yourself or pull down extra dependencies.

As far as providing only build of binary command-line programs (and not
libs) and building needed libs for each tool in a sandbox build; that's
been discussed over on the mac side w/ brew.

I for one *really* appreciate having binary installs of haskell libs
available.  Some take *forever* to compile (e.g. llvm-general), and I
really like having one consistent set of libs to worry about and not having
to figure out library version number juggling myself.  I use a lot of
haskell tools, and I also compile haskell programs / do development in
haskell.  If a lib's already been compiled into a package, it's making that
available for other computers to install, rather than make other boxes
recompile that themselves.
For things not in [haskell-core], I've been using cabal2arch to make
PKGBUILDs, put those on AUR, and install those myself.  I don't have
anything cabal-install'd at the user level.


On Wed, Jan 22, 2014 at 2:22 PM, Jeff Johnson <jefdaj at gmail.com> wrote:

> Hi everyone!
>
> I've been becoming more and more dependent on Haskell programs lately.
> There aren't many popular ones (yet!), but those that do exist seem
> uncommonly good and have quickly become core parts of my workflow: pandoc,
> gitit, git-annex, and hoodle are the main ones so far, plus maybe xmonad.
>
> But they also seem idiosyncratic and hard to install: builds often fail,
> pacman spits tons of errors even when upgrading successfully, you sometimes
> have to reinstall them all at once to maintain compatibility, etc. I've
> read these pages:
>
> http://comments.gmane.org/gmane.comp.lang.haskell.arch-linux/1743
> http://wiki.archlinux.org/index.php/Haskell_package_guidelines
>
> And I'm confused about the point of separate [haskell-*] repositories. Why
> all the overhead? The simplest thing I could imagine working would be a
> PKGBUILD with a "snapshot" of compatible dependency versions. Then you
> could do a sandboxed build from scratch each time. Somehing like:
>
> _pkgname=hoodle
> pkgname=$_pkgname-cabal
> ...
> makedepends=('cabal-git') # sandboxes introduced in 1.18
> _cabaldepends=(
>   ...
>   'coroutine-object-0.2.0.0'
>   'hoodle-types-0.2.2'
>   'xournal-types-0.5.0.2'
>   'hoodle-builder-0.2.2.0'
>   'hoodle-parser-0.2.2'
>   'xournal-parser-0.5.0.2'
>   ...
> )
> build() {
>   ...
>   cabal-git sandbox init
>   cabal-git update
>   cabal-git install $_cabaldepends $_pkgname-$pkgver
>   ...
> }
>
> The only downside would be a lot of compilation, but that could be solved
> the same way it is for non-Haskell packages: popular ones get adopted into
> [community]. Does that sound sensible? Or am I on the way to deciding I
> should contribute to an existing repository? Should I just try it and see?
>
> Oh and apologies if this has been answered; I just joined the mailing list.
> Jeff
>
>
> _______________________________________________
> 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/20140122/d1ee0fd2/attachment.html>