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 attachment 135307 [details, diff] 30_libpoppler_0.5.4
Created attachment 135309 [details, diff] 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.
this is now what is done for TeX Live 2009; 2 years later, this can be finally closed :)
