Hi Sébastien, > > 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 ]
Seems that things are getting more complicated. Recall that here we'are going to prevent users from GPL violation in situations such as this one: debootstrap; apt install libmkl-rt; apt install octave; octave ... (1) Another solution which avoids directly depending on OpenBLAS came up in my mind, which looks like: libmkl-rt -- Pre-Depends: libblas3 | libblas.so.3; Provides: libblas.so.3 ... (2) The solution (2) will keep the user safe in situation (1). However while having a discussion with a Debian Maintainer, a bug of solution (2) was pointed out by him: debootstrap; apt install libmkl-rt; apt purge libblas3; octave ... (3) In situation (3), MKL is still the only provider of libblas.so.3, and GPL will be violated even if the user answered "NO" when installing MKL. If we are going to find a solution for (3), things will be even more complex ... He put forward a simpler solution: Just don't provide libblas.so.3, such that MKL will never be used to satisfy the dependency of libblas.so.3 . Based on his idea, my new solution is the follows: libmkl-rt -- Depends: libblas3 | libblas.so.3 Provides: NOTHING ... (4) So it's totally safe now. If there is MKL, there must be a free libblas.so.3 implementation with a priority definitely larger than 1, overriding MKL in terms of auto-mode alternatives. On the other hand, if that alternative is manually set, then there is nothing to worry about. This solution is also able to resolve problems found in (1) and (3). > > 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 ] I think this is not needed if we use solution (4). MKL will never be the only libblas.so.3 "provider" existing on system. Apart from all things discussed above, there is upstream confirmation to the ambiguous license declaration in several headers. See [1] The blockers are cleared. I think I'll update the package as proposed, and the copyright information as said in [1] before this weekend. [1] https://github.com/intel/mkl-dnn/issues/206#issuecomment-385772103 Regards, Lumin
signature.asc
Description: PGP signature
