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/msg00007.html
