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

On Sat, 2018-05-19 at 10:55 +, Lumin wrote: > On Fri, May 18, 2018 at 11:49:05PM +0800, Drew Parsons wrote: > > > > I wonder if the simplest solution is to just have > > intel-mkl Depends: libblas. i.e. use policy to simply prevent a > > sole > > mkl installation. > > > > That way, the

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

On Fri, May 18, 2018 at 11:49:05PM +0800, Drew Parsons wrote: > > I wonder if the simplest solution is to just have > intel-mkl Depends: libblas. i.e. use policy to simply prevent a sole > mkl installation. > > That way, the mkl alternative will always have a free BLAS to press > it's

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

On Sat, 2018-05-12 at 03:22 +, Lumin wrote: > Hi Sébastien, > > > But IMO it's acceptable to not perfectly deal with the > > corner case > > where only MKL is installed, as long as some warning is displayed. > > I insist on removing the Provides, even if it looks weird. For sake > of >

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

Hi Sébastien, > Using a Pre-Depends here is IMO wrong. Quoting Policy §7.2: Thanks. I didn't notice that when considering ways to avoid corner cases. > I also think that removing the Provides is not a good idea. The alternative is > provided by the package, and that should be made clear in the

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

On Sun, May 06, 2018 at 08:29:29AM +, Lumin wrote: > > 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 -- > >

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

On Sun, 2018-05-06 at 10:13 +0200, Sébastien Villemot wrote: > > Yes, but it’s the GPL that forbids distribution of a binary linking > together > GPL code and non-free code. But we're not distributing GPL binaries for use with nonfree MKL, we're distributing them to use with OpenBLAS or ATLAS.

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

Hello guys, I've just updated the MKL packaging, and added a BLAS performance tester there. I'll test the package soon, but let me first describe the changes. > 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

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

On Wed, May 02, 2018 at 10:03:38AM -0500, Dirk Eddelbuettel wrote: > > On 2 May 2018 at 14:41, Lumin wrote: > | 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

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

On Sun, May 06, 2018 at 08:00:53AM +, Lumin wrote: > On Wed, May 02, 2018 at 10:03:38AM -0500, Dirk Eddelbuettel wrote: > > > > On 2 May 2018 at 14:41, Lumin wrote: > > | Seems that things are getting more complicated. Recall that here we'are > > | going to prevent users from GPL violation in

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

On 2 May 2018 at 14:41, Lumin wrote: | 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) Are you sure? I do not think

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

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

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

On Tue, May 01, 2018 at 12:14:17PM +, 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

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

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

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

OBOn Mon, Apr 30, 2018 at 05:49:16PM +0200, Sébastien Villemot wrote: > On Mon, Apr 30, 2018 at 03:31:29PM +, Lumin wrote: > > > Four symbol links are installed to usr/lib/${DEB_HOST_MULTIARCH}/mkl/ > > directory, see [2][3]. Using ld.so environt variable to switch > > blas/lapack is

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

On Mon, Apr 30, 2018 at 03:31:29PM +, Lumin wrote: > Four symbol links are installed to usr/lib/${DEB_HOST_MULTIARCH}/mkl/ > directory, see [2][3]. Using ld.so environt variable to switch > blas/lapack is documented in README.Debian [4]. Reading that README.Debian, I realize that your

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

Hi Sébastien, > 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

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

On Sun, 2018-04-29 at 21:50 +0200, Sébastien Villemot wrote: > On Sun, Apr 29, 2018 at 09:18:08AM +0800, Drew Parsons wrote: > > > The discussion raises a separate question. Suppose the > > administrator > > does make OpenBLAS the preferred alternative for the system, but an > > individual user

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

On Sun, Apr 29, 2018 at 09:18:08AM +0800, Drew Parsons wrote: > 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

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

Dear Lumin, On Sun, Apr 29, 2018 at 07:28:20AM +, 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

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

Hello guys, > 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

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

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

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

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

On 28 April 2018 at 21:50, Sébastien Villemot wrote: | These priorities are meant to express what Debian thinks is the best option to | implement BLAS. This thread shows that statement to be incorrect. It appears evenly split -- (I didn't count, but roughly) three people on each side, so a tie.

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

OBOn Sat, Apr 28, 2018 at 02:35:29PM -0500, Dirk Eddelbuettel wrote: > > On 28 April 2018 at 11:56, Dima Kogan wrote: > | Andreas Tille writes: > | > | > On Fri, Apr 27, 2018 at 06:36:51PM +0200, S?bastien Villemot wrote: > | > > | >> There is also a licensing issue: using

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

OBOn Sat, Apr 28, 2018 at 11:56:02AM -0700, Dima Kogan wrote: > Andreas Tille writes: > > On Fri, Apr 27, 2018 at 06:36:51PM +0200, S?bastien Villemot wrote: > > > >> There is also a licensing issue: using GPL'd software (e.g. GNU > >> Octave) with MKL is not allowed. > > > > I

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

On 28 April 2018 at 11:56, Dima Kogan wrote: | Andreas Tille writes: | | > On Fri, Apr 27, 2018 at 06:36:51PM +0200, S�bastien Villemot wrote: | > | >> There is also a licensing issue: using GPL'd software (e.g. GNU | >> Octave) with MKL is not allowed. | > | > I think that's

Package nearly ready. (was: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

Hi, On Fri, 2018-04-27 at 11:53 -0500, Dirk Eddelbuettel wrote: > I agree with Lumin here and not Seb -- if and when one adds MKL, it > should > also be higher priority. That is the point of such a package (which > will > likely linger in contrib or non-free anyway). As suggested by Sébastien

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

Hi, On Fri, Apr 27, 2018 at 06:36:51PM +0200, Sébastien Villemot wrote: > There is also a licensing issue: using GPL'd software (e.g. GNU Octave) with > MKL is not allowed. I think that's a pretty strong reason to rate non-free software lowest in the alternatives. Packaging useful non-free

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

I agree with Lumin here and not Seb -- if and when one adds MKL, it should also be higher priority. That is the point of such a package (which will likely linger in contrib or non-free anyway). FWIW rather recently I put together a simpler script (not a package). Blog post here:

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

Dear Lumin, On Fri, Apr 27, 2018 at 04:24:43PM +, Lumin wrote: > The main purpose for me to write this mail is to notify > you guys that I'm going to assign MKL a higher priority > than OpenBLAS via the update-alternative mechanism. > > MKL provides alternatives to e.g. libblas.so.3 >