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