Re: Removing ATLAS?
On 2023-11-05 14: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.
...
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.
I would make these paragraphs stronger, emphasising that the build
should always normally be done against generic BLAS/LAPACK, with the
optimised libraries to be used at runtime rather than build-time. For
Build-Depends, we tend to use alternatives with the generic build placed
first to be picked up by buildds, while not getting in the way of anyone
building for themselves locally (with an optimised implementation
installed)
My suggested wording might be
...
As a consequence, please drop any (build-)dependency on atlas.
This should be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Normally, packages should Build-Depend on the Netlib reference
implementation
(libblas-dev, and liblapack-dev where required), and to *not* enforce
anything
in the Depends field of binary packages (dpkg-shlibs 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 optimised 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
Build-Depends: liblapack-dev | liblapack.so
where specific optimised implementations may provide
libblas.so/liblapack.so
If a specific optimised implementation is preferred at runtime, that
could be hinted in the order or alternative Build-Depends,
e.g.
Build-Depends: libblas-dev | libopenblas-dev | libblis-dev |
libblas.so
or
Build-Depends: libblas-dev | libblis-dev | libopenblas-dev |
libblas.so
though that will not affect buildds which will use the first alternative
libblas-dev in any case.
(it will also not affect the entry automatically added to
${shlibs:Depends}).
...
Drew
Reply to: