Bug#760936: BLAS: not Multi-Arch safe

[Helmut Grohne]

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