Dear Mo Zhou, Le 01/02/2019 à 05:55, Mo Zhou a écrit : > 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
I don't see any problem with the above, but if you prefer, why not get rid of one level this way: Package: libblis2-openmp, Provides: libblas.so.3 Package: libblis2-pthread, Provides: libblas.so.3 Package: libblis2-serial, Provides: libblas.so.3 Package: python3-numpy, Depends: libblas.so.3 Packages which need a specific build of blis link with this specific build, the others link with blas. Or are there products that would need to be linked with blis rather than blas, and don't care for the specific build? In this case you could also: 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 Kind regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
