1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 12/08/15 01:22 PM, Alexis Ballier wrote: |
5 |
> On Wed, 12 Aug 2015 13:06:43 -0400 Ian Stakenvicius |
6 |
> <axs@g.o> wrote: |
7 |
> |
8 |
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 |
9 |
>> |
10 |
>> On 12/08/15 01:05 PM, Ian Stakenvicius wrote: |
11 |
>>> On 12/08/15 01:00 PM, Alexis Ballier wrote: |
12 |
>>>> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius |
13 |
>>>> <axs@g.o> wrote: |
14 |
>>> |
15 |
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 |
16 |
>>>>> |
17 |
>>>>> On 12/08/15 12:42 PM, Ulrich Mueller wrote: |
18 |
>>>>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote: |
19 |
>>>>>>> 2 - is there a particular reasoning for the - in |
20 |
>>>>>>> front of qt4 here? I only ask because it would seem |
21 |
>>>>>>> that a single default-enable should suffice in lists |
22 |
>>>>>>> like this to indicate a resolution path, no? That is, |
23 |
>>>>>>> '^^ ( +flag1 -flag2 -flag3 -flag4 )' to me seems like |
24 |
>>>>>>> it would be the same as '^^ ( +flag1 flag2 flag3 |
25 |
>>>>>>> flag4 )' |
26 |
>>>>>> |
27 |
>>>>>> If the user has both "qt4 qt5", then enabling qt5 alone |
28 |
>>>>>> won't help to resolve "^^ ( qt5 qt4 )". |
29 |
>>>>>> |
30 |
>>>>> |
31 |
>>>>> Right, but the PM knows based on a particular |
32 |
>>>>> REQUIRED_USE operator what it would need to do when a |
33 |
>>>>> particular flag is set to default. Given '^^' is |
34 |
>>>>> must-be-one-of, the +flag would be enabled and all the |
35 |
>>>>> other flags would be disabled, right? |
36 |
>>>>> |
37 |
>>>>> Here's how I'd see it mapping out: |
38 |
>>>>> |
39 |
>>>>> || ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ ( |
40 |
>>>>> +flag1 flag2 ... ) , PM forces-on flag1, forces-off all |
41 |
>>>>> others ?? ( +flag2 flag2 ... ) , PM forces off all but |
42 |
>>>>> flag1 |
43 |
>>>>> |
44 |
>>>>> I'm not sure if the following make sense though... |
45 |
>>>>> thoughts? |
46 |
>>>>> |
47 |
>>>>> {,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? ( |
48 |
>>>>> +!flag2 ) , PM forces !flag2, meaning forces-off flag2 |
49 |
>>>>> |
50 |
>>>>> |
51 |
>>>>> I'm just wondering if it's really necessary in terms of |
52 |
>>>>> syntax to specify the flag-negation that the PM would |
53 |
>>>>> need to do. |
54 |
>>> |
55 |
>>> |
56 |
>>>> See my other email: neither + nor - are necessary :) |
57 |
>>> |
58 |
>>> |
59 |
>>> |
60 |
>>> |
61 |
>>> I'd disagree on that -- technically they aren't necessary, |
62 |
>>> but the whole reason why these new operators were added in |
63 |
>>> the first place was so that it's a lot easier for developers |
64 |
>>> to fill in REQUIRED_USE and get the logic right. Mapping out |
65 |
>>> a ^^ ( flag1 flag2 flag3 flag4 ) into all of its permissible |
66 |
>>> flag-a? ( flagb !flagc !flagd ) variants is a royal pain. |
67 |
>>> Plus there's readability/understandability to consider here. |
68 |
>>> |
69 |
>> |
70 |
>> err, flaga? ( !flagb !flagc !flagd ) i mean.. |
71 |
> |
72 |
> It is indeed longer (n flags to roughly n² flags expanded i'd |
73 |
> say), but i disagree on the readability: i find it much more |
74 |
> readable as "if flaga is enabled then flagb, flagc and flagd must |
75 |
> be disabled" etc. which express clearly the preference than |
76 |
> "exactly one of flaga flagb flagc flagd except if there is a |
77 |
> problem then flaga but not the others". |
78 |
> |
79 |
> Also, there's something we've overseen with the +/- syntax: What |
80 |
> about "^^ ( +flaga -flagb -flagc -flagd )" with USE="-flaga flagb |
81 |
> flagc" ? The only way to solve it would be USE="flaga -flagb |
82 |
> -flagc" while the "implication syntax" could give you USE="-flaga |
83 |
> flagb -flagc" (or any other preference of the ebuild writer). |
84 |
> |
85 |
|
86 |
I don't think we've overseen that. If there's a conflict due to any |
87 |
two flags being set in ^^ ( +a b c d ), the default resolution is to |
88 |
enable a and disable b,c,d. Doesn't matter if a is one of the ones |
89 |
enabled or not. |
90 |
|
91 |
If you want to try and roll out the syntax, such that for any |
92 |
particular given set of flags being enabled there is a preferable |
93 |
default, then yes it'll have to be written out longhand for sure. |
94 |
|
95 |
OR we could just adjust PMS to assume flag order determines |
96 |
precedence and still not bother with a new operator: For "^^ ( a b |
97 |
c )" if a then b,c forced-off; elif b then c forced-off; elif !c |
98 |
then a forced-on; fi |
99 |
|
100 |
|
101 |
|
102 |
> Finally, about getting the logic right, since it's a subset of |
103 |
> the current syntax I don't think that should be a problem :) |
104 |
|
105 |
The superset of the "{,!}flag1? ( {,!}flag2 )" syntax was requested |
106 |
and created I believe -because- dev's were finding it |
107 |
difficult/annoying to write the logic out longhand and get it right. |
108 |
AND it made the messages a lot more clear to end-users too, as I |
109 |
recall, as "only-one-of ( flagset )" is a lot more clear and concise |
110 |
than "flag1-enabled so must-enable/disable-the-rest-in-flagset." I |
111 |
didn't pay that much attention at the time though so if anyone |
112 |
involved with those operator requests etc could chime in on |
113 |
reasoning I'd appreciate it. |
114 |
|
115 |
|
116 |
|
117 |
-----BEGIN PGP SIGNATURE----- |
118 |
Version: GnuPG v2 |
119 |
|
120 |
iF4EAREIAAYFAlXLhMkACgkQAJxUfCtlWe2A3wEA0jrf9slDrcM92yhXpGpTzBbD |
121 |
baQAYRUrJsNEI+frKx4BAM9gWVbmGr6U9KAwBdzUVkOFUmZmFj9h7BHFdDsniI1t |
122 |
=7UNL |
123 |
-----END PGP SIGNATURE----- |