FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-12-2007, 01:20 PM
Ciaran McCreesh
 
Default EAPI placement

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
 
Old 12-12-2007, 01:22 PM
Doug Klima
 
Default EAPI placement

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
 
Old 12-12-2007, 01:27 PM
Ciaran McCreesh
 
Default EAPI placement

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
 
Old 12-12-2007, 01:37 PM
Ciaran McCreesh
 
Default EAPI placement

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
 
Old 12-12-2007, 02:14 PM
Piotr Jaroszyński
 
Default EAPI placement

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
 
Old 12-12-2007, 02:23 PM
Doug Klima
 
Default EAPI placement

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
 
Old 12-12-2007, 09:14 PM
Carsten Lohrke
 
Default EAPI placement

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
 
Old 12-12-2007, 09:37 PM
"Santiago M. Mola"
 
Default EAPI placement

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
 
Old 12-12-2007, 09:50 PM
Ciaran McCreesh
 
Default EAPI placement

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
 
Old 12-13-2007, 01:43 AM
Marius Mauch
 
Default EAPI placement

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
 

Thread Tools




All times are GMT. The time now is 01:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org