On 14 November 2013 04:23, Martin Vaeth <[email protected]> wrote: > The use.stable.mask "solution" is to not inform the user but just > decide behind his back that he cannot use the flag and enforce > this decision. > Instead, e.g. one can let portage report if some useflag described > in use.stable.mask needs to be disabled, or one can use some > "I_KNOW_WHAT_I_AM_DOING" name, or whatever. There are many ways > of reporting. But forcing a decision on the user without even > communicating reasonably why this decision was forced is very bad IMHO.
Ah, that explains why I hadn't thought I'd seen what this subject was about, because I expected when I saw (-foo) In emerge's overview output, that the flag "foo" was simply hard-masked profile-wide, for "some reason". If there was better indication that these flags are simply masked due to a stability level difference, I'd have expected a different indicator in the output. Seems as this is the reality we have: ebuild: stable, unstable, hardmasked/experimental useflag: stable, hardmasked/experimental Seems logical we make useflags potentially be: useflag: stable, unstable, hardmasked/experimental "Somehow", or at least, if that is already the case, it needs to be more obvious what is occurring, and what steps we should be taking if we want to work around it. Maybe IUSE can be extended in a future EAPI to have ~ , or we could have a seperate variable to indicate useflag stability. ideas: -foo # I don't want foo, but defer if stability differences make that impossible. -~foo # I don't want foo, and I don't care if removing foo reduces stability. -**foo # I don't care if foo is experimental , turn that shit off or something. At very least, emerge --pretend should say something like ((~)-foo) To indicate foo is turned off due to a stability mask, though I don't know how to make it clear to end users what that means. Just showing something different however is often enough to make interested parties curious. -- Kent
