On Thu, 18 Feb 2021 at 12:06:58 +0100, Pino Toscano wrote: > In data lunedì 15 febbraio 2021 13:07:13 CET, Simon McVittie ha scritto: > > > 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
Sorry, I didn't spot that the interdependencies were already strict. I'll close the MR. > 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. So elpa-pdf-tools-server is linked to libpoppler-glib, and because the (parts of the) libpoppler-glib API that it uses has not changed for a while, it is happy with an old version; but then during a partial upgrade, it can get this elpa-pdf-tools-server \- old libpoppler-glib | \- libpoppler95 \- libpoppler102 and the two copies of libpoppler fight? That seems entirely plausible, and I don't immediately see a way to fix it without adding Breaks (which would force a lockstep upgrade, somewhat defeating the purpose of SONAMEs). GNOME had similar issues during the libffi transition, where gjs' direct use of libffi conflicted with its indirect use via GLib, and I think we ended up adding Breaks to force the broken combinations not to happen. > 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. That does look like emacs-pdf-tools is doing things that aren't guaranteed to work, yes, and the solution is indeed to improve libpoppler-glib to do what emacs-pdf-tools needs (and then make emacs-pdf-tools depend on the newer version instead of working around older versions). smcv