1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 12/08/15 01:00 PM, Alexis Ballier wrote: |
5 |
> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius |
6 |
> <axs@g.o> wrote: |
7 |
> |
8 |
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 |
9 |
>> |
10 |
>> On 12/08/15 12:42 PM, Ulrich Mueller wrote: |
11 |
>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote: |
12 |
>>>> 2 - is there a particular reasoning for the - in front of |
13 |
>>>> qt4 here? I only ask because it would seem that a single |
14 |
>>>> default-enable should suffice in lists like this to |
15 |
>>>> indicate a resolution path, no? That is, '^^ ( +flag1 |
16 |
>>>> -flag2 -flag3 -flag4 )' to me seems like it would be the |
17 |
>>>> same as '^^ ( +flag1 flag2 flag3 flag4 )' |
18 |
>>> |
19 |
>>> If the user has both "qt4 qt5", then enabling qt5 alone |
20 |
>>> won't help to resolve "^^ ( qt5 qt4 )". |
21 |
>>> |
22 |
>> |
23 |
>> Right, but the PM knows based on a particular REQUIRED_USE |
24 |
>> operator what it would need to do when a particular flag is set |
25 |
>> to default. Given '^^' is must-be-one-of, the +flag would be |
26 |
>> enabled and all the other flags would be disabled, right? |
27 |
>> |
28 |
>> Here's how I'd see it mapping out: |
29 |
>> |
30 |
>> || ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ ( +flag1 |
31 |
>> flag2 ... ) , PM forces-on flag1, forces-off all others ?? ( |
32 |
>> +flag2 flag2 ... ) , PM forces off all but flag1 |
33 |
>> |
34 |
>> I'm not sure if the following make sense though... thoughts? |
35 |
>> |
36 |
>> {,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? ( +!flag2 |
37 |
>> ) , PM forces !flag2, meaning forces-off flag2 |
38 |
>> |
39 |
>> |
40 |
>> I'm just wondering if it's really necessary in terms of syntax |
41 |
>> to specify the flag-negation that the PM would need to do. |
42 |
> |
43 |
> |
44 |
> See my other email: neither + nor - are necessary :) |
45 |
> |
46 |
> |
47 |
|
48 |
|
49 |
I'd disagree on that -- technically they aren't necessary, but the |
50 |
whole reason why these new operators were added in the first place |
51 |
was so that it's a lot easier for developers to fill in REQUIRED_USE |
52 |
and get the logic right. Mapping out a ^^ ( flag1 flag2 flag3 flag4 |
53 |
) into all of its permissible flag-a? ( flagb !flagc !flagd ) |
54 |
variants is a royal pain. Plus there's |
55 |
readability/understandability to consider here. |
56 |
|
57 |
|
58 |
|
59 |
-----BEGIN PGP SIGNATURE----- |
60 |
Version: GnuPG v2 |
61 |
|
62 |
iF4EAREIAAYFAlXLfMYACgkQAJxUfCtlWe3JpQD9Gt87cclSsz3FTw5KbnlsSjVX |
63 |
zf4FXOa4IMI4AcRCy+EA/37u0n/USxmMUDQxbVZT7Kp4O9EkdYR/DdNHQNUlBYMe |
64 |
=Cpmr |
65 |
-----END PGP SIGNATURE----- |