Bug#878121: Updates about BLAS64, co-installable variants
Mo Zhou
lumin at debian.org
Tue Feb 5 03:34:16 GMT 2019
Hi Sébastien,
I'd like to update the proposal again. Alerted by the threading issue
about Octave+MKL, I changed my mind to make all variants co-installable
so any user would have a chance to switch them without installation/removal.
This proposal has been applied to BLIS (>= 0.5.1-8) already.
I believe this version of layout looks far much better.
And it must be pointed out that I've assigned BLIS variants with the
following priority numbers:
blis-openmp 38
blis-pthread 37
blis-serial 36
===================== Package Contents =====================================
~ ❯❯❯ ls /usr/lib/x86_64-linux-gnu/blis*
/usr/lib/x86_64-linux-gnu/blis64-openmp:
libblas64.so libblas64.so.3 libblis64.a libblis64.so libblis64.so.2
/usr/lib/x86_64-linux-gnu/blis64-pthread:
libblas64.so libblas64.so.3 libblis64.a libblis64.so libblis64.so.2
/usr/lib/x86_64-linux-gnu/blis64-serial:
libblas64.so libblas64.so.3 libblis64.a libblis64.so libblis64.so.2
/usr/lib/x86_64-linux-gnu/blis-openmp:
libblas.so libblas.so.3 libblis.a libblis.so libblis.so.2
/usr/lib/x86_64-linux-gnu/blis-pthread:
libblas.so libblas.so.3 libblis.a libblis.so libblis.so.2
/usr/lib/x86_64-linux-gnu/blis-serial:
libblas.so libblas.so.3 libblis.a libblis.so libblis.so.2
===================== Virtual packages ======================================
Package: libblis2-openmp, Provides: libblas.so.3, libblis.so.2
Package: libblis2-pthread, Provides: libblas.so.3, libblis.so.2
Package: libblis2-serial, Provides: libblas.so.3, libblis.so.2
Package: libblis2 (meta),
Package: python3-numpy, Depends: libblas.so.3
The meta package is still necessary because of symbols/shlibdeps.
Different threading variants have the same ABI/API, so the dependency
template is written as
libblis.so.2 libblis2 #MINVER#
instead of e.g.
libblis.so.2 libblis2-openmp #MINVER#
===================== BLAS/BLAS64 alternatives ===================================
~ ❯❯❯ update-alternatives --config libblas.so.3-x86_64-linux-gnu
There are 7 choices for the alternative libblas.so.3-x86_64-linux-gnu (providing /usr/lib/x86_64-linux-gnu/libblas.so.3).
Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 100 auto mode
1 /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3 35 manual mode
2 /usr/lib/x86_64-linux-gnu/blas/libblas.so.3 10 manual mode
3 /usr/lib/x86_64-linux-gnu/blis-openmp/libblas.so.3 38 manual mode
4 /usr/lib/x86_64-linux-gnu/blis-pthread/libblas.so.3 37 manual mode
5 /usr/lib/x86_64-linux-gnu/blis-serial/libblas.so.3 36 manual mode
7 /usr/lib/x86_64-linux-gnu/libmkl_rt.so 1 manual mode
8 /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 100 manual mode
~ ❯❯❯ update-alternatives --config libblas64.so.3-x86_64-linux-gnu
There are 5 choices for the alternative libblas64.so.3-x86_64-linux-gnu (providing /usr/lib/x86_64-linux-gnu/libblas64.so.3).
Selection Path Priority Status
------------------------------------------------------------
0 /usr/lib/x86_64-linux-gnu/blis64-openmp/libblas64.so.3 38 auto mode
1 /usr/lib/x86_64-linux-gnu/blis64-openmp/libblas64.so.3 38 manual mode
2 /usr/lib/x86_64-linux-gnu/blis64-pthread/libblas64.so.3 37 manual mode
3 /usr/lib/x86_64-linux-gnu/blis64-serial/libblas64.so.3 36 manual mode
* 5 /usr/lib/x86_64-linux-gnu/libmkl_rt.so 1 manual mode
==================== BLIS/BLIS64 alternatives ====================================
~ ❯❯❯ update-alternatives --config libblis.so.2-x86_64-linux-gnu
There are 3 choices for the alternative libblis.so.2-x86_64-linux-gnu (providing /usr/lib/x86_64-linux-gnu/libblis.so.2).
Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/lib/x86_64-linux-gnu/blis-openmp/libblis.so.2 38 auto mode
1 /usr/lib/x86_64-linux-gnu/blis-openmp/libblis.so.2 38 manual mode
2 /usr/lib/x86_64-linux-gnu/blis-pthread/libblis.so.2 37 manual mode
3 /usr/lib/x86_64-linux-gnu/blis-serial/libblis.so.2 36 manual mode
~ ❯❯❯ update-alternatives --config libblis64.so.3-x86_64-linux-gnu
There are 3 choices for the alternative libblis64.so.3-x86_64-linux-gnu (providing /usr/lib/x86_64-linux-gnu/libblis64.so.2).
Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/lib/x86_64-linux-gnu/blis64-openmp/libblis64.so.2 38 auto mode
1 /usr/lib/x86_64-linux-gnu/blis64-openmp/libblis64.so.2 38 manual mode
2 /usr/lib/x86_64-linux-gnu/blis64-pthread/libblis64.so.2 37 manual mode
3 /usr/lib/x86_64-linux-gnu/blis64-serial/libblis64.so.2 36 manual mode
(Oh well. I caught a bug while writing this email. The alternative name
should be libblis64.so.***2***-x86_64-linux-gnu)
On Fri, Jan 04, 2019 at 10:09:15AM +0100, Sébastien Villemot wrote:
> Le mardi 18 décembre 2018 à 15:12 +0000, Mo Zhou a écrit :
> > On Tue, Dec 18, 2018 at 12:42:22PM +0100, Sébastien Villemot wrote:
> > > > BTW, what is the "-base" (in libopenblas-base) supposed to mean?
> > >
> > > I don't even remember what it means, but it is clearly a legacy from
> > > the past. Ideally the package should be named "libopenblas0". But I did
> > > not bother with transitioning from one to the other, since it is rather
> > > tedious, with strictly zero benefit for users.
> >
> > Then it's a good chance for us to get rid of it, when modifying the
> > package layout. We can avoid a transition if we turn the old pacakges
> > into meta packages. I still prefer my proposed package layout, i.e.
> >
> > libopenblas0 (meta):
> > deps: libopenblas0-openmp | libopenblas0-pthread | ...
> > libopenblas-base (meta, because it cannot be safely removed):
> > deps: libopenblas0
> > libopenblas0-openmp:
> > conflicts: libopenblas0-pthread, ...
> >
> > libopenblas-dev (meta):
> > deps: libopenblas0,
> > libopenblas-openmp-dev | libopenblas-pthread-dev | ...
> > libopenblas-openmp-dev:
> > conflicts: libopenblas-pthread-dev, ...
> >
> > Such layout has several advantages:
> >
> > 1. compared to (libopenblas0 i.e. pthread version, libopenblas0-openmp),
> > the (libopenblas0-openmp, libopenblas0-pthread) layout is more
> > explicit and tidy.
> >
> > 2. we can control the default openblas implementation by adjusting
> > the dependency of libopenblas0 (meta) and libopenblas-dev (meta).
> > And maintainers of reverse dependencies won't have the headache to
> > choose one from (openmp, pthread, ...)
> >
> > 3. won't break packages that depend on libopenblas-base
>
> Ok, I think you convinced me.
>
> Note that we also want a libopenblas0-serial.
>
> (I'm CC'ing #878121 so that we don't forget this layout proposal for OpenBLAS).
More information about the debian-science-maintainers
mailing list