On 03/25/2018 02:02 AM, Kent Fredric wrote: > On Sat, 24 Mar 2018 21:43:41 -0700 > Zac Medico <zmed...@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
signature.asc
Description: OpenPGP digital signature
