Bug 372485 – sys-apps/portage: autounmask should not unmask user-masks

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Nikos Chantziaras 2011-06-21 13:59:10 UTC]

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

[Comment 1 Sebastian Luther (few) 2011-06-21 16:16:28 UTC]

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.

[Comment 2 Nikos Chantziaras 2011-06-21 16:32:41 UTC]

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.

[Comment 3 Zac Medico 2011-06-21 17:15:50 UTC]

(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).

[Comment 4 Sebastian Luther (few) 2011-06-21 18:14:16 UTC]

(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.

[Comment 5 Zac Medico 2011-09-18 19:49:06 UTC]

*** Bug 376681 has been marked as a duplicate of this bug. ***

[Comment 6 Zac Medico 2011-09-19 14:38:54 UTC]

Theres a --autounmask-keep-masks option in git now:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=d36be695ea48025ba195deb82f51846aee2254ec

[Comment 7 Zac Medico 2011-09-19 15:28:16 UTC]

Also, it suggests --autounmask-keep-masks instead of --autounmask=n:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=cfae195364f3cc9700f34eef031933ff701d029d

[Comment 8 Zac Medico 2011-09-19 16:10:18 UTC]

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

[Comment 9 Sebastian Luther (few) 2011-09-20 08:20:30 UTC]

*** Bug 369917 has been marked as a duplicate of this bug. ***

[Comment 10 Zac Medico 2011-09-29 18:46:28 UTC]

This is fixed in 2.1.10.20 and 2.2.0_alpha60.