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 2E92E138A2F for ; Sat, 16 Aug 2014 23:30:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6B283E0922; Sat, 16 Aug 2014 23:30:40 +0000 (UTC) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8D604E08FA for ; Sat, 16 Aug 2014 23:30:39 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id eb12so3038213oac.22 for ; Sat, 16 Aug 2014 16:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=1ZzVSmaI7KAwchpCaOgcKHFl/js5g1xxZsj1Ce0PEBU=; b=p5c+83Tzi1H8fvuhJkuLx09X+FZ9q+4DMYD8bQseCDRqX4AcBBvYn9MOFKQDnGN6mG bHvdClkJ2nugjvVLzjARHYZ7OIoQIxNKeAE3+jWxAJJcqaJtT3vCpUWsWbhqMgaPqllI YEAwc94roO9OKyFjlPxynr6S7zJgxx3sVxwxYwCRV5nsV5QErvn8/5cFXX12EFtQC5Rx gdrb+pUJFrYMXQgsdJG+OQy+kaWQzE9v92DwKbneVniuV62+Y84eGdupuv4LIPtGHueE 4Nyrl4qrBlYinL4KI+qEjt8+wC5czWC7Z8HO+nml7a815CBAgzpxqzQv+mxGSV91/JES RWmw== X-Received: by 10.182.65.65 with SMTP id v1mr28775912obs.58.1408231838786; Sat, 16 Aug 2014 16:30:38 -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 t2sm13374335obg.27.2014.08.16.16.30.36 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 16 Aug 2014 16:30:37 -0700 (PDT) Sender: William Hubbs Received: (nullmailer pid 11310 invoked by uid 1000); Sat, 16 Aug 2014 23:30:30 -0000 Date: Sat, 16 Aug 2014 18:30:30 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Cc: mgorny@gentoo.org Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default Message-ID: <20140816233030.GB11181@linux1> Mail-Followup-To: gentoo-dev@lists.gentoo.org, mgorny@gentoo.org References: <20140816215428.GA6773@linux1> <20140817005417.5106da3c@pomiot.lan> 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="+g7M9IMkV8truYOl" Content-Disposition: inline In-Reply-To: <20140817005417.5106da3c@pomiot.lan> User-Agent: Mutt/1.5.22 (2013-10-16) X-Archives-Salt: f25adf47-bbd8-482f-81da-bd9497ff786a X-Archives-Hash: c292fe5da812b87ec4919b870ad7eed5 --+g7M9IMkV8truYOl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 17, 2014 at 12:54:17AM +0200, Micha=C5=82 G=C3=B3rny wrote: > Dnia 2014-08-16, o godz. 16:54:28 > William Hubbs napisa=C5=82(a): >=20 > > 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. > >=20 > > For example: > >=20 > > - 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. >=20 > Why doesn't it call default_src_unpack too? In the original proposal, the loop that ran foo_src_unpack, bar_src_unpack, etc would be part of default_src_unpack. > > 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. >=20 > 'Unpredictable' is very lightly said. 'Complete mayhem' seems much more > appropriate. >=20 > Right now, finding proper phase functions may be a bit hard due to > indirect inherits. Imagine all the fun of debugging phase functions > when every single indirect inherits adds to the stack. I don't want > even to discuss the issue of ordering them all. Agreed. It definitely would be a mess. > > 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. >=20 > That is not really a problem of PMS behavior but a problem with > the eclasses. If eclasses were done at least semi-reasonably, you > would be able to easily guess which phase functions are exported by > which eclass. I'm all ears as they say; feel free to start a new thread on redesigning our eclasses. I have no idea how they could be done differently to make this easier. >=20 > > 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. > >=20 > > Going back to my previous example, say your ebuild does the following: > >=20 > > -- code begins here -- > >=20 > > inherit foo bar > >=20 > > # Foo and bar both have src_unpack and src_install functions. > > # we want foo's src_unpack and bar's src_install: > >=20 > > ECLASS_PHASES=3D"foo_src_unpack > > bar_src_install" > >=20 > > -- code ends here --- >=20 > And how is this exactly different than: >=20 > src_unpack() { foo_src_unpack; } > src_install() { bar_src_install; } >=20 > forced by your previous idea? As I see it, it's just a redundant way of > doing the same thing. A few bytes shorter maybe, at the cost of having > to control and consider another variable. =20 I'm not arguing that either. > What happens if ebuild specifies both ECLASS_PHASES=3D"foo_src_unpack" > and explicit src_unpack()? The src_unpack() in the ebuild wins. > That said, I suggest you focus your efforts on solving the real issue > -- that is, fixing the eclasses -- rather than trying to shoehorn > an ugly workaround into PMS. Like I said above, I'm all ears; start a new thread about how the eclasses can be fixed. William --+g7M9IMkV8truYOl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPv6ZYACgkQblQW9DDEZTj67QCfbhoRtJpe/Xr7WkMfk+O2i5zl QlIAoIhgJ+GwsYiCaRx3P1lAqTgrBWyb =RNne -----END PGP SIGNATURE----- --+g7M9IMkV8truYOl--