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 mk
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 preferen
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
> debcon
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 d
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 libb
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 inst
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 t
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 libmk
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 unse
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 documente
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 impleme
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
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 whe
13 matches
Mail list logo
