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

[Mo Zhou]

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 +0000, 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.