From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-48246-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1RF3fm-0004uR-A1
for garchives@archives.gentoo.org; Sat, 15 Oct 2011 12:49:06 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id DC2CA21C0CF;
Sat, 15 Oct 2011 12:48:56 +0000 (UTC)
Received: from mail-gy0-f181.google.com (mail-gy0-f181.google.com [209.85.160.181])
by pigeon.gentoo.org (Postfix) with ESMTP id 3700121C063
for <gentoo-dev@lists.gentoo.org>; Sat, 15 Oct 2011 12:48:26 +0000 (UTC)
Received: by gye5 with SMTP id 5so2496790gye.40
for <gentoo-dev@lists.gentoo.org>; Sat, 15 Oct 2011 05:48:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=mime-version:reply-to:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:content-type
:content-transfer-encoding;
bh=B07w4D0PIH8UkfQ+ipvkxH/bIq0XnJ+9rSOpf8NER/c=;
b=sqXNcMzbDUvRllzL/hYKjaGu9Iu5Mw/IzWiFb8RqSvh2ZeDoVhPnN7jIuR6We0vpC2
KscP4L810+U1qO/klbZn6S1R7yOVUEVxLCfRh1XzkXhnMtVGnSeMJkJw94LvUcgT7Wwq
6R3T5xSzCONBKGvgdae7jSYZS43muIoaJKRq4=
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.68.20.135 with SMTP id n7mr23612173pbe.125.1318682906182; Sat,
15 Oct 2011 05:48:26 -0700 (PDT)
Sender: neurogeekster@gmail.com
Received: by 10.68.52.169 with HTTP; Sat, 15 Oct 2011 05:48:25 -0700 (PDT)
In-Reply-To: <4E98E7B8.7000102@gentoo.org>
References: <4E8766F1.2020609@gentoo.org>
<CAEdQ38HexzFJVfou2Q0ikQqQHd++MNaOkoPHRdiuY-X0GP0C3A@mail.gmail.com>
<20111014193958.GA3465@localhost>
<4E98A793.8050806@gentoo.org>
<4E98B88F.3010206@gentoo.org>
<4E98BCD9.5060204@gentoo.org>
<CAAr7Pr91dHR-9xnoR81CyJB7wUxUOQH05k2yXNqTvmWz=ByeAw@mail.gmail.com>
<4E98DDA4.60002@gentoo.org>
<4E98E7B8.7000102@gentoo.org>
Date: Sat, 15 Oct 2011 08:48:25 -0400
X-Google-Sender-Auth: sNdZ8wApsiZcPIqCf7J07SiDgkw
Message-ID: <CAD3zpDmpDfdnEJJeM8_0X7Z9H1WC1Ku2GwbRY7aSZAH_Zdw9hg@mail.gmail.com>
Subject: Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
From: "Jesus Rivero (Neurogeek)" <neurogeek@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt:
X-Archives-Hash: 43f44e59558ab6864298888a2f1c4cac
On Fri, Oct 14, 2011 at 9:54 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> On 10/14/2011 09:11 PM, "Pawe=C5=82 Hajdan, Jr." wrote:
>> On 10/14/11 5:38 PM, Alec Warner wrote:
>>> I believe op's point is that there is no one to escalate the problem
>>> to; certainly the council members are not going to do the work
>>> themselves and we already have our best people on it.
>>
>> I'm aware of that. My point is that I think there are many scenarios in
>> which EAPI-4 + python.eclass can work, especially if it's used only for
>> few things in cases like www-client/chromium
>>
>> Because the python team takes _ages_ to do the transition that is
>> holding back many other packages, because they've made python.eclass
>> overly complex and now try to make it perfect,
>>
>> I'd just like to get an "OK" to enable EAPI-4 for that eclass.
>>
>> Please note that it's still up to dependent packages which EAPI they
>> use. If they break python.eclass with EAPI-4 they shouldn't update to
>> that EAPI. However, if there are packages using python.eclass that could
>> work fine with EAPI-4, it shouldn't be blocking them for *ages*
>>
>
> That would be an ok approach from my perspective: We could just change
> line 14 of python.eclass and let package maintainers report breakage as
> they increment EAPI. I am confident that nothing EAPI <=3D 3 would break.
>
> Is anyone (especially djc and the python herd members) opposed to this?
>
>
Sorry I wasn't able to post before. But...
This can be done and in fact has been discussed before, just allow
ebuild to not die with EAPI=3D4, but this doesn do anything at all, just
not die on EAPI=3D4. All the features and the good stuff just won't be
there as other use cases need (as Robin and Tony mentioned).
We've been working on a redesign of the eclass but is nothing like
stealing candy from a kid, there are many things involved, such as the
large amount of Python ABIs that people use regularly, distutils
quirks, current eclass complexity, among others that make it quite
challenging to come up with something new.
I'm all up for making eclass accept EAPI=3D4 ebuilds, but to fully
implement EAPI=3D4 fesatures, I'm going to have to ask you guys for a
bit of more patience. I know you have done just that, being patient,
but just a bit more. I know we can deliver a solution for this soon
enough.
Best regards,
--=20
Jesus Rivero (Neurogeek)
Gentoo Developer