Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
On Sun, 2018-04-29 at 09:45 +0900, Charles Plessy wrote:
> Le Sat, Apr 28, 2018 at 11:56:02AM -0700, Dima Kogan a écrit :
> >
> > If I was a user who manually added the non-free repos and then
> > manually
> > installed the mkl libraries, I'd be aggravated to find out that
> > there's
> > yet another hoop I need to jump through to actually use these
> > libraries.
> > This would be a waste of my time, especially since I have already
> > taken
> > actions to clearly indicate that I want MKL.
>
> Hi Dima,
>
> this user story supports your point of view, but it is not the only
> one.
> For instance, on a shared workstation, if one user asks the system
> administrator to install the mkl libraries, other users might be
> quite
> surprised if they were enabled by default. Let's not discuss which
> scenario has the strongest balance between importance and
> probabiliby;
> the point I would like to make is that on a system with broad aims
> such
> as Debian, the reality is always going to be complex.
>
> For this reason, it is frequent and fine to ask users to check
> /usr/share/<package>/README.Debian after installing a package in
> order
> to enable its functionality. Extra sugar such as selection via
> Debconf
> would of course be even better.
>
I agree, debconf configuration is a good compromise.
There's a mix of needs. Those who install it because they specifically
want to use it in preference to OpenBLAS. Those who only install it
for benchmarking or for a subset of users. Then too there's Debian's
mission to promote free software.
The sticking point I think is the issue of potential licence violation.
I think that makes it a problem to configure it quietly at highest
priority. Setting it as preferred alternative should be done with
informed consent. debconf is a good mechanism for that. And it also
meets the expectation of those who want it up and running when they
install, without additional fiddling with alternatives afterwards.
The discussion raises a separate question. Suppose the administrator
does make OpenBLAS the preferred alternative for the system, but an
individual user prefers to use IntelMKL. How should the user configure
this (for the generic blas.so.3 symbols, not recompiling explicitly
against the specific library) ? Set up symlinks in a local dir and
point to that dir with LD_LIBRARY_PATH ?
Drew
Reply to: