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
