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 a
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
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 y
Chris Gianelloni kirjoitti:
> 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 t
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 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 s
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
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
> f
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 ru
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 pat
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.
>
> Regar
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
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 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 b
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
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
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
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
>>
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.
--
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. Handlin
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
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 starts. Attached a patch f
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 s
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
=
24 matches
Mail list logo
