>> * eselect: although eselect seems the way to go, it not yet fully
>> functional. As I was working on the mkl ebuild, I found out it is not
>> possible to add a new blas/lapack implementation without changing the
>> eselect sources. As an example, mkl-7.2 is supported, but not in
>> portage, and outdated. Also eselect blas/lapack do not yet provide a
>> mechanism to show library directories and include directories. Something
>> like "eselect blas show cflags"? Am I missing something?
>
> I've just decided to start working on this. I wrote an ebuild last night
> for Goto BLAS, which provided the motivation to fix this setup.
I could contribute or test it if you are not done with it yet.
>> * Should we really keep those obsolete packages:
>> - sci-libs/atlas: now decomposed as sci-libs/blas-atlas and
>> sci-libs/lapack-atlas
>> - sci-libs/blas: redundant with sci-libs/blas-reference
>> - sci-libs/lapack: redundant with sci-libs/lapack-reference
>
> But take a look at the keywords. Although it does look like we can
> remove atlas since {blas,lapack}-atlas are stable on the same keywords,
> we can't do so for blas and lapack yet because *-reference aren't stable
> on (blas) x86 s390 ppc64 (lapack) x86 or ~arch on (lapack) ppc64.
I took a deeper look at the differences, if it can speed up the
stabilization:
* The blas-reference has exactly the same code as the older one, so I
guess keywording should be straight forward.
* The lapack-reference has an extra set of patches. I can only test on
x86 or amd64, which are not the problematic arches in this case.
>> * documentation: shouldn't blas/lapack install man pages and quick
>> references as well as in Fedora (or may be an app-docs/lapack)?
>
> Sounds useful. Got a patch?
I've just comited some app-doc/{blas,lapack}-docs to the overlay at
http://gentooscience.org,
Sebastien
--
[email protected] mailing list
