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. 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
pgpBA7OyKTQKm.pgp
Description: OpenPGP digital signature
