1 |
On Sunday 17 May 2009, Piotr Jaroszyński wrote: |
2 |
> Hello, |
3 |
> |
4 |
> I have just updated GLEP 55 [1], hopefully making it a bit clearer. |
5 |
> |
6 |
> Just FYI, my order of preference of solutions is: |
7 |
> |
8 |
> 1. EAPI-suffixed ebuilds (obviously) |
9 |
> 2. EAPI in the filename with one-time extension change |
10 |
> 3. Easily fetchable EAPI inside the ebuild and one-time extension |
11 |
> change |
12 |
|
13 |
Judging from this list, fourth option present in the GLEP is |
14 |
unacceptable for you? |
15 |
4. Easily fetchable EAPI inside the ebuild |
16 |
|
17 |
From what I understand, the difference between 3 and 4 is that |
18 |
|
19 |
(4) would break pre-glep55 Portage versions that see an ebuild with no |
20 |
metadata cache present if the ebuild uses a future EAPI that |
21 |
introduces changes as described in the "Current behaviour" section. |
22 |
(4) would otherwise keep the current workflow the same except |
23 |
restricting the way the EAPI variable is defined in the ebuild. |
24 |
|
25 |
I would argue that most people who are be exposed to repositories that |
26 |
do not carry a metadata cache (overlays) which use new EAPIs also keep |
27 |
their portage version current. I'd say go with option (4) now and by |
28 |
the time EAPI 4 is collected, written up, agreed upon and implemented, |
29 |
enough time went by so we would not have to introduce an artificial |
30 |
delay. |
31 |
And after that, there won't be any delay to avoid breakage anymore. |
32 |
|
33 |
|
34 |
Robert |