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

Groups > linux.debian.bugs.dist > #1148270 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

Contents

  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

#1148270 — 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

[toc] | [next] | [standalone]

#1148667

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
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web