Bug#929296: libopenblas-base: is libopenblas.so needed?

[Mo Zhou]

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:
> Why is /usr/lib/x86_64-linux-gnu/libopenblasp-r0.3.5.so provided by
> libopenblas-base?

Julia links against libopenblas.so.0 instead of libblas.so /
liblapack.so .
Julia's linear algebra standard library is not quite ready for
library switching.

> 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.

> If libopenblasp-r0.3.5.so is present then it is used preferentially to
> provide BLAS and LAPACK symbols, so the shared library
> (_flapack.x86_64-linux-gnu.so in the case of python-scipy) ends up with 
>   NEEDED libopenblas.so.0
> instead of
>   NEEDED liblapack.so.3
>   NEEDED libblas.so.3

libopenblasp-r0.3.5.so should never be used as BLAS / LAPACK provider
as it's SONAME unmatches the depencency template and would incur
breakage to our dependency tree.

If a program is really linked against libopenblas.so.0, liblapack.so.3,
and libblas.so.3, it is still problematic as symbol clashes between
(possibly) different implementations may lead to unexpected results.

> The official builds of scipy are fine since they build against the
> generic BLAS. But local builds can become confused, which is what I
> think happened with Bug#914655.  The package Depends: libblas3 |
> libblas.so.3 where in this case it would need Depends: libopenblas-base.
> 
> So, is libopenblasp-r0.3.5.so really supposed to be provided in
> /usr/lib/x86_64-linux-gnu by libopenblas-base, or this a bug which
> should be fixed when the various BLAS flavours are being expanded?

I'm sure libopenblasp-r0.3.5.so cannot be removed. Every OpenBLAS
flavor will ship 3 shared objects:

   openblas-flavor/libopenblas*.so.*  SONAME: libopenblas.so.0
   openblas-flavor/libblas.so.3       SONAME: libblas.so.3
   openblas-flavor/liblapack.so.3     SONAME: liblapack.so.3