Summary: | Optionally inform user why USE flag is masked | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sam James <sam> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | fturco, josef64, kingjon3377, lssndrbarbieri |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=735660 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sam James
2020-05-16 23:31:02 UTC
I found it quite surprising that a USE flag I enabled in /etc/portage/package.use was completely ignored due to being masked in the profile One would think that an explicit user config choice would override the profile. May I also suggest that the user's config choice either override the profile, or better yet, have a contradiction between /etc/portage and the profile be flagged as a fatal usage error? So yes I agree that it should explain that a flag is masked, but I think it should go further and treat it as a fatal error in the same way as if you try to install a masked package. Blunt version: Treat enabling a masked flag as a fatal error the same way as trying to install a masked package (i.e., hard masked, keywording, license, blocked by another package, etc) I agree this would be useful. I tried toying with this a bit (where does a mask come from) in q, but I think it needs something clearer. At least the grep is sort of eliminated, e.g. `q -mv ruby` will tell a ruby:2.4 mask lives in profiles/package.mask, but it doesn't allow to show mask overrides, e.g. something globally masked, and unmasked in a profile, and therefore explain why a package is NOT masked. *** This bug has been marked as a duplicate of bug 489304 *** |