FS#50216 - [mupdf] packaging is overly complex, and misses mujs

Attached to Project: Community Packages
Opened by Andrew (abrouwers) - Sunday, 31 July 2016, 15:00 GMT
Last edited by Christian Hesse (eworm) - Tuesday, 27 December 2016, 14:30 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

I'd like to propose re-simplifying the mupdf package:

1) First, mujs was lost and no longer exists in any package, as far as I can see. "llpp" needs this to build, and it doesn't add a lot of extra space (see: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/mupdf&id=9cd32fde9e45fa2404a3b29951e374d643a3fdb2 )

2) The split packaging seems to be done in an effort to reduce space, but it's pretty confusing.
* mupdf-gl vs mupdf - based on the description, it's vague about what the differences are, and why one might want one over the other
* None of the split packages have reverse dependencies, and are pretty small - especially because mupdf is mostly used as a dependency to BUILD mupdf-based viewers (see: zathura, llpp)

I understand splitting some rarely-used tools, but IMO, the base "mupdf" package should include everything else, including mujs.
This task depends upon

Closed by  Christian Hesse (eworm)
Tuesday, 27 December 2016, 14:30 GMT
Reason for closing:  Not a bug
Additional comments about closing:  We keep things as-is.
Comment by Andrew (abrouwers) - Sunday, 31 July 2016, 15:01 GMT
FWIW, the arch package is even more complex than what debian does :-)

https://packages.debian.org/source/sid/mupdf
Comment by Gaetan Bisson (vesath) - Sunday, 31 July 2016, 19:52 GMT
Seems to me the problem Christian was trying to solve by adding that "complexity" is the insane size a vanilla install of mupdf takes.
Upstream refuses to help build a shared library, so all the code (the entirety of mujs, a full-featured CJK font, etc.) ends up in each binary.
If we ship them all in one package, as we normally would, it'd easily be about 200 MB.
I've had the same issue with mupdf-git on AUR and decided not to embed the CJK font to help mitigate this.
However I believe the correct fix would be to find a way to build a shared library and use that in mupdf, mutools, zathura, etc.
Comment by Christian Hesse (eworm) - Monday, 01 August 2016, 13:56 GMT
> 1) First, mujs was lost and no longer exists in any package, as far as I can
> see. "llpp" needs this to build, and it doesn't add a lot of extra space
> (see: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/mupdf&id=9cd32fde9e45fa2404a3b29951e374d643a3fdb2 )

I think what you refer to by "mujs" is part of the library. So it is contained in the library (and as it is linked statically in every binary as well). The AUR package "llpp" builds just with with its dependency on libmupdf. So what's wrong there?

> 2) The split packaging seems to be done in an effort to reduce space, but it's pretty confusing.
> * mupdf-gl vs mupdf - based on the description, it's vague about what the differences are, and why one might want one over the other

The first uses an OpenGL backend, the second does not. So what is vague here?

> * None of the split packages have reverse dependencies, and are pretty small

No reverse dependencies as everything is linked statically. But nothing is "pretty small" here... That's why I split it.

> - especially because mupdf is mostly used as a dependency to BUILD mupdf-based viewers (see: zathura, llpp)

Packages that need mupdf for building should have a build dependency on libmupdf.

Patches for a shared library are welcome. Until anybody provides these the package will be split.

So... Any outstanding issues?

Loading...