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

[Pino Toscano]

Hi Simon,

In data lunedì 15 febbraio 2021 13:07:13 CET, Simon McVittie ha scritto:
> Control: retitle 969907 epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
> Control: tags 969907 + patch
> 
> Sorry, this reply should have gone to the clone in libpoppler-glib8,
> not to the archived original bug in epdfinfo (which I don't think was
> ever really an epdfinfo bug).
> 
> On Mon, 15 Feb 2021 at 12:03:35 +0000, Simon McVittie wrote:
> > I don't think this is actually about whether libpoppler-glib added new ABI
> > without bumping the shlibs version - it has a .symbols file that tracks
> > the version in which each public symbol was added.
> >
> > Instead, I think this is about private symbols and partial
> > upgrades. libpoppler102 and libpoppler-glib8 come from the same
> > source package, so libpoppler-glib8 is very likely to make assumptions
> > about private implementation details of the corresponding version of
> > libpoppler102; many of the source files glib/*.cc that get compiled into
> > libpoppler-glib8 have #include "poppler-private.h". This is fine if
> > everyone does an `apt upgrade` with no pinning, but breaks down if people
> > do arbitrary partial upgrades with pinning or interactively (leading to a
> > "Frankendebian" system).
> > 
> > If the upstream developers of poppler are asked to support a system where
> > libpoppler102 and libpoppler-glib8 are at different versions, I'm pretty
> > sure the first thing they will say is "don't". I think the same is
> > appropriate for downstreams.

Yes, this is correct.

> > 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
and indeed:

  $ apt-cache show libpoppler-glib8
  Package: libpoppler-glib8
  Source: poppler
  Version: 20.09.0-3.1
  [...]
  Depends: libpoppler102 (= 20.09.0-3.1), libc6 (>= 2.14), libcairo2 (>= 1.12.0), libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.41), libstdc++6 (>= 5.2)
  [...]

So the strict dependency is already in place. If I check the version
that was reported in the bug report, I see:

  $ debsnap -d . libpoppler-glib8 -a amd64 0.85.0-2
  $ dpkg -I libpoppler-glib8_0.85.0-2_amd64.deb
   Package: libpoppler-glib8
   Source: poppler
   Version: 0.85.0-2
   Depends: libpoppler95 (= 0.85.0-2), libc6 (>= 2.14), libcairo2 (>= 1.12.0), libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.41), libstdc++6 (>= 5.2)

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.

This was also a problem in case there was an incomplete dist-upgrade to
the newer poppler, so the newer libpoppler was pulled in but the newer
libpoppler-glib not. I remember having seen this in the past (when I
used to maintain poppler), but it happened once and indeed it was due
to an incomplete dist-upgrade. IMHO this will not happen in
oldstable->stable dist-upgrades, as everything will be build with the
newer libraries, and hopefully the dist-upgrade will be done fully.

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.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-freedesktop-maintainers/attachments/20210218/28b343cf/attachment.sig>