Comment # 11 on bug 1177260 from Stefan Br�ns

(In reply to Egbert Eich from comment #10)
> (In reply to Stefan Br�ns from comment #8)
> 
> 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.

LapackE should be covered as well, yes.

Though, the current update-alternatives setup is somewhat problematic IMHO -
switching only some parts of the blas implementation does not make sense, and
may even lead to strange bugs.

I propose to replace the individual library symlinks with a directory symlink.
For each variant, have one '/usr/lib(64)/blas-{netlib,openblas_X,...}/'
directory which contains all the blas-related libraries. Then add a
/usr/lib(64)/blas-default symlink (managed by ua) pointing to e.g.
/usr/lib(64)/blas-openblas_serial/.

/usr/lib(64)/blas-netlib would contain e.g. libblas.so.3,liblapack.so.3,etc as
individual libraries (or appropriate symlinks), while
/usr/lib(64)/blas-openblas_serial/ would contain
libblas.so.3,liblapack.so.3,etc as symlinks all pointing to the
libopenblas_serial.so file.

The default would become visible by adding /usr/lib(64)/blas-default/ to
/etc/ld.so.conf.

This also makes it easy to override the blas implementation for an individual
application, just add e.g. /usr/lib(64)/blas-openblas_pthreads/ to
LD_LIBRARY_PATH.