Source: emmax Version: 0~beta.20100307-3 Severity: normal Tags: sid trixie User: debian-scie...@lists.debian.org Usertags: atlas-rm
Dear Maintainer, emmax build-depends on libatlas-base-dev, and depends on libatlas3-base and libatlas-base-dev, which are produced by the source package atlas. atlas is obsolete and scheduled to be removed from Debian, ideally by the trixie release. See the following thread on the Debian Science list for more details: https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org As a consequence, please drop any (build-)dependency on atlas. This should normally be straightforward to achieve, by simply replacing atlas with another BLAS (and possibly also LAPACK) implementation. Ideally, packages should Build-Depend on the Netlib reference implementation (libblas-dev, and liblapack-dev where required), and not enforce anything in the Depends field of binary packages (dpkg-shlibdeps will automatically add the appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}). Alternative implementations may be given in Build-Depends for the ease of users making local builds with an optimized implementation installed, but the generic reference implementation should be placed first to be used by buildds. The simplest example is Build-Depends: libblas-dev | libblas.so, liblapack-dev | liblapack.so where specific optimized implementations may provide the libblas.so/liblapack.so pseudo-package. Similarly, if one wants to encourage users to install an optimized implementation at runtime, then one can add “Recommends: libopenblas0 | libblis4” in binary packages. Also note that if your package needs libcblas (which is currently only provided by libatlas-base-dev), then the solution is to modify the build system so that it rather uses libblas (because, under Debian, the latter already incorporates the symbols provided by libcblas). In the specific case of emmax, I understand that it needs clapack.h which is currently shipped by libatlas-base-dev. clapack.h is apparently an early attempt at providing a C interface to some LAPACK functions (which are in Fortran). The modern solution for that problem is to use LAPACKE (note the final “E”), which is provided by liblapacke-dev. It is a standardized and maintained C interface to all LAPACK routines. If migrating to LAPACKE is too complicated, then I guess an easy solution is to embed clapack.h into src:emmax. Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
