Bug#897238: 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

Bug#897238: 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

Bug#897238: 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 >

Bug#897238: 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

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.

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

Just forgot to CC the RFS bug. - Forwarded message from Lumin - Date: Sun, 6 May 2018 08:29:29 + From: Lumin To: sebast...@debian.org Cc: debian-scie...@lists.debian.org Subject: Re: Re: Bits about Intel MKL packaging -- Higher Priority

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

Bug#897238: 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

Bug#897238: 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

Bug#897238: 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