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