1 |
Hello, |
2 |
|
3 |
I think we're mostly aware what the use and benefits |
4 |
of the *use.stable.mask files are. |
5 |
|
6 |
They would be at least really useful in Python ebuilds, where we |
7 |
have to either: |
8 |
|
9 |
a) forcedly stabilize a particular Python implementation (like pypy), |
10 |
|
11 |
b) don't support it all, |
12 |
|
13 |
c) or just keep two package revisions around, one with 'stable' Python |
14 |
implementations for stabilization and the other with all |
15 |
implementations for testing users. |
16 |
|
17 |
|
18 |
Therefore, having *use.stable.mask would be at least helpful to us. But |
19 |
as far as I can see, the spec says we can use it only in profile dirs |
20 |
with EAPI 5... |
21 |
|
22 |
So far, I doubt anyone would want us to migrate our major profiles |
23 |
to a newer EAPI, like EAPI 4, not to mention fresh 5. And of course, |
24 |
that wouldn't follow our migration path practices. |
25 |
|
26 |
|
27 |
Therefore, I see the following solutions: |
28 |
|
29 |
1) duplicate most of the major profiles. Make an EAPI 5-enabled wrapper |
30 |
profiles which will provide the *use.stable.mask files. Require users |
31 |
to migrate to those profiles after getting an EAPI 5 capable package |
32 |
manager (how?). Possibly mask the relevant flags completely in other |
33 |
profiles. |
34 |
|
35 |
|
36 |
2) change the rules. Make *use.stable.mask files not require EAPI 5 |
37 |
profile dirs but apply only to EAPI 5 packages. The outcome is similar |
38 |
-- package managers without the feature ignore the ebuilds. If they |
39 |
have EAPI 5, they should be able to handle stable unmasking as well. |
40 |
|
41 |
Of course, it all falls apart because of package manager strictness. |
42 |
We may want to change that retroactively and quickly release updated |
43 |
package managers before the EAPI 5 support is spread wider (assuming |
44 |
some transitional period before we will start using the files), or defer |
45 |
it into EAPI 6. |
46 |
|
47 |
|
48 |
Either way, I believe that *use.stable.mask would be very helpful if we |
49 |
were able to use it. What are your thoughts? |
50 |
|
51 |
-- |
52 |
Best regards, |
53 |
Michał Górny |