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
signature.asc
Description: PGP signature
