1 |
With the current route where EAPI=3 will simply be EAPI=2 + |
2 |
offset-prefix support, and EAPI=4 will be EAPI=3 + some other stuff, the |
3 |
following question arose: |
4 |
|
5 |
Should an ebuild using an EAPI that has offset-prefix support make the |
6 |
use of that support mandatory or optional? |
7 |
|
8 |
In other words, one can perfectly fine write an ebuild EAPI=3 that will |
9 |
not work in an offset-prefix install, due to improper absence of EPREFIX, |
10 |
ED and EROOT. Should we allow this formally, or not? |
11 |
|
12 |
Why is this a problem? Simply because it can be done, but more because |
13 |
EAPI=4 will introduce features a developer would like to use/rely on, |
14 |
while she/he does not want, or is not able to write the ebuild in a |
15 |
Prefix conforming way. |
16 |
|
17 |
The pros for forcing ebuilds to be offset-prefix aware are: |
18 |
- an ebuild having EAPI >= 3 (as it looks now) is supposed to work |
19 |
for Prefix users |
20 |
- hence also obviously is (supposed to be) checked for Prefix |
21 |
- repoman might be able to check for obvious mistakes regarding |
22 |
offset-prefix installations |
23 |
|
24 |
The cons: |
25 |
- all developers need to be aware of how Prefix works, and be able to |
26 |
write ebuilds for it (I can post all the answers to the Prefix quiz) |
27 |
- basically requires a Prefix to be setup to test |
28 |
- it will stop developers to some degree to use higher EAPIs in the |
29 |
worst case |
30 |
|
31 |
The pros for allowing ebuilds that have an offset-prefix aware EAPI to |
32 |
ignore the offset-prefix are: |
33 |
- easy drop-in replacement for devs, basically the contra of all the |
34 |
cons of the previous approach. |
35 |
|
36 |
The cons: |
37 |
- not immediately clear which ebuild is offset-prefix aware (could look |
38 |
at Prefix keywords) |
39 |
- needs proper rules; an ebuild that has offset-prefix support may not |
40 |
have this support removed again (breaks Prefix users, how to enforce?) |
41 |
- ebuilds may get offset-prefix support at a later stage, which may not |
42 |
entirely be understood/noticed by (their maintaining) devs |
43 |
|
44 |
Please voice your opinion and share your insights, if any. |
45 |
|
46 |
|
47 |
-- |
48 |
Fabian Groffen |
49 |
Gentoo on a different level |