Re: Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

[Lumin <cdluminate@gmail.com>]

Hi Sébastien,

> - if MKL was not already selected and the user says no, the setting
> will be
> left untouched (either in automatic or manual mode, depending on the
> user
> customization)
> 
> - if MKL was already selected and the user says no (e.g. after a
> reconfigure),
> then MKL will be unselected (and the BLAS with the highest priority
> will
> become the current alternative)
> 
> - if the user says yes, MKL is selected (while with your actual code,
> if the
> alternative was in manual mode, then MKL would still be unselected
> even with
> priority 50)

Now I understand what you meant. I changed postinst in this [1] commit.
_mkl_rt_priority is set to 1 and will never be changed. Now we select
MKL as default by setting is in manual mode, instead of assinging a
high priority so that update-alternatives automatically selects the
highest one. This implementation is tightly matched to the literal
meaning of the debconf question.

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.)

README.Debian [2] is also updated according to the changes.

Current HEAD is 2ce1edd8cc57ed87c080edccd36456bb9953fd22.
I haven't test the new postinst script yet.

[1] https://salsa.debian.org/science-team/intel-mkl/commit/a90fd6389940
e134baa049a69efac79a076ac870
[2] https://salsa.debian.org/science-team/intel-mkl/commit/2ce1edd8cc57
ed87c080edccd36456bb9953fd22