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't
declare a dependency on libopenblas-base.
This seems to me not o.k.
Since libblas.so.3 from package libopenblas-base itself is linked to
libopenblas.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
