[Debian-med-packaging] Bug#1056671: (build-)depends on atlas, which is obsolete and scheduled for removal

[Sébastien Villemot]

Source: emmax
Version: 0~beta.20100307-3
Severity: normal
Tags: sid trixie
User: debian-science at 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.camel@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