Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
smcv at debian.org
Thu Feb 18 15:33:23 GMT 2021
On Thu, 18 Feb 2021 at 12:06:58 +0100, Pino Toscano wrote:
> In data lunedì 15 febbraio 2021 13:07:13 CET, Simon McVittie ha scritto:
> > > In Cairo and Pango (which have a similar structure with multiple binary
> > > packages making use of each other's implementation details), I added a
> > > debian/shlibs.local to make sure the binary packages all get lockstep
> > > dependencies. I think the same technique would be appropriate here. See
> > > attached.
> I honestly do not understand how this is even a problem, considering I
> fixed this more than 5 years ago:
Sorry, I didn't spot that the interdependencies were already strict. I'll
close the MR.
> I'd rather think that the situation happened because
> elpa-pdf-tools-server links both to libpoppler and libpoppler-glib:
> the rebuild against poppler 20.09.0 (i.e. libpoppler102) make
> elpa-pdf-tools-server link to libpoppler102 (forcing the newer
> dependency to it), and setting an old dependency for libpoppler-glib
> because there is no need for a newer version.
So elpa-pdf-tools-server is linked to libpoppler-glib, and because the
(parts of the) libpoppler-glib API that it uses has not changed for a
while, it is happy with an old version; but then during a partial
upgrade, it can get this
\- old libpoppler-glib
| \- libpoppler95
and the two copies of libpoppler fight?
That seems entirely plausible, and I don't immediately see a way to
fix it without adding Breaks (which would force a lockstep upgrade,
somewhat defeating the purpose of SONAMEs).
GNOME had similar issues during the libffi transition, where gjs' direct
use of libffi conflicted with its indirect use via GLib, and I think we
ended up adding Breaks to force the broken combinations not to happen.
> Another contributing factor is that emacs-pdf-tools "abuses" the
> libpoppler-glib internals, see server/poppler-hack.cc. I don't know
> why it does that, and I'd rather see the actual issues fixed in
That does look like emacs-pdf-tools is doing things that aren't guaranteed
to work, yes, and the solution is indeed to improve libpoppler-glib to do
what emacs-pdf-tools needs (and then make emacs-pdf-tools depend on the
newer version instead of working around older versions).
More information about the Pkg-freedesktop-maintainers