+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.
Search Criteria
Package Details: pandoc-bin 3.5-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/pandoc-bin.git (read-only, click to copy) |
---|---|
Package Base: | pandoc-bin |
Description: | Conversion between documentation formats |
Upstream URL: | https://pandoc.org |
Licenses: | GPL-2.0-or-later |
Conflicts: | pandoc-cli |
Provides: | pandoc, pandoc-cli |
Submitter: | cdkitching |
Maintainer: | a821 |
Last Packager: | a821 |
Votes: | 309 |
Popularity: | 1.89 |
First Submitted: | 2017-10-03 08:45 (UTC) |
Last Updated: | 2024-10-06 10:31 (UTC) |
Dependencies (9)
- groff (groff-gitAUR) (optional) – for pdf output using pdfroff engine
- pandoc-crossref (pandoc-crossref-static-gitAUR, pandoc-crossref-binAUR) (optional) – for numbering figures, equations, tables and cross-references to them with pandoc-crossref filter
- python-weasyprint (optional) – for pdf output using weasyprint engine
- tectonic (tectonic-gitAUR) (optional) – for pdf output using tectonic engine
- texlive-context (texlive-installerAUR, texlive-fullAUR, texlive-dummyAUR) (optional) – for pdf output using context engine
- texlive-fontsrecommended (texlive-installerAUR, texlive-fullAUR, texlive-dummyAUR) (optional) – for pdf output using latex or xelatex engines
- texlive-latex (texlive-installerAUR, texlive-fullAUR, texlive-dummyAUR) (optional) – for pdf output using pdflatex engine
- texlive-xetex (texlive-installerAUR, texlive-fullAUR, texlive-dummyAUR) (optional) – for pdf output using xelatex engine
- typst (typst-gitAUR) (optional) – for pdf output using typst engine
Required by (330)
- ajnin (requires pandoc) (make)
- allegro-git (requires pandoc) (make)
- allegro-sdl-git (requires pandoc) (make)
- amsynth-git (requires pandoc) (make)
- asn1c (requires pandoc) (make)
- aursec (requires pandoc) (make)
- aursec-git (requires pandoc) (make)
- aursec-tui (requires pandoc) (make)
- aursec-tui-git (requires pandoc) (make)
- autotrash (requires pandoc-cli) (make)
- autovala (requires pandoc) (make)
- baca-ereader-git (requires pandoc) (make)
- bdebstrap (requires pandoc) (make)
- bdsync (requires pandoc) (make)
- beast-git (requires pandoc) (make)
- beef (requires pandoc) (make)
- bergamont-marian-git (requires pandoc) (make)
- bookletimposer (requires pandoc) (make)
- bosq-git (requires pandoc-cli) (make)
- bower-mail (requires pandoc) (make)
- Show 310 more...
Sources (3)
Latest Comments
« First ‹ Previous 1 .. 4 5 6 7 8 9 10 Next › Last »
neitsab commented on 2017-07-12 00:58 (UTC)
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.
bhrgunatha commented on 2017-06-27 02:23 (UTC)
Lots of AUR packages providing prebuilt binaries are named with a -bin suffix so pandoc-bin?
runical commented on 2017-06-26 15:07 (UTC) (edited on 2017-06-26 15:08 (UTC) by runical)
Take a look on the wiki: https://wiki.archlinux.org/index.php/Arch_User_Repository#Other_requests
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.
cdkitching commented on 2017-06-26 14:48 (UTC)
Certainly reasonable suggestions for names. Is there a way to rename an AUR package?
Is there an upside to building my own? I opted to do it this way to avoid having a gigabyte of makedepends.
runical commented on 2017-06-26 13:56 (UTC)
@cdkitching: Pandoc-static was indeed available, but it was made obsolete by the introduction of a statically linked pandoc in the repos. Hence, Fauno deleted the package. However, you should be able to get the package name by cloning pandoc-static.
However, shouldn't the name be pandoc-bin, as you're just taking the executable provided by upstream? Static implies that you build the package locally, but statically linked.
cdkitching commented on 2017-06-25 20:43 (UTC)
Looks like you're right, joelongjimian. Let's do that.
Pinned Comments
cdkitching commented on 2023-09-22 09:07 (UTC)
Using this package will waste instead of save disk space if:
Neither of these scenarios is particularly likely.