Bug#919272: Is multiple-layers of alternatives a good thing to users?

Ian Jackson ijackson at chiark.greenend.org.uk
Sun Feb 3 21:34:08 GMT 2019


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 <ijackson at 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.



More information about the debian-science-maintainers mailing list