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 <jef...@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@haskell.org > http://www.haskell.org/mailman/listinfo/arch-haskell > >
_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
