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
_pkg_setup() {
something_wrong && die
}
s
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 eclas
On Sat, 15 Dec 2007 10:43:35 +0100
Vlastimil Babka <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 12 Dec 2007 23:14:24 +0100
> > Carsten Lohrke <[EMAIL PROTECTED]> wrote:
> >> I disagree here. It would be annoying and possibly even hindering
> >> in future not being able to use hi
Ciaran McCreesh wrote:
> On Wed, 12 Dec 2007 23:14:24 +0100
> Carsten Lohrke <[EMAIL PROTECTED]> 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
Ciaran McCreesh kirjoitti:
> On Wed, 12 Dec 2007 15:08:36 +0100
> "Santiago M. Mola" <[EMAIL PROTECTED]> 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
On Tue, 11 Dec 2007 20:00:51 -0500
Doug Klima <[EMAIL PROTECTED]> 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
On Wed, 12 Dec 2007 23:14:24 +0100
Carsten Lohrke <[EMAIL PROTECTED]> 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
On Dec 12, 2007 11:14 PM, Carsten Lohrke <[EMAIL PROTECTED]> 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 be
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 ch
Ciaran McCreesh wrote:
> On Wed, 12 Dec 2007 09:20:02 -0500
> Doug Klima <[EMAIL PROTECTED]> 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 u
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 i
On Wed, 12 Dec 2007 09:22:41 -0500
Doug Klima <[EMAIL PROTECTED]> 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
On Wed, 12 Dec 2007 09:20:02 -0500
Doug Klima <[EMAIL PROTECTED]> 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 unde
Ciaran McCreesh wrote:
> On Tue, 11 Dec 2007 16:59:28 -0500
> Doug Klima <[EMAIL PROTECTED]> 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 wo
On Wed, 12 Dec 2007 15:08:36 +0100
"Santiago M. Mola" <[EMAIL PROTECTED]> 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 i
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
On Dec 12, 2007 1:21 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
> On Tue, 11 Dec 2007 16:59:28 -0500
> Doug Klima <[EMAIL PROTECTED]> wrote:
> > discuss.
>
> * EAPI may only be set before the 'inherit' in an ebuild.
>
> * Eclasses may not set EAPI.
>
> * Eclasses may not assume a particular EAP
On Tue, 11 Dec 2007 16:59:28 -0500
Doug Klima <[EMAIL PROTECTED]> 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
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
signature.asc
Description: OpenPGP digital signature
Marius Mauch wrote:
On Tue, 11 Dec 2007 16:59:28 -0500
Doug Klima <[EMAIL PROTECTED]> 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 con
On Tue, 11 Dec 2007 16:59:28 -0500
Doug Klima <[EMAIL PROTECTED]> 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
Since it doesn't appear the question was answered by the last thread.
I'm starting a new thread.
did we decide where EAPI goes in an ebuild?
yes, just above the inherit
that's the safest and simplest thing to do, anyway
zmedico: what if I have EAPI=2 above the inherit but an eclass
has EAPI=1
22 matches
Mail list logo
