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

Thibaut Paumard thibaut at debian.org
Fri Feb 1 13:40:51 GMT 2019


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20190201/c9ffba57/attachment.sig>


More information about the debian-science-maintainers mailing list