[gentoo-dev] EAPI placement

[gentoo-dev] EAPI placement

[Doug Klima]

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

[gentoo-dev] Re: EAPI placement

[Markus Ullmann]

[-- Attachment #1: Type: text/plain, Size: 261 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] EAPI placement

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: EAPI placement

[Thomas Anderson]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: EAPI placement

[Doug Klima]

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

Re: [gentoo-dev] EAPI placement

[Doug Klima]

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

Re: [gentoo-dev] EAPI placement

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] EAPI placement

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] EAPI placement

[Santiago M. Mola]

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

Re: [gentoo-dev] EAPI placement

[Doug Klima]

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

Re: [gentoo-dev] EAPI placement

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

On Wed, 12 Dec 2007 15:08:36 +0100
"Santiago M. Mola" <coldwind@gentoo.org> wrote:
> Would it be possible to have eclass/eapiBLAH/foo.eclass?

No. Not even with an EAPI change. This is one of the deficiencies in
the way EAPI was designed -- an EAPI cannot change the behaviour of
inherit, nor can it introduce new global-scope functions.

The .ebuild-eapi proposal didn't have this problem, but unfortunately it
was rejected for political reasons...

> > * 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.

The problem is that people change eclasses and don't check every single
package that uses them. Find a solution for that problem and then
eclasses supporting only a subset of EAPIs becomes feasible.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] EAPI placement

[Doug Klima]

Ciaran McCreesh 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.
>
> * 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.
>
>   
My point is it's fine to state this, however there needs to be
enforcement of this in the associated utilities. repoman, etc.
Unfortunately, eclasses are not checked at all at commit time, which
would allow developers to make this potentially catastrophic change.

So we're going to have "eapi 1 && inherit foo-eapi1.eclass" allowable in
"foo.eclass"? When will this "eapi" keyword be available for eclasses to
use?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI placement

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

On Wed, 12 Dec 2007 09:20:02 -0500
Doug Klima <cardoe@gentoo.org> wrote:
> 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.

It's only unexpected if people screw up. If everyone understands the
restrictions I posted and sticks to them then things work. If people
start trying to be clever things go horribly wrong.

> 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.

Or you need to get PMS and package managers retroactively updated to
saying that 'inherit' does a 'declare -r EAPI'... Although that's only
a good idea if you operate on the assumption that developers will screw
up.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] EAPI placement

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On Wed, 12 Dec 2007 09:22:41 -0500
Doug Klima <cardoe@gentoo.org> wrote:
> My point is it's fine to state this, however there needs to be
> enforcement of this in the associated utilities. repoman, etc.
> Unfortunately, eclasses are not checked at all at commit time, which
> would allow developers to make this potentially catastrophic change.

Well, the other option is to enforce it via the package manager. But
that's enforcing tree policy via EAPI, which we were trying to avoid.

> So we're going to have "eapi 1 && inherit foo-eapi1.eclass" allowable
> in "foo.eclass"? When will this "eapi" keyword be available for
> eclasses to use?

[[ $EAPI == 1 ]]

Adding an eapi keyword would require a new EAPI, so you'd have to do
the variable test for 0 and 1 anyway (and note that the empty EAPI is
exactly like EAPI 0, and you can't assume that you'll get one or the
other).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] EAPI placement

[Piotr Jaroszyński]

On Wednesday 12 of December 2007 15:20:19 Ciaran McCreesh wrote:
> The .ebuild-eapi proposal didn't have this problem, but unfortunately it
> was rejected for political reasons...

I wasn't around then, but the requirment of actually sourcing the ebuild to 
read the EAPI value is extremely stupid indeed. Let's change it...

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI placement

[Doug Klima]

Ciaran McCreesh wrote:
> On Wed, 12 Dec 2007 09:20:02 -0500
> Doug Klima <cardoe@gentoo.org> wrote:
>   
>> 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.
>>     
>
> It's only unexpected if people screw up. If everyone understands the
> restrictions I posted and sticks to them then things work. If people
> start trying to be clever things go horribly wrong.
>
>   
>> 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.
>>     
>
> Or you need to get PMS and package managers retroactively updated to
> saying that 'inherit' does a 'declare -r EAPI'... Although that's only
> a good idea if you operate on the assumption that developers will screw
> up.
>
>   
That's the assumption I'm operating under because you and I both know if
repoman and friends don't prevent it, it will happen. We can have all
the docs in the world, but if we don't go about some steps to prevent
bad things from happening. They can and will.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI placement

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
> * Eclasses may not set EAPI.
>
> * Eclasses may not assume a particular EAPI.

I disagree here. It would be annoying and possibly even hindering in future 
not being able to use higher EAPI features in eclasses. Point is the eclass 
has to check, if the author of an ebuild sets another EAPI and throw an 
error, in this case.


The most basic issue, which we didn't even discuss yet, afaik, is how to make 
every developer aware which feature belongs to which EAPI. I freely admit, I 
do not know that. Is there a list somewhere? 

EAPI issues may lead to a lot of confusion and eclass bloat, especially since 
we still can't remove stale eclasses afaik.


Carsten

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI placement

[Santiago M. Mola]

On Dec 12, 2007 11:14 PM, Carsten Lohrke <carlo@gentoo.org> wrote:
> On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
> > * Eclasses may not set EAPI.
> >
> > * Eclasses may not assume a particular EAPI.
>
> I disagree here. It would be annoying and possibly even hindering in future
> not being able to use higher EAPI features in eclasses. Point is the eclass
> has to check, if the author of an ebuild sets another EAPI and throw an
> error, in this case.

Nobody said that eclasses can't use new features. Just that they
cannot _set_ EAPI or assume they are working with any EAPI. But an
eclass can check which EAPI is set in the environment (that's which
EAPI the ebuild set) and act accordingly, using features available on
that EAPI.

>
> The most basic issue, which we didn't even discuss yet, afaik, is how to make
> every developer aware which feature belongs to which EAPI. I freely admit, I
> do not know that. Is there a list somewhere?

EAPIs are defined in PMS [1] although I don't find an "officla" copy
at gentoo.org (only the one in dev.g.o/~spb).

>
> EAPI issues may lead to a lot of confusion and eclass bloat, especially since
> we still can't remove stale eclasses afaik.
>

Yep, that issue should be addresses as it is in paludis and pkgcore.

[1] http://www.gentoo.org/proj/en/qa/pms.xml

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

Re: [gentoo-dev] EAPI placement

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Wed, 12 Dec 2007 23:14:24 +0100
Carsten Lohrke <carlo@gentoo.org> wrote:
> I disagree here. It would be annoying and possibly even hindering in
> future not being able to use higher EAPI features in eclasses. Point
> is the eclass has to check, if the author of an ebuild sets another
> EAPI and throw an error, in this case.

There is no way for an eclass to throw an error. Nor, with the current
way Portage implements EAPI, is there a way to add such a way.

> The most basic issue, which we didn't even discuss yet, afaik, is how
> to make every developer aware which feature belongs to which EAPI. I
> freely admit, I do not know that. Is there a list somewhere? 

It's in PMS. svn co http://svn.repogirl.net/pms for a copy.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] EAPI placement

[Marius Mauch]

On Tue, 11 Dec 2007 20:00:51 -0500
Doug Klima <cardoe@gentoo.org> wrote:

> 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.

Which doesn't work at all. Simple example would be the introduction of
new phases, e.g. src_configure with EAPI=2:

foo.eclass:

EAPI=2

setup_env {
    # do some stuff that differs betwwen EAPI-1 and EAPI-2
}

src_configure {
    econf --some-special-eclass-option
}

bar.ebuild:

inherit foo

EAPI=1

setup_env 

# no src_* functions defined

Now should the package manager execute src_configure or not? And that's
assuming we actually track all values of EAPI and their origin as well
as the origin of all functions/variables in the current environment.
Or should setup_env be executed with EAPI=1 (as it's called in the
ebuild) or EAPI=2 (as it's defined in the eclass)? There are no real
answers to those problems.

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI placement

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

Ciaran McCreesh kirjoitti:
> On Wed, 12 Dec 2007 15:08:36 +0100
> "Santiago M. Mola" <coldwind@gentoo.org> wrote:
>> Would it be possible to have eclass/eapiBLAH/foo.eclass?
> 
> No. Not even with an EAPI change. This is one of the deficiencies in
> the way EAPI was designed -- an EAPI cannot change the behaviour of
> inherit, nor can it introduce new global-scope functions.
> 

Actually adding new global scope functions is possible with the help of
base/profile.bashrc . We can use that file to add stubs so that sourcing
the ebuild still works. The only restriction is that the new function
can't be used to evaluate the value of EAPI.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] EAPI placement

[Vlastimil Babka]

Ciaran McCreesh wrote:
> On Wed, 12 Dec 2007 23:14:24 +0100
> Carsten Lohrke <carlo@gentoo.org> wrote:
>> I disagree here. It would be annoying and possibly even hindering in
>> future not being able to use higher EAPI features in eclasses. Point
>> is the eclass has to check, if the author of an ebuild sets another
>> EAPI and throw an error, in this case.
> 
> There is no way for an eclass to throw an error. Nor, with the current
> way Portage implements EAPI, is there a way to add such a way.

How bout declaring all supported (possibly with later conditional checks
on EAPI variable etc) EAPIs in eclass via some variable, and repoman
checking that EAPI set in the ebuild is compatible with all inherited
eclasses? And if you need newer EAPI in the ebuild, get eclasses updated
first (even if its just updating the compatibility declaration).
Also, repoman could check that EAPI is not being set in the eclass.

VB
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI placement

[Marius Mauch]

On Sat, 15 Dec 2007 10:43:35 +0100
Vlastimil Babka <caster@gentoo.org> wrote:

> Ciaran McCreesh wrote:
> > On Wed, 12 Dec 2007 23:14:24 +0100
> > Carsten Lohrke <carlo@gentoo.org> wrote:
> >> I disagree here. It would be annoying and possibly even hindering
> >> in future not being able to use higher EAPI features in eclasses.
> >> Point is the eclass has to check, if the author of an ebuild sets
> >> another EAPI and throw an error, in this case.
> > 
> > There is no way for an eclass to throw an error. Nor, with the
> > current way Portage implements EAPI, is there a way to add such a
> > way.
> 
> How bout declaring all supported (possibly with later conditional
> checks on EAPI variable etc) EAPIs in eclass via some variable, and
> repoman checking that EAPI set in the ebuild is compatible with all
> inherited eclasses? And if you need newer EAPI in the ebuild, get
> eclasses updated first (even if its just updating the compatibility
> declaration). Also, repoman could check that EAPI is not being set in
> the eclass.

Nice idea, but gets quite complicated when multiple (possibly nested)
eclasses are involved as we'd have to generate a complete inheritance
graph and get that new variable separately for each eclass. Or
alternatively each eclass has to update the variable with the
intersection between the old value and it's own set of supported EAPIs.

And doesn't really solve the problem, just reduces the scope a fair bit
(e.g. if an eclass drops support for an EAPI version repoman will only
catch it gradually if the packages using it are bumped, unless you
manually check the whole tree).

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI placement

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Mittwoch, 12. Dezember 2007, Santiago M. Mola wrote:
> Nobody said that eclasses can't use new features. 

Using new features in ebuilds or eclasses relates. EAPI A using ebuild with 
EAPI B using eclass (but not defining any EAPI) is your hard nut. Shouldn't 
happen, but will. And bugs in eclasses unfortunately don't have a minor 
impact.

> Just that they 
> cannot _set_ EAPI or assume they are working with any EAPI.

And I say they can - under the condition that you have a defined subset of 
ebuilds belonging to that eclass.

> Yep, that issue should be addresses as it is in paludis and pkgcore.

Neither one is Gentoo's package manager Please spare me an answer. :)


Carsten

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] EAPI placement

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
> On Wed, 12 Dec 2007 23:14:24 +0100
> There is no way for an eclass to throw an error. Nor, with the current
> way Portage implements EAPI, is there a way to add such a way.

It's not perfect, but 

<eclass>_pkg_setup() {
 something_wrong && die 
}

should work reasonably well.


> It's in PMS. svn co http://svn.repogirl.net/pms for a copy.

Right. But when you think every dev will read the PMS to find out what's fine 
to do and what not for N++ EAPIs again and again, while he wants only a short 
list of do's and don'ts, your bathing temperature is far above average.

What I do think - and no, I won't read this rediculous large 
category/ebuild-x.y-rN-my.local.version-too-much-coffein-drinks.ebuild-epaiN-anyone-else-with-a-stupid-idea 
thread - is, that EPAI changes and there implications apparently have not 
been well thought out and the best we can do is to ensure there are as few 
eclass/ebuild-relating differing EAPIs as possible.


Carsten

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: EAPI placement

[Steve Long]

Carsten Lohrke wrote:
> On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
>> * Eclasses may not set EAPI.
>>
>> * Eclasses may not assume a particular EAPI.
> 
> I disagree here. It would be annoying and possibly even hindering in
> future not being able to use higher EAPI features in eclasses. Point is
> the eclass has to check, if the author of an ebuild sets another EAPI and
> throw an error, in this case.
>
Agreed. There's no problem from the bash side of this, only the PM specific
code.

> The most basic issue, which we didn't even discuss yet, afaik, is how to
> make every developer aware which feature belongs to which EAPI. I freely
> admit, I do not know that. Is there a list somewhere?
>
Well the official one is the internal Gentoo PMS repo. The Council haven't
changed the policy so far this term on what is the "authoritative" PMS.
(Nor of course have they accepted any of the drafts officially.)
 
> EAPI issues may lead to a lot of confusion and eclass bloat, especially
> since we still can't remove stale eclasses afaik.
>
Another maintenance headache, agreed.

Is it possible to remove an eclass if it can be shown that there are no apps
in the tree using it, say for over 2 years? That would give Gentoo
equivalence with longer-term "support" from other distros, while allowing
some breathing space wrt installed ebuilds. It'd be easy enough to automate
a hook to move deleted eclasses to local overlay as well.
 
> On Mittwoch, 12. Dezember 2007, Santiago M. Mola wrote:
>> Nobody said that eclasses can't use new features.
> 
> Using new features in ebuilds or eclasses relates. EAPI A using ebuild
> with EAPI B using eclass (but not defining any EAPI) is your hard nut.
> Shouldn't happen, but will. And bugs in eclasses unfortunately don't have
> a minor impact.
>
>> Just that they
>> cannot _set_ EAPI or assume they are working with any EAPI.
>
> And I say they can - under the condition that you have a defined subset of 
> ebuilds belonging to that eclass.

And it's a major loss of flexibility in addition to the maintenance problems
you highlight. A dynamic EAPI declaration in an ebuild is foolish, but
testing the EAPI value in an eclass and taking alternative action, or
indeed allowing dynamic setting in that context (which would require
additional metadata-- in this case i think the overhead is worth it, given
that eclasses are much less numerous than ebuilds, and it's actually
*adding* to what we can do already) makes a lot more sense.

<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

So there's no technical reason not to to, apart from some concern about
signalling die()?

<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

Ouch. Well at least EAPI anything is still experimental atm. Thank heavens
for peer review :D


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: EAPI placement

[Duncan]

Steve Long <slong@rathaus.eclipse.co.uk> posted
fknh2s$59n$1@ger.gmane.org, excerpted below, on  Mon, 24 Dec 2007 05:51:34
+0000:

>> The most basic issue, which we didn't even discuss yet, afaik, is how
>> to make every developer aware which feature belongs to which EAPI. I
>> freely admit, I do not know that. Is there a list somewhere?
>>
> Well the official one is the internal Gentoo PMS repo. The Council
> haven't changed the policy so far this term on what is the
> "authoritative" PMS. (Nor of course have they accepted any of the drafts
> officially.)

The problem right now is that while you are correct, that's the official 
list, due to technical/political issues, the Gentoo-official PMS repo 
doesn't (or didn't as of the last council meeting, according to the log) 
have any EAPI-1 info at all, as it's currently outdated, with the work 
all going into the off-Gentoo repo.  (Apparently, there aren't any 
official Gentoo devs working on PMS ATM. =8^(  Did I mention political 
issues in addition to technical ones?)

Thus, one can get detailed but unofficial specs from the informal non-
Gentoo repo, or a general summary as in the new-version portage 
announcement mentioning EAPI-1 support, now, or look at the code of the 
various PMs. =8^(

>> EAPI issues may lead to a lot of confusion and eclass bloat, especially
>> since we still can't remove stale eclasses afaik.
>>
> Another maintenance headache, agreed.
> 
> Is it possible to remove an eclass if it can be shown that there are no
> apps in the tree using it, say for over 2 years? That would give Gentoo
> equivalence with longer-term "support" from other distros, while
> allowing some breathing space wrt installed ebuilds. It'd be easy enough
> to automate a hook to move deleted eclasses to local overlay as well.

Well... according to the portage devs (as posted on the portage devel 
list) newer portage now stores the complete build environment, including 
the state of all inherited eclasses at the time of the original merge, 
and uses them at unmerge if at all possible.  If the merge was from an 
older version before this info was stored, or if the package database is 
corrupted and thus is otherwise missing the complete eclass info, portage 
can and does still pull from the live tree.

Thus, in theory, a year or so after the first version with that 
functionality working goes/went stable (I don't track stable status as 
I'm on ~arch, so I've no idea if it's stable yet or not, or for that 
matter which version first qualified), it should then be possible to 
start removing old/stale eclasses, keeping in mind that even after they 
are removed, if someone /really/ needs them, they can still fetch them 
out of the source control system attic.

So in any case, it should be possible <2 years from now; just not yet.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] PMS location (Was: Re: EAPI placement)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

On Mon, 24 Dec 2007 08:27:39 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> The problem right now is that while you are correct, that's the
> official list, due to technical/political issues, the Gentoo-official
> PMS repo doesn't (or didn't as of the last council meeting, according
> to the log) have any EAPI-1 info at all, as it's currently outdated,
> with the work all going into the off-Gentoo repo.

No no. The 'Gentoo-official' repo doesn't have any EAPI-1 info at all
because whoever's supposed to have set up the 'Gentoo-official' repo
hasn't bothered to tell any of the people doing the committing a) where
the repo is or how to commit to it, b) what the technical reasons for
moving away from the current repo are or c) who all has root on the box
upon which the repo is hosted. Even if any of the PMS contributors
*wanted* to commit to an official Gentoo repository, they couldn't
because neither the Council nor whoever did the setting up have
bothered to tell them about it.

> (Apparently, there aren't any official Gentoo devs working on PMS
> ATM. =8^(  Did I mention political issues in addition to technical
> ones?)

So far as I'm aware, spb is still technically an official Gentoo
developer.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: PMS location (Was: Re: EAPI placement)

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071224083819.003f0d26@blueyonder.co.uk, excerpted below, on  Mon, 24 Dec
2007 08:38:19 +0000:

> Even if any of the PMS contributors *wanted* to commit to an official
> Gentoo repository, they couldn't because neither the Council nor
> whoever did the setting up have bothered to tell them about it.

That would appear to be part of the technical issues side.  As I 
understood the last council log discussion, the eventual idea is to 
handle it similar to what's being done with Roy's RC or whatever it ends 
up being called (formerly baselayout, proposed OpenRC shot down due to 
preexisting trademark rights belonging to someone else), but infra hasn't 
gotten the full thing setup yet, proper permissions and secure access and 
all that.  Apparently, at present, pretty much the only one with access 
is the one who actually did the port, and he's hasn't done much with it 
since.

Thanks for correcting the "no Gentoo people working on it" thing tho.  I 
couldn't understand quite /no/, tho it might be only one, SPB.

FWIW, I intended to post this link earlier but forgot to include it (tho 
I did mention it was in the last council meeting log so those interested 
knew what to look for, at least).  The PMS discussion was last, the only 
thing in Open Floor, which started at logged time 21:51 on line 311:

http://www.gentoo.org/proj/en/council/meeting-logs/20071213.txt

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: PMS location (Was: Re: EAPI placement)

[Roy Marples]

On Mon, 2007-12-24 at 21:39 +0000, Duncan wrote:
> Apparently, at present, pretty much the only one with access 
> is the one who actually did the port, and he's hasn't done much with it 
> since.

I beg to differ - I've down an awful lot with the code.
It now installs and works cleanly on a vanilla FreeBSD.
man pages have been written for every userland tool and library function
it provides.
Init scripts now support a "template" system, based on Free/Net BSDs RC.
Lots of Gentoo reported bugs have been fixed.

Infact, the last of the planned changes have now been comitted to my
local repo and I'll be itching to make a release soon into the New Year.

Granted I'm waiting on Gentoo Infra to host it (the git repo) because
that is what we agreed. However I'm probably going to end up going with
someone else, or hosting myself, because it's now coming up to 2 months
and nothings ready yet. Heck, my retirement bug [1] is still pending and
I currently have full access to all my accounts on various boxes. So
either I'm a very trustable guy that you really don't want to retire
(tough, I have) or some people are slacking.

[1] http://bugs.gentoo.org/show_bug.cgi?id=199318

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Roy's retirement (Was: PMS location)

[Duncan]

Roy Marples <roy@marples.name> posted
1198537244.2806.13.camel@uberpc.marples.name, excerpted below, on  Mon, 24
Dec 2007 23:00:44 +0000:

> On Mon, 2007-12-24 at 21:39 +0000, Duncan wrote:
>> Apparently, at present, pretty much the only one with access is the one
>> who actually did the port, and he's hasn't done much with it since.
> 
> I beg to differ - I've down an awful lot with the code.

I guess I was a bit ambiguous as I had mentioned your project in passing, 
but that remark as quoted was intended to apply to the Gentoo PMS repo, 
not your RC project (which I know has seen progress as I've been 
following the blog).

Sorry for the confusion.

> Granted I'm waiting on Gentoo Infra to host it (the git repo) because
> that is what we agreed. However I'm probably going to end up going with
> someone else, or hosting myself, because it's now coming up to 2 months
> and nothings ready yet. 

... So the remark, while intended for the Gentoo PMS repo, would seem to 
apply to the Gentoo repo for your project as well...  Not to be hard on 
infra here, just reality, which must be dealt with.

> Heck, my retirement bug [1] is still pending and
> I currently have full access to all my accounts on various boxes. So
> either I'm a very trustable guy that you really don't want to retire
> (tough, I have) or some people are slacking.

>From all the discussion I've seen, you /are/ trusted.  The arrangement 
they are working on for you is the first of its kind (probably one reason 
it's taking the time it is), and I don't think something they'd have 
considered for just anyone.  (If you note, the PMS repo thing, which they 
are treating similar, is documentation, not code, certainly not code that 
has been and will continue to be at the core of very close to every 
Gentoo box out there.)

> [1] http://bugs.gentoo.org/show_bug.cgi?id=199318

I expect that's showing in the "lack of haste" in closing the retirement 
bug as well. You are still trusted and your code will continue to be at 
the center of Gentoo for the foreseeable future, so regardless of dev 
access or not you could still screw Gentoo over if that was your intent, 
and given that, well, there are just more pressing matters to attend to.

That said, while flattered, I'd be bugged about it too if it were me.  I 
know I'm sermonizing the choir here but crackers love stale but still 
active accounts, and it remains your name on the line, so yeah, there's 
reason for concern.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: PMS location (Was: Re: EAPI placement)

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]

On Mon, Dec 24, 2007 at 11:00:44PM +0000, Roy Marples wrote:
> On Mon, 2007-12-24 at 21:39 +0000, Duncan wrote:
> > Apparently, at present, pretty much the only one with access 
> > is the one who actually did the port, and he's hasn't done much with it 
> > since.
> 
> I beg to differ - I've down an awful lot with the code.
> It now installs and works cleanly on a vanilla FreeBSD.
> man pages have been written for every userland tool and library function
> it provides.
> Init scripts now support a "template" system, based on Free/Net BSDs RC.
> Lots of Gentoo reported bugs have been fixed.
> 
> Infact, the last of the planned changes have now been comitted to my
> local repo and I'll be itching to make a release soon into the New Year.
> 
> Granted I'm waiting on Gentoo Infra to host it (the git repo) because
> that is what we agreed. However I'm probably going to end up going with
> someone else, or hosting myself, because it's now coming up to 2 months
> and nothings ready yet. Heck, my retirement bug [1] is still pending and
> I currently have full access to all my accounts on various boxes. So
> either I'm a very trustable guy that you really don't want to retire
> (tough, I have) or some people are slacking.
> [1] http://bugs.gentoo.org/show_bug.cgi?id=199318
We're getting there.

Infra moves a bit slowly at times, because it's not all we do.
On the retirement side, I was holding off doing them, to get a larger
batch, that had their 1 month of notice today, if you search for bugs
with 'infra-retire' in the whiteboard right now, you'll find them until
I've got them completed.

The CVS stuff should have been locked out already, not sure how you
tested that.

The Git stuff is coming very shortly (probably as a Christmas gift from
infra tmrw), I've spent the last week or so on it. (I think the upstream
gitosis author is going to kill me, but meh, it had to be done to make
it work for Gentoo).

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]

Re: [gentoo-dev] Re: PMS location (Was: Re: EAPI placement)

[Roy Marples]

On Mon, 2007-12-24 at 19:52 -0800, Robin H. Johnson wrote:
> The CVS stuff should have been locked out already, not sure how you
> tested that.

I didn't.
I assumed that as I had access to d.g.o, I had CVS access too.
My bad.

> The Git stuff is coming very shortly (probably as a Christmas gift from
> infra tmrw), I've spent the last week or so on it. (I think the upstream
> gitosis author is going to kill me, but meh, it had to be done to make
> it work for Gentoo).

Great!

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list