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 Jackson <ijack...@chiark.greenend.org.uk> These 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.
