From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D787B13877A for ; Sat, 16 Aug 2014 21:54:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5E472E0918; Sat, 16 Aug 2014 21:54:33 +0000 (UTC) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 84C3DE090A for ; Sat, 16 Aug 2014 21:54:32 +0000 (UTC) Received: by mail-oi0-f41.google.com with SMTP id a141so2599471oig.14 for ; Sat, 16 Aug 2014 14:54:31 -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 :mime-version:content-type:content-disposition:user-agent; bh=cR3xquCGpoRF2OemEL3/FgRqqzWzRYeSwPLbSrCnsaU=; b=qSyjoRIlxEC+80+goMzFRywX7nE7ERD2jbEdUBg3OR7Hkis325Qt1XyDv7PI8si567 lff30vxYofFQfEt6TMwpWlYwd8KGpXEAsGWhKA611S3781+WtFJ4zqwo0MsjbUR2uYE5 B14bMTCR1fqrSj/sf8lue0CqLlvOdK1LdP7tfupzkqRJQ8zUDYN1N/FAHYML+HRzlHxQ z9mk/C8U/xkG0SILZ5yJ5Ty7pX2Nbha/WJcBQpIeHb9p4mocn89uKpqoneaWSqlKs5sc N1J5d3Lwz6PKL+a3mUkUV2dPXd6pQetYt6H5KQvAk2qH2yB6qan6Qjq3P9NTJZvzByWy aS/A== X-Received: by 10.182.51.229 with SMTP id n5mr28183946obo.47.1408226071756; Sat, 16 Aug 2014 14:54:31 -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 uq2sm13174681obc.9.2014.08.16.14.54.29 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 16 Aug 2014 14:54:30 -0700 (PDT) Sender: William Hubbs Received: (nullmailer pid 6965 invoked by uid 1000); Sat, 16 Aug 2014 21:54:28 -0000 Date: Sat, 16 Aug 2014 16:54:28 -0500 From: William Hubbs To: gentoo development Subject: [gentoo-dev] rfc: calling all eclass phase functions by default Message-ID: <20140816215428.GA6773@linux1> Mail-Followup-To: gentoo development Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-Archives-Salt: d93afb76-f8c3-4c19-bd16-479867b4954f X-Archives-Hash: 9dcaa406cc49f78743b9209f6c26adf1 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline All, there is an ongoing discussion about how we handle eclass phase functions by default [1]. Currently, EXPORT_FUNCTIONS is called in eclasses, and because of the way this works, the phase function that is exported last in the chain of inherited eclasses is the one that is called for a given phase, overriding the PMS default phase function. The initial proposal is to change this behaviour so that the PMS default phase functions call all matching phase functions from inherited eclasses in sequence. For example: - your ebuild inherits foo and bar and each of them have src_unpack functions. With this new behaviour, the default src_unpack would run foo_src_unpack, bar_src_unpack, then perform its own actions. I strongly oppose this change, because I feel it will make our entire tree very unpredictable at best. I realize this might eliminate boilerplating from our tree. Weighing that against the possible ramifications in this big of a change in automagic behaviour, I think the cost is much higher than the gain. I am also not very comfortable with our current state, because it has a lot of uncertainty in terms of how the eclass phase functions are called. 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. Going back to my previous example, say your ebuild does the following: -- code begins here -- inherit foo bar # Foo and bar both have src_unpack and src_install functions. # we want foo's src_unpack and bar's src_install: ECLASS_PHASES="foo_src_unpack bar_src_install" -- code ends here --- If ECLASS_PHASES is undefined, I think the default should be to not run the eclass phase functions. Yes, this means there is some boilerplating. However, there are some strong advantages: - this is no longer dependent on order of inheritance. - The ebuild author knows exactly which eclass phase functions will be run. Thoughts? William [1] https://bugs.gentoo.org/show_bugs.cgi?id=516014 --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPv0xQACgkQblQW9DDEZTjX2QCfZgyisZ77ZJcsR+JY4XQNLmTX gxcAoLEUV0kaP6KiaMqLJXlaTER13NR4 =ydWS -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh--