Bug#1130768: use the libjs-pdf package instead of in-tree bundled blobs
John Scott
jscott at posteo.net
Sat Mar 14 22:21:58 GMT 2026
Source: webkit2gtk
Severity: normal
User: debian-qa at lists.debian.org
Usertags: source-contains-prebuilt-javascript-object
X-Debbugs-Cc: pdf.js at packages.debian.org
Right now WebKitGTK uses Mozilla's PDF.js and keeps it in the source tree at Source/ThirdParty/pdfjs/. The README.webkit file there says:
> Because the build process for PDF.js depends on a large number of Node.js dependencies, we choose to build from upstream's prebuilt "dist" releases rather than the original source code.
> This is not ideal and possibly violates the packaging requirements of most major Linux distributions. However, requiring a huge number of Node.js packages would surely result in most distributions disabling the PDF support altogether.
Has that obstacle been surmounted? Debian has a libjs-pdf package already, and by using that any doubt about the wholesomeness of these bundled sources can be alleviated. The contents of /usr/share/javascript/pdf/ look like they correspond to this WebKit subdirectory. The README.webkit file does specify steps to update the bundled PDF.js but there don't seem to be patches or meaningful changes; it's more for the sake of tidyness, it seems. The packaged version of PDF.js ought to work without tweaks.
To be honest, I can't find which WebKit binary package(s) get this copy of PDF.js bundled into them or where they are. The remaining choice is whether WebKit should use the installed libjs-pdf at runtime, or whether to use libjs-pdf at build-time and have those artifacts folded into the binary package.
The latter would probably be very easy, maybe replacing the files in Source/ThirdParty/pdfjs/ with symlinks to the system-wide files so the build process will use those. Our WebKit package may need to set Built-Using or Static-Built-Using depending on particular details of licenses and such.
In principle it would be nice if WebKit could simply use what's in /usr/share/javascript/ directly, similar to how system-wide WebExtensions work. This would probably need upstream coordination and since I can't even find where PDF.js is lurking in the binaries now, this is kind of out of the question.
Has this been brought up before? I couldn't find a bug, but it looks like we're very fortunate to have PDF.js already in Debian and a clear set of instructions for substituting our version for theirs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-webkit-maintainers/attachments/20260314/1f0d6919/attachment.sig>
More information about the Pkg-webkit-maintainers
mailing list