(I've been not quite following, so take this with a grain of salt.)
The normal approach in pkgsrc is to set a system-wide variable to
specify the implementation, and thus to install only one of the
alternatives. We do this for pgsql and kerberos.
If the ABI of the variants is really the same, then one can flip the
variable and "make replace OLDNAME=" with the new openblas. Or just
pkg_delete -f and install the ne one.
If they are made parallel installable, sort of like guile20 and guile22,
then there can be a per-package variable to link against various
versions. However, if there is a library that links against OpenBLAS,
and then something else links against that, and also directly, or
indirectly via another library that links againat a different version,
then it gets very messy very fast. It's likely that the files will be
namespaces (/usr/pkg/openblas-{foo,bar}/lib/libopenblas.so), but much
harder to namespace the symbols. So two in one binary is very likely
not going to work.
An alternative approach is to bootstrap pkgsrc multiple time, with a
single global variable set to different implementations, and build
different packages in the the different pkg instances. While the astute
reader will note that this does not scale well to multiple difficult
packages, we don't really need scaling, but rather feasible solutions
for the actual problems of interest. Still, it seems too complicated.
Another approach is to write better tests and fix the various packages.
Without understanding the details, it seems that it is basically a bug
that multiple variants exist. But I realize coping with bugs is
sometimes easier than fixing them.
I see in wip openblas-devel and OpenBLAS, and they seem to be the same
version. Where are the various versions being considered to be
switched?
Attachment:
signature.asc
Description: PGP signature