Since it doesn't appear the question was answered by the last thread.
I'm starting a new thread.
<Cardoe> did we decide where EAPI goes in an ebuild?
<zmedico> yes, just above the inherit
<zmedico> that's the safest and simplest thing to do, anyway
<Cardoe> zmedico: what if I have EAPI=2 above the inherit but an eclass
has EAPI=1
<zmedico> then the eclass would override the EAPI
<zmedico> which probably isn't what you want
<zmedico> are there any eclasses defining EAPI now? I hope not. :)
* lavajoe has quit ("Leaving")
<Cardoe> I'm not sure
<zlin> not in gentoo-x86
<Cardoe> but I think it would be something that would happen in the future
<Cardoe> if an eclass uses features that require a specific EAPI
<Cardoe> wouldn't it make sense to list that in there?
<zlin> the kde4 eclasses in the kde4-experimental overlay set eapi=1.
<zmedico> it's fine to do that, it's just too early to do that on lots
of eclasses in the main tree, because EAPI=1 is too new
<zmedico> we don't even have stages with EAPI=1 aware portage in them
released yet
<zlin> it probably shouldn't ever be done in an existing eclass.
<Cardoe> I think putting EAPI above inherit is bad
<Cardoe> because you're relying on the ebuild author to audit all the
eclass code to know which EAPI version is required
<Cardoe> for all the code
<zmedico> same thing if you put it below, no?
<Cardoe> no
<Cardoe> because the eclass code should get executed at EAPI=1
<Cardoe> while the ebuild could get executed at EAPI=2
<zmedico> well, people can hash this stuff out over time
<zmedico> there's no rush
<zmedico> with >=portage-2.1.4 we can make incompatible changes to
eclasses :)
<Cardoe> ok but you see what I'm saying?
<Cardoe> it should go *AFTER* inherit
<zmedico> to me, mixing code intended for multiple EAPIs is messy
<zmedico> it's conceivable to have 2 different EAPIs where it's not even
possible
<Cardoe> While it might be messy, I can guarantee it will happen.
<Cardoe> eutils might go to eapi=2 and some ebuild might need eapi=3,
but eutils isn't ported to eapi=3 yet.
<Cardoe> If you allow our developers to do it, it will happen.
<Cardoe> Plain and simple. Unless repoman blocks this.
<zmedico> we'll have some rules
<Cardoe> Ok. Let's establish them.
<Cardoe> releasing features and saying "eh.. we'll figure it out as we
go" won't work
<Cardoe> because you're gonna find people are going to stick stuff all
over the place from the get go unless there are formal rules now
<zmedico> 1) don't do anything stupid without discussing it with the
community first ;)
<Cardoe> well, we tried to talk about it on the mailing list but didn't
get a solid answer.
<Cardoe> I'm starting a new thread, and including this convo.
<Cardoe> that's a too lose rule, people break that on a daily basis in
the tree.
<Cardoe> Let's address the issue now, rather then having a broken tree 3
months from now that will require 500 commits to fix.
<Cardoe> I'll just send this to the ML now.
discuss.
--
Doug Klima
Gentoo Developer
--
gentoo-dev@gentoo.org mailing list
I'm starting a new thread.
<Cardoe> did we decide where EAPI goes in an ebuild?
<zmedico> yes, just above the inherit
<zmedico> that's the safest and simplest thing to do, anyway
<Cardoe> zmedico: what if I have EAPI=2 above the inherit but an eclass
has EAPI=1
<zmedico> then the eclass would override the EAPI
<zmedico> which probably isn't what you want
<zmedico> are there any eclasses defining EAPI now? I hope not. :)
* lavajoe has quit ("Leaving")
<Cardoe> I'm not sure
<zlin> not in gentoo-x86
<Cardoe> but I think it would be something that would happen in the future
<Cardoe> if an eclass uses features that require a specific EAPI
<Cardoe> wouldn't it make sense to list that in there?
<zlin> the kde4 eclasses in the kde4-experimental overlay set eapi=1.
<zmedico> it's fine to do that, it's just too early to do that on lots
of eclasses in the main tree, because EAPI=1 is too new
<zmedico> we don't even have stages with EAPI=1 aware portage in them
released yet
<zlin> it probably shouldn't ever be done in an existing eclass.
<Cardoe> I think putting EAPI above inherit is bad
<Cardoe> because you're relying on the ebuild author to audit all the
eclass code to know which EAPI version is required
<Cardoe> for all the code
<zmedico> same thing if you put it below, no?
<Cardoe> no
<Cardoe> because the eclass code should get executed at EAPI=1
<Cardoe> while the ebuild could get executed at EAPI=2
<zmedico> well, people can hash this stuff out over time
<zmedico> there's no rush
<zmedico> with >=portage-2.1.4 we can make incompatible changes to
eclasses :)
<Cardoe> ok but you see what I'm saying?
<Cardoe> it should go *AFTER* inherit
<zmedico> to me, mixing code intended for multiple EAPIs is messy
<zmedico> it's conceivable to have 2 different EAPIs where it's not even
possible
<Cardoe> While it might be messy, I can guarantee it will happen.
<Cardoe> eutils might go to eapi=2 and some ebuild might need eapi=3,
but eutils isn't ported to eapi=3 yet.
<Cardoe> If you allow our developers to do it, it will happen.
<Cardoe> Plain and simple. Unless repoman blocks this.
<zmedico> we'll have some rules
<Cardoe> Ok. Let's establish them.
<Cardoe> releasing features and saying "eh.. we'll figure it out as we
go" won't work
<Cardoe> because you're gonna find people are going to stick stuff all
over the place from the get go unless there are formal rules now
<zmedico> 1) don't do anything stupid without discussing it with the
community first ;)
<Cardoe> well, we tried to talk about it on the mailing list but didn't
get a solid answer.
<Cardoe> I'm starting a new thread, and including this convo.
<Cardoe> that's a too lose rule, people break that on a daily basis in
the tree.
<Cardoe> Let's address the issue now, rather then having a broken tree 3
months from now that will require 500 commits to fix.
<Cardoe> I'll just send this to the ML now.
discuss.
--
Doug Klima
Gentoo Developer
--
gentoo-dev@gentoo.org mailing list
