On Tue, May 01, 2018 at 12:14:17PM +0000, Lumin wrote: > Since libmkl-rt Provides libblas.so.3, it is not totally safe even > if we set its priority to 1. That's because MKL will still be selected > when there is only one libblas.so.3 provider, namely MKL. Due to > this reason, I appended libopenblas-base as a dependency of libmkl-rt, > so that MKL will never be selected by update-alternatives in auto mode. > (I'm not sure what will happen if a package which provides libblas.so.3 > and also depends libblas.so.3 . Let me simply depend on openblas > instead.)
I had overlooked this corner case, thanks. It should be however very rare, because all packages that depend on a BLAS/LAPACK implementation use something like "Depends: libblas3 | libblas.so.3" (i.e. a concrete package before the virtual one). But it can indeed happen if the user first selects MKL then the depending package. I think depending on openblas is a bit weird. If the users reply "no" and MKL is the only alternative available, then I'd rather display a debconf message warning the user about the situation. The test about MKL being the only option could be something like: if [ $(update-alternatives --query libblas.so.3-@DEB_HOST_MULTIARCH@ | grep ^Alternative: | wc -l) = 1 ] > Current HEAD is 2ce1edd8cc57ed87c080edccd36456bb9953fd22. > I haven't test the new postinst script yet. Thanks. There is a small bug: in both libmkl-rt.postinst.in and libmkl-dev.postinst.in, when the users reply "no", you put both BLAS and LAPACK alternatives in auto mode if MKL was selected for BLAS. You should rather split that in two tests: one for BLAS, one for LAPACK, because in theory it's possible to have BLAS pointing to MKL and not LAPACK. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
signature.asc
Description: PGP signature
