EAPI placement
 

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

EAPI placement
 

Doug Klima schrieb:
> <Cardoe> zmedico: what if I have EAPI=2 above the inherit but an eclass
> has EAPI=1

if an eclass sets EAPI, then the ebuild shouldn't... make it two
eclasses if needed or plain bump them if really really needed.

Greetz
Jokey

EAPI placement
 

On Tue, 11 Dec 2007 16:59:28 -0500
Doug Klima <cardoe@gentoo.org> wrote:

> Since it doesn't appear the question was answered by the last thread.
> I'm starting a new thread.

The only sane solution I can think of is that eclasses shouldn't be
allowed to change EAPI, but use conditionals to behave differently if
needed. Mixing two (or more) different arbitrary EAPIs isn't going to
work as after the inital parsing package managers will only see the
last EAPI value anyway. Also there is no guarantee that future EAPI
versions will be backwards compatible, so if eclasses could have an
EAPI version it would eventually require that all packages using it
need the same EAPI version (similar for nested inheritance).

It's trivial to let inherit check that an eclass doesn't modify EAPI,
and adding the conditional code to eclasses isn't difficult either:

foo.eclass:

if [ -z "$EAPI" ]; then
inherit foo-eapi0
fi
case "$EAPI" in
0)
inherit foo-eapi0
;;
1|2)
inherit foo-eapi1_2
;;
*)
eerror "foo.eclass: unsupported EAPI value $EAPI"
;;
esac

# EAPI independent code here

Obviously instead of specific eclasses one could also inline the
relevant code. The only two issues I see in this concept are the
eventual multiplication of eclasses and the lack of proper error
handling for unsupported EAPIs.

Marius

PS: Yes, this idea has been mentioned in the old thread as well

--
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

EAPI placement
 

On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote:
> Doug Klima schrieb:
> > <Cardoe> zmedico: what if I have EAPI=2 above the inherit but an eclass
> > has EAPI=1
>
> if an eclass sets EAPI, then the ebuild shouldn't... make it two
> eclasses if needed or plain bump them if really really needed.
>
> Greetz
> Jokey

That doesn't sound right. What happens if the eclass sets an EAPI(say 1), but
you need to use say X feature(which is in EAPI 2). By what you said, this
would prevent the ebuild from using the features in EAPI 2. It also isn't
smart to bump eclasses' EAPI--EAPI should be set to the lowest common
denominator that that feature being used is in.

If that made sense ;)

--
2.6.23-gentoo-r3

EAPI placement
 

Thomas Anderson wrote:

On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote:

Doug Klima schrieb:

<Cardoe> zmedico: what if I have EAPI=2 above the inherit but an eclass
has EAPI=1

if an eclass sets EAPI, then the ebuild shouldn't... make it two
eclasses if needed or plain bump them if really really needed.

Greetz
Jokey


That doesn't sound right. What happens if the eclass sets an EAPI(say 1), but
you need to use say X feature(which is in EAPI 2). By what you said, this
would prevent the ebuild from using the features in EAPI 2. It also isn't
smart to bump eclasses' EAPI--EAPI should be set to the lowest common
denominator that that feature being used is in.


If that made sense ;)



The issue additionally is that future EAPIs may remove deprecated
features and may also have conflicting actions. So running an ebuild
that's designed for say EAPI=2, which conflicts with EAPI=1, as EAPI=1
may be broken.


--
Doug Klima <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/
--
gentoo-dev@gentoo.org mailing list

EAPI placement
 

Marius Mauch wrote:

On Tue, 11 Dec 2007 16:59:28 -0500
Doug Klima <cardoe@gentoo.org> wrote:


Since it doesn't appear the question was answered by the last thread.
I'm starting a new thread.


The only sane solution I can think of is that eclasses shouldn't be
allowed to change EAPI, but use conditionals to behave differently if
needed. Mixing two (or more) different arbitrary EAPIs isn't going to
work as after the inital parsing package managers will only see the
last EAPI value anyway. Also there is no guarantee that future EAPI
versions will be backwards compatible, so if eclasses could have an
EAPI version it would eventually require that all packages using it
need the same EAPI version (similar for nested inheritance).

It's trivial to let inherit check that an eclass doesn't modify EAPI,
and adding the conditional code to eclasses isn't difficult either:


foo.eclass:

if [ -z "$EAPI" ]; then
inherit foo-eapi0
fi
case "$EAPI" in
0)
inherit foo-eapi0
;;
1|2)
inherit foo-eapi1_2
;;
*)
eerror "foo.eclass: unsupported EAPI value $EAPI"
;;
esac

# EAPI independent code here

Obviously instead of specific eclasses one could also inline the
relevant code. The only two issues I see in this concept are the
eventual multiplication of eclasses and the lack of proper error
handling for unsupported EAPIs.

Marius

PS: Yes, this idea has been mentioned in the old thread as well



This again leads to in a sense, code duplication due to the fact that
you have to have several different versions of the code for each EAPI.
When you could simply have $pkg_manager execute an eclass as 1 EAPI,
another eclass as another and the ebuild as a third EAPI and simplify it
for the eclass maintenance.


--
Doug Klima <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/
--
gentoo-dev@gentoo.org mailing list

EAPI placement
 

Doug Klima kirjoitti:
> Since it doesn't appear the question was answered by the last thread.
> I'm starting a new thread.
>

http://article.gmane.org/gmane.linux.gentoo.devel/52981/match=eapi

I think it was answered.

Regards,
Petteri

EAPI placement
 

On Tue, 11 Dec 2007 16:59:28 -0500
Doug Klima <cardoe@gentoo.org> wrote:
> discuss.

* EAPI may only be set before the 'inherit' in an ebuild.

* Eclasses may not set EAPI.

* Eclasses may not assume a particular EAPI.

* If an eclass needs to work with multiple EAPIs, EAPI-specific code
should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code
and a conditional inherit should remain in foo.eclass.

* Eclasses cannot be made not to work with any given EAPI. If such
functionality is desirable, someone needs to file an EAPI request for
permitting an alternative to 'die' that is legal in global scope.

--
Ciaran McCreesh

EAPI placement
 

On Dec 12, 2007 1:21 PM, Ciaran McCreesh
<ciaran.mccreesh@blueyonder.co.uk> wrote:
> On Tue, 11 Dec 2007 16:59:28 -0500
> Doug Klima <cardoe@gentoo.org> wrote:
> > discuss.
>
> * EAPI may only be set before the 'inherit' in an ebuild.
>
> * Eclasses may not set EAPI.
>
> * Eclasses may not assume a particular EAPI.
>
> * If an eclass needs to work with multiple EAPIs, EAPI-specific code
> should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code
> and a conditional inherit should remain in foo.eclass.

It seems the most reasonable option I've read until now.

Would it be possible to have eclass/eapiBLAH/foo.eclass?

> * Eclasses cannot be made not to work with any given EAPI. If such
> functionality is desirable, someone needs to file an EAPI request for
> permitting an alternative to 'die' that is legal in global scope.

So is it desirable?

If portage masks ebuilds with an unsupported EAPI, what's the point?
It'd be enough to be able to check EAPI compatibility in eclasses
quickly so repoman and others can print a nice error.

--
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
--
gentoo-dev@gentoo.org mailing list

EAPI placement
 

Petteri Räty wrote:
> Doug Klima kirjoitti:
>
>> Since it doesn't appear the question was answered by the last thread.
>> I'm starting a new thread.
>>
>>
>
> http://article.gmane.org/gmane.linux.gentoo.devel/52981/match=eapi
>
> I think it was answered.
>
> Regards,
> Petteri
>
>
And I brough up valid reasons with zmedico why putting it before the
inherit line was flawed currently since it could lead to some seriously
unexpected behavior. If that's the case, it needs to be a very strict
check in repoman and we need repoman on the eclasses to prevent people
from putting EAPI into the eclasses.
--
gentoo-dev@gentoo.org mailing list