Package Details: pandoc-lite

Git Clone URL: (read-only)
Package Base: pandoc-lite
Description: Pandoc - executable only, without 750MB Haskell depends/makedepends
Upstream URL:
Licenses: GPL
Conflicts: pandoc
Provides: pandoc=
Replaces: pandoc-static
Submitter: cdkitching
Maintainer: cdkitching
Last Packager: cdkitching
Votes: 53
Popularity: 12.681016
First Submitted: 2017-06-25 03:49
Last Updated: 2017-06-25 03:49

Dependencies (0)

Required by (57)

Sources (2)

Latest Comments

fauno commented on 2017-09-14 13:35

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:

azrdev commented on 2017-07-24 19:39

>> 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

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].



neitsab commented on 2017-07-12 00:58

+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

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

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

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

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.

bhrgunatha commented on 2017-06-27 02:23

Lots of AUR packages providing prebuilt binaries are named with a -bin suffix so pandoc-bin?

runical commented on 2017-06-26 15:07

Take a look on the wiki:

Essentially, you should upload the PKGBUILD under a new name and then file a merge request to merge this package's comments and votes into the new package.

As for building, there are some who prefer to build their own packages if possible. I personally prefer that to using binaries, but seeing how complex pandoc-static was, it might not be viable. As far as I can tell, there are no definitive advantages to building your own, but it does make sure that the package is built from the code you expect it to be built and against the correct dependencies. This should reveal problems before you use the binary.

All comments