Gentoo Archives: gentoo-dev

From: Doug Klima <cardoe@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] EAPI placement
Date: Tue, 11 Dec 2007 22:03:21
Message-Id: 475F0840.4040503@gentoo.org
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

Replies

Subject Author
[gentoo-dev] Re: EAPI placement Markus Ullmann <jokey@g.o>
Re: [gentoo-dev] EAPI placement Marius Mauch <genone@g.o>
Re: [gentoo-dev] EAPI placement "Petteri Räty" <betelgeuse@g.o>
Re: [gentoo-dev] EAPI placement Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk>