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
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:
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,
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
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:
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
6 matches
Mail list logo
