Currently, portage will unmask packages that have been masked by the user in /etc/portage/package.mask. This is undesired, because the user knows best; he/she put the masks there for a reason. Portage should not circumvent them. Specifying --autounmask=n does not offer a solution; this turns the feature off completely instead of only unmasking profile masks but obeying user-masks. Reproducible: Always
Dependencies, etc. change. What yesterday was a good idea might be a bad one today. The comment gives you the reason for the change. If you want to avoid the change you need to avoid the reason.
It should give a message then. But not unmask. The reason can be changed how exactly? There's a million reasons why someone masked something. You definitely can't make any prognosis whether one can "change the reason" or not, or whether the reason is changeable at all.
(In reply to comment #2) > It should give a message then. But not unmask. For default behavior, I think that the "hold no masks sacred" approach is optimal, for a couple of reasons: (1) It's always possible for /etc/portage to contain obsolete configurations that the user will really want to ignore. (2) --autounmask only applies to unsatisfied dependencies, and the fraction of all dependency calculations in which we have unsatisfied dependencies due to local masks should be a very small minority. Until we come up with a different solution, it's easy enough for the user to set --autounmask=n in these situations. > The reason can be changed how exactly? There's a million reasons why someone > masked something. You definitely can't make any prognosis whether one can > "change the reason" or not, or whether the reason is changeable at all. Of course not, but as said, it's more likely that (1) applies than that (2) applies, and when (2) applies it's easy enough to set --autounmask=n. As an alternative to --autounmask=n, it might also be nice to have something like --autounmask-local-mask=n to disable autounmask just for local masks (like I've suggested in bug 369917, comment #2).
(In reply to comment #2) > [...] > The reason can be changed how exactly? There's a million reasons why someone > masked something. > [...] When I say reason, I mean the reason for emerge to unmask the package, not the reason why it is masked.
*** Bug 376681 has been marked as a duplicate of this bug. ***
Theres a --autounmask-keep-masks option in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=d36be695ea48025ba195deb82f51846aee2254ec
Also, it suggests --autounmask-keep-masks instead of --autounmask=n: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=cfae195364f3cc9700f34eef031933ff701d029d
Since ** keyword changes are handled similarly to package.unmask changes, I've updated the --autounmask-keep-masks stuff for consistency: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=392cc10c0a6f608ab7a8f4a8043b58589c6ee21c http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=72ef29a6adaa053cf2d538349a3a1555909ed697
*** Bug 369917 has been marked as a duplicate of this bug. ***
This is fixed in 2.1.10.20 and 2.2.0_alpha60.
