1 |
>>>>> On Wed, 16 Dec 2009, Zac Medico wrote: |
2 |
|
3 |
> Ciaran McCreesh wrote: |
4 |
>> Unfortunately, Zac is doing otherwise, and experience shows that |
5 |
>> what Zac does ends up being the final decision. You'll need to |
6 |
>> either convince him to revert the other things he's put in EAPI 3 |
7 |
>> (which I think is just unpack changes, so far), or get the Council |
8 |
>> to make him do so, or persuade the Council to change their minds on |
9 |
>> what's in 3. |
10 |
|
11 |
We don't need to do anything of the above. We abide by the council's |
12 |
decision, because the council defines what goes into an EAPI and what |
13 |
not. |
14 |
|
15 |
In any case, since .xz support will be in EAPI 4, it would be a |
16 |
trivial change to move it to EAPI 3. |
17 |
|
18 |
> The council doesn't have to "make" me do anything. The final EAPI 3 |
19 |
> will have exactly what the council wants and nothing more. I added |
20 |
> xz unpack in EAPI 3_pre2 because I just assumed that everyone would |
21 |
> agree on it. If the council wants to exclude xz unpack in the final |
22 |
> EAPI 3, that's okay and I'll do as the council wishes. |
23 |
|
24 |
Thank you for the clarification. |
25 |
|
26 |
I guess it's an one-line change in Portage to include or not include |
27 |
xz in EAPI 3? |
28 |
|
29 |
Ulrich |