Don, Peter Simons says that pandoc won't build on arch because parsec 2 is not available there, and pandoc depends on parsec < 3. I don't want to change that dependency, because when compiled against the current parsec 3, pandoc is about twice as slow as when compiled against parsec 2. Peter proposes uploading a new 'open-pandoc' package with the parsec restriction removed. I think that will just confuse users who want to install pandoc; a better solution, obviously, would be for parsec 2 to be made available on Arch. I don't know why it wouldn't be; after all, parsec 2 is (last I checked) still the version in the Haskell platform, and the default for cabal-install; and many Hackage packages besides pandoc depend on parsec < 3. So I thought I'd ping you to see what the story is; please cc Peter in your reply... John +++ Peter Simons [Feb 16 10 01:47 ]:
Hi John,
Suppose you're using pandoc in a web app that delivers up hundreds of pages, some quite long.
if you do that, Pandoc is a mission-critical component in your setup and it's fine to dedicate extra effort to, say, building it with Parsec 2. For occasional users like me, however, the difference in performance is hardly measurable.
Well, if you don't want your software to work on ArchLinux, then this is the way to go. It's your choice.
It's not my fault that it doesn't work on Arch.
Of course it is. You deliver a cabal file that refuses to build Pandoc with Parsec 3, even though it would build just fine! Who else do you think should be responsible for that?
Anyway, I have found a solution that should work. I'll fix Pandoc's Cabal file and upload that version to Hackage calling it, say open-pandoc. The automatic cabal2arch converter will make that package available in ArchLinux within a couple of days, and then everything will be fine.
Take care, Peter
----- End forwarded message -----