Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Ivo De Decker]

Hi Simon,

There is a theoretical and a practical aspect to this issue. From a 
theoretical point of view, the dependency relations should not be 
stricter than necessary, to allow partial upgrades and to avoid 
complicating migration to testing of library transitions.

On 4/11/21 12:37 PM, Simon McVittie wrote:
>> A way to fix this, is to add a dependency to the newer libpoppler-glib8 as
>> well (as was done for elpa-pdf-tools-server). Obviously, it would be nice to
>> have an elegant way to handle this automatically at build time to make sure
>> the dependencies are correct, without having to add them manually.
> 
> Should libpoppler102 get a Breaks: libpoppler-glib8 (<< 20.08.0-1~), where
> that version was the first one to have the libpoppler102 SONAME? That
> would ensure that the bad partial upgrade you describe can't happen,
> because if a dependent package uses libpoppler102 ABI directly, and
> also uses libpoppler indirectly via libpoppler-glib8, then it's the
> same libpoppler.

The issue only happens if the same package depends on both libpoppler 
and libpoppler-glib, so forcing libpoppler and libpoppler-glib to be 
upgraded at the same time, is more strict than is theoretically needed. 
Also, I wonder if this would still allow the reverse issue to happen:

If an old inkscape is linked against the old libpoppler-glib8 and 
libpoppler95, installing libpoppler102 would force libpoppler-glib8 to 
be upgraded, and the old inkscape would link against the old libpoppler 
and the new libpoppler-glib, causing the same issue (I didn't test if 
this happens in practice).

> Or, would this work?
> 
> * in src:poppler libpoppler-glib8.symbols.in, bump the version on every
>    symbol to at least 20.08.0-1~ (the version that had the most recent
>    SONAME bump) and upload to unstable

This would cause every package that links against libpoppler-glib8, but 
not (directly) against libpoppler to depend on the newer version of 
libpoppler-glib8, even if that's not necessary. In practice, this would 
severely reduce the usefulness of using the symbols file. And make 
partial upgrades (for users) and smooth updates (for library transitions 
to testing) much harder.

> * binNMU the dependent packages elpa-pdf-tools-server, gambas3-gb-poppler
>    and inkscape
> 
> That way, the binNMU'd versions of the dependent packages would have:
> 
>      Depends: libpoppler-glib8 (>= 20.08.0-1~), libpoppler102 (>= x)
> 
> and the bad partial upgrade you describe could not happen, because the
> dependent package (inkscape in your example) would pull in the new
> libpoppler-glib8 in addition to the new libpoppler102.

It would create the desired dependency, but I'm not sure if this is 
better than just manually adding it to the 2 remaining packages we are 
aware of (especially at this stage of the freeze).

> For completeness, maybe it would make sense to give libpoppler-cpp0v5 and
> libpoppler-qt5-1 the same treatment as libpoppler-glib8 (whatever that is),
> since they could suffer from the same bug if an application calls into
> libpoppler both directly and via libpoppler-cpp0v5 or libpoppler-qt5-1 -
> although I don't know whether that happens in practice.

Well, I suspect there are actually quite a lot of these issue a our 
packages, but that many of them are not usually detected. Doing partial 
upgrades might result in binaries being (transitively) linked to 
different (incompatible) version of the same library. Even when that 
happens, it's not always immediately obvious. In the inkscape example, 
the issue only shows up when you try to open a pdf, not when you just 
start the program. So the fact that the programs runs successfully in 
some cases, doesn't guarantee that the issue isn't present.

This issue reminds me of https://bugs.debian.org/962320, which is 
somewhat similar, because multiple versions of the same boost library 
are linked into the same binary. In that case, this was detected because 
some of the packages weren't rebuilt yet, but I suspect it might be 
possible to trigger a similar issue by doing a partial upgrade of a 
package that (transitively) pulls in a number of boost libraries.

This brings me to the practical aspect of this issue: we try to support 
partial upgrades, and generate the correct dependency relation to make 
sure that unsupported combinations of packages can't be installed at the 
same time. However, we currently don't have a way to generate these 
dependencies when multiple interdependent libraries are involved. I'm 
unsure how we could handle this in general, but it certainly would be 
nice to have a way to do so. For now, though (and especially for 
bullseye), I think we should accept that we aren't going to solve this 
issue in general. The best we can do, is to try to fix obvious cases 
where we are aware of the issue. In other cases, we'll probably need to 
advise our users to do a full upgrade instead of a partial one.

Cheers,

Ivo