On Sun, 2007-11-11 at 21:01 +0200, Petteri Räty wrote:
I plan to make the java eclasses use the EAPI 1
Any chance we can *at least* wait until we have a release out the door
that has a portage version which supports these features *before* we
start trying to use them in the tree? Our general
On Tue, 13 Nov 2007 12:22:03 -0800
Chris Gianelloni [EMAIL PROTECTED] wrote:
Any chance we can *at least* wait until we have a release out the door
that has a portage version which supports these features *before* we
start trying to use them in the tree? Our general rule was to not use
On Tue, 2007-11-13 at 20:31 +, Ciaran McCreesh wrote:
That was only the case because previously, using new features that
Portage didn't support would cause horrible breakage. Now, instead, the
ebuilds show up as being masked.
...which is just as good as broken when it happens to a new user
On Tue, 13 Nov 2007 16:17:59 -0800
Chris Gianelloni [EMAIL PROTECTED] wrote:
On Tue, 2007-11-13 at 20:31 +, Ciaran McCreesh wrote:
That was only the case because previously, using new features that
Portage didn't support would cause horrible breakage. Now, instead,
the ebuilds show up
On Wed, 14 Nov 2007 00:39:50 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
Read it (and my explanation of it earlier in the thread) until you
understand it. There is nothing consistent in what I'm saying.
...bleh. *in*consistent.
NNeee oe...
--
On Wed, 2007-11-14 at 00:39 +, Ciaran McCreesh wrote:
Umm... So in the paragraph above, you say an EAPI-specific eclass
isn't a good idea, and here you push it as the proposed solution.
Huh? Consistency, please...
Read it (and my explanation of it earlier in the thread) until you
On Tue, 13 Nov 2007 17:25:44 -0800
Chris Gianelloni [EMAIL PROTECTED] wrote:
EAPI *can't* be set in an eclass correctly anyway because EAPI is
allowed to (and likely will in the future) change the behaviour of
inherit.
...and this proves my point. Rather than simply stating this, you
Ciaran McCreesh wrote:
...which is just as good as broken when it happens to a new user
first installing Gentoo and wondering why he can't even follow the
directions in the Handbook.
...so you just ensure that the handbook tells the user to upgrade the
package manager as quickly as
Petteri Räty kirjoitti:
Usually it's best that ebuild variables follow the order that is in
skel.ebuild. So know we should decide where to place EAPI. I suggest we
put it it after LICENSE as that's where the more technical stuff like
SLOT starts. Attached a patch for skel.ebuild.
Regards,
Petteri Räty kirjoitti:
Petteri Räty kirjoitti:
Usually it's best that ebuild variables follow the order that is in
skel.ebuild. So know we should decide where to place EAPI. I suggest we
put it it after LICENSE as that's where the more technical stuff like
SLOT starts. Attached a patch for
Fabian Groffen kirjoitti:
On 09-11-2007 23:55:51 +0200, Petteri Räty wrote:
Usually it's best that ebuild variables follow the order that is in
skel.ebuild. So know we should decide where to place EAPI. I suggest we
put it it after LICENSE as that's where the more technical stuff like
SLOT
On Sun, 11 Nov 2007 21:01:41 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
If we go with this solution then I guess eclasses must check for the
EAPI variable and then act accordingly. For example if the ebuild sets
EAPI=2 and the eclass is designed for EAPI=1 then it could be made to
die in case
Ciaran McCreesh kirjoitti:
On Sun, 11 Nov 2007 21:01:41 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
If we go with this solution then I guess eclasses must check for the
EAPI variable and then act accordingly. For example if the ebuild sets
EAPI=2 and the eclass is designed for EAPI=1 then it
On Sun, 11 Nov 2007 21:21:30 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
Neither EAPI 0 nor EAPI 1 provide any mechanism for an ebuild to
'die' at global scope. There's simply no way for eclasses to
complain that they're being misused.
Well nothing formal but the ebuild developer should
On 11-11-2007 19:27:50 +, Ciaran McCreesh wrote:
On Sun, 11 Nov 2007 21:21:30 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
Neither EAPI 0 nor EAPI 1 provide any mechanism for an ebuild to
'die' at global scope. There's simply no way for eclasses to
complain that they're being
On Sun, 11 Nov 2007 21:50:05 +0100
Fabian Groffen [EMAIL PROTECTED] wrote:
In this setting, one could say that eclasses should remain EAPI=0,
such that all ebuilds will be able to work with them.
Mm. Slight problem with wording here, which is causing confusion.
Eclasses don't have an EAPI.
On Sonntag, 11. November 2007, Ciaran McCreesh wrote:
I suspect that for existing eclasses, the safest way to proceed is to
make a new eclass and move common code into a third eclass. So you'd
have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common,
and foo-eapi1.eclass doing
Usually it's best that ebuild variables follow the order that is in
skel.ebuild. So know we should decide where to place EAPI. I suggest we
put it it after LICENSE as that's where the more technical stuff like
SLOT starts. Attached a patch for skel.ebuild.
Regards,
Petteri
Index: skel.ebuild
On Fri, 09 Nov 2007 23:55:51 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
Usually it's best that ebuild variables follow the order that is in
skel.ebuild. So know we should decide where to place EAPI. I suggest
we put it it after LICENSE as that's where the more technical stuff
like SLOT
Ciaran McCreesh kirjoitti:
On Fri, 09 Nov 2007 23:55:51 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
Usually it's best that ebuild variables follow the order that is in
skel.ebuild. So know we should decide where to place EAPI. I suggest
we put it it after LICENSE as that's where the more
On Freitag, 9. November 2007, Petteri Räty wrote:
What if I want to use EAPI=1 features in an eclass? So if we for example
we have an ebuild using EAPI=2 and then it inherits and eclass that sets
EAPI=1 for slot deps.
You check which EAPI the ebuild sets, then either continue or die. Handling
On Sat, 10 Nov 2007 01:39:18 +0100
Carsten Lohrke [EMAIL PROTECTED] wrote:
Handling depends a bit upon, if EAPI should always be downwards
compatible.
It won't be. It's likely that future EAPIs will introduce new
strictness requirements and remove certain legacy variables and
utilities.
--
22 matches
Mail list logo
