Package Details: pandoc-bin 3.1.12.2-1

Git Clone URL: https://aur.archlinux.org/pandoc-bin.git (read-only, click to copy)
Package Base: pandoc-bin
Description: Pandoc - executable only, without 750MB Haskell depends/makedepends
Upstream URL: https://pandoc.org
Licenses: GPL2
Conflicts: pandoc-cli
Provides: pandoc, pandoc-cli
Submitter: cdkitching
Maintainer: gustawho
Last Packager: gustawho
Votes: 307
Popularity: 3.39
First Submitted: 2017-10-03 08:45 (UTC)
Last Updated: 2024-03-08 07:54 (UTC)

Dependencies (1)

Required by (314)

Sources (3)

Pinned Comments

cdkitching commented on 2023-09-22 09:07 (UTC)

Using this package will waste instead of save disk space if:

  • You're a haskell developer and need the shared libraries/compilers/etc. anyway.
  • You have >10 other statically-linked haskell packages around the same size as Pandoc (in which case you'll get a saving from making them all dynamically linked).

Neither of these scenarios is particularly likely.

Latest Comments

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 Next › Last »

timofonic commented on 2017-09-26 18:43 (UTC)

What about the extremely amount of pandoc filters? Are those available in AUR too? They are too much to check them, maybe there's a way to automatize it by using databases like repology.org

timofonic commented on 2017-09-22 23:52 (UTC)

There are a newer version... https://github.com/jgm/pandoc/archive/1.19.2.4.tar.gz But not new binary :( Also. Does this version include the zillion of patches? I was writing them, but a system failure made me lost them all :(

fauno commented on 2017-09-14 13:35 (UTC)

just my 2 cents: a while ago i was maintaining pandoc-static which built a static pandoc from source and avoided the haskell dependencies. i dropped it when an arch dev included pandoc in [community] and agreed to build pandoc statically too. i've no idea why this package went back to depend on haskell, and the arch dev has been unresponsive to my email. fwiw the pandoc-static pkgbuild is here: https://git.parabola.nu/abslibre.git/tree/pcr/pandoc-static

azrdev commented on 2017-07-24 19:39 (UTC)

>> it appears that pandoc-citeproc is also provided by the debian package, so I guess it might be easier to add a package_pandoc-citeproc() to your PKGBUILD. > Looks like you're right, joelongjimian. Let's do that. Could you do it, please?

neitsab commented on 2017-07-12 01:17 (UTC)

Two remarks: - why the explicit version number in provides() array? - cmark should be added as a dependency: pandoc from official repos depends on haskell-cmark which itself depends on cmark[1] (and official pandoc used to depend directly on it too before the switch to dynamic linking), and Hackage page also refers cmark as a dep [2]. Cheers [1] https://www.archlinux.org/packages/community/x86_64/haskell-cmark/ [2] https://hackage.haskell.org/package/pandoc

neitsab commented on 2017-07-12 00:58 (UTC)

+1 for -bin. I cannot find the source for this guideline on the wiki right now either, but it is for sure common practice in the AUR and should as such be favored. Thanks for creating this package.

runical commented on 2017-07-02 15:23 (UTC)

It does make sense to name it -bin @cyrevolt. It is a binary version of the package, not one built from source. If they were to drop pandoc from the repos, that would be the source package pandoc package, this would be -bin. The same thing is the case with syncthing and syncthing-bin to name an example. Anyway, there used to be a guideline iirc, but I can't seem to find it. From what I remember: - Source build or binary when source is not available (propriatary software like dropbox) has the normal package name - Binary releases of the software if source build can be done has -bin suffix - VCS-packages, suffix with the VCS (git -> -git etc.) - Other suffixes should say something about the build Anyway, enough of my rambling. As you can tell, I'm strongly in favour of -bin if cdkitching decides to actually change the name.

cyrevolt commented on 2017-07-02 14:28 (UTC)

Thanks so much for this package! :) On naming: I think the main point would be to differentiate between this package and the community package. So I am actually fine with the current name (pandoc-lite), because pandoc vs. pandoc-bin might be confusing, as it's not like the pandoc package is built from source or something, but also a prebuilt binary package. And I agree with hexagon5un, static would be misleading as well if it's not really static. I don't see dependencies listed here though, so it looks like a static build to my humble eyes. Anyway, kudos! :)

wamserma commented on 2017-06-27 16:00 (UTC)

I'm voting for pandoc-bin! pandoc-static should only be used if the PKGBUILD creates a true static build. Otherwise it will be a mess with downstream distros such as ALARM (where pulling in an x64 binary does not make any sense). Dunno how many people have clogged up their small ARM machines with 800 Megs of Haskell deps just for pandoc.

hexagon5un commented on 2017-06-27 09:27 (UTC)

Naming: pandoc-static is best. See if you can get that. Kudos: I created an account just to vote for this package. Thanks very much.

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 Next › Last »