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
Opened by Andrew (abrouwers) - Sunday, 31 July 2016, 15:00 GMT
Last edited by Christian Hesse (eworm) - Tuesday, 27 December 2016, 14:30 GMT
|
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.
Tuesday, 27 December 2016, 14:30 GMT
Reason for closing: Not a bug
Additional comments about closing: We keep things as-is.
https://packages.debian.org/source/sid/mupdf
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.
> 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?