Hi Drew,
I didn't closely investigate into the scipy bug, but I can answer
some of your questions. BTW, does anything break in a clean chroot?
I mean, making sure a thing works fine in an unclean environment
is difficult.
On 2019-05-21 04:57, Drew Parsons wrote:
The problem is that libopenblasp-r0.3.5.so contains exactly the same
symbols as libblas.so and liblapack.so. This seems to be confusing
linkers, e.g. see Bug#914655 for python-scipy.
The Debian dependency template resolving of the BLAS / LAPACK family
is designed to work like this:
- linked against libblas.so.3 -> enable alternative,
resolve to libblas.so.3 | libblas.so.3
- linked against libopenblas.so.0 -> tight requirement on openblas,
resolve to libopenblas-base
Even if libopenblas.so.0 contains the same set of symbols as
(libblas.so.3 + liblapack.so.3 + some extended routines),
the SONAME matters for our dependency tree.