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