We've discussed this but it didn't seem much has happened since. Long story short, you need to stop symlinking stuff to /usr/lib* and instead create a set of USE flags to select blas/lapack implementation and an eclass to enforce those flags.
To whom it may interest I have implemented such an eclass in my fork of the science-overlay: https://github.com/gentoo/sci/compare/master...Doeme:master#diff-7f6f012dc8db266ba1e7b5f7a931734c The approach: * Introduces USE-flags for all BLAS- and Lapack-implementations * Enforces that exactly one of these USE-flag has to be enabled automatically * Lets packages specify compatibility with certain implementations (BLAS/LAPACK_COMPAT=(mkl)) or with all possible implementations BLAS/LAPACK_COMPAT_ALL=1 * Lets the USE-flag propagate down the dependency-graph via BLAS/LAPACK_USEDEP (similar mechanism to PYTHON_USEDEP) Additionally, It allows packages to specify whether they need the respective C-headers with BLAS_USE_CBLAS or LAPACK_USE_LAPACKE Also, the BLAS/LAPACK_DEPEND get added automatically to DEPEND. A conditional can be added with BLAS/LAPACK_CONDITIONAL_FLAG="foo" resulting in DEPENDs like DEPEND="foo? (${BLAS_DEPEND})". To logically OR multiple flags (i.e. *_CONDITIONAL_FLAG="(foo || bar)") one can use *_CONDITIONAL_FLAG=(foo bar) Thank you for your attention
Here be dragons^W GLEPs https://github.com/Doeme/glep/blob/master/glep-xxxx.rst Also, see forum post https://forums.gentoo.org/viewtopic-p-8146934.html
(In reply to Dominik Schmidt from comment #2) > Here be dragons^W GLEPs > https://github.com/Doeme/glep/blob/master/glep-xxxx.rst > > Also, see forum post https://forums.gentoo.org/viewtopic-p-8146934.html Thank you for your effort. However, we generally don't do GLEPs for eclasses. The eclass documentation should be sufficient, and I don't really see what gain would a GLEP have. That said, I'm not going to stop you if you want to submit it for review and adoption. I'm going to look at your eclass and leave a few comments via GitHub.
Hi (In reply to Michał Górny from comment #3) > Thank you for your effort. However, we generally don't do GLEPs for > eclasses. The eclass documentation should be sufficient, and I don't really > see what gain would a GLEP have. The rationale behind doing a GLEP was the same as in any other bureaucracy: Find the largest lever available and pull it. Should I rather do a pull-request on the portage tree? Or what is the usual approach for a non-developer to contribute such things? Post patches here? Thanks Doeme
(In reply to Dominik Schmidt from comment #4) > (In reply to Michał Górny from comment #3) > > Thank you for your effort. However, we generally don't do GLEPs for > > eclasses. The eclass documentation should be sufficient, and I don't really > > see what gain would a GLEP have. > > The rationale behind doing a GLEP was the same as in any other bureaucracy: > Find the largest lever available and pull it. > > Should I rather do a pull-request on the portage tree? > Or what is the usual approach for a non-developer to contribute such things? > Post patches here? Thank you very much for your effort. The Science Team will be happy to sponsor your commits. Either a pull request or a series of patches is okay. You can choose at your convenience. The new eclass will need to be posted on gentoo-dev mailing list to request for comments. Cheers, Benda
We are bringing this topic up again. Some new insights have been gained over the years. The on-going discussion is at, https://archives.gentoo.org/gentoo-dev/message/d917547f7a9e1226fca63632a1e02026
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=111f0de1c6a774430837161b1bca64747bb0b58c commit 111f0de1c6a774430837161b1bca64747bb0b58c Author: Mo Zhou <cdluminate@gmail.com> AuthorDate: 2019-06-25 09:05:15 +0000 Commit: Benda Xu <heroxbd@gentoo.org> CommitDate: 2019-06-25 10:57:59 +0000 app-eselect/eselect-{blas,lapack}: new design for BLAS/LAPACK switch. As discussed in the gentoo-dev, it is decided to adopt the runtime switching of BLAS/CBLAS that has been proved by the experience of Debian. The Gentoo libgcc-style ld.so.conf runtime switching has been adopted as well, so as to avoid changing symlinks in /usr ignoring package manager. This design solves all the remaining problems regarding BLAS/LAPACK, thus making alternative-2.eclass (runtime switching of build options) and proposed USE_EXPAND (PYTHON_TARGET like eclass) obsolete. Finally we are at it. Thanks to all for years of ideas, debates and hard work. Reference: https://archives.gentoo.org/gentoo-dev/message/0177fea10e3ee06d85713101d17fc8d6 Closes: https://bugs.gentoo.org/632624 Closes: https://bugs.gentoo.org/470908 Closes: https://bugs.gentoo.org/267691 Closes: https://github.com/gentoo/gentoo/pull/12316 Closes: https://github.com/gentoo/gentoo/pull/12318 Closes: https://github.com/gentoo/sci/pull/835 Closes: https://github.com/gentoo/sci/pull/837 Credit: Dominik Schmidt, TheChymera, kiwifb, lkraav, Alessandro-Barbieri Signed-off-by: Mo Zhou <cdluminate@gmail.com> Signed-off-by: Benda Xu <heroxbd@gentoo.org> app-eselect/eselect-blas/eselect-blas-0.2.ebuild | 28 ++++ app-eselect/eselect-blas/files/blas.eselect-0.2 | 168 +++++++++++++++++++++ app-eselect/eselect-blas/files/blas.eselect.5 | 34 +++-- .../eselect-lapack/eselect-lapack-0.2.ebuild | 27 ++++ .../eselect-lapack/files/lapack.eselect-0.2 | 167 ++++++++++++++++++++ app-eselect/eselect-lapack/files/lapack.eselect.5 | 26 +++- 6 files changed, 434 insertions(+), 16 deletions(-)
