1 |
On 03/25/2018 02:02 AM, Kent Fredric wrote: |
2 |
> On Sat, 24 Mar 2018 21:43:41 -0700 |
3 |
> Zac Medico <zmedico@g.o> wrote: |
4 |
> |
5 |
>> But if the majority demographic is as you describe, then they shouldn't |
6 |
>> be using anything having dependencies that require package.unmask or ** |
7 |
>> keywords changes. |
8 |
> |
9 |
> Again, they *dont*, the problem is portage makes the mistake of |
10 |
> thinking they do. |
11 |
> |
12 |
> This happens especially around virtuals where there is an existing |
13 |
> problem of portage not doing the right thing when perl-core/* exists in |
14 |
> some definition. |
15 |
> |
16 |
> I don't have details on hand to give you as to how this happens, |
17 |
> but I've seen this happen often enough around packages *I maintain* and |
18 |
> *I* can't explain why portage is trying to install it, only that |
19 |
> --auto-unmask-keep-masks=y makes the problem mysteriously go away. |
20 |
|
21 |
An issue like that involving REQUIRED_USE has been reported, and today |
22 |
I've created a patch that corrects the problem: |
23 |
|
24 |
https://bugs.gentoo.org/622462 |
25 |
|
26 |
> The question for me is not "auto unmask is good" vs "autounmask is |
27 |
> bad", autounmask is fine on its own and is very useful. |
28 |
> |
29 |
> Its the default of --autounmask-keep-masks=n that I find short on value. |
30 |
> |
31 |
> If anything, I suggest there needs to be an |
32 |
> --autounmask-keep-masks=conditional, or something, that narrows the |
33 |
> range of solutions portage will try and only attempt to unmask ** or |
34 |
> package.mask in the following conditions: |
35 |
> |
36 |
> - An explicitly masked package/version is explicitly requested on the command line. |
37 |
> - A package is a direct dependency of of the above |
38 |
> - As above, but for the world file |
39 |
> |
40 |
> That is, assume the only reason for masked packages to be considered is: |
41 |
> - The user in some way directly requested them |
42 |
> - A logical consequence of the user directly requesting a masked package |
43 |
|
44 |
It's possible that bug 622462 is not the only way to trigger this |
45 |
problem. If anyone experiences a problem like this, then a bug report |
46 |
would be appreciated. |
47 |
-- |
48 |
Thanks, |
49 |
Zac |