From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-87229-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id D81D9138334
for <garchives@archives.gentoo.org>; Wed, 29 May 2019 14:00:37 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 535FEE08DA;
Wed, 29 May 2019 14:00:33 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 0C557E0875
for <gentoo-dev@lists.gentoo.org>; Wed, 29 May 2019 14:00:32 +0000 (UTC)
Received: from muon (vm4.gentoo.osuosl.org [140.211.166.172])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
(Authenticated sender: heroxbd)
by smtp.gentoo.org (Postfix) with ESMTPSA id 3EDFC34523D
for <gentoo-dev@lists.gentoo.org>; Wed, 29 May 2019 14:00:30 +0000 (UTC)
Received: from [2001:470:4c22:ae86:babe:10:0:1] (port=47658 helo=proton)
by muon with esmtp (Exim 4.89)
(envelope-from <heroxbd@gentoo.org>)
id 1hVz7y-0000Kj-Ti
for gentoo-dev@lists.gentoo.org; Wed, 29 May 2019 14:00:27 +0000
From: Benda Xu <heroxbd@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] RFC: BLAS and LAPACK runtime switching
References: <2d3636f5bd6a738f30a4ad2e697b1ddb@debian.org>
<d8630ad99775233b33da0be5063b177b560246ba.camel@gentoo.org>
Date: Wed, 29 May 2019 22:00:26 +0800
In-Reply-To: <d8630ad99775233b33da0be5063b177b560246ba.camel@gentoo.org>
(David Seifert's message of "Tue, 28 May 2019 14:05:48 +0200")
Message-ID: <878supwebp.fsf@proton.d.airelinux.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
MIME-Version: 1.0
Content-Type: text/plain
X-Archives-Salt: c2475132-fb33-4e75-9ff0-0b6ec2818032
X-Archives-Hash: a723b4f089e3c5952ee9de6b33c2a8d5
Dear David,
David Seifert <soap@gentoo.org> writes:
> We already have such a solution in the sci-overlay. It has proven
> extremely brittle and shaky.
What's more, using eselect set which library to link to was regarded
harmful.
> The plan is to do this via USE flags similar to python-single-r1
> flags.
Yes, that was the conclusion in 2017.
But now there is something to be renewed, see below.
> Optionally, we can leave a "virtual" USE flag, where users can switch
> implementation at runtime, but this will not be a supported
> configuration.
[...]
> While I understand that runtime-switching sounds like a great feature,
> it has proven too difficult to get right and too hard to enforce
> invariants on correct symlinks.
I thought so, too. Back in 2017, I did an investigate of Debian runtime
switching, and concluded the patches were too heavy for us. That was the
main reason we did not consider the Debian runtime switching way.[0, 1]
However, I have made a deeper study this year, and concluded it is quite
doable in a simple way in Gentoo.
Historically, in alternative{,-2}.eclass of the science overlay,
"alternative" is a name from Debian[2]. We have made it too complex over
the years, and now there is a good chance to make it simple again.
> People that want this can go the virtual+eselect approach in the
> overlay,
Which is brittle and shaky as we agree.
> but 99% of Gentoo users will be happy with just linking against
> OpenBLAS/reference-lapack and not having to fix weird stale symlinks
> that eselect-alternatives somehow lost track of.
With the simplified approach Mo is after, there will no longer be weird
stale symlinks issues. The solution has been successfully proved by the
update-alternative mechanism in Debian. Actually, by adopting mgorny's
LDPATH way of handing gcc runtime, we don't need symlinks at all![3]
For more details, please refer to
https://people.debian.org/~lumin/gsoc19-gentoo.pdf
> See also:
> https://bugs.gentoo.org/632624
> https://bugs.gentoo.org/348843#c30
Thanks. That reminded me of all the discussions we all along.
Yours,
Benda
0. https://github.com/gentoo/sci/issues/805#issuecomment-345690034
1. https://github.com/gentoo/sci/issues/805#issuecomment-345701064
2. https://github.com/gentoo/sci/issues/805#issuecomment-332887691
3. https://bugs.gentoo.org/632618