Gentoo Archives: gentoo-science

From: Reinis Danne <rei4dan@×××××.com>
To: gentoo-science@l.g.o
Subject: Re: [gentoo-science] blas selection in lapack-reference
Date: Wed, 22 Jan 2014 10:02:14
Message-Id: 20140122100207.GE13149@dhcppc1
In Reply to: Re: [gentoo-science] blas selection in lapack-reference by "François Bissey"
1 On Wed, Jan 22, 2014 at 10:54:48PM +1300, François Bissey wrote:
2 > On 2014-01-22 22:47, Reinis Danne wrote:
3 > > On Tue, Jan 21, 2014 at 07:47:48PM -0600, Steven Trogdon wrote:
4 > >> On Wed, 22 Jan 2014 13:52:57 +1300
5 > >> François Bissey <fbissey@××××××××××××.nz> wrote:
6 > >>
7 > >> > We have yet another instance of someone emerging lapack-reference
8 > >> > without
9 > >> > a valid blas configuration in
10 > >> > https://bugs.gentoo.org/show_bug.cgi?id=498490
11 > >> > (not their original problem).
12 > >> > I think we should do something about this in lapack-reference and
13 > >> > possibly
14 > >> > other ebuilds.
15 > >> > In pkg_setup, we could run
16 > >> > eselect blas update
17 > >> > to make sure that a valid configuration is active
18 > >> > and display an informational message about the blas provider
19 > >> > used with the output of
20 > >> > eselect blas show
21 > >> >
22 > >> > Who thinks is a good/bad idea?
23 > >> >
24 > >> > Francois
25 > >> >
26 > >>
27 > >> For one, I'm in favor of something like this - though I probably don't
28 > >> have
29 > >> much say in the matter. I've been bitten by not eselecting {blas,
30 > >> cblas,
31 > >> lapack} after an upgrade. And I've even posted on this forum the
32 > >> problem.
33 > >>
34 > >> http://article.gmane.org/gmane.linux.gentoo.science/1915
35 > >> http://article.gmane.org/gmane.linux.gentoo.science/1916
36 > >>
37 > >> I resolved things, quite accidently, by re-eselecting the important
38 > >> components which were eselected before the upgrade.
39 > >>
40 > >> Steve
41 > >>
42 > >
43 > > I fixed provider selection during upgrades in overlay
44 > > (yesterday). Now it should have valid provider set at any time.
45 > > With that do you still think it would need this extra eselect
46 > > update in ebuild?
47 > >
48 > >
49 > It seems that the difficult point is when you go from no provider
50 > available
51 > to one provider available. If that case is fixed then: No
52
53 That case also works.
54
55
56 Reinis