Package Details: mupdf-git 20210319.33e4e2a3d-1

Git Clone URL: (read-only, click to copy)
Package Base: mupdf-git
Description: Lightweight PDF, XPS, and E-book viewer
Upstream URL:
Licenses: AGPL3
Conflicts: mupdf, mupdf-gl, mupdf-tools
Provides: mupdf, mupdf-gl, mupdf-tools
Submitter: None
Maintainer: vesath
Last Packager: vesath
Votes: 14
Popularity: 0.000000
First Submitted: 2011-03-07 21:49
Last Updated: 2021-03-24 18:31

Required by (21)

Sources (5)

Latest Comments

1 2 3 4 5 6 Next › Last »

vesath commented on 2019-10-30 22:31

rien333: Thanks for noticing. I see no point splitting this package into a viewer and separate tools. So I've added what you suggested to provides/conflicts, as well as mupdf-gl since we're in fact using the binary from the GL platform. (Upstream does not recommend using the x11 platform binary if you can avoid it.)

rien333 commented on 2019-10-27 23:08

@vesath Currently, this package builds some files provided by mupdf-tools:

error: failed to commit transaction (conflicting files)
mupdf-git: /usr/bin/muraster exists in filesystem (owned by mupdf-tools)
mupdf-git: /usr/bin/mutool exists in filesystem (owned by mupdf-tools)
mupdf-git: /usr/share/man/man1/mutool.1.gz exists in filesystem (owned by mupdf-tools

Maybe add mupdf-tools to conflicts or disable creating these files?

vesath commented on 2017-01-25 22:10

misc: There's no "must". Trusted users do as they please. Personally I consider Arch a shared-libs-based distro so I won't waste time and space packaging static libs. (It's bad enough that common code is duplicated four times between mujstest, mupdf, muraster, and mutool.)

misc commented on 2016-10-06 17:32

Seems the entire libmupdf stuff now must be packaged separately, as community does:

vesath commented on 2016-07-09 17:17

For a while the ever-increasing size of this package has been a real annoyance to me. It's a direct consequence of upstream's static-linking policy: common code and fonts are embedded into each individual binary. Ideally they would be built into a shared library which individual binaries would link against. However that's not trivial to achieve in our modest PKGBUILD. So in the meantime I tried to keep the package size under control with two slightly controversial tweaks:
- static libraries are no longer provided
- CJK fonts are no longer embedded

I believe this keeps this package fit for nearly everyone's purpose and it brings its size down from 176 MB to 44 MB. Feel free to voice any concerns you might have, together with suggestions on alternative ways to keep this package manageable. Cheers.

tutu commented on 2016-01-10 17:16

vesath: Thanks for the info about how to deal with libs. It is very nice to be able to talk to someone that have more experience on the topic. I will study a bit about how to construct a package in AUR and perhaps create a mujs package :-).

vesath commented on 2016-01-10 07:02

tutu: If your own project is unrelated to mupdf, there is really no reason for you to depend on the specific versions of mujs (or any other library) that mupdf requires and bundles into its libmupdfthird.a; you should simply use upstream mujs.

Last time I checked, mupdf could not be built against our shared openjpeg system libraries that our openjpeg package provides, indeed because it relies on yet unreleased openjpeg features. Of course I will compile against system libs whenever possible: the Arch way teaches us to avoid compiling libraries statically.

Regarding zlib, it is not explicitely included in the packages dependencies because it is already indirectly included as a dependency of pretty much everything: freetype2 depends on it, jbig2dec depends on libpng which depends on it, etc.

tutu commented on 2016-01-10 00:41

Hello again vesath - Thanks for the explanation, it was really helpful.

I noticed that you listed freetype2, jbig2dec, libjpeg and libxext as dependencies. Aren't zlib and the dependencies currently in mupdf Arch package supposed to be added as well? Some of those libraries are listed in the README file from mupdf and are not present in the PKGBUILD. Here is a quick summary of mupdf README and the dependencies:

- dependencies: freetype2, jbig2dec, libjpeg, openjpeg, zlib
- optional:
# Command line tools (HAVE_X11=yes/no): xorg-dev
# OpenGL-based viewer (HAVE_GLFW=yes/no): mesa-common-dev, libgl1-mesa-dev, xorg-dev, libxcursor-dev, libxrandr-dev, libxinerama-dev.

The reason why I needed libmujs.a has actually been solved. The developers of mupdf are basically creating a static library called libmupdfthird.a with the third-party libs (mujs, openjpeg, etc). Since you are initializing the mujs git submodule, the routines I need are static linked to libmupdfthird.a. The same thing happen to openjpeg.

Since Arch does have a package to openjpeg2 I tried to remove the line that active the submodule for openjpeg, however I had some compilation issues (some function were missing arguments - I think mupdf uses the most up to date version).

I wonder if we could skip the initialization of openjpeg git submodule when a new stable release of openjpeg2 is available in the Arch package repository. What do you think?

Thanks again.

vesath commented on 2016-01-09 08:18

tutu: Yes! Like openjpeg and jbig2dec, mujs is a separate project and should be packaged separately. It probably is a dependency of nothing but mupdf, still it was wrong of me to ship its libraries (static or otherwise) with mupdf.

Concerning Arch's policy, there is a consensus to avoid static libs whenever possible, though they are tolerated when there is no dynamic counterpart. Nothing more. Of course a mujs or mujs-git package in the AUR would be a very welcome addition.

tutu commented on 2016-01-09 05:58

Hi vesath - Thanks for the reply, I really appreciate your comment. I'm current using llpp-git package and the current maintainer (drrossum) suggested ( to switch the required dependency from mupdf to mupdf-git. llpp uses most up to date mupdf libs and other third party libs, such as, mujs.

Do you think it would be wise in creating a package in AUR for mujs to address this issue? The have mujs source here, so, perhaps one could create a mujs-git? Or this is not recommend by Arch community?

Thanks for the advice about `make install-nacl-libs`. I will do some research and see if solves my problem. Thanks again.