From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-science+bounces-1904-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 45EDF138247
	for <garchives@archives.gentoo.org>; Tue, 21 Jan 2014 20:04:49 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 65FB5E0F69;
	Tue, 21 Jan 2014 20:04:47 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id AC412E0F66
	for <gentoo-science@lists.gentoo.org>; Tue, 21 Jan 2014 20:04:45 +0000 (UTC)
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: bicatali)
	by smtp.gentoo.org (Postfix) with ESMTPSA id C71CA33FA8B
	for <gentoo-science@lists.gentoo.org>; Tue, 21 Jan 2014 20:04:44 +0000 (UTC)
Received: by mail-ig0-f179.google.com with SMTP id c10so11863221igq.0
        for <gentoo-science@lists.gentoo.org>; Tue, 21 Jan 2014 12:04:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=mime-version:reply-to:in-reply-to:references:date:message-id
         :subject:from:to:content-type;
        bh=2LUnawVeXKHzT0uR0vErcgJb3qqcUgPQhT0MF6xgWmk=;
        b=LfWJbse6qNvzRfAOxr0lFega2//F/x+qdbeoo3SbO+xKi6dNwb7a+WasMxN6q7U0ij
         O75dvbHqwHymUsv64b9evoNc02hwSaSfgJz8UPId7Mw8mhC7p+Aszs2mt+9CL4hoqvgd
         GZttIbryi8OUWxRTgbMoCXk58+sy3LxB4cWLF0HZqbp7y0mhHGGsOPA8OouYDIUKBqiO
         oSuF12YatOZufgnMV9kB+3YEvn/UQpHAU0GgmOiRvOWgffcfCZdg0fb3WFWudKTK5IN3
         Q6RkoT/cKbAp6iHODkHDM3MgOn8kN9/LO97FMkDAoXdKsfbMZgrArwAeCMOMu8bO9d+q
         CNow==
Precedence: bulk
List-Post: <mailto:gentoo-science@lists.gentoo.org>
List-Help: <mailto:gentoo-science+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-science+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-science+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-science.gentoo.org>
X-BeenThere: gentoo-science@lists.gentoo.org
Reply-to: gentoo-science@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.50.66.180 with SMTP id g20mr19556114igt.29.1390334683340;
 Tue, 21 Jan 2014 12:04:43 -0800 (PST)
Received: by 10.64.89.41 with HTTP; Tue, 21 Jan 2014 12:04:43 -0800 (PST)
In-Reply-To: <20140121192641.GB13149@dhcppc1>
References: <1390240392-12173-1-git-send-email-rei4dan@gmail.com>
	<CAA-OU2qgiadwBAEduFBDS7zSCsLZDcYoZgYTt5fZ-YXOhhASww@mail.gmail.com>
	<20140121192641.GB13149@dhcppc1>
Date: Tue, 21 Jan 2014 12:04:43 -0800
Message-ID: <CAA-OU2qOGjWdM1JakyzkL1Kc+U-OpnYybisD2Jgkryz1Licw2g@mail.gmail.com>
Subject: Re: [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates
From: =?UTF-8?Q?S=C3=A9bastien_Fabbro?= <bicatali@gentoo.org>
To: gentoo-science@lists.gentoo.org
Content-Type: multipart/alternative; boundary=047d7bdc14e8ebc0c704f0808427
X-Archives-Salt: 2571f9da-c817-4972-9644-6775ec7e2c15
X-Archives-Hash: d3ec041a48ffd91e1ecf0acf37883758

--047d7bdc14e8ebc0c704f0808427
Content-Type: text/plain; charset=UTF-8

On Tue, Jan 21, 2014 at 11:26 AM, Reinis Danne <rei4dan@gmail.com> wrote:

>
> How the eselect module creation could work? Something like this?
>
> ~# eselect module create blas
> ~# eselect blas add atlas importance src dest [src dest [..]]
> ...
> ~# eselect blas remove atlas
> ~# eselect delete blas
>


That is the idea. Last one should be "eselect module delete blas".


> > * given the number of bugs, we should keep the linking to the reference
> > names libraries, so we could eselect providers without re-compiling all
> > reverse dependencies. We could do this in the open sourced providers by
> > changing the soname of the libraries we compile, and in the binary ones
> > (mkl,amcl...) with a link script generated library.
>
> Yes, this is ok and AFAICT it is like that now in the overlay.
>
>
It is not. Let's take blas for example. Install openblas and
blas-reference, then eselect blas reference. Then install lapack-reference,
then remove blas-reference. You will have to re-install lapack-reference,
because of a missing reference to librefblas.so. If openblas had the
libblas.so soname and link, you would not have to. I'm actually not sure
whether it is a side effect of our as-needed policy.

We need to change all blas ebuilds to make sure they have the same soname,
and add to alternatives_for blas the libraries to link. For blas-reference,
eigen, atlas and openblas, this is just a matter of a link flag. For acml
and mkl, this is trickier, thus the gen_usr_ldscript from toolchain-funcs
eclass idea. If the ldscript stuff is not much overhead, we could apply it
to all.

Sebastien

--047d7bdc14e8ebc0c704f0808427
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Jan 21, 2014 at 11:26 AM, Reinis Danne <span dir=
=3D"ltr">&lt;<a href=3D"mailto:rei4dan@gmail.com" target=3D"_blank">rei4dan=
@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
How the eselect module creation could work? Something like this?<br>
<br>
~# eselect module create blas<br>
~# eselect blas add atlas importance src dest [src dest [..]]<br>
...<br>
~# eselect blas remove atlas<br>
~# eselect delete blas<br></blockquote><div>=C2=A0</div><div><br></div><div=
 style>That is the idea. Last one should be &quot;eselect module delete bla=
s&quot;.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

&gt; * given the number of bugs, we should keep the linking to the referenc=
e<br>
&gt; names libraries, so we could eselect providers without re-compiling al=
l<br>
&gt; reverse dependencies. We could do this in the open sourced providers b=
y<br>
&gt; changing the soname of the libraries we compile, and in the binary one=
s<br>
&gt; (mkl,amcl...) with a link script generated library.<br>
<br>
Yes, this is ok and AFAICT it is like that now in the overlay.<br>
<br></blockquote><div>=C2=A0</div><div style>It is not. Let&#39;s take blas=
 for example. Install openblas and blas-reference, then eselect blas refere=
nce. Then install lapack-reference, then remove blas-reference. You will ha=
ve to re-install lapack-reference, because of a missing reference to libref=
blas.so. If openblas had the libblas.so soname and link, you would not have=
 to. I&#39;m actually not sure whether it is a side effect of our as-needed=
 policy.</div>
<div style>=C2=A0</div><div style>We need to change all blas ebuilds to mak=
e sure they have the same soname, and add to alternatives_for blas the libr=
aries to link. For blas-reference, eigen, atlas and openblas, this is just =
a matter of a link flag. For acml and mkl, this is trickier, thus the gen_u=
sr_ldscript from toolchain-funcs eclass idea. If the ldscript stuff is not =
much overhead, we could apply it to all.</div>
<div style><br></div><div style>Sebastien</div><div style><br></div></div><=
/div></div>

--047d7bdc14e8ebc0c704f0808427--