1 |
Andreas K. Huettel schrieb: |
2 |
> Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell: |
3 |
>> Could you elaborate what the reasons FOR it are (not that I don't know |
4 |
>> any, but you brought it up) since this will add work for every developer |
5 |
>> to check a) how the behavior of the new EAPI impacts the current ebuild |
6 |
>> and b) how the behvaior of inherited eclasses change depending on EAPI. |
7 |
> |
8 |
> a) Easier eclass maintenance. |
9 |
> Restricting the kde4 eclasses to EAPI 3 and 4 made the code indeed simpler. |
10 |
> We'll raise that to 4 only soon (after fixing the remaining ebuilds in the |
11 |
> tree.) |
12 |
|
13 |
An eclass, which includes helper commands like eutils or versionator |
14 |
eclass wont benefit from it. Only specific eclasses (like your kde |
15 |
example would benefit and for those, the related team can always decide |
16 |
to bump all their packages to the wanted EAPI and then to bump the |
17 |
eclass requirement. So no need to force this on everyone else. |
18 |
|
19 |
> |
20 |
> b) Easier overall tree maintenance. |
21 |
> I've recently removed a useflag on poppler (xpdf-headers for those |
22 |
> interested). Of course, this involved fixing all in-tree reverse dependencies |
23 |
> first. Now I consider myself very lucky there, because all except two packages |
24 |
> were EAPI 4 and I could use (+). One package was EAPI 3 and I unceremoniously |
25 |
> bumped it to 4. One was EAPI 0. Having fun with || there. |
26 |
|
27 |
If a package has a maintainer, you could just ask him to fix the issue, |
28 |
so you dont have to even think about the EAPI. And if there is no |
29 |
maintainer, you can take and bump it. And if noone wants to maintain it, |
30 |
it will be dropped at some point. So you can bump whatever you maintain, |
31 |
just still the question: Why force this on everyone else? |
32 |
|
33 |
|
34 |
-- |
35 |
|
36 |
Thomas Sachau |
37 |
Gentoo Linux Developer |