On 03/25/2018 02:02 AM, Kent Fredric wrote:
> On Sat, 24 Mar 2018 21:43:41 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> But if the majority demographic is as you describe, then they shouldn't
>> be using anything having dependencies that require package.unmask or **
>> keywords changes.
> 
> Again, they *dont*, the problem is portage makes the mistake of
> thinking they do.
> 
> This happens especially around virtuals where there is an existing
> problem of portage not doing the right thing when perl-core/* exists in
> some definition.
> 
> I don't have details on hand to give you as to how this happens,
> but I've seen this happen often enough around packages *I maintain* and
> *I* can't explain why portage is trying to install it, only that
> --auto-unmask-keep-masks=y makes the problem mysteriously go away.

An issue like that involving REQUIRED_USE has been reported, and today
I've created a patch that corrects the problem:

    https://bugs.gentoo.org/622462

> The question for me is not "auto unmask is good" vs "autounmask is
> bad", autounmask is fine on its own and is very useful.
> 
> Its the default of --autounmask-keep-masks=n that I find short on value.
> 
> If anything, I suggest there needs to be an
> --autounmask-keep-masks=conditional, or something, that narrows the
> range of solutions portage will try and only attempt to unmask ** or
> package.mask in the following conditions:
> 
> - An explicitly masked package/version is explicitly requested on the command line.
> - A package is a direct dependency of of the above
> - As above, but for the world file
> 
> That is, assume the only reason for masked packages to be considered is:
> - The user in some way directly requested them
> - A logical consequence of the user directly requesting a masked package

It's possible that bug 622462 is not the only way to trigger this
problem. If anyone experiences a problem like this, then a bug report
would be appreciated.
-- 
Thanks,
Zac