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.
>From bc7c009360869d8985462bab43fc24b1685df08a Mon Sep 17 00:00:00 2001
From: Simon McVittie <s...@debian.org>
Date: Mon, 15 Feb 2021 11:53:51 +0000
Subject: [PATCH] d/shlibs.local: Upgrade all binary packages in lockstep
Like many projects where one source package builds multiple binary
packages, poppler has private headers that share non-public interfaces
between its binary packages. Upgrading one binary package from this
source without upgrading the others is not something that its upstream
developers are ever going to test or support, and neither should we.
Closes: #969537
---
debian/changelog | 12 ++++++++++++
debian/shlibs.local | 4 ++++
2 files changed, 16 insertions(+)
create mode 100644 debian/shlibs.local
diff --git a/debian/changelog b/debian/changelog
index d65fa9f..54c96af 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+poppler (20.09.0-3.2) UNRELEASED; urgency=medium
+
+ * d/shlibs.local: Upgrade all binary packages in lockstep.
+ Like many projects where one source package builds multiple binary
+ packages, poppler has private headers that share non-public interfaces
+ between its binary packages. Upgrading one binary package from this
+ source without upgrading the others is not something that its upstream
+ developers are ever going to test or support, and neither should we.
+ (Closes: #969537)
+
+ -- Simon McVittie <s...@debian.org> Mon, 15 Feb 2021 11:44:22 +0000
+
poppler (20.09.0-3.1) unstable; urgency=medium
* debian/tests: make autopkgtests cross-test-friendly (Closes: #969726)
diff --git a/debian/shlibs.local b/debian/shlibs.local
new file mode 100644
index 0000000..af3275a
--- /dev/null
+++ b/debian/shlibs.local
@@ -0,0 +1,4 @@
+libpoppler 102 libpoppler102 (= ${binary:Version})
+libpoppler-cpp 0 libpoppler-cpp0v5 (= ${binary:Version})
+libpoppler-glib 8 libpoppler-glib8 (= ${binary:Version})
+libpoppler-qt5 1 libpoppler-qt5-1 (= ${binary:Version})
--
2.30.0
