Bug#919272: Is multiple-layers of alternatives a good thing to users?
Hi Guus,
On Mon, Feb 04, 2019 at 07:55:41AM +0100, Guus Sliepen wrote:
> > libblis.so.2 libblis2 #MINVER#
>
> If the ABI and API are the same for all variants, a much better
> solutions seems to me to have a single libblis2 that can switch at
> runtime between the different variants, perhaps using an environment
> variable to decide. That would require some support from upstream
> though.
Yes, I agree that such support is better. Actually the libmkl-rt library
from intel-mkl (non-free) supports the feature you said[1], and its
quite convenient. However for the BLIS upstream I think they don't have
enough fund and energy to develop such a feature. Based on that,
the current solution looks good enough.
[1] Env var MKL_THREADING_LAYER={intel,gnu,tbb,sequential}
allows to to switch threading model among libiomp5, libgomp,
libtbb2, and none.
Bug#919272: Is multiple-layers of alternatives a good thing to users?
On Mon, Feb 04, 2019 at 06:07:55AM +, Mo Zhou wrote: > My updated version, all variants are co-installable now: > > 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# If the ABI and API are the same for all variants, a much better solutions seems to me to have a single libblis2 that can switch at runtime between the different variants, perhaps using an environment variable to decide. That would require some support from upstream though. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#919272: Is multiple-layers of alternatives a good thing to users?
Hi Ian and Thibaut, Inspired by Thibaut's comment, I worked out a good solution for the co-installation problem, which only results in a single layer of alternatives. Thibaut's proposed layout: > 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: python3-numpy,Depends: libblas.so.3 My updated version, all variants are co-installable now: 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# On Sun, Feb 03, 2019 at 09:34:08PM +, Ian Jackson wrote: > In general coinstallability is a good thing. > ... > This would mean that the user could choose a different library for > "programs which wanted BLAS" and "programs which wanted BLIS" but I > don't think that is a problem ? > ... > I agree that multiple layers of alternatives indirection is > undesirable. But I think these libraries can be made coinstallable > without that. My initial design of package layout is hierarchical. Inspired by the comments I found the above solution after a rethink. BLIS packaging has been updated and I'm testing it now. Thank you for comments.
Bug#919272: Is multiple-layers of alternatives a good thing to users?
Mo Zhou writes ("Is multiple-layers of alternatives a good thing to users?"):
> A user suggested[1] that the 6 variants[2] of BLIS should be
> co-installable. However, making them co-installable would result in
> multiple layers of alternatives in the update-alternatives system and
> will possibly confuse users, as discussed in [3]. I wrote this mail
> in case anyone has a better solution so we will have a chance to fix[1].
>
> Tacking the three 32-bit variants as examples, we will have the
> following alternative chain if the 3 variants were made co-installable:
>
> Package: libblis2-openmp, Provides: libblis.so.2
> Package: libblis2-pthread, Provides: libblis.so.2
> Package: libblis2-serial, Provides: libblis.so.2
> Package: libblis2 (meta), Provides: libblas.so.3, Depends: libblis.so.2,
> Package: python3-numpy,Depends: libblas.so.3
>
> numpy asks for libblas.so.3
> -> libblas.so.3 is an alternative pointing to libblis2
> -> libblis.so.2 is an alternative pointing to any one of the three
> variants
In general coinstallability is a good thing.
I don't understand why the multiple levels of alternatives are
inevitable. Why could each of the variants not provide both an
alternative option for libblas.so.3, and separately one for
libblis.so.3 ?
This would mean that the user could choose a different library for
"programs which wanted BLAS" and "programs which wanted BLIS" but I
don't think that is a problem ?
(Getting there from here is left as an exercise to the reader...)
> Such layout not only makes the packaging more difficult to maintain, but
> also makes it harder for the user to understand what BLAS backend is
> actually invoked.
I agree that multiple layers of alternatives indirection is
undesirable. But I think these libraries can be made coinstallable
without that.
HTH.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#919272: Is multiple-layers of alternatives a good thing to users?
Dear Mo Zhou, Le 01/02/2019 à 05:55, Mo Zhou a écrit : > Tacking the three 32-bit variants as examples, we will have the > following alternative chain if the 3 variants were made co-installable: > > Package: libblis2-openmp, Provides: libblis.so.2 > Package: libblis2-pthread, Provides: libblis.so.2 > Package: libblis2-serial, Provides: libblis.so.2 > Package: libblis2 (meta), Provides: libblas.so.3, Depends: libblis.so.2, > Package: python3-numpy,Depends: libblas.so.3 > > numpy asks for libblas.so.3 > -> libblas.so.3 is an alternative pointing to libblis2 > -> libblis.so.2 is an alternative pointing to any one of the three > variants I don't see any problem with the above, but if you prefer, why not get rid of one level this way: Package: libblis2-openmp, Provides: libblas.so.3 Package: libblis2-pthread, Provides: libblas.so.3 Package: libblis2-serial, Provides: libblas.so.3 Package: python3-numpy,Depends: libblas.so.3 Packages which need a specific build of blis link with this specific build, the others link with blas. Or are there products that would need to be linked with blis rather than blas, and don't care for the specific build? In this case you could also: 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: python3-numpy,Depends: libblas.so.3 Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#919272: Is multiple-layers of alternatives a good thing to users?
Hi devel, A user suggested[1] that the 6 variants[2] of BLIS should be co-installable. However, making them co-installable would result in multiple layers of alternatives in the update-alternatives system and will possibly confuse users, as discussed in [3]. I wrote this mail in case anyone has a better solution so we will have a chance to fix[1]. Tacking the three 32-bit variants as examples, we will have the following alternative chain if the 3 variants were made co-installable: Package: libblis2-openmp, Provides: libblis.so.2 Package: libblis2-pthread, Provides: libblis.so.2 Package: libblis2-serial, Provides: libblis.so.2 Package: libblis2 (meta), Provides: libblas.so.3, Depends: libblis.so.2, Package: python3-numpy,Depends: libblas.so.3 numpy asks for libblas.so.3 -> libblas.so.3 is an alternative pointing to libblis2 -> libblis.so.2 is an alternative pointing to any one of the three variants Such layout not only makes the packaging more difficult to maintain, but also makes it harder for the user to understand what BLAS backend is actually invoked. So my current solution is only allowing one instance of the three variants installed on the system, i.e. every one of the three variants conflicts with each other. Drew and Sébastien agreed with the choice to make the variants conflict to each other. So I personally tend to leave the bug[1] unresolved. However if anyone comes up with a better idea or solution, or believes that multiple layers of alternatives are fine, we could discuss about it and try to address the co-installability issue[1]. As a side note, different variants of BLIS are co-installable on Fedora, but they come with different SONAMEs and there is no any mechanism similar to update-alternatives at all. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919272 [2] 6 variants = (32-bit index, 64-bit index) x (openmp, pthread, serial) [3] https://lists.debian.org/debian-science/2019/01/msg7.html
