Comment # 10 on bug 1177260 from Egbert Eich

(In reply to Stefan Br�ns from comment #8)

> 1. openBLAS is not available for RISC-V, and likely never will
> 2. directly linking to openblas_* forfeits the possibility to use a
> different BLAS/LAPACK implementation.
> 3. Netlib (c)blas + lapack is ~0.7 + 7 MByte, openblas is ~28 MByte. 

Right.

> > 
> > Right. libopenblas is not a provider of libblas.so.3..., libcblas.so.3...,
> > liblapack.so.3... either.
> 
> It does not provide the SONAME, so it is not picked up on the RPM level. The
> same is true for any other BLAS implementation I am aware of. But thats
> orthogonal to the question whether it is picked up as a runtime provider
> using update-alternatives.
> 
> As long as some file/symlink named libblas.so.3 is in the runtime linker
> path (either ld.conf* or LD_LIBRARY_PATH), it will be picked up, even if it
> is a library with a completely different SONAME and file name.

Sure.

Your changes to lapack looked fine. I've sent them on to Factory. I cannot
accept your drop request for science/CBLAS, yet, as it is still the devel
project for Factory. I've filed a separate drop request for that.
The priorities of liblapack, libblas and libcblas from the netlib lapack are
higher than for the ones from openblas. Thus, even if openblas is installed, it
will not be picked up automatically. 
Do you prefer it this way?

While looking at this, I've noticed there are no update-alternatives for the
lapack C interface.
openblas does provide this as well, though. It should probably be added.