Thanks for the information. That's a worryingly high wall to climb and I'm concerned about implications for other platforms as well.
I would appreciate if you can see about getting an exception, but I think I will change PyMuPDF to an optional but recommended dependency fairly soon. I haven't made a major investment in it as yet with new code, but it does provide some powerful features that would be a major engineering effort to replicate and are likely not going to materialize in another open source library anytime soon. (Specifically: incremental updates, safe editing of PDF/A, PDF object garbage collection, fast rasterizing, robust text extraction.) The most commonly used Python PDF library, PyPDF2, is essentially unmaintained and in poor shape. On Mon, 26 Mar 2018 at 10:32 Sean Whitton <spwhit...@spwhitton.name> wrote: > control: reassign -1 wnpp > control: forcemerge 841404 -1 > > Dear James, > > On Mon, Mar 26 2018, James R. Barlow wrote: > > > In v6.0.0, which addresses and hopefully fixes #888917, I have > introduced a > > new dependency on PyMuPDF (Python bindings for MuPDF). Unfortunately > PyMuPDF > > isn't available in Debian as yet (I have checked there is no > python3-pymupdf). > > Thank you for working on that bug! > > > The build procedure should go like this: > > > > - download/unpack MuPDF to mupdf/ > > - download/unpar PyMuPDF to pymupdf/ > > - cp pymupdf/fitz/_mupdf_config.h mupdf/include/mupdf/fitz/config.h > > - export CFLAGS=-fPIC > > - make HAVE_X11=no HAVE_GLFW=no HAVE_GLUT=no > > - patch pymupdf/setup.py to point library_dirs and include_dirs to the > > output of mupdf/ build > > > > The reason for this circumlocution is that the vendor of MuPDF, Artifex, > > does not provide or support dynamic libraries or a stable ABI, and > > compiling the Python bindings requires a dynamic library. Perhaps as a > way > > to warn people about their stance, they don't enable -fPIC by default and > > link their application statically. > > > > This means that unfortunately, one cannot link to libmupdf-dev (and > > actually, I'm not sure if libmupdf-dev serves any purpose at all, unless > > it were rebuilt with -fPIC). Certainly if the maintainers of this > > package could be persuaded to build it with -fPIC that would make this > > much easier. > > > > I did try to build with it with Debian sid against the libmupdf-dev > > library. The error, as with Ubuntu, is: > > relocation R_X86_64_PC32 against symbol `fz_empty_irect' can not be > > used when making a shared object; recompile with -fPIC > > If we followed this build procedure then there would be two copies of > mupdf in Debian: in the mupdf package and in the pymypdf package. This > is disallowed by Debian Policy 4.13 because it makes it harder to apply > security updates. And for any libraries that read PDFs, security is a > real concern (see the mupdf bug list: there have been several CVEs). > > Further, Policy 10.2 explicitly forbids building static libraries with > -fPIC, unless an exception thought warranted in discussion on our main > development mailing list. > > I think this might be a case where we can argue for that exception, but > I'm going to need to do some reading before I can be sure that that's > what we should do. So unfortunately OCRmyPDF is probably going to be > out-of-date in Debian for a while. > > > I'm happy to help with the packaging of this dependency, and I got it the > > process working for Python binary wheels already. However, I don't > really > > know much about Debian processes and policy. > > Thanks. The best place to start would probably be our libraries policy, > section 10.2 of Debian Policy.[1] And the following relevant bugs: > #617253, #719351, #841403. > > [1] https://www.debian.org/doc/debian-policy/ > > -- > Sean Whitton >
