Bug#760936: BLAS: not Multi-Arch safe

[Helmut Grohne]

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