Bug#1036911: libpsm_infinipath alternative is incompatible with Multi-Arch
Package: libpsm2-2-compat,libpsm-infinipath1
Severity: important
X-Debbugs-Cc: glaweh@debian.org, emollier@debian.org, debian-cross@lists.debian.org
Hi Roland et al,
in Hamburg, I've been looking to cross building some openmpi-dependent
packages with Étienne Mollier. We ended up figuring that the psm
packages probably need to support Multi-Arch on the shared-library level
in order to support cross building higher up in the stack as openmpi
ends up depending on both and this is where it gets non-trivial.
So in effect, we are looking into what it would take to make these
packages Multi-Arch: same. And while that has some minor problems on
various levels, there is a bigger one sticking out and that's their use
of update-alternatives. While the actual library as is used by
downstream packages is
/usr/lib/@DEB_HOST_MULTIARCH@/libpsm_infinipath.so.@PSM_LIB_MAJOR@ and
thus is fine from a multi-arch point of view, the name of the
alternative being libpsm_infinipath.so.@PSM_LIB_MAJOR@ presents a
problem. If we were to co-install two instances of a libpsm_infinipath
implementation, those would clash on their alternative name. This is not
a new problem and it has need been solved e.g. by blas and lapack by
appending the multiarch tuple to the alternative name. In effect, doing
what they did to these packages is a prerequisite to making them
Multi-Arch: same (regardless of all the other details). Related to that
the alternative values also do not reside in multiarch locations.
They're relatively easy to move as their only consumer is the
alternative, but the alternative is a public interface used by users and
we break it both by renamining it and by moving its providers. This is
bad.
The simplest way to fix this would be waiting for an soname bump (which
breaks users anyway) and taking that as an opportunity to apply
multiarch. We fear that a soname bump is not about to be happening. So
we probably have to break it anyway as openmpi is quite of an important
piece of software. It's not clear how to migrate that properly. If the
expected number of users installing both implementations is low, we can
just break it (remove the old alternative and add a new one loosing the
user configuration state) and inform the user via NEWS.Debian. Is that
an acceptable procedure? When doing that, we probably have change both
implementations to remove all alternative providers in order to create
the new one. This will work, because update-alternatives is happy about
--remove'ing a non-existent alternative.
Do you agree with this plan? If yes, Helmut can look into writing a patch.
Helmut and Étienne from Hamburg
Reply to: