1 |
Am 25.01.2011 15:09, schrieb Tomáš Chvátal: |
2 |
> Dne 25.1.2011 14:33, Thomas Sachau napsal(a): |
3 |
>> Do you have some more arguments for your request? Most new developers will have to know about all |
4 |
>> EAPi versions anyway since they join an existing team with existing ebuilds, which will mostly not |
5 |
>> use the newest EAPI. |
6 |
> |
7 |
>> As an argument againt this: Noone forces you to keep older EAPI versions of the ebuilds you |
8 |
>> maintain, you can always bump them to the latest EAPI. But why do you want to force this on all |
9 |
>> developers? If i have an EAPI-0 ebuild and am fine with it, why should i convert it to the latest EAPI? |
10 |
> |
11 |
> 1) less stuff to memorize: |
12 |
> seriously mostly if you just use latest EAPI and 0 you can make yourself |
13 |
> not to bother for example with quirks required to use prefix properly in |
14 |
> EAPI2 |
15 |
|
16 |
You are free to only use latest EAPI and EAPI-0 in your ebuilds. So you dont have to memorize the |
17 |
changes in the other EAPI versions. But why do you want to force this on me too? I have to maintain |
18 |
my ebuilds and have to debug the bugs for it, so why not give me the choice to use whatever i prefer |
19 |
to use? |
20 |
|
21 |
> 2) easier migration and deprecation of old EAPIs: |
22 |
> If we enforce latest EAPI to be used EAPIs will be phased out by |
23 |
> automatic upgrade process where we can migrate them. |
24 |
|
25 |
Why would any migration be easier? You always have to check the difference between current and |
26 |
planned EAPI during a migration, this wont change with the policy. And why do you want to deprecate |
27 |
older EAPI versions? |
28 |
|
29 |
> 3) using less codepaths: |
30 |
> so we can find out what the heck is wrong easier in both eclasses and |
31 |
> portage if we know that it was hit with the latest code |
32 |
|
33 |
As i said for the previous points: If you maintain something, you can use whatever you like, |
34 |
including the latest versions, so this is no issue i can see. |
35 |
|
36 |
> 4) eapis are done to bring shiny features: |
37 |
> usually ebuilds using new EAPI should be cleaner and easier to read than |
38 |
> the old EAPI ones, by worst case scenario you just add the EAPI=Version |
39 |
> line to the ebuild which makes it bit larger. |
40 |
|
41 |
Sure, but if it is just another line and nothing else changes, why should i then even add that line? |
42 |
I prefer to keep things to the minimum required and if it works fine for me without the additional |
43 |
line, why should i add it? |
44 |
|
45 |
> |
46 |
>>> |
47 |
>>> Winner for being PITA in this race is python.eclass that HAS completely |
48 |
>>> different behavior based on EAPI version used... |
49 |
> |
50 |
>> The python eclass issues are not just EAPI related, the complete eclass is very complex and hard to |
51 |
>> read/understand. And just because the eclass has additional EAPI-specific behaviour, this is |
52 |
>> specific to this eclass and should not be an argument for the general EAPI discussion. |
53 |
> |
54 |
> |
55 |
> I just said that the eclass has different behaviour for each eapi. Which |
56 |
> is true, nothing more nothing less. And you have to memorize it and |
57 |
> check the behavior in reported bug with various EAPIs. |
58 |
|
59 |
This means, that you either have to convince the python eclass maintainers to reduce the complexity |
60 |
of their eclass or you dont maintain ebuilds, which have to use their eclasses. |
61 |
|
62 |
Alternatively you can just remember the behaviour for the latest EAPI and use that in your ebuilds, |
63 |
so how does the different behaviour for previous EAPI versions create issues for you? |
64 |
|
65 |
> |
66 |
> Tomas |
67 |
|
68 |
-- |
69 |
Thomas Sachau |
70 |
|
71 |
Gentoo Linux Developer |