Your message dated Mon, 15 Jan 2024 16:44:14 +0100
with message-id <[email protected]>
and subject line Re: depends on atlas, which is obsolete and scheduled for 
removal
has caused the Debian Bug report #1056694,
regarding depends on atlas, which is obsolete and scheduled for removal
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
1056694: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056694
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: python-escript
Version: 5.6-5
Severity: normal
Tags: sid trixie
User: [email protected]
Usertags: atlas-rm

Dear Maintainer,

python3-escript and python3-escript-mpi both depend (only on armel) on
libatlas3-base, which is produced by the source package atlas. At this stage I
admit I don’t really understand where that dependency comes from.

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/[email protected]

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).

Thanks for your work,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

--- End Message ---
--- Begin Message ---
Le vendredi 24 novembre 2023 à 18:02 +0100, Sébastien Villemot a
écrit :
> python3-escript and python3-escript-mpi both depend (only on armel) on
> libatlas3-base, which is produced by the source package atlas. At this stage I
> admit I don’t really understand where that dependency comes from.

The dependency on atlas on the armel architecture is no longer present.
Hence closing.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
-- 
debian-science-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Reply via email to