Source: mplcursors Version: 0.5.2-1 Severity: serious Justification: debci mplcursors Build-Depends:libopenblas0
This is bad for several reasons. Firstly, OpenBLAS is not available on all architectures. In particular it's not available on armel (and mipsel), and therefore debci testing on armel fails, due to the missing libopenblas0. That's why I'm filing this bug as Severity: serious (debci). Secondly, it's wrong to specify a specific library binary package in Build-Depends. Build-Depends should be made using the development package instead, i.e. Build-Depends: libblas-dev. Note that is not Build-Depends: libopenblas-dev, see next point. Thirdly, in regards to BLAS support, all BLAS packages are binary-compatible, with the preferred BLAS implementation controllable using the debian alternatives mechanisms. Even where OpenBLAS is available, it may not be the best BLAS implementation for the activity that a particular system performs. That is, the local admin might determine that blis or atlas (or intel-mkl) performs better. Not to mention the various threaded builds which would generally have better performance than libopenblas0, which is a serial build. For this reason, debian packages using blas are usually built against the generic (slow) libblas-dev. Then one of the performant BLAS implementation is installed at runtime by the system administrator. On your own machine you'll want one of the optimised BLAS implementations installed (libopenblas0, for instance). So to allow for this the Build-Depends can include alternatives. But the first alternative should be the generic development package, libblas-dev, so that it's used by the debian buildds to build the package. Thus, the Build-Depends should be something like Build-Depends: libblas-dev | libopenblas-dev | libblis-dev | libatlas-base-dev
