Dear Lumin, On Sun, Apr 29, 2018 at 07:28:20AM +0000, Lumin wrote: > > I agree, debconf configuration is a good compromise. > > Thank you everyone for your attention. I agree to use debconf > too and it looks like the best solution to the disagreements > in previous discussions. The mechanism was implemented in > the packaging lately. > > The user will be asked whether he/she wants to use libmkl_rt.so > as an alternative to libblas.so.3 and liblapack.so.3 [1][2], > and the db_input importance is set to critical. Default option > is false. By default, or if user rejects this proposal, the > lowest priority will be assgined to libmkl-rt [3]. > Another reason why default is set to false is because we > have to also consider about the users who don't know what > they are doing, and the users who don't know what MKL is at all. Thanks for implementing this. I think this is a reasonable compromise. Maybe the wording about license violations could be slightly improved. I suggest the following for replacing the 2nd paragraph of the debconf prompt: However, MKL is non-free software, and in particular its source code is not publicly available. By using MKL as the default BLAS/LAPACK implementation, you might be violating the licensing terms of copyleft software that would become dynamically linked against it. Please verify that the licensing terms of the program(s) that you intend to use with MKL are compatible with the MKL licensing terms. For the case of software under the GNU General Public License, you may want to read this FAQ: https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs > In the original post I proposed to also set it as alternative to > libblas.so/liblapack.so . However this is problematic since > MKL is a superset which not only includes BLAS/LAPACK symbols > but also many other MKL-specific symbols. To avoid accidents > or problematic usage such as an ELF being linked at symbols > which exist in MKL, (e.g. #include <mkl.h>, gcc ... -lblas -llapack) > but not the other BLAS implementations, I changed my mind > and decided to do nothing with libblas.so / liblapack.so . Note that ATLAS and OpenBLAS have similar issues: they export symbols that are not in the BLAS ABI, but are nevertheless registered as libblas.so alternative. My assumption has been that, if someone links with -lblas, then he is only asking for the BLAS ABI and not more. If someone wants to link against symbols specific to ATLAS/OpenBLAS, then he should link against -latlas/-lopenblas. So, for consistency, I think it is ok to register MKL as providing libblas.so/liblapack.so. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: PGP signature