Bugzilla Bug 198236

app-text/texlive-core ships a copy of Xpdf while it could depend on and link
against the system's xpdf or poppler library.

Debian currently ships patches to link against multiple versions of the poppler
library, see attached below.

Created an attachment (id=135307) [details]
30_libpoppler_0.5.4

Created an attachment (id=135309) [details]
30_libpoppler_0.5.9

is there any noticeable improvement to use poppler vs libxpdf ?

I had seen these patches, but refrained me from touching them because debian
usually doesnt care much about compatibility with other libs that the ones they
ship in the same repository, while we should make sure it works with any
poppler version.
Having a conditional patch depending on libpoppler version is definitely a
"no", I didnt check if the 0.5.9 patch works against 0.6.1.

However, doing like that is probably a very good enhancement in order to put
the beast on a diet.

(In reply to comment #3)
> is there any noticeable improvement to use poppler vs libxpdf ?

AFAIK app-text/xpdf doesn't provide a libxpdf. Or do you mean the included
"libxpdf"?

> I had seen these patches, but refrained me from touching them because debian
> usually doesnt care much about compatibility with other libs that the ones they
> ship in the same repository, while we should make sure it works with any
> poppler version.
> Having a conditional patch depending on libpoppler version is definitely a
> "no", I didnt check if the 0.5.9 patch works against 0.6.1.

Seems libpoppler changed its API in 0.5.1 and 0.5.9. There's no way to predict
or work around a change like that, but I agree it would be the best way to go
if we had only one patch that would figure out the correct poppler version on
compile time.

> However, doing like that is probably a very good enhancement in order to put
> the beast on a diet.

++ Very much lessening the load on security support.

(In reply to comment #4)
> (In reply to comment #3)
> > is there any noticeable improvement to use poppler vs libxpdf ?
> 
> AFAIK app-text/xpdf doesn't provide a libxpdf. Or do you mean the included
> "libxpdf"?

yes I meant poppler vs the included libxpdf, apart that nobody likes packages
that include eveything rather than using the system ones. This patch makes it
using a different library so I didnt spend much time trying to make it work.

Anyway, just for the sake of having texlive-core as small as possible, this one
is on my hunt list; but there are a few others (cjk-latex, ps2eps) that will
get the same treatment. If you have any other improvments like that, please let
me know, and this includes stuff that could have their own ebuild but are not
in the tree.

(In reply to comment #3)
> is there any noticeable improvement to use poppler vs libxpdf ?

Most projects did switch from xpdf to poppler because of the many unsolved
security issues in xpdf, did they not?
Well, that is what I think I read long time ago. I may be wrong. :)

I would really like to see texlive utilizing system libpoppler.

I will test this patch from fedora:
http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/texlive/devel/texlive-poppler.patch

And with this patch to poppler texlive-core compiles.
http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/poppler/devel/poppler-ObjStream.patch

(In reply to comment #6)
> (In reply to comment #3)
> > is there any noticeable improvement to use poppler vs libxpdf ?
> 
> Most projects did switch from xpdf to poppler because of the many unsolved
> security issues in xpdf, did they not?

bah, afaik, poppler & libxpdf get the same security issues as they have the
same codebase. The problem is more about included libs.

> I would really like to see texlive utilizing system libpoppler.

Me too, but the problem is that I dont see any poppler related changes upstream
(at least in texlive's repo, perhaps xetex & pdftex repos have been switched, I
dont know). That would mean maintaining homebrew patches for something very
important (pdf output) which I'm not really fan.

debian's patch disabled some programs due to api incompatibility, fedora's
patch requires to patch poppler (which exports more structures and which would
require manual abi/api checking); I would *really* prefer seeing upstream
switching instead of patching it myself in gentoo's repos.

We could try to contact upstream to allow using system poppler and see what is
holding them back. Talking to the other distros sounds promising, too -- Maybe
we can figure out where problems lie and agree on a solution.

Alexis, did you try contacting upstream or other distros? How would you like to
proceed, because moving this forward should be a priority to muchly ease
maintenance security-wise.

(In reply to comment #10)
> Alexis, did you try contacting upstream or other distros? How would you like to
> proceed, because moving this forward should be a priority to muchly ease
> maintenance security-wise.

nope I didnt. I guess I could ask on the new texlive-distro ml to know what
others are doing and why, etc.

However, I'm still not entirely convinced by poppler api stability :/

(In reply to comment #11)
> nope I didnt. I guess I could ask on the new texlive-distro ml to know what
> others are doing and why, etc.

Please do :-)

> However, I'm still not entirely convinced by poppler api stability :/

You are right there have been api changes in the past, I can't say anything
against it. And they sure are annoying! I would just assume that maintaining
textlive specific patches to upgrade to a new api for a limited time would be
less annoying than merging xpdf security patches everywhere and have users
upgrade the whole tex.

Ok, so here comes a follow up:

First of all, if a few of those things are ok for a binary distro, for me it's
definitely not:
- linking to a library without checking for it
- modifying a library to make it export more symbols than what upstream said
- making some program use another library without upstream ack & support

The discussion started at:
http://tug.org/pipermail/tldistro/2008q2/000010.html

It was very interesting, then I had less time but proposed some patches then
got no more answer, probably because they don't have much time either.

One important thing to note is that those patches won't work with poppler 0.8.x
since, once again, they changed their API... poppler people seem to have lot of
fun breaking the API and reinventing the wheel (wait.. it won't build against
it because they thought it was wise to use a c++ class to abstract FILE* and
fprintf... what a brilliant idea!). I'm now thinking that TeX is not the good
target audience for such fun and will not continue to push for that. If anyone
wants to see pdftex, xetex, and in the end texlive use poppler, please push
that upstream.

Since texlive 2008 is almost out and, to my knowledge, poppler support hasn't
been pushed there, I'm afraid we will still use libxpdf for this release.

Thanks for bringing it upstream, and the link. The behaviour of changing the
API in poppler is very unfortunate. It only increases the effort of keeping TeX
working against it.
But from what I read in the thread, the other maintainers also were eager to
clear up remaining problems.

I've added dev-tex/{lua,pdf}tex as standalone packages that link against
poppler instead of the bundled libxpdf.

What I'm planning to do for tl20008:
leave the bundled xpdf as default
use only the standalone luatex ebuild
add an eselect-module for pdftex so that it can be switched and more easily
updated

if everything goes well, i'll probably drop pdftex from texlive.

I think the only one remaining will be xetex, which should be much easier to
handle.