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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org