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).
