1 |
Hi, |
2 |
|
3 |
Please review the attached future.eclass. Long story short, the idea is |
4 |
to provide some of the EAPI 6 feel to EAPI 5 ebuilds. |
5 |
|
6 |
Quoting the beginning of the DESCRIPTION: |
7 |
|
8 |
# This eclass contains backports of functions that were accepted |
9 |
# by the Council for the EAPI following the EAPI used by ebuild, |
10 |
# and can be implemented in pure shell script. |
11 |
# |
12 |
# The goals of the eclass are to: |
13 |
# 1. provide wider testing of Portage implementations of the next EAPI |
14 |
# functions, |
15 |
# 2. allows developer to use some of the features of the next EAPI |
16 |
# before it is approved production-ready and implemented in Portage |
17 |
# for long enough, |
18 |
# 3. improve EAPI migration time through allowing some of the ebuild |
19 |
# updates earlier, |
20 |
# 4. reduce the necessity of inheriting large, complex and frequently |
21 |
# changing eclasses whenever possible. |
22 |
|
23 |
and the feature list: |
24 |
|
25 |
# Currently implemented EAPI 6 features for EAPI 5: |
26 |
# 1. get_libdir() #463586, simpler than in multilib.eclass; |
27 |
# 2. einstalldocs() #459862, does not use dohtml as eutils.eclass does; |
28 |
# 3. eapply() #463768; |
29 |
# 4. eapply_user() #475288; |
30 |
# 5. new default src_prepare() & src_install() exported; |
31 |
# 6. einstall() is banned #524112 [may be non-portable]; |
32 |
# 7. dohtml() is deprecated #520546 [may be non-portable]. |
33 |
|
34 |
|
35 |
-- |
36 |
Best regards, |
37 |
Michał Górny |