Package: libblas3
Version: 1.2.20110419-7
Severity: important
libblas3 Provides: libblas.so.3
libatlas3-base Provides: libblas.so.3
The problem here is that I can install, for example,
libblas3:amd64 and libatlas3-base:i386, and they are
managed by the same alternative.
Helmut and I think you
On Tue, Sep 09, 2014 at 11:11:39AM +0200, Thorsten Glaser wrote:
The problem here is that I can install, for example,
libblas3:amd64 and libatlas3-base:i386, and they are
managed by the same alternative.
Let me sketch a scenario to make the projected breakage explicit:
Let's say my package
Le mardi 09 septembre 2014 à 11:11 +0200, Thorsten Glaser a écrit :
Helmut and I think you need to move the libblas.so.3
symlink into arch-qualified subdirectories and manage
multiple alternatives, one per architecture.
I think this is the way to go. It will have to wait for the release of
S�bastien Villemot dixit:
Le mardi 09 septembre 2014 à 11:11 +0200, Thorsten Glaser a écrit :
Helmut and I think you need to move the libblas.so.3
symlink into arch-qualified subdirectories and manage
multiple alternatives, one per architecture.
I think this is the way to go. It will have to
Le mardi 09 septembre 2014 à 12:37 +, Thorsten Glaser a écrit :
Sbastien Villemot dixit:
Le mardi 09 septembre 2014 à 11:11 +0200, Thorsten Glaser a écrit :
Helmut and I think you need to move the libblas.so.3
symlink into arch-qualified subdirectories and manage
multiple
I think you are getting this wrong.
On Tue, Sep 09, 2014 at 02:06:37PM +0100, Sébastien Villemot wrote:
Essentially this is a wishlist bug, because BLAS implementations have
never been multi-arch safe (and the packages are not marked as
M-A:same). The particular situation that you are
Le mardi 09 septembre 2014 à 15:17 +0200, Helmut Grohne a écrit :
Given that transitions are now frozen for Jessie, and given that the
freeze is less than 2 months ahead, I think that this is too big a
change to be implemented now, for several reasons: it involves multiple
packages (blas,
7 matches
Mail list logo
