The following line is what I use for the PyTorch package (ignore the
fact that I forgot to bump the BLIS abi from 3 to 4):
Recommends: libopenblas0 | libblis3 | libatlas3-base | libmkl-rt | libblas3
So the latest Recommends line for performance critical packages relying
on BLAS/LAPACK should use:
Recommends: libopenblas0 | libblis4 | libmkl-rt | libblas3
libmkl-rt is oudated (I knew it), but anyway usable. Quite a few months
ago I wrote the plan for overhauling the MKL package. Will carry it out
when I'm available for that.
libblas3 as the last fallback when none of the others are available.
This seems missing from the message draft.
BLIS has a quite good architecture coverage compared to openblas.
Currently we only miss libblis4 on hurd-amd64 (I'm surprised. Hurd has
finally got amd64 version), and arc. While BLIS does not really optimize
every architecture, it should be anyway better than the very naive
fortran implementation.
On 11/5/23 08:02, Sébastien Villemot wrote:
Le samedi 08 juillet 2023 à 10:01 +0200, Sébastien Villemot a écrit :
As the maintainer of the atlas package over the last decade, I now
wonder whether we should remove it from the archive.
Since the present thread seems to indicate that there to be a consensus
towards removing atlas from Debian, I am going to move forward.
Please find below a bug report template, which I plan to use for
reporting bugs against the ~20 packages that currently have a (build-
)dependency against atlas. Feedback is welcome.
----------------------------------------------------------------------------------
Subject: (build-)depends on atlas, which is obsolete and scheduled for removal
Package: $PACKAGE / Source: $SOURCE
Version: $VERSION
Tags: sid trixie
User: debian-science@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
$SOURCE build-depends on libatlas-base-dev / $PACKAGE depends on
libatlas3-base, which is 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.
The typical setup is to build depend on the Netlib reference implementation
(libblas-dev and possibly also liblapack-dev), and to not enforce anything in
dependencies of binary packages.
If an optimized BLAS/LAPACK implementation is needed at build time (for example
for accelerating tests), then libopenblas-dev and libblis-dev offer good
options (keeping in mind that openblas is only available on some
architectures).
If one wants to encourage users to install an optimized
implementation, then one can use “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).
Thanks for your work,
