On Fri, Oct 10, 2008 at 5:41 AM, Duncan <[EMAIL PROTECTED]> wrote:
> "Alec Warner" <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted
> below, on Fri, 10 Oct 2008 00:17:14 -0700:
>
>> Consider this your first and last warning from Userrel.
>
> FWIW... at least on gmane, that appears as a re
"Alec Warner" <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted
below, on Fri, 10 Oct 2008 00:17:14 -0700:
> Consider this your first and last warning from Userrel.
FWIW... at least on gmane, that appears as a response to aballier (gentoo
dev), with references headers indicating the same
first and last warning from Userrel.
-Alec
[0] Subject: Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
[1] http://www.gentoo.org/proj/en/council/coc.xml
> I don't quite see how that deals with an eclass calling econf in its
> exported src_compile? Seems like EAPI versioning for eclasses (with
> implicit 0 only) is more what you're after for that issue (so the PM
> could suppress src_configure if src_compile is going to resolve to an
> EAPI-0 eclas
On Tue, Oct 07, 2008 at 05:07:21PM +0100, Steve Long wrote:
> Ciaran McCreesh wrote:
>
> > On Sun, 5 Oct 2008 17:38:11 +0200
> > Ulrich Mueller <[EMAIL PROTECTED]> wrote:
> >> > By the way, do we really want to special case eapi-2 in every
> >> > eclass ? That's lot of code duplication and will ge
Ciaran McCreesh wrote:
> On Sun, 5 Oct 2008 17:38:11 +0200
> Ulrich Mueller <[EMAIL PROTECTED]> wrote:
>> > By the way, do we really want to special case eapi-2 in every
>> > eclass ? That's lot of code duplication and will get even worse
>> > when we'll reach eapi-42. That would have been cool to
On Tue, 07 Oct 2008 17:07:21 +0100
Steve Long <[EMAIL PROTECTED]> wrote:
> > It's illegal, according to PMS. It also won't work with Paludis,
> > since phase function definitions aren't made available until just
> > before that phase executes (there is a reason for this -- it
> > provides us with a
Alexis Ballier wrote:
> Indeed; different names could be given to different implementations of
> the same thing, but that might completely kill the point of abstracting
> it.
> Maybe eclasses should die on unknown eapi; the fact is I really hate the
> current way it's done when switching an ebuild
