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
}
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 ebuild
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 higher EAPI
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
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
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 EAPI.
* If an
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
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
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
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 work with multiple
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 to
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
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 unexpected if
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
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 being able to
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 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 be
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
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
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
20 matches
Mail list logo
