Re: [gentoo-dev] [PATCH v2] profiles: add more language codes to desc/l10n.desc
On 2019-06-13 13:46, Jaco Kroon wrote: > Any chance of adding en-NZ? > > asterisk-core-sounds depends on L10N USE_EXPAND and there is an upstream > en-NZ pack. It's the only language pack for which there isn't currently > an option already in the list here. Sure, why not. Looks reasonably enough to me. -- MS
Re: [gentoo-dev] [PATCH v4 08/19] user.eclass: Factor out finding nologin into separate function
On Thu, 2019-06-13 at 09:01 -0400, Michael Orlitzky wrote:
> On 6/13/19 1:33 AM, Michał Górny wrote:
> > > > + eshell=$(user_get_nologin)
> > >
> > > Then this would have to become
> > >
> > > eshell=$(userland_get_nologin "${USERLAND}")
> >
> > Do you have any real use for that?
> >
>
> No. It's a better design IMO since you can e.g. test the function by
> passing it an argument rather than by setting a global variable (which
> has other consequences). But no immediate application.
>
I'm sorry but this makes no sense. The function already depends on ROOT
variable, and on presence of specific files in the filesystem. I see no
reason to make USERLAND special here.
Furthermore, it's an internal function with no external application.
It has two call sites, and in both we want the same value of USERLAND
(which is defined by profiles) to apply.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PATCH] xorg-3.eclass: EAUTORECONF_DEPENDS belong to BDEPEND
On Thu, 13 Jun 2019 15:02:23 +0200
Michael Haubenwallner wrote:
> On 6/13/19 2:45 PM, James Le Cuirot wrote:
> > On Thu, 13 Jun 2019 13:08:15 +0200
> > Michael Haubenwallner wrote:
> >
> >> EAUTORECONF_DEPENDS is non-empty for ppc-aix and x86-winnt only.
> >> Also, unset variable 'arch' after use.
> >> ---
> >> eclass/xorg-3.eclass | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
> >> index 6ac90a64d59..f135058fba6 100644
> >> --- a/eclass/xorg-3.eclass
> >> +++ b/eclass/xorg-3.eclass
> >> @@ -116,7 +116,8 @@ WANT_AUTOMAKE="latest"
> >> for arch in ${XORG_EAUTORECONF_ARCHES}; do
> >>EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
> >> done
> >> -DEPEND+=" ${EAUTORECONF_DEPENDS}"
> >> +unset arch
> >> +BDEPEND+=" ${EAUTORECONF_DEPENDS}"
> >> [[ ${XORG_EAUTORECONF} != no ]] && BDEPEND+=" ${EAUTORECONF_DEPEND}"
> >> unset EAUTORECONF_DEPENDS
> >> unset EAUTORECONF_DEPEND
> >
> > Apart from the unset, the comment doesn't seem to relate to the actual
> > change?
>
> Agreed: The relation should become clear with 15 lines of context.
> Or do you mean something else?
Okay, I get it now. I was also slightly confused by the very similar
variable names.
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpI9AKyjHgoG.pgp
Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH] xorg-3.eclass: EAUTORECONF_DEPENDS belong to BDEPEND
On 6/13/19 2:45 PM, James Le Cuirot wrote:
> On Thu, 13 Jun 2019 13:08:15 +0200
> Michael Haubenwallner wrote:
>
>> EAUTORECONF_DEPENDS is non-empty for ppc-aix and x86-winnt only.
>> Also, unset variable 'arch' after use.
>> ---
>> eclass/xorg-3.eclass | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
>> index 6ac90a64d59..f135058fba6 100644
>> --- a/eclass/xorg-3.eclass
>> +++ b/eclass/xorg-3.eclass
>> @@ -116,7 +116,8 @@ WANT_AUTOMAKE="latest"
>> for arch in ${XORG_EAUTORECONF_ARCHES}; do
>> EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
>> done
>> -DEPEND+=" ${EAUTORECONF_DEPENDS}"
>> +unset arch
>> +BDEPEND+=" ${EAUTORECONF_DEPENDS}"
>> [[ ${XORG_EAUTORECONF} != no ]] && BDEPEND+=" ${EAUTORECONF_DEPEND}"
>> unset EAUTORECONF_DEPENDS
>> unset EAUTORECONF_DEPEND
>
> Apart from the unset, the comment doesn't seem to relate to the actual
> change?
Agreed: The relation should become clear with 15 lines of context.
Or do you mean something else?
Thanks!
/haubi/
From 1eb3709d84b04c4fbbed342de8f5721233e35e2f Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner
Date: Thu, 13 Jun 2019 12:58:04 +0200
Subject: [PATCH] xorg-3.eclass: EAUTORECONF_DEPENDS belong to BDEPEND
EAUTORECONF_DEPENDS is non-empty for ppc-aix and x86-winnt only.
Also, unset variable 'arch' after use.
---
eclass/xorg-3.eclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index 6ac90a64d59..f135058fba6 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -104,31 +104,32 @@ fi
# Set up autotools shared dependencies
# Remember that all versions here MUST be stable
XORG_EAUTORECONF_ARCHES="ppc-aix x86-winnt"
EAUTORECONF_DEPEND+="
>=sys-devel/libtool-2.2.6a
sys-devel/m4"
if [[ ${PN} != util-macros ]] ; then
EAUTORECONF_DEPEND+=" >=x11-misc/util-macros-1.18 >=media-fonts/font-util-1.2.0"
fi
WANT_AUTOCONF="latest"
WANT_AUTOMAKE="latest"
for arch in ${XORG_EAUTORECONF_ARCHES}; do
EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
done
-DEPEND+=" ${EAUTORECONF_DEPENDS}"
+unset arch
+BDEPEND+=" ${EAUTORECONF_DEPENDS}"
[[ ${XORG_EAUTORECONF} != no ]] && BDEPEND+=" ${EAUTORECONF_DEPEND}"
unset EAUTORECONF_DEPENDS
unset EAUTORECONF_DEPEND
# @ECLASS-VARIABLE: XORG_STATIC
# @DESCRIPTION:
# Enables static-libs useflag. Set to no, if your package gets:
#
# QA: configure: WARNING: unrecognized options: --disable-static
: ${XORG_STATIC:="yes"}
# Add static-libs useflag where useful.
if [[ ${XORG_STATIC} == yes \
&& ${CATEGORY} != app-doc \
&& ${CATEGORY} != x11-apps \
--
2.19.2
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v4 08/19] user.eclass: Factor out finding nologin into separate function
On 6/13/19 1:33 AM, Michał Górny wrote:
>>
>>> + eshell=$(user_get_nologin)
>>
>> Then this would have to become
>>
>> eshell=$(userland_get_nologin "${USERLAND}")
>
> Do you have any real use for that?
>
No. It's a better design IMO since you can e.g. test the function by
passing it an argument rather than by setting a global variable (which
has other consequences). But no immediate application.
Re: [gentoo-dev] [PATCH v4 00/19] User/group packages
On 6/13/19 4:54 AM, Alexey Shvetsov wrote: > Hi! > > Its a good thing that you're reviewing user class. I write some thought > previosly about it. > > Why not create some set for standart uid:gid for services so they will > be identicall in all installations? > > like slurm has uid:gid 500:500 > nginx 80:80 or something... > This is what we're doing =)
Re: [gentoo-dev] [PATCH v2] profiles: add more language codes to desc/l10n.desc
Hi, Any chance of adding en-NZ? asterisk-core-sounds depends on L10N USE_EXPAND and there is an upstream en-NZ pack. It's the only language pack for which there isn't currently an option already in the list here. Kind Regards, Jaco On 2019/06/13 10:26, Marek Szuba wrote: Many thanks for the feedback, here is the revised patch: * * * All of these are supported by recent versions of app-text/tesseract. Checked against ISO-639 using the code tables from https://iso639-3.sil.org/ . Signed-off-by: Marek Szuba --- profiles/desc/l10n.desc | 14 ++ 1 file changed, 14 insertions(+) diff --git a/profiles/desc/l10n.desc b/profiles/desc/l10n.desc index 4d30aa57eb3..e5e21346174 100644 --- a/profiles/desc/l10n.desc +++ b/profiles/desc/l10n.desc @@ -41,8 +41,10 @@ bs - Bosnian ca - Catalan ca-valencia - Catalan (Valencian) cak - Kaqchikel +ceb - Cebuano chr - Cherokee cnr - Montenegrin +co - Corsican cs - Czech cy - Welsh da - Danish @@ -53,6 +55,7 @@ de-DE - German (Germany) dgo - Dogri (individual language) doi - Dogri (macrolanguage) dsb - Lower Sorbian +dv - Dhivehi dz - Dzongkha el - Modern Greek en - English @@ -88,13 +91,16 @@ he - Hebrew hi - Hindi hr - Croatian hsb - Upper Sorbian +ht - Haitian hu - Hungarian hy - Armenian ia - Interlingua id - Indonesian is - Icelandic it - Italian +iu - Inuktitut ja - Japanese +jv - Javanese ka - Georgian kab - Kabyle kk - Kazakh @@ -120,6 +126,7 @@ mn - Mongolian mni - Manipuri mr - Marathi ms - Malay (macrolanguage) +mt - Maltese my - Burmese nan - Min Nan Chinese nb - Norwegian Bokmål @@ -134,9 +141,11 @@ om - Oromo or - Oriya (macrolanguage) pa - Punjabi pl - Polish +ps - Pushto pt - Portuguese pt-BR - Portuguese (Brazil) pt-PT - Portuguese (Portugal) +qu - Quechua rm - Romansh ro - Romanian ru - Russian @@ -156,6 +165,7 @@ sr - Serbian sr-Latn - Serbian (Latin script) ss - Swati st - Southern Sotho +su - Sundanese sv - Swedish sw - Swahili (macrolanguage) sw-TZ - Swahili (Tanzania) @@ -165,9 +175,11 @@ ta-LK - Tamil (Sri Lanka) te - Telugu tg - Tajik th - Thai +ti - Tigrinya tk - Turkmen tl - Tagalog tn - Tswana +to - Tonga (Tonga Islands) tr - Turkish ts - Tsonga tt - Tatar @@ -178,6 +190,8 @@ uz - Uzbek ve - Venda vi - Vietnamese xh - Xhosa +yi - Yiddish +yo - Yoruba zh - Chinese zh-CN - Chinese (China) zh-TW - Chinese (Taiwan)
Re: [gentoo-dev] [PATCH] xorg-3.eclass: EAUTORECONF_DEPENDS belong to BDEPEND
On Thu, 13 Jun 2019 13:08:15 +0200
Michael Haubenwallner wrote:
> EAUTORECONF_DEPENDS is non-empty for ppc-aix and x86-winnt only.
> Also, unset variable 'arch' after use.
> ---
> eclass/xorg-3.eclass | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
> index 6ac90a64d59..f135058fba6 100644
> --- a/eclass/xorg-3.eclass
> +++ b/eclass/xorg-3.eclass
> @@ -116,7 +116,8 @@ WANT_AUTOMAKE="latest"
> for arch in ${XORG_EAUTORECONF_ARCHES}; do
> EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
> done
> -DEPEND+=" ${EAUTORECONF_DEPENDS}"
> +unset arch
> +BDEPEND+=" ${EAUTORECONF_DEPENDS}"
> [[ ${XORG_EAUTORECONF} != no ]] && BDEPEND+=" ${EAUTORECONF_DEPEND}"
> unset EAUTORECONF_DEPENDS
> unset EAUTORECONF_DEPEND
Apart from the unset, the comment doesn't seem to relate to the actual
change?
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpNdvQqpsruD.pgp
Description: OpenPGP digital signature
[gentoo-dev] [PATCH] xorg-3.eclass: EAUTORECONF_DEPENDS belong to BDEPEND
EAUTORECONF_DEPENDS is non-empty for ppc-aix and x86-winnt only.
Also, unset variable 'arch' after use.
---
eclass/xorg-3.eclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index 6ac90a64d59..f135058fba6 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -116,7 +116,8 @@ WANT_AUTOMAKE="latest"
for arch in ${XORG_EAUTORECONF_ARCHES}; do
EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
done
-DEPEND+=" ${EAUTORECONF_DEPENDS}"
+unset arch
+BDEPEND+=" ${EAUTORECONF_DEPENDS}"
[[ ${XORG_EAUTORECONF} != no ]] && BDEPEND+=" ${EAUTORECONF_DEPEND}"
unset EAUTORECONF_DEPENDS
unset EAUTORECONF_DEPEND
--
2.19.2
Re: [gentoo-dev] [PATCH v4 00/19] User/group packages
Hi!
Its a good thing that you're reviewing user class. I write some thought
previosly about it.
Why not create some set for standart uid:gid for services so they will
be identicall in all installations?
like slurm has uid:gid 500:500
nginx 80:80 or something...
Michał Górny писал 11-06-2019 19:23:
Hi,
Here's hopefully the final iteration of the patches. Changes since v3:
- changed description to 'System user/group' (from 'service'),
- fixed acct-user to fail when ACCT_USER_GROUPS is empty (and not just
when it is unset).
Please review.
--
Best regards,
Michał Górny
Michał Górny (19):
user.eclass: Remove dead/broken Darwin support
user.eclass: NetBSD has 'getent'
user.eclass: Do not create user-group automatically
user.eclass: Prevent automated home creation in useradd
user.eclass: Support disabling home directory creation
user.eclass: Support forcing specified UID/GID
user.eclass: Die if no free UID/GID is found
user.eclass: Factor out finding nologin into separate function
user.eclass: Introduce esetshell
user.eclass: Introduce eget{user,group}name
user.eclass: Also permit using functions in pkg_*rm phases
user.eclass: Support getting & setting comment field
user.eclass: Introduce e{get,set}groups
acct-group.eclass: A new eclass to maintain group accounts
acct-user.eclass: A new eclass to maintain user accounts
acct-user.eclass: Supporting locking & unlocking accounts
acct-group/ftp: Add 'ftp' group (GID 21)
acct-user/ftp: Add 'ftp' user (UID 21)
net-ftp/ftpbase: Utilize {group,user}/ftp
acct-group/ftp/ftp-0.ebuild| 9 +
acct-group/ftp/metadata.xml| 5 +
acct-user/ftp/ftp-0.ebuild | 14 +
acct-user/ftp/metadata.xml | 5 +
eclass/acct-group.eclass | 124
eclass/acct-user.eclass| 373
eclass/user.eclass | 385 -
net-ftp/ftpbase/ftpbase-0.01-r3.ebuild | 39 +++
profiles/categories| 2 +
9 files changed, 886 insertions(+), 70 deletions(-)
create mode 100644 acct-group/ftp/ftp-0.ebuild
create mode 100644 acct-group/ftp/metadata.xml
create mode 100644 acct-user/ftp/ftp-0.ebuild
create mode 100644 acct-user/ftp/metadata.xml
create mode 100644 eclass/acct-group.eclass
create mode 100644 eclass/acct-user.eclass
create mode 100644 net-ftp/ftpbase/ftpbase-0.01-r3.ebuild
--
Best Regards,
Alexey 'Alexxy' Shvetsov
Best Regards,
Alexey 'Alexxy' Shvetsov, PhD
Department of Molecular and Radiation Biophysics
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Leningrad region, Gatchina, Russia
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru
[gentoo-dev] [PATCH v2] profiles: add more language codes to desc/l10n.desc
Many thanks for the feedback, here is the revised patch: * * * All of these are supported by recent versions of app-text/tesseract. Checked against ISO-639 using the code tables from https://iso639-3.sil.org/ . Signed-off-by: Marek Szuba --- profiles/desc/l10n.desc | 14 ++ 1 file changed, 14 insertions(+) diff --git a/profiles/desc/l10n.desc b/profiles/desc/l10n.desc index 4d30aa57eb3..e5e21346174 100644 --- a/profiles/desc/l10n.desc +++ b/profiles/desc/l10n.desc @@ -41,8 +41,10 @@ bs - Bosnian ca - Catalan ca-valencia - Catalan (Valencian) cak - Kaqchikel +ceb - Cebuano chr - Cherokee cnr - Montenegrin +co - Corsican cs - Czech cy - Welsh da - Danish @@ -53,6 +55,7 @@ de-DE - German (Germany) dgo - Dogri (individual language) doi - Dogri (macrolanguage) dsb - Lower Sorbian +dv - Dhivehi dz - Dzongkha el - Modern Greek en - English @@ -88,13 +91,16 @@ he - Hebrew hi - Hindi hr - Croatian hsb - Upper Sorbian +ht - Haitian hu - Hungarian hy - Armenian ia - Interlingua id - Indonesian is - Icelandic it - Italian +iu - Inuktitut ja - Japanese +jv - Javanese ka - Georgian kab - Kabyle kk - Kazakh @@ -120,6 +126,7 @@ mn - Mongolian mni - Manipuri mr - Marathi ms - Malay (macrolanguage) +mt - Maltese my - Burmese nan - Min Nan Chinese nb - Norwegian Bokmål @@ -134,9 +141,11 @@ om - Oromo or - Oriya (macrolanguage) pa - Punjabi pl - Polish +ps - Pushto pt - Portuguese pt-BR - Portuguese (Brazil) pt-PT - Portuguese (Portugal) +qu - Quechua rm - Romansh ro - Romanian ru - Russian @@ -156,6 +165,7 @@ sr - Serbian sr-Latn - Serbian (Latin script) ss - Swati st - Southern Sotho +su - Sundanese sv - Swedish sw - Swahili (macrolanguage) sw-TZ - Swahili (Tanzania) @@ -165,9 +175,11 @@ ta-LK - Tamil (Sri Lanka) te - Telugu tg - Tajik th - Thai +ti - Tigrinya tk - Turkmen tl - Tagalog tn - Tswana +to - Tonga (Tonga Islands) tr - Turkish ts - Tsonga tt - Tatar @@ -178,6 +190,8 @@ uz - Uzbek ve - Venda vi - Vietnamese xh - Xhosa +yi - Yiddish +yo - Yoruba zh - Chinese zh-CN - Chinese (China) zh-TW - Chinese (Taiwan) -- 2.21.0 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: BLAS and LAPACK runtime switching (Re-designed)
On Thu, 2019-06-13 at 00:15 -0700, Mo Zhou wrote:
> Hi Gentoo devs,
>
> I redesigned the solution for BLAS/LAPACK runtime switching.
> New solution is based on eselect+ld.so.conf . See following.
>
> > Goal
> >
> >
> > * When a program is linked against libblas.so or liblapack.so
> > provided by any BLAS/LAPACK provider, the eselect-based solution
> > will allow user to switch the underlying library without recompiling
> > anything.
>
> Instead of manipulating symlinks, I wrote a dedicated eselect module
> for BLAS:
>
> https://github.com/cdluminate/my-overlay/blob/master/app-eselect/eselect-blas/files/blas.eselect-0.2
>
> This implementation will generate a corresponding ld.so.conf file
> on switching and refresh ld.so cache.
>
> advantages:
>
> 1. not longer manipulates symlinks under package manager directory,
>see https://bugs.gentoo.org/531842 and https://bugs.gentoo.org/632624
>
> 2. we don't have to think about static lib and header switching like
>Debian does.
>
> > * When a program is linked against a specific implementation, e.g.
> > libmkl_rt.so, the solution doesn't break anything.
>
> This still holds with the new solution.
>
> > Solution
> >
> >
> > Similar to Debian's update-alternatives mechanism, Gentoo's eselect
> > is good at dealing with drop-in replacements as well. My preliminary
>
> The redesigned solution totally diverted from Debian's solution.
>
> * sci-libs/lapack provides standard API and ABI for BLAS/CBLAS/LAPACK
> and LAPACKE. It provides a default set of libblas.so, libcblas.so,
> and liblapack.so . Reverse dependencies linked against the three
> libraries (reference blas) will take advantage of the runtime
> switching mechanism through USE="virtual-blas virtual-lapack".
> Reverse dependencies linked to specific implementations such as
> libopenblas.so won't be affected at all.
>
> * every non-standard BLAS/LAPACK implementations could be registered
> as alternatives via USE="virtual-blas virtual-lapack". Once the
> virtual-* flags are toggled, the ebuild file will build some
> extra shared objects with correct SONAME.
>
> For example:
>
> /usr/lib64/libblis.so.2 (SONAME=libblis.so.2, general purpose)
> /usr/lib64/blas/blis/libblas.so.3 (USE="virtual-blas",
> SONAME=libblas.so.3)
> /usr/lib64/blas/blis/libcblas.so.3 (USE="virtual-blas",
> SONAME=libcblas.so.3)
>
> * Reverse dependencies of BLAS/LAPACK could optionally provide the
> "virtual-blas virtual-lapack" USE flags.
>
> if use virtual-*:
> link against reference blas/lapack
> else:
> link against whatever the ebuild maintainer like and get rid
> of the switching mechanism
>
> > Proposed Changes
> >
> >
> > 1. Deprecate sci-libs/{blas,cblas,lapack,lapacke}-reference from gentoo
> >main repo. They use exactly the same source tarball. It's not quite
> >helpful to package these components in a fine-grained manner. A
> > single
> >sci-libs/lapack package is enough.
>
> sci-libs/{blas,cblas,lapack,lapacke}::gentoo should be deprecated. They
> are based on exactly the same source tarball, and maintaining 4 ebuild
> files for a single tarball is not a good choice IHMO. Those old ebuild
> files seems to leverage the flexibility of upstream build system
> because it enables one to, for example, skip the reference blas build
> and use an existing optimized BLAS impelementation and hence introduce
> flexibility. That flexibility is hard to maintain and is not necessary
> anymore with the new runtime switching mechanism.
>
> That's why I propose to merge the 4 ebuild into a single one:
> sci-libs/lapack. We don't need to add the "reference" postfix
> because no upstream will loot the name "lapack". When talking
> about "lapack" it's always the reference implementation.
What's the real gain here, and how does it compare to loss of
flexibility of being able to build only what the package in question
needs?
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: BLAS and LAPACK runtime switching (Re-designed)
Hi Gentoo devs,
I redesigned the solution for BLAS/LAPACK runtime switching.
New solution is based on eselect+ld.so.conf . See following.
> Goal
>
>
> * When a program is linked against libblas.so or liblapack.so
> provided by any BLAS/LAPACK provider, the eselect-based solution
> will allow user to switch the underlying library without recompiling
> anything.
Instead of manipulating symlinks, I wrote a dedicated eselect module
for BLAS:
https://github.com/cdluminate/my-overlay/blob/master/app-eselect/eselect-blas/files/blas.eselect-0.2
This implementation will generate a corresponding ld.so.conf file
on switching and refresh ld.so cache.
advantages:
1. not longer manipulates symlinks under package manager directory,
see https://bugs.gentoo.org/531842 and https://bugs.gentoo.org/632624
2. we don't have to think about static lib and header switching like
Debian does.
> * When a program is linked against a specific implementation, e.g.
> libmkl_rt.so, the solution doesn't break anything.
This still holds with the new solution.
> Solution
>
>
> Similar to Debian's update-alternatives mechanism, Gentoo's eselect
> is good at dealing with drop-in replacements as well. My preliminary
The redesigned solution totally diverted from Debian's solution.
* sci-libs/lapack provides standard API and ABI for BLAS/CBLAS/LAPACK
and LAPACKE. It provides a default set of libblas.so, libcblas.so,
and liblapack.so . Reverse dependencies linked against the three
libraries (reference blas) will take advantage of the runtime
switching mechanism through USE="virtual-blas virtual-lapack".
Reverse dependencies linked to specific implementations such as
libopenblas.so won't be affected at all.
* every non-standard BLAS/LAPACK implementations could be registered
as alternatives via USE="virtual-blas virtual-lapack". Once the
virtual-* flags are toggled, the ebuild file will build some
extra shared objects with correct SONAME.
For example:
/usr/lib64/libblis.so.2 (SONAME=libblis.so.2, general purpose)
/usr/lib64/blas/blis/libblas.so.3 (USE="virtual-blas",
SONAME=libblas.so.3)
/usr/lib64/blas/blis/libcblas.so.3 (USE="virtual-blas",
SONAME=libcblas.so.3)
* Reverse dependencies of BLAS/LAPACK could optionally provide the
"virtual-blas virtual-lapack" USE flags.
if use virtual-*:
link against reference blas/lapack
else:
link against whatever the ebuild maintainer like and get rid
of the switching mechanism
> Proposed Changes
>
>
> 1. Deprecate sci-libs/{blas,cblas,lapack,lapacke}-reference from gentoo
>main repo. They use exactly the same source tarball. It's not quite
>helpful to package these components in a fine-grained manner. A
> single
>sci-libs/lapack package is enough.
sci-libs/{blas,cblas,lapack,lapacke}::gentoo should be deprecated. They
are based on exactly the same source tarball, and maintaining 4 ebuild
files for a single tarball is not a good choice IHMO. Those old ebuild
files seems to leverage the flexibility of upstream build system
because it enables one to, for example, skip the reference blas build
and use an existing optimized BLAS impelementation and hence introduce
flexibility. That flexibility is hard to maintain and is not necessary
anymore with the new runtime switching mechanism.
That's why I propose to merge the 4 ebuild into a single one:
sci-libs/lapack. We don't need to add the "reference" postfix
because no upstream will loot the name "lapack". When talking
about "lapack" it's always the reference implementation.
> 2. Merge the "cblas" eselect unit into "blas" unit. It is potentially
>harmful when "blas" and "cblas" point to different implementations.
>That means "app-eselect/eselect-cblas" should be deprecated.
eselect-cblas should be deprecated. That affects gsl because it is
registered as an cblas alternative. gsl doesn't provide the standard
BLAS (fortran) API+ABI so it will not be added as a runtime switching
candidate.
Does this redesinged solution look acceptable now?
Best,
Mo.
