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

Simon McVittie smcv at debian.org
Mon Feb 15 12:07:13 GMT 2021

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.
> 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'm increasingly tempted to open a debhelper feature request asking for
> dh_shlibdeps to strengthen intra-source-package dependencies to be in
> lockstep by default, because this seems to be more common than strict
> separation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-d-shlibs.local-Upgrade-all-binary-packages-in-lockst.patch
Type: text/x-diff
Size: 1978 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-freedesktop-maintainers/attachments/20210215/bee01648/attachment.patch>

More information about the Pkg-freedesktop-maintainers mailing list