Re: LAPACK vs. OpenBLAS

[Paul Garlick]

Hi Ludo,

> A surprisingly large number of packages depend on ‘lapack’:

> Perhaps we could have a lint checker warning against the use of
lapack.

Good idea.  Possibly with a helpful message along the lines of 'the
openblas package provides a LAPACK interface'.

I encountered this issue when packaging an optimization package [0]
recently.  The build system, cmake, requires a path to the BLAS_LIBRARY
and also a path to the LAPACK_LIBRARY.  One can see how the shared
library liblapack.so, provided by the lapack package, could be the
first (but mistaken) choice for the packager.

I notice that Debian [1] use NO_LAPACK=1 as an extra make option for
openblas.  This  has the effect of generating a liblapack.so file.

For the case of optizelle, the package I was working on, I labelled the
openblas input as "blas/lapack" to make it clear that the package has a
dual purpose.

Best regards,

Paul.

[0] https://hpc.guix.info/package/optizelle
[1] https://sources.debian.org/src/openblas/0.3.13+ds-3/debian/rules/