Package: libpsm2-2-compat,libpsm-infinipath1 Severity: important X-Debbugs-Cc: [email protected], [email protected], [email protected]
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
