1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 12/08/15 11:55 AM, Alexis Ballier wrote: |
5 |
> On Wed, 12 Aug 2015 11:30:39 -0400 Ian Stakenvicius |
6 |
> <axs@g.o> wrote: |
7 |
> |
8 |
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 |
9 |
>> |
10 |
>> On 12/08/15 11:08 AM, Ulrich Mueller wrote: |
11 |
>>>>>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote: |
12 |
>>> |
13 |
>>>> i.e. something that really tells the PM how to automate |
14 |
>>>> the choice: - 'qt5 -> !qt4' is rather straightforward to |
15 |
>>>> solve and tells the PM how (note that it is not equivalent |
16 |
>>>> to 'qt4 -> !qt5') - '^^ ( qt5 qt4 )' requires the PM to |
17 |
>>>> make a choice in order to automate it |
18 |
>>> |
19 |
>>> I was thinking about some syntax like this: |
20 |
>>> |
21 |
>>> REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )" |
22 |
>>> |
23 |
>>> The package manager would first evaluate each group in |
24 |
>>> REQUIRED_USE with the original set of USE flags. If that |
25 |
>>> doesn't evaluate to true, retry with flags changed as |
26 |
>>> indicated by the + and - signs. |
27 |
>>> |
28 |
>>> Ulrich |
29 |
>>> |
30 |
>> |
31 |
>> Having the ability for REQUIRED_USE to provide a default |
32 |
>> resolution path should definitely help with things; I assume |
33 |
>> this is meant to do its work via --autounmask-write or similar, |
34 |
>> ie to help users adjust their config files? Or was the thought |
35 |
>> to allow PMs to override USE immediately? |
36 |
> |
37 |
> |
38 |
> I think it is better seen as a list of implications, esp. for |
39 |
> this kind of questions :) With that in mind, there is no |
40 |
> autounmask-write: effective USE for a given package is input USE |
41 |
> with these implications applied. |
42 |
|
43 |
..if I'm understanding what you're saying here, you see this as |
44 |
something the PM will use to adjust the input use list so that the |
45 |
emerge itself will go ahead with the newly adjusted flags; am I |
46 |
understanding that correctly? |
47 |
|
48 |
In other words, there won't be any user control/alert/override for |
49 |
what the default actions will be, if the user's profile isn't set up |
50 |
in a way that satisfies REQUIRED_USE, correct? so if I have |
51 |
'app-cat/pkg qt4' in my package.use, but USE="qt5" in my profile, |
52 |
then because both flags end up being enabled the REQUIRED_USE="^^ ( |
53 |
+qt5 qt4 )" in app-cat/pkg will just force-off my package.use entry |
54 |
and everything will proceed as if it wasn't there? |
55 |
|
56 |
|
57 |
> |
58 |
>> Questions: |
59 |
>> |
60 |
>> 1 - how does +foo in REQUIRED_USE relate to use-defaults set in |
61 |
>> IUSE? |
62 |
> |
63 |
> This questions remains. I see use-defaults in IUSE as part of |
64 |
> "input USE" above. |
65 |
|
66 |
Yes, just as it is now, the use-defaults in IUSE are part of the |
67 |
"input use". What I'm wondering is, would the +foo in |
68 |
REQUIRED_USE="|| ( +foo bar )" be something that should be used in |
69 |
combination with IUSE="+foo" (perhaps even require it) or would its |
70 |
functionality and specification be entirely independent of it? |
71 |
Right now for ||(), setting IUSE="+foo" gets around that issue in |
72 |
almost all cases, the only case it doesn't is when the user has |
73 |
explicitly set USE="-foo" (or USE="-*"). |
74 |
|
75 |
|
76 |
> |
77 |
> |
78 |
> [...] |
79 |
>> 3 - will having REQUIRED_USE be able to force flags on (and |
80 |
>> others off) likely result in abuse of profiles and other use |
81 |
>> defaults? I forsee this being a way, for instance, for a dev |
82 |
>> to get around users setting USE="-*" in make.conf to ensure a |
83 |
>> default use flag setting is honoured. |
84 |
> |
85 |
> How? |
86 |
|
87 |
This assumes that the PM will just set the flags that resolve the |
88 |
REQUIRED_USE directly (ie modify the "input use" based on the |
89 |
defaults provided) and go ahead, which seems to be what you're |
90 |
implying will be the implementation, earlier on. See my response re |
91 |
#1 above as well, since if I understand this correctly the |
92 |
REQUIRED_USE="|| ( +foo bar )" will set +foo even if USE="-*" in the |
93 |
profile right? |
94 |
|
95 |
|
96 |
> |
97 |
>> 4 - Will a change to which flag the '+' is on likely to require |
98 |
>> a revbump for VDB updates? For something like '^^ ( +qt4 qt5 |
99 |
>> )' I could see maintainers wanting to switch which flag is |
100 |
>> default across a bunch of packages at once when, say, the qt |
101 |
>> team wants qt5 to become the de-facto default. |
102 |
> |
103 |
> It'll "require" a rebuild for those whose default changes anyway. |
104 |
> I'd say no revbump since we don't revbump all affected packages |
105 |
> when we add default enabled flags to make.defaults. |
106 |
|
107 |
Thinking about it I think I answered my own question, in that there |
108 |
shouldn't be any need for this to affect VDB since the end-result is |
109 |
expressed in the state recorded in 'USE'. And no VDB change means |
110 |
no need for a revbump. Whether or not the change results in a |
111 |
rebuild on -N will depend on whether or not the state of the user's |
112 |
profile will result in a REQUIRED_USE conflict that needs to be |
113 |
default-resolved or not, and that's true from emerge to emerge no |
114 |
matter what. |
115 |
|
116 |
|
117 |
-----BEGIN PGP SIGNATURE----- |
118 |
Version: GnuPG v2 |
119 |
|
120 |
iF4EAREIAAYFAlXLc+MACgkQAJxUfCtlWe3GKgEAvfYZ3SD2NcKCeZjf4qlfzy2G |
121 |
Fjzfub0X2BfuiAVJnbgA/RIaxTQRGt7PL693qNS3HxOX/q2T7l6W3Hv105NeBTlT |
122 |
=S9wv |
123 |
-----END PGP SIGNATURE----- |