Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1148667

Bug#1036911: libpsm_infinipath alternative is incompatible with Multi-Arch

Show all headers | View raw

Hi Helmut, Étienne,

your plan is fine with me. The expected number of users installing both 
implementations is definitely low. I have no objection if you do an NMU 
once your patch is complete.

Thanks,

Roland

On 5/29/23 12:27, Helmut Grohne wrote:
> 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
>

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Bug#1036911: libpsm_infinipath alternative is incompatible with Multi-Arch Helmut Grohne <helmut@subdivi.de> - 2023-05-29 12:40 +0200
  Bug#1036911: libpsm_infinipath alternative is incompatible with Multi-Arch Roland Fehrenbacher <rf@q-leap.de> - 2023-06-03 11:00 +0200

csiph-web