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/