Bugzilla Bug 189722

This is a bug tracker to follow the update of the new virtuals for blas, cblas
and lapack mentioned on the science list. It resides now in the science
overlay.
Bugs (old ones and newer ones) involving blas,cblas,lapack configuration should
block this one.

We could proceed as follow:
1- Quick stabilization of the latest {blas,cblas,lapack}-reference packages
(just commited, but I only tested x86 and amd64).
2 - Import all new virtual packages and optimized libraries.
3 - Wait 30 days, ask for stabilization of optmized libraries without bugs.
4 - cleanup of obsolete versions, virtuals and stale bugs. 

We have also a new documentation going on in bug #189680.

Sébastien

*** Bug 189802 has been marked as a duplicate of this bug. ***

I've been running into vast quantities of issues lately where cblas-reference
or some lapack is looking for a pkgconfig file that my older blas didn't
install. One way to deal with this is to bump the virtual so it requires
pkgconfig-safe versions.

> I've been running into vast quantities of issues lately where cblas-reference
> or some lapack is looking for a pkgconfig file that my older blas didn't
> install. One way to deal with this is to bump the virtual so it requires
> pkgconfig-safe versions.

I am waiting for various arches to stabilize the *-reference so we can bump the
new virtuals. We also need to have the possibility of re-eselecting the same
profile, which is the eselect bug #189942 ;-), and is probably also what's
slowing down arches to stabilize. I must admit the whole process is a bit
circular.

(In reply to comment #2)
> I've been running into vast quantities of issues lately where cblas-reference
> or some lapack is looking for a pkgconfig file that my older blas didn't
> install. One way to deal with this is to bump the virtual so it requires
> pkgconfig-safe versions.
> 

We may also need to bump eselect and make sure it is pulled in via eselect-blas
etc, so users have the fixed /usr/share/eselect/libs/skel.bash on their systems
before they get started with the new ebuilds.

Markus

(In reply to comment #4)
> We may also need to bump eselect and make sure it is pulled in via eselect-blas
> etc, so users have the fixed /usr/share/eselect/libs/skel.bash on their systems
> before they get started with the new ebuilds.

We first need to find someone who will roll an eselect release.

All done here too.