1 |
Since it doesn't appear the question was answered by the last thread. |
2 |
I'm starting a new thread. |
3 |
|
4 |
<Cardoe> did we decide where EAPI goes in an ebuild? |
5 |
<zmedico> yes, just above the inherit |
6 |
<zmedico> that's the safest and simplest thing to do, anyway |
7 |
<Cardoe> zmedico: what if I have EAPI=2 above the inherit but an eclass |
8 |
has EAPI=1 |
9 |
<zmedico> then the eclass would override the EAPI |
10 |
<zmedico> which probably isn't what you want |
11 |
<zmedico> are there any eclasses defining EAPI now? I hope not. :) |
12 |
* lavajoe has quit ("Leaving") |
13 |
<Cardoe> I'm not sure |
14 |
<zlin> not in gentoo-x86 |
15 |
<Cardoe> but I think it would be something that would happen in the future |
16 |
<Cardoe> if an eclass uses features that require a specific EAPI |
17 |
<Cardoe> wouldn't it make sense to list that in there? |
18 |
<zlin> the kde4 eclasses in the kde4-experimental overlay set eapi=1. |
19 |
<zmedico> it's fine to do that, it's just too early to do that on lots |
20 |
of eclasses in the main tree, because EAPI=1 is too new |
21 |
<zmedico> we don't even have stages with EAPI=1 aware portage in them |
22 |
released yet |
23 |
<zlin> it probably shouldn't ever be done in an existing eclass. |
24 |
<Cardoe> I think putting EAPI above inherit is bad |
25 |
<Cardoe> because you're relying on the ebuild author to audit all the |
26 |
eclass code to know which EAPI version is required |
27 |
<Cardoe> for all the code |
28 |
<zmedico> same thing if you put it below, no? |
29 |
<Cardoe> no |
30 |
<Cardoe> because the eclass code should get executed at EAPI=1 |
31 |
<Cardoe> while the ebuild could get executed at EAPI=2 |
32 |
<zmedico> well, people can hash this stuff out over time |
33 |
<zmedico> there's no rush |
34 |
<zmedico> with >=portage-2.1.4 we can make incompatible changes to |
35 |
eclasses :) |
36 |
<Cardoe> ok but you see what I'm saying? |
37 |
<Cardoe> it should go *AFTER* inherit |
38 |
<zmedico> to me, mixing code intended for multiple EAPIs is messy |
39 |
<zmedico> it's conceivable to have 2 different EAPIs where it's not even |
40 |
possible |
41 |
<Cardoe> While it might be messy, I can guarantee it will happen. |
42 |
<Cardoe> eutils might go to eapi=2 and some ebuild might need eapi=3, |
43 |
but eutils isn't ported to eapi=3 yet. |
44 |
<Cardoe> If you allow our developers to do it, it will happen. |
45 |
<Cardoe> Plain and simple. Unless repoman blocks this. |
46 |
<zmedico> we'll have some rules |
47 |
<Cardoe> Ok. Let's establish them. |
48 |
<Cardoe> releasing features and saying "eh.. we'll figure it out as we |
49 |
go" won't work |
50 |
<Cardoe> because you're gonna find people are going to stick stuff all |
51 |
over the place from the get go unless there are formal rules now |
52 |
<zmedico> 1) don't do anything stupid without discussing it with the |
53 |
community first ;) |
54 |
<Cardoe> well, we tried to talk about it on the mailing list but didn't |
55 |
get a solid answer. |
56 |
<Cardoe> I'm starting a new thread, and including this convo. |
57 |
<Cardoe> that's a too lose rule, people break that on a daily basis in |
58 |
the tree. |
59 |
<Cardoe> Let's address the issue now, rather then having a broken tree 3 |
60 |
months from now that will require 500 commits to fix. |
61 |
<Cardoe> I'll just send this to the ML now. |
62 |
|
63 |
discuss. |
64 |
|
65 |
-- |
66 |
Doug Klima |
67 |
Gentoo Developer |
68 |
-- |
69 |
gentoo-dev@g.o mailing list |