Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)

[Sébastien Villemot]

Le vendredi 16 décembre 2022 à 13:47 +0100, Jochen Sprickerhof a
écrit :
> Hi Sébastien,
> 
> * Sébastien Villemot <sebastien at debian.org> [2022-12-16 10:30]:
> > Le jeudi 15 décembre 2022 à 21:16 +0100, Paul Gevers a écrit :
> > > On 13-12-2022 21:59, Sébastien Villemot wrote:
> > > > The problem is that atlas needs to be recompiled against lapack 3.11.0.
> > > > Which has been done in atlas 3.10.3-13. But atlas itself cannot migrate
> > > > to testing because of #1025699.
> > > 
> > > While I understand recompiling "solves" the issue, normally this error
> > > "undefined reference" hints at removal of symbols. Normally that should
> > > be handled by a SONAME bump which would trigger auto trackers to be
> > > generated for the transition. Such trackers notify the release team of
> > > transitions and they can trigger rebuilds (you know that drill,
> > > including the transition bug filing for coordination). Why do you think
> > > that a SONAME bump wasn't the right solution in this case?
> > 
> > Actually the error is not due to a symbol removed, but to a symbol
> > *added*. So no SONAME bump is warranted.
> > 
> > Let me explain:
> > 
> > In lapack 3.11.0, several new symbols ({z,c,d,s}trsyl3_) were added to
> > liblapack.so.3 (a linear algebra library with a Fortran interface).
> > As a consequence, new wrapper functions around these symbols were also
> > added to liblapacke.so.3 (note the “e”), which is a C wrapper around
> > liblapack.so.3, and which is also shipped by src:lapack. Hence the
> > latest liblapacke.so.3 depends on the new symbols in liblapack.so.3.
> > 
> > Now, libatlas3-base (compiled from src:atlas) also provides its own
> > version of liblapack.so.3 (through the alternatives system¹). But,
> > until it is recompiled against lapack 3.11.0, that version of
> > liblapack.so.3 does not contain the new symbols. Hence, when
> > liblapack.so.3 is provided by libatlas3-base, loading liblapacke.so.3
> > produces the error that is seen in the failing test.
> > 
> > Essentially, what is missing is a restriction which would forbid the
> > co-installation of liblapacke ⩾ 3.11 and libatlas3-base compiled
> > against lapack < 3.11. I don’t know how to express that using our
> > tooling, but maybe I’m unimaginative.
> 
> I think you can get that with a virtual abi package, something like:
> 
> Provides: libblas-abi (= 3.11)
> 
> And have downstream packages shlibs depend on that virtual package:
> 
> override_dh_makeshlibs:
> 	dh_makeshlibs -plibfoo -V 'libblas-abi (= 3.11)'
> 	dh_makeshlibs --remaining-packages
> 
> Maybe also add a:
> 
> Conflicts: libblas-abi (= 3.11)
> 
> So only one lib can be installed at the same time and drop the 
> alternatives system.

In the current system, in which the BLAS and LAPACK implementation are
decided through the alternatives system, it’s not possible to solve the
problem through versioned provides. Because even if the dependency on
the versioned provides is satisfied, this does not prevent another
flavour of LAPACK (not satisfying the dependency) to be installed and
selected through the alternatives system.

So indeed the only clean way of solving this issue seems to forbid
coinstallability of several BLAS or LAPACK flavours. But the latter is
considered as a feature, not as a bug. I agree that using the
alternatives system for a shared library is a bit ugly and does not
play well with our tooling, but that’s a choice that was made long ago
and it also brings some flexibility for the user (it’s easy to switch
from one implementation to the other).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20221216/57a3efcf/attachment.sig>