Bug#754463: RFS: pdf2htmlex/0.11+ds-1
* Johannes Schauer <j.schauer@email.de>, 2014-07-12, 09:40:
Hmm, there is no protection against the two versions getting of sync.
Which means that there is no guarantee that we are shipping source for
the minified version. :(
But setting "Built-Using: pdf.js" would guard against that, would it
not?
It would guard against the possibility of losing source.
But it could still happen that compatibility.js and compatibility.min.js
versions (in /usr/share/pdf2htmlEX/) don't match.
Is the non-minified version used by pdf2htmlEX at runtime at all? I
think it isn't, but I could be wrong. If it's not, then maybe get rid of
the symlink, and drop libjs-pdf from Depends?
I filed a wishlist bug against pdf.js (#754533) and at the same time
introduced a "Built-Using: pdf.js".
I don't think it worked:
dpkg-genchanges: warning: unknown information field 'Built-Using' in input data in general section of control info file
Built-Using should be used in the binary stanza, not in the source
stanza. Please see Policy §7.8.
uscan: error: mk-origtargz --package pdf2htmlex --version 0.11 --compression gzip --directory . --copyright-file debian/copyright .//coolwanglu/pdf2htmlEX/archive/pdf2htmlEX-0.11.tar.gz gave error exit status 2
[…]
The problem was created because the uscan manpage explicitly recommends
to use a filenamemangle for github projects. Apparently this does the
wrong thing as it also affects the filename used in the download url.
Not quite. AIUI, the problem is that uscan expects that filenamemangle
will strip directory components from the filename. The uscan manpage
suggests using
filenamemangle=s/(?:.*)?v?(\d[\d\.]*)\.tar\.gz/<project>-$1.tar.gz/
which strip them (note ".*"), but your filenamemangle wouldn't.
That said, the fact that uscan doesn't strip directory components after
applying filenamemangle sounds like a bug in uscan, with potential
security implications...
--
Jakub Wilk
Reply to: