Hello,

I think we're mostly aware what the use and benefits
of the *use.stable.mask files are.

They would be at least really useful in Python ebuilds, where we
have to either:

a) forcedly stabilize a particular Python implementation (like pypy),

b) don't support it all,

c) or just keep two package revisions around, one with 'stable' Python
implementations for stabilization and the other with all
implementations for testing users.


Therefore, having *use.stable.mask would be at least helpful to us. But
as far as I can see, the spec says we can use it only in profile dirs
with EAPI 5...

So far, I doubt anyone would want us to migrate our major profiles
to a newer EAPI, like EAPI 4, not to mention fresh 5. And of course,
that wouldn't follow our migration path practices.


Therefore, I see the following solutions:

1) duplicate most of the major profiles. Make an EAPI 5-enabled wrapper
profiles which will provide the *use.stable.mask files. Require users
to migrate to those profiles after getting an EAPI 5 capable package
manager (how?). Possibly mask the relevant flags completely in other
profiles.


2) change the rules. Make *use.stable.mask files not require EAPI 5
profile dirs but apply only to EAPI 5 packages. The outcome is similar
-- package managers without the feature ignore the ebuilds. If they
have EAPI 5, they should be able to handle stable unmasking as well.

Of course, it all falls apart because of package manager strictness.
We may want to change that retroactively and quickly release updated
package managers before the EAPI 5 support is spread wider (assuming
some transitional period before we will start using the files), or defer
it into EAPI 6.


Either way, I believe that *use.stable.mask would be very helpful if we
were able to use it. What are your thoughts?

-- 
Best regards,
Michał Górny