Bug#760936: BLAS: not Multi-Arch safe
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 need to move the libblas.so.3 symlink into arch-qualified subdirectories and manage multiple alternatives, one per architecture. Helmut suggested to just add Conflicts: libblas.so.3 to all providers of the libblas.so.3 virtual package, so they are not coïnstallable, then drop the alternatives Geraffel and just use normal M-A coïnstallability. Please do enlighten us to the reason of this alternatives system ☺ Related is #760821 which is an error (partially) caused by this problem. -- System Information: Debian Release: jessie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages libblas3 depends on: ii libc6 2.19-10 ii libgcc1 1:4.9.1-12 ii libgfortran3 4.9.1-12 ii libquadmath0 4.9.1-12 libblas3 recommends no packages. libblas3 suggests no packages. -- no debconf information -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#760936: BLAS: not Multi-Arch safe
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 foo Depends on libblas3 | libblas.so.3. Now
foo:i386 is installed, but the alternative is chosen to be served from
libblas3:amd64. Since libatlas3-base:i386 provides libblas.so.3:i386, I
can install foo that way, but it will fail to work. This is exactly what
happened on #760821.
Helmut and I think you need to move the libblas.so.3
symlink into arch-qualified subdirectories and manage
multiple alternatives, one per architecture.
By managing per-architecture alternatives libblas.so.3 is only provided
when it is actually available. I am not sure how much code this
transition would break. From a quick glance, all providers (atlas, blas,
...) need to be updated. In addition, python-scipy will have its test
suite broken. Probably more.
Helmut suggested to just add Conflicts: libblas.so.3
to all providers of the libblas.so.3 virtual package,
so they are not coïnstallable, then drop the alternatives
Geraffel and just use normal M-A coïnstallability. Please
do enlighten us to the reason of this alternatives system ???
Dropping the alternatives handling is optional here (, but after adding
conflicts there can only be one provider at any one time, so it is kinda
useless). This is the quick and dirty solution that will make the
breakage go away now.
There is yet another workaround to the issue at hand. The blas providers
could provide an additional package (for internal consumption only)
named libblas.so.3-${DEB_HOST_ARCH} and conflict this particular
package for all other (release) architectures. That would ensure that
all blas providers would always use the same architecture without
sacrificing the ability to install multiple providers for the same
architecture.
Further down the road, replacing the update-alternatives mechanism with
tiny meta packages containing just the symbolic link would also work.
The existing packages would drop their provides libblas.so.3 and new
packages shipping just that symlink would provide and conflict
libblas.so.3. Sadly, this introduces quite a few small packages.
Helmut
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#760936: BLAS: not Multi-Arch safe
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 Jessie though, because we are too late in the current cycle to make that change. Helmut suggested to just add Conflicts: libblas.so.3 to all providers of the libblas.so.3 virtual package, so they are not coïnstallable, then drop the alternatives Geraffel and just use normal M-A coïnstallability. Please do enlighten us to the reason of this alternatives system ☺ Because it is useful to be able to switch between Netlib BLAS, ATLAS and OpenBLAS without using the package manager. So, introducing conflicts between the various implementations is a regression from my POV, and I won't do that. Thanks for your feedback, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#760936: BLAS: not Multi-Arch safe
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 wait for the release of Jessie though, because we are too late in the current cycle to make that change. This is a very bold statement, considering we are dealing with realistic application breakage (as M-A is projected as “the solution” by more and more people) here. bye, //mirabilos -- emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;) Hallo, ich bin der Holger (Hallo Holger!), und ich bin ebenfalls ... pine-User, und das auch noch gewohnheitsmäßig (Oooohhh). [aus dasr] -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#760936: BLAS: not Multi-Arch safe
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 alternatives, one per architecture. I think this is the way to go. It will have to wait for the release of Jessie though, because we are too late in the current cycle to make that change. This is a very bold statement, considering we are dealing with realistic application breakage (as M-A is projected as “the solution” by more and more people) here. 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 describing is due to someone using one BLAS implementation on one arch and another implementation on the other arch, which is essentially an attempt to circumvent the fact that BLAS packages are not M-A:same. So far nobody has complained about the non availability of multi-arch for BLAS. You are now rightfully raising this issue, and it will be dealt with, but it does not make it automatically urgent. 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, lapack, atlas, openblas); it needs coordinated changes in those packages, which means that they must all transition to testing at the same time; the change is tricky because it involves lots of code in maintainer scripts, with possible problems on upgrade paths; I will have almost no time in October for Debian. If you come up soon with working patches for these 4 packages, I will do my best to review and upload them. Otherwise I don't think that this move is realistic before the freeze. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#760936: BLAS: not Multi-Arch safe
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 describing is due to The Multi-Arch spec tried to make all packages Multi-Arch safe by default. In particular, most packages that are not M-A:same are Multi-Arch safe. libblas3 is not. It can lead to a situation where dependencies are satisfied, but the resulting installation is non-functional. someone using one BLAS implementation on one arch and another implementation on the other arch, which is essentially an attempt to circumvent the fact that BLAS packages are not M-A:same. This doesn't have to be an active choice of the user. It can just happen that you enabled i386 on your amd64 box (as is recommended in the release notes for running software like skype), that apt will pull in a foreign-arch implementation of blas, because the meta data tells that this would work, while it doesn't. This bug is not about making blas M-A:same (which would be wishlist), but about blas not breaking after adding a foreign architecture. 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, lapack, atlas, openblas); it needs coordinated changes in those packages, which means that they must all transition to testing at the same time; the change is tricky because it involves lots of code in maintainer scripts, with possible problems on upgrade paths; I will have almost no time in October for Debian. I agree that any way to solve this issue involves severe changes, which may be unsuitable for jessie. But for jessie we do not have to Multi-Arch blas. It suffices to make it Multi-Arch safe. If you come up soon with working patches for these 4 packages, I will do my best to review and upload them. Otherwise I don't think that this move is realistic before the freeze. Let me propose another funky workaround for jessie: Introduce a new, empty arch:any package (whose sole purpose is to exist). Do not mark it as Multi-Arch anything (this is crucial and why you cannot reuse things like libc6 or dpkg for this). Then have all blas implementations depend on this package. Any blas implementation being installed will pull in the new package for the architecture. Any other blas implementation will only be installable for the same architecture now. Even though, this goes through NEW and has to touch at least four packages, it does not cause a transition. It also does not cause the update-alternatives handling to change. What do you think? Helmut -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#760936: BLAS: not Multi-Arch safe
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, lapack, atlas, openblas); it needs coordinated changes in those packages, which means that they must all transition to testing at the same time; the change is tricky because it involves lots of code in maintainer scripts, with possible problems on upgrade paths; I will have almost no time in October for Debian. I agree that any way to solve this issue involves severe changes, which may be unsuitable for jessie. But for jessie we do not have to Multi-Arch blas. It suffices to make it Multi-Arch safe. If you come up soon with working patches for these 4 packages, I will do my best to review and upload them. Otherwise I don't think that this move is realistic before the freeze. Let me propose another funky workaround for jessie: Introduce a new, empty arch:any package (whose sole purpose is to exist). Do not mark it as Multi-Arch anything (this is crucial and why you cannot reuse things like libc6 or dpkg for this). Then have all blas implementations depend on this package. Any blas implementation being installed will pull in the new package for the architecture. Any other blas implementation will only be installable for the same architecture now. Even though, this goes through NEW and has to touch at least four packages, it does not cause a transition. It also does not cause the update-alternatives handling to change. What do you think? Thanks for suggesting this alternative solution, which I think is a good compromise for jessie. It is a bit ugly, but I don't see any other way of forbidding M-A co-installability of two different packages. Hopefully the ftpmasters won't oppose this. I'll try to implement this soon. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
