As someone who's been watching this bug for a while, I feel the need to
interject to defend the Debian maintainers before they're alienated.
Given how trivial a poppler-less xpdf package would be to create, the
Debian maintainers probably have good reason not to package one. I'm
guessing this is due to the fact that poppler/xpdf has had more than its
fair share of security issues, and justifying a second copy of that code
in Debian, and having to take responsibility for applying any security
fixes to that code is too much work to justify for a single package,
versus a library.
As for the patch, yes it contains very few functional changes, but
being too large by itself *is* enough to reject. The diff is extremely
unlikely to apply cleanly to new versions of xpdf making it hard to port
but even more problematically, it'll need to be updated each poppler
release, and these tend to change the API a lot. What happens when
functionality not present in the current version of poppler finally
propagates in from xpdf, and configuration variables and methods are
duplicated in the xpdf-specific global parameters class (e.g.
enableT1lib)? xpdf and poppler will end up working with independent
copies of the configuration variables and accessor methods. This is the
fragile base class problem.
This problem isn't an ABI issue, it's a software engineering
dysfunction issue. Even forking xpdf and having that fork target
poppler, as has been done/attempted before[1,2] is potentially
problematic. In any normal development situation packages using
libraries will only depend on functionality present in the libraries it
uses at the time of release. Xpdf using poppler is the opposite. New
releases of xpdf introduce functionality that the viewer depends on. Any
version of xpdf using poppler will have to interact with versions of
poppler that haven't yet incorporated this functionality.
My point is that this problem is non-trivial to solve, and the Debian
maintainers are already going above and beyond in producing a package
that uses poppler. As far as I can see, the only people in a position to
correctly maintain an xpdf version that works correctly with poppler is
the poppler devs themselves. They care enough about the xpdf code base
to fork it, perhaps they'll appreciate that trying to support packaging
both xpdf and their code is hurting the former. Maybe this could be
placed in a politely worded e-mail from a Debian maintainer.
Lastly, despite the issues mentioned above I've also created a stripped
down xpdf which doesn't replicate/extend the GlobalParams class. It
stores xpdf-specific configuration variables in a new class, and only
sets configuration variables from the parsed config file that can be
accessed via the methods poppler's GlobalParams exposes [3]. This is
primarily just so I can get a working version of xpdf on Ubunutu (and
hence uses poppler 0.20) but I thought I might as well mention it.
Francis
[1] https://github.com/rbrito/xpdf-poppler
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351279
[3] https://github.com/FrancisRussell/xpdf-lite
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
