| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 12/08/15 12:53 PM, Ulrich Mueller wrote: |
| 5 |
>>>>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote: |
| 6 |
> |
| 7 |
>> On 12/08/15 11:55 AM, Alexis Ballier wrote: |
| 8 |
>>> I think it is better seen as a list of implications, esp. |
| 9 |
>>> for this kind of questions :) With that in mind, there is no |
| 10 |
>>> autounmask-write: effective USE for a given package is input |
| 11 |
>>> USE with these implications applied. |
| 12 |
> |
| 13 |
> This very well summarises it. |
| 14 |
> |
| 15 |
>> ..if I'm understanding what you're saying here, you see this |
| 16 |
>> as something the PM will use to adjust the input use list so |
| 17 |
>> that the emerge itself will go ahead with the newly adjusted |
| 18 |
>> flags; am I understanding that correctly? |
| 19 |
> |
| 20 |
>> In other words, there won't be any user control/alert/override |
| 21 |
>> for what the default actions will be, if the user's profile |
| 22 |
>> isn't set up in a way that satisfies REQUIRED_USE, correct? so |
| 23 |
>> if I have 'app-cat/pkg qt4' in my package.use, but USE="qt5" in |
| 24 |
>> my profile, then because both flags end up being enabled the |
| 25 |
>> REQUIRED_USE="^^ ( +qt5 qt4 )" in app-cat/pkg will just |
| 26 |
>> force-off my package.use entry and everything will proceed as |
| 27 |
>> if it wasn't there? |
| 28 |
> |
| 29 |
> Indeed, maybe there would be too much magic at work there. |
| 30 |
> However, note that also currently you won't be able to emerge the |
| 31 |
> package with a package.use that results in conflicting flags. |
| 32 |
> |
| 33 |
> Ulrich |
| 34 |
> |
| 35 |
|
| 36 |
How would that be determined, then? These REQUIRED_USE flag forces |
| 37 |
would somehow occur in between the USE= assignment from the |
| 38 |
profile/make.conf and the entries from package.use ? |
| 39 |
|
| 40 |
This is why I was wondering if it'd make more sense for these |
| 41 |
REQUIRE_USE defaults to just help portage resolve the deptree, and |
| 42 |
then --autounmask-write to fix package.use to match before |
| 43 |
proceeding. Not as nice to end-users I know, but at least portage |
| 44 |
would resolve currently-unresolvable solutions to a known default; |
| 45 |
afaik portage can't even suggest a default solution the way things |
| 46 |
are now, can it? |
| 47 |
|
| 48 |
|
| 49 |
|
| 50 |
-----BEGIN PGP SIGNATURE----- |
| 51 |
Version: GnuPG v2 |
| 52 |
|
| 53 |
iF4EAREIAAYFAlXLfAIACgkQAJxUfCtlWe1LhgEAtWKXnWtYLGxt/o6e+cKSXn3u |
| 54 |
VWidCNO/QKlT9Ji5uQQA/R9biZJqccv4I64JFW9tKWKAuWA3S67VaE9Rj/QZ3GNy |
| 55 |
=Mbw/ |
| 56 |
-----END PGP SIGNATURE----- |
Archives