Ofc there will be no issue with update-alternatives if blas alternatives are indeed consistent within each architecture. I just doubt this is the case. It would be worth checking.
Anyway to resolve the present bug, removing Multi-arch from libgmm-dev is a good solution, as we discussed. On Tue, 16 Jun 2026 at 12:36, Drew Parsons <[email protected]> wrote: > On 2026-06-16 12:16, Konstantinos Poulios wrote: > > > > Going beyond this specific bug, the main issue is that BLAS has an > > ambiguous API/ABI. What I am pointing out is that AFAIK > > update-alternatives cannot deal with such ambiguities. Right? > > Not exactly. The alternatives are for each architecture, > so if they are consistent within each, then there is no conflict. > > That is, s390x might be different from other architectures, > but so long as openblas, blis etc are using the same interface as > reference BLAS, > there should be no problem. > > > At least for mkl, it leads to errors as reported in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067732 , but based > > on the confb.cpp test results shown by Drew, I would not be surprised > > if there are more undiscovered bugs related to complex number blas. > > This is indeed a serious conflict, if intel-mkl is handling the > interface differently > from the other implementations. The bug is rightly placed with the > intel-mkl package. > A great pity if intel-mkl is necessarily incompatible; I had thought the > BLAS ABI had been > standardised sufficiently to avoid that. >
