| 1 |
>>>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote: |
| 2 |
|
| 3 |
> On 12/08/15 11:55 AM, Alexis Ballier wrote: |
| 4 |
>> I think it is better seen as a list of implications, esp. for |
| 5 |
>> this kind of questions :) With that in mind, there is no |
| 6 |
>> autounmask-write: effective USE for a given package is input USE |
| 7 |
>> with these implications applied. |
| 8 |
|
| 9 |
This very well summarises it. |
| 10 |
|
| 11 |
> ..if I'm understanding what you're saying here, you see this as |
| 12 |
> something the PM will use to adjust the input use list so that the |
| 13 |
> emerge itself will go ahead with the newly adjusted flags; am I |
| 14 |
> understanding that correctly? |
| 15 |
|
| 16 |
> In other words, there won't be any user control/alert/override for |
| 17 |
> what the default actions will be, if the user's profile isn't set up |
| 18 |
> in a way that satisfies REQUIRED_USE, correct? so if I have |
| 19 |
> 'app-cat/pkg qt4' in my package.use, but USE="qt5" in my profile, |
| 20 |
> then because both flags end up being enabled the REQUIRED_USE="^^ ( |
| 21 |
> +qt5 qt4 )" in app-cat/pkg will just force-off my package.use entry |
| 22 |
> and everything will proceed as if it wasn't there? |
| 23 |
|
| 24 |
Indeed, maybe there would be too much magic at work there. However, |
| 25 |
note that also currently you won't be able to emerge the package with |
| 26 |
a package.use that results in conflicting flags. |
| 27 |
|
| 28 |
Ulrich |
Archives