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
signature.asc
Description: This is a digitally signed message part.
