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

[Jochen Sprickerhof]

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.

Cheers Jochen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20221216/0b245594/attachment.sig>