Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, 2017-03-04 at 08:02 -0700, Sean Whitton wrote:
> Dear Jason,
>
> On Sat, Mar 04, 2017 at 12:00:19AM -0600, Jason Crain wrote:
> > If you're going to adopt the Xpdf package, I thought you might want
> > to
> > know a little about Xpdf first and why the Debian package is the
> > way
> > that it is. The Debian package modifies Xpdf to make it use
> > poppler
> > (https://poppler.freedesktop.org) for rendering instead of using
> > it's
> > own internal code. I think this was done for security and bug
> > fixes,
> > and because the poppler upstream is more responsive than Xpdf.
> >
> > Poppler is a fork of Xpdf. Before poppler, it was common for
> > applications which wanted to read PDFs to embed a copy of the Xpdf
> > code.
> > Poppler was created to turn sections of the Xpdf code into a
> > library so
> > that it could be more easily reused, to have a centralized place
> > for
> > development, and to put APIs over the code.
I know about all this already. In fact I did port the code in January
2014 when it (3.03-11) was about to be removed from testing for Jessie.
See the thread starting at https://lists.debian.org/debian-devel/2014/0
1/msg00254.html. These patches were not needed/accepted since somebody
else had done the same work resulting in version 3.03-12. (I was never
asked to publish my patches, and I did not check them versus the ones
that went into the Debian package.)
> > Debian's Xpdf is significantly different from upstream Xpdf. The
> > package has build rules and patches which modify the code to be
> > compatibile with poppler. Also, since the poppler devs do not
> > guarantee
> > stability for the old Xpdf functions, because those functions were
> > never
> > intended to be a stable interface, the patches will occasionally
> > need to
> > be modified to match any changes in poppler.
This is the big problem, the two code bases are diverging. See a good
description about the status of xpdf from December 2013:
https://www.agwa.name/blog/post/the_sorry_state_of_xpdf_in_debian
After my asking around to poppler and upstream Glyph & Cog, LLC, in the
name of Derek B. Noonburg, created a new upstream release, 3.04. See
the CHANGES file (changelog in the debian package) in the upstream
tarball for the latest fixes.
However, Debian chose to continue trying to catch up with the patches
to libpoppler, in my opinion a very bad choice. The current state is
really bad, most of the bugs are due to the use of the libpoppler
backend.
> Thank you very much for this input, Jason.
>
> It sounds like the source should not in fact be repacked. What do
> you
> think, Svante?
The solution I've chosen is to remove the poppler backend completely.
That fixes 11+ important and normal bugs (and probably many minor and
wishlist ones too, I haven't looked into that yet)
If somebody wants a poppler-based xpdf, it should be renamed to
something else, e.g. ppdf, and maybe even be integrated in the poppler
upstream code. Trying to merge xpdf frontend with the poppler backend
is just a loosing battle.
Just to give you a look into what I've done, I uploaded xpdf-3.04.real-
5 to mentors.debian.net. (Some minor changes are still needed I think,
before I'm happy with the result).
As said before: debdiff is not possible to use against 3.04-4, but it
is with 3.04.real-4 and 3.04-5.
Thanks for your attention,
Svante
Reply to: