-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 30/05/14 08:03 AM, Anthony G. Basile wrote:
> On 05/29/14 23:21, Ian Stakenvicius wrote:
>> USE_EXPAND generally works or is meant to work when all
>> participating ebuilds are ok with working from the exact same set
>> of flags.
>
> Not at all. There are a several counter examples but one
> particularly close to what I'm proposing is LINGUAS. Look at how
> it is used in postgresql-base:
>
> LINGUAS="af cs de en es fa fr hr hu it ko nb pl pt_BR ro ru sk sl
> sv tr zh_CN zh_TW"
>
> for lingua in ${LINGUAS} ; do IUSE+=" linguas_${lingua}" done
>
> Only a few of the 251 linguas listed in profiles/desc/linguas.desc
> are used.
>
That's a bit of a different case -- if a package doesn't support any
of the LINGUAS that a user chooses, then the user just gets the
package that would be the same as having LINGUAS unset. And this is
perfectly fine, because everything (afaik) provides either 'en' or an
unspecified 'C' type locale by default.
If a user has i.e. SSL="polarssl" in make.conf and emerges things that
don't have polarssl on their list, then those things won't have SSL
support at all, right?
>
> Fallback logic would have to be on a per ebuild basis. It makes
> no sense otherwise. Eg. There is no preferred ssl provider for
> curl and USE=ssl there simply means "curl will have an ssl layer"
> without prejudice as to the backend that will provide that ssl
> layer.
>
I thought the main purpose of this was to avoid a bunch of per-package
fallback logic? IE, what's the difference in using the SSL use expand
here, or just having packages directly IUSE="+ssl gnutls +openssl nss
polarssl" with standardized global use flags? the only consistency
that I see the SSL use-expand providing is an enforcement of the flags
that will be used to identify a particular implementation, and i'm
pretty sure we already have that...
>
> No. What's wrong with
>
> REQUIRED_USE=" ssl? ( ^^ ( curl_ssl_axtls curl_ssl_cyassl
> curl_ssl_gnutls curl_ssl_openssl curl_ssl_nss curl_ssl_polarssl
> curl_ssl_winssl ) )"
>
Nothing at all, but I don't see a generic global SSL USE_EXPAND adding
any particular benefit, either. What are the intended benefits to
this, besides aesthetics??
USE_EXPANDs are meant to be globally set; when they need to be dealt
with per-package, they get messy and annoying for end users -- that's
one of the main issues i've seen from the multilib eclass project,
since ABI_X86 et al really aren't meant to be set globally and
difficult-to-manage package.use mess arises out of it.
I know that USE_EXPANDs are handy in allowing the subset of packages
that use them to have an isolated set of use flags, but i'm not sure
if there's really a benefit to having a separation of i.e. 'nss' and
'ssl_nss' in an end-user's USE ??
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlOIkEAACgkQ2ugaI38ACPAJowD/d5gJsEhy0T9Y2p7WM1PLW+bE
uPrb4QRuNol6yxt3NDEA/R9uD21lYzVcxR6WtPZ2DbCmIl0AIaR/89h/lGLTukDr
=a8AD
-----END PGP SIGNATURE-----
