1 |
Hi, |
2 |
|
3 |
I don'f feel very well with this idea especially because no matter how hard I |
4 |
try I don't get comfortable with EAPI-3. No offense to our prefix guys, you |
5 |
surely did a hell of a good job and EAPI-3 seems to really get you out of |
6 |
quite some trouble you had with earlier EAPIs, but... |
7 |
I for myself never tried a prefix installation and I don't have any intentions |
8 |
to do this in the foreseeable future so I still prefer EAPI-2 wherever I can |
9 |
simply because EAPI-3 imposes overhead on my side which I have no real benefit |
10 |
from and I have no real clue about how to write proper EAPI-3 ebuilds. |
11 |
|
12 |
-- |
13 |
Lars Wendler (Polynomial-C) |
14 |
Gentoo package maintainer and bug-wrangler |
15 |
|
16 |
Am Dienstag 25 Januar 2011, 12:20:30 schrieb Tomáš Chvátal: |
17 |
> Hi, |
18 |
> I would like to upgrade tree-wide policy for EAPI usage in main tree. |
19 |
> Currently we say that developers can use any named version they wish or |
20 |
> find sufficient. |
21 |
> I would on other hand like to have all ebuilds to use Latest EAPI |
22 |
> version possible (given the eclasses support it [hint hint maintainers |
23 |
> of eclasses should always try to support latest :P]) with expection for |
24 |
> base-system or more specialy depgraph for portage that needs to be |
25 |
> EAPI0. [[ And here we need to find out some upgrade proccess that would |
26 |
> work for everyone so we could somehow migrate them too :)]] |
27 |
> |
28 |
> With this usually new developers should be aware only of latest EAPI and |
29 |
> wont need to memorize what which EAPI support. Heck even I sometimes |
30 |
> forget what i can do with some version and whatnot. |
31 |
> |
32 |
> Winner for being PITA in this race is python.eclass that HAS completely |
33 |
> different behavior based on EAPI version used... |
34 |
> |
35 |
> Cheers |
36 |
> |
37 |
> Tomas |