1 |
Tiziano Müller wrote: |
2 |
> Am Freitag, den 15.05.2009, 23:30 +0300 schrieb Petteri Räty: |
3 |
>> William Hubbs wrote: |
4 |
>>> On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote: |
5 |
>>>> On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote: |
6 |
>>>>> Thanks Robin for finally pushing this in the tree, just didn't find the |
7 |
>>>>> time to. |
8 |
>>>>> |
9 |
>>>>> Maybe it's a good time to emphasize this: Keep in mind that changing the |
10 |
>>>>> EAPI in an ebuild requires a revision bump (including reset to unstable |
11 |
>>>>> keywords, etc.). |
12 |
>>>> That's going to cause a large problem. |
13 |
>>>> The entire point is that the STABLE ebuilds need to be changed, |
14 |
>>>> otherwise they will try to depend on the libusb-1 series (and fail |
15 |
>>>> dismally). |
16 |
>>>> For switching from EAPI0 to EAPI1, if the ebuild still compiles fine, |
17 |
>>>> then I see no reason that a slot dep change cannot be just put in with |
18 |
>>>> the EAPI change. (The same cannot be said for EAPIx -> EAPI2, as further |
19 |
>>>> changes are needed for that case). |
20 |
>>> |
21 |
>>> As far as I know, the only time you need to do a rev bump and reset to |
22 |
>>> unstable is if you change the files that are installed by the package. |
23 |
>>> |
24 |
>>> So, as far as I know, unless you are migrating to an EAPI that is not |
25 |
>>> stable or changing the files that are installed by the package, it is |
26 |
>>> not necessary to do a rev bump just for changing the EAPI as long as |
27 |
>>> you make sure that the ebuild emerges fine under the new EAPI. |
28 |
>>> |
29 |
>> Indeed there's no problem switching EAPIs as long as a stable Portage |
30 |
>> supports the EAPI you are migrating to. Portage was buggy with this when |
31 |
>> EAPI 2 was introduced but that has since been fixed. |
32 |
> |
33 |
> Wrong. For example: |
34 |
> - stuff like docompress may change the content being installed depending |
35 |
> on the package manager |
36 |
> - --disable-static (maybe in a later EAPI) changes content |
37 |
> - slot-dep-operators change the rdepend of installed packages, so it |
38 |
> changes how the package manager has to handle reverse packages on |
39 |
> uninstall (in EAPI 3) |
40 |
> |
41 |
|
42 |
Switching EAPIs in my mind means taking care it works with new EAPIs. |
43 |
Why switch in the first place if you aren't making modifications to the |
44 |
ebuild? |
45 |
|
46 |
> On the other hand you also have to make sure you have a stable portage |
47 |
> for a time long enough so mostly everyone has it installed. Otherwise |
48 |
> you could break users systems pretty badly depending on the packages. |
49 |
> And Arch-Teams usually do a pretty good job in catching such cases. |
50 |
> |
51 |
|
52 |
How would this breakage happen? The ebuild in the vdb still has the old |
53 |
EAPI. |
54 |
|
55 |
> And we also always said that a rev bump should be done on non trivial |
56 |
> changes or non-build-fixes and changing the EAPI is technical seen |
57 |
> mostly a non-trivial change. |
58 |
> |
59 |
|
60 |
Switching between EAPI 0 and 1 for example is quite trivial. In Java |
61 |
ebuilds we should always use slot deps because jars get installed to a |
62 |
SLOT dependent path. I doubt our users would want to see us revision |
63 |
bumping our ebuilds for that. |
64 |
|
65 |
> Do we want to document the following? (do we have already?) |
66 |
> - When is it allowed to use an EAPI in the tree (given as offset to the |
67 |
> release of portage supporting that eapi) |
68 |
> - When is it allowed to use an EAPI in the stable tree (given as offset |
69 |
> of when a portage version supporting that EAPI got stable) |
70 |
> |
71 |
|
72 |
Currently: |
73 |
1. Usage of an EAPI in the tree is allowed after council gives the OK. |
74 |
2. When the Portage version supporting it goes stable |
75 |
|
76 |
If you want please check devmanual and file a bug if it needs |
77 |
updating/new info regarding this. |
78 |
|
79 |
Regards, |
80 |
Petteri |