On 2019-01-07 11:53, Jörg-Volker Peetz wrote:
Hi,running the appended little script on my system a lot of packages are found which contain libraries linked to libopenblas.so.0. But all these packages don'tdeclare a dependency on libopenblas-base. This seems to me not o.k. Since libblas.so.3 from package libopenblas-base itself is linked tolibopenblas.so.0, I guess the linking to libopenblas.so.0 is expendable.
There could be a handful of different things going on here. OpenBLAS is (arguably) the better open source BLAS, so some package explicitly Build-Depends: libopenblas-dev. That's part of the problem that we're striving to fix with the libblas-dev | libblas.so virtual package.
In some case the situation is a little subtle. The maintainer might know about the alternatives so specifies Build-Depends: libopenblas-dev | libatlas-base-dev | libblas-dev | libblas.so. Intuitively this seems sensible, "all for alternatives but prefer OpenBLAS if possible". But it doesn't work with the Debian buildds, which strictly select only the first alternative (so will FTBFS on an arch which doesn't provide openblas).
But the problem you described, linking to libopenblas.so.0 but not depending on the package, is simply a bug that needs to be fixed. It could happen if the maintainer hasn't specified Depends: ${shlibs:Depends} in control or doesn't run dh or dh_shlibdeps. dh_shlibdeps (or dpkg-shlibdeps) will determine that libopenblas.so.0 is represented by Depends: libblas3 | libblas.so.3. lintian would detect the problem. It indicates lazy packaging.
Drew