abhidg:

The PKGBUILD I've now worked with ghc 6.8 but is now broken with ghc 6.10... I'll try fixing it.

I think the best solution to this problem is to wait for makepkg splitting support to be integrated into pacman. Then we could have two packages built from the same PKGBUILD:

* pandoc: containing the binaries and man pages. * pandoc-dev: containing the libraries.

Then gitit and other stuff which need the libraries could depend on pandoc-dev.

Knowing John, you could probably just ask the developer to make this split upstream. -- Don

abhidg:

2009/2/15 Don Stewart :

...

Knowing John, you could probably just ask the developer to make this split upstream.

OK, I've opened an issue in the upstream bugtracker: http://code.google.com/p/pandoc/issues/detail?id=126

Excellent!

abhidg:

2009/2/15 Don Stewart :

...

abhidg:

...

2009/2/15 Don Stewart :

...

Knowing John, you could probably just ask the developer to make this split upstream.

OK, I've opened an issue in the upstream bugtracker: http://code.google.com/p/pandoc/issues/detail?id=126

Excellent!

The split can be easily done using cabal or using runhaskell, from John's comment on issue 126 in pandoc's bugtracker.

I've prepared two packages: haskell-pandoc and pandoc. haskell-pandoc depends on the ghc toolchain and the other haskell libraries; it also depends on pandoc. pandoc contains only the binary 'pandoc', some helper scripts and the manual pages. Thus the pandoc package only needs to depend on gmp and zlib.

Doing `pactree -u haskell-pandoc` (pactree is in pacman-contrib) gives the dependency chain of haskell-pandoc as:

ghc gmp gcc-libs glibc kernel-headers tzdata texinfo ncurses findutils gzip bash readline libedit haskell-utf8-string haskell-zip-archive * haskell-binary * haskell-digest * zlib haskell-zlib pandoc

Of these the * ones are not yet in [community], but they need to be if pandoc is to be updated to 1.1.

And my general view is that if a Haskell app needs some Haskell libs, we should move them in.