1 |
On Tue, 15 Dec 2009 19:59:44 +0100, Fabian Groffen <grobian@g.o> |
2 |
wrote: |
3 |
> With the current route where EAPI=3 will simply be EAPI=2 + |
4 |
> offset-prefix support, and EAPI=4 will be EAPI=3 + some other stuff, the |
5 |
> following question arose: |
6 |
> |
7 |
> Should an ebuild using an EAPI that has offset-prefix support make the |
8 |
> use of that support mandatory or optional? |
9 |
|
10 |
As a Gentoo Linux developer, I certainly wouldn't want to say that my |
11 |
EAPI-3+ ebuilds are guaranteed to work on Gentoo Prefix platforms without |
12 |
testing(keywording) it. |
13 |
|
14 |
As a Gentoo Prefix user, I certainly wouldn't want devs that don't know |
15 |
how to test an ebuild to work on Gentoo Prefix to say that it works. |
16 |
As a Gentoo Prefix developer, I certainly don't want to fix bugs by people |
17 |
that don't know how test on (or have access to) Gentoo Prefix. |
18 |
|
19 |
In the end, every Gentoo Prefix arch needs a specific keyword anyway. |
20 |
Unless that changes, I can't say that I see many benefits to making |
21 |
offset-prefix support mandatory in EAPI-3. OTOH, if it is mandatory and I |
22 |
screw it up for Gentoo Prefix platforms, no one will know until it gets |
23 |
keyworded (and hence tested). |
24 |
|
25 |
-Jeremy |
26 |
|
27 |
|
28 |
> In other words, one can perfectly fine write an ebuild EAPI=3 that will |
29 |
> not work in an offset-prefix install, due to improper absence of |
30 |
EPREFIX, |
31 |
> ED and EROOT. Should we allow this formally, or not? |
32 |
> |
33 |
> Why is this a problem? Simply because it can be done, but more because |
34 |
> EAPI=4 will introduce features a developer would like to use/rely on, |
35 |
> while she/he does not want, or is not able to write the ebuild in a |
36 |
> Prefix conforming way. |
37 |
> |
38 |
> The pros for forcing ebuilds to be offset-prefix aware are: |
39 |
> - an ebuild having EAPI >= 3 (as it looks now) is supposed to work |
40 |
> for Prefix users |
41 |
> - hence also obviously is (supposed to be) checked for Prefix |
42 |
> - repoman might be able to check for obvious mistakes regarding |
43 |
> offset-prefix installations |
44 |
> |
45 |
> The cons: |
46 |
> - all developers need to be aware of how Prefix works, and be able to |
47 |
> write ebuilds for it (I can post all the answers to the Prefix quiz) |
48 |
> - basically requires a Prefix to be setup to test |
49 |
> - it will stop developers to some degree to use higher EAPIs in the |
50 |
> worst case |
51 |
> |
52 |
> The pros for allowing ebuilds that have an offset-prefix aware EAPI to |
53 |
> ignore the offset-prefix are: |
54 |
> - easy drop-in replacement for devs, basically the contra of all the |
55 |
> cons of the previous approach. |
56 |
> |
57 |
> The cons: |
58 |
> - not immediately clear which ebuild is offset-prefix aware (could look |
59 |
> at Prefix keywords) |
60 |
> - needs proper rules; an ebuild that has offset-prefix support may not |
61 |
> have this support removed again (breaks Prefix users, how to enforce?) |
62 |
> - ebuilds may get offset-prefix support at a later stage, which may not |
63 |
> entirely be understood/noticed by (their maintaining) devs |
64 |
> |
65 |
> Please voice your opinion and share your insights, if any. |