Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Simon McVittie]

Control: retitle -1 inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

On Sat, 10 Apr 2021 at 22:13:13 +0200, Ivo De Decker wrote:
> Install inkscape on a buster system. The pdf David attached can be opened
> without issue. Upgrade only inkscape to bullseye (letting apt pull in the
> dependencies, which include libpoppler102 but not the newer libpoppler-glib8).
> When opening the pdf inkscape closes with an error, and the kernel reports:
> inkscape[9032]: segfault at 9 ip 00007fad9e3e1d3e sp 00007fff5127ae30 error 4 in libpoppler-glib.so.8.10.0[7fad9e3c4000+27000]
> 
> Installing the new libpoppler-glib8 fixes the issue.
> 
> A way to fix this, is to add a dependency to the newer libpoppler-glib8 as
> well (as was done for elpa-pdf-tools-server). Obviously, it would be nice to
> have an elegant way to handle this automatically at build time to make sure
> the dependencies are correct, without having to add them manually.

Should libpoppler102 get a Breaks: libpoppler-glib8 (<< 20.08.0-1~), where
that version was the first one to have the libpoppler102 SONAME? That
would ensure that the bad partial upgrade you describe can't happen,
because if a dependent package uses libpoppler102 ABI directly, and
also uses libpoppler indirectly via libpoppler-glib8, then it's the
same libpoppler.

Or, would this work?

* in src:poppler libpoppler-glib8.symbols.in, bump the version on every
  symbol to at least 20.08.0-1~ (the version that had the most recent
  SONAME bump) and upload to unstable
* binNMU the dependent packages elpa-pdf-tools-server, gambas3-gb-poppler
  and inkscape

That way, the binNMU'd versions of the dependent packages would have:

    Depends: libpoppler-glib8 (>= 20.08.0-1~), libpoppler102 (>= x)

and the bad partial upgrade you describe could not happen, because the
dependent package (inkscape in your example) would pull in the new
libpoppler-glib8 in addition to the new libpoppler102.

For completeness, maybe it would make sense to give libpoppler-cpp0v5 and
libpoppler-qt5-1 the same treatment as libpoppler-glib8 (whatever that is),
since they could suffer from the same bug if an application calls into
libpoppler both directly and via libpoppler-cpp0v5 or libpoppler-qt5-1 -
although I don't know whether that happens in practice.

    smcv