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