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.
