From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-67260-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id B3F36138A2F
for <garchives@archives.gentoo.org>; Sat, 16 Aug 2014 23:01:19 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 543A9E0967;
Sat, 16 Aug 2014 23:01:13 +0000 (UTC)
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 5AE06E0955
for <gentoo-dev@lists.gentoo.org>; Sat, 16 Aug 2014 23:01:12 +0000 (UTC)
Received: by mail-oi0-f54.google.com with SMTP id i138so2657861oig.27
for <gentoo-dev@lists.gentoo.org>; Sat, 16 Aug 2014 16:01:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=sender:date:from:to:subject:message-id:mail-followup-to:references
:mime-version:content-type:content-disposition:in-reply-to
:user-agent;
bh=Ggo8B1GDzdnNkuGQvfV3fg6tq0ZujUu1dfzZ2q/dPNI=;
b=czJAep3IiV7Mx08qjcWmb/GJGFaZu6DN3HhQ8pZK2QSf79GFGEvy0Gq4j8OUIkK5Zr
wOlOe6gN9+aotA3NF3HAEgvRe2X6zveamIGB0gMdHsxQooVSnaoblnhJCvAf29h0zqPR
9D9xrrPyGCczev7g78Iz6XhBdRXUC7PBIdz6s860GYpbtrhrK4BBEN3BU1Yxi9ZrCiXh
TU1/gavjhDTGX6h7YSHZ4189BxI38xxR98BOz/T/0pAY+b9wLoB5CWC/3/6XJCXotvcw
7pYpp4hACBQhj5IKExiN/RxFY0yKDJ7iVxffJaEJHTWrpjhpqiYXds2WiJaJIjB5s1xV
+NsQ==
X-Received: by 10.182.79.65 with SMTP id h1mr28461094obx.53.1408230071514;
Sat, 16 Aug 2014 16:01:11 -0700 (PDT)
Received: from linux1 (cpe-76-187-91-128.tx.res.rr.com. [76.187.91.128])
by mx.google.com with ESMTPSA id pa1sm13328760obb.1.2014.08.16.16.01.09
for <gentoo-dev@lists.gentoo.org>
(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
Sat, 16 Aug 2014 16:01:10 -0700 (PDT)
Sender: William Hubbs <w.d.hubbs@gmail.com>
Received: (nullmailer pid 11245 invoked by uid 1000);
Sat, 16 Aug 2014 23:01:08 -0000
Date: Sat, 16 Aug 2014 18:01:08 -0500
From: William Hubbs <williamh@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Message-ID: <20140816230108.GA11181@linux1>
Mail-Followup-To: gentoo-dev@lists.gentoo.org
References: <20140816215428.GA6773@linux1>
<CAATnKFB4E3UrQgeRvi5h0N0tXkhUT8mR3Yk56t2hiy9afojqCQ@mail.gmail.com>
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
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt"
Content-Disposition: inline
In-Reply-To: <CAATnKFB4E3UrQgeRvi5h0N0tXkhUT8mR3Yk56t2hiy9afojqCQ@mail.gmail.com>
User-Agent: Mutt/1.5.22 (2013-10-16)
X-Archives-Salt: 79b8f907-70e6-4708-92f5-fd4c2a3a77bf
X-Archives-Hash: 0291e050b9378a799623952d4aac9205
--pf9I7BMVVzbSWLtt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Aug 17, 2014 at 10:32:14AM +1200, Kent Fredric wrote:
> On 17 August 2014 09:54, William Hubbs <williamh@gentoo.org> wrote:
> > My counter proposal to this is that we stop calling eclass phase
> > functions automatically, and to minimize the amount of boilerplating
> > we would have to do, we use a variable, such as ECLASS_PHASES which
> > would be defined at the ebuild level and contain a list of the eclass
> > phase functions we want to run automatically.
>
> This proposal, seems reasonable, given my comments. I anticipate however
> its biggest downside would be
> the requirement to state *all* the functions you want, which would lead to
> maintenance headaches
> due to people forgetting to declare they wanted some function or other.
>=20
> So if you could sculpt it to be broader by default and have less scope for
> developer error, that'd be an improvement.
>=20
> --- code start --
> ECLASS_EXCLUDE=3D"foo_src_unpack bar_src_unpack"
> inherit foo bar baz
>=20
>=20
> --- code end ---
>=20
> here, src_unpack would be baz_src_unpack *regardless* of composition order
> because "foo" and "bar" were barred from being used, and baz took
> precedence as a result.
>=20
> If baz provides no src_unpack, then the ebuild in question is simply left
> without one.
My concern about reverse logic like excludes is this:
-- code start --
# foo and bas provide src_unpack, but you don't want the PMS default
# src_unpack to run them, and bar does not provide src_unpack:
# You want the rest of the PMS default src_unpack actions to run, so you
# don't write src_unpack.
ECLASS_EXCLUDE=3D"foo_src_unpack bas_src_unpack"
inherit foo bar bas
-- code stop --
This works fine until the eclass maintainer for bar.eclass decides to
add bar_src_unpack.
As soon as that happens, your ebuild is broken.
William
--pf9I7BMVVzbSWLtt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlPv4rQACgkQblQW9DDEZTg9RACglIBGN6mYY6dMUg4Dh0yskksI
XAwAnA8bNnwORCNVlXAcB2DMQ3wCOmEE
=88qX
-----END PGP SIGNATURE-----
--pf9I7BMVVzbSWLtt--