Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8

[Simon McVittie]

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:
> https://salsa.debian.org/freedesktop-team/poppler/-/commit/7929aa2d5ec9464fea755f622319d224787c4110

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

    elpa-pdf-tools-server
        \- old libpoppler-glib
        |   \- libpoppler95
        \- libpoppler102

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
> libpoppler-glib.

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).

    smcv