Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
pino at debian.org
Thu Feb 18 11:06:58 GMT 2021
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:
$ apt-cache show libpoppler-glib8
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Pkg-freedesktop-maintainers