Kent Fredric <[email protected]> wrote:
>
> Maybe IUSE can be extended in a future EAPI to have ~
I like this "~foo" idea very much from the user's point of view:
You see clearly why useflags are disabled, and one could have a
"simple" mechanism to override it.
However, extending IUSE is not the correct way, because
you would need a matrix in every ebuild which cannot be
reasonably maintained: Every useflag can be masked or stable on
each architecture differently. So, supporting the currently
existing {package,}.use.mask in the profiles might make sense,
just the effect needs to be modified somewhat.
1. A tiny change in the display: ~foo instead of (-foo)
2. A more severe change in the way how to unmask it:
(a) ACCEPT_KEYWORD=~ARCH can unmask it (as currenttly).
(b) /etc/portage/package.accept_keywords does *not* unmask it
(contrary to now); this would avoid the dependency hell.
Instead:
(c1) The entry ~foo in /etc/portage/package.use unkeywords foo.
Alternatively (or in addition):
(c2) The entry foo in /etc/portage/package.use.accept_keywords
unmasks it; this could be even extended with architectures
and '**' as the current accept_keywords.
(d) Of course, changing the profile (like overriding it in
/etc/portage/profile) can unmask it, too (as currently),
but this should not be encouraged.
If I see it correctly, this would not even require an EAPI bump,
since /etc/portage/package.* files are not subject to pms.
I hope that (b) is not hard to implement in portage, since
it means that portage has to keep track about the cause of
an unkeywording.
