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 4418113877A for ; Sat, 16 Aug 2014 22:53:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8FE54E094A; Sat, 16 Aug 2014 22:53:38 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A474CE0904 for ; Sat, 16 Aug 2014 22:53:37 +0000 (UTC) Received: from pomiot.lan (77-254-95-248.adsl.inetia.pl [77.254.95.248]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id AE82A3400FF; Sat, 16 Aug 2014 22:53:35 +0000 (UTC) Date: Sun, 17 Aug 2014 00:54:17 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: William Hubbs Cc: gentoo development Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default Message-ID: <20140817005417.5106da3c@pomiot.lan> In-Reply-To: <20140816215428.GA6773@linux1> References: <20140816215428.GA6773@linux1> Organization: Gentoo X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-pc-linux-gnu) 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-sha512; boundary="Sig_/1Y0G37drpXAHTXs5T9KlG2Q"; protocol="application/pgp-signature" X-Archives-Salt: 961583f3-480b-41fa-9ea1-ce5d543e3085 X-Archives-Hash: ab80b2d3356d13ba3fe293254b818ffa --Sig_/1Y0G37drpXAHTXs5T9KlG2Q Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-08-16, o godz. 16:54:28 William Hubbs napisa=B3(a): > 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. Why doesn't it call default_src_unpack too? > 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. 'Unpredictable' is very lightly said. 'Complete mayhem' seems much more appropriate. 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. For example, a quick grep suggests that 72 eclasses declare src_compile(). Now imagine how many eclasses end up inherited in more complex ebuilds. Of course, the final number would be smaller since many eclasses will simply have to drop phase functions to avoid forcing every single ebuild to redefine phases to avoid colliding behavior. However, I exaggerate a bit here. The issue won't hit too many people because the learning curve would look more like a cliff which you will be climbing up upside down using only your tongue, during a storm. > 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. 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. > 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 --- And how is this exactly different than: src_unpack() { foo_src_unpack; } src_install() { bar_src_install; } 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. What happens if ebuild specifies both ECLASS_PHASES=3D"foo_src_unpack" and explicit src_unpack()? > If ECLASS_PHASES is undefined, I think the default should be to not run > the eclass phase functions. Do we want to run default EAPI phases? Do we want to have an extra variable to control these? > Yes, this means there is some boilerplating. However, there are some > strong advantages: >=20 > - this is no longer dependent on order of inheritance. > - The ebuild author knows exactly which eclass phase functions will > be run. >=20 > Thoughts? The current behavior compared to the two extremes suggested here sounds like a good compromise. It's not perfect but it works very well for most of the ebuilds, keeping only a few overly verbose and a few unpredictable. The first suggested idea is the kind of extreme trying to solve the overly verbose ebuilds. While it could work in the end, it will certainly make getting all ebuilds and eclasses right a pain. Moreover, it is full of pitfalls and hidden issues. The second idea is the complete opposite extreme. It kills all automation, forcing verbose references in every ebuild. Imagine all those simple Perl modules that have to list all the phase functions... and imagine all the extra pitfalls of missing phase function calls. 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. --=20 Best regards, Micha=B3 G=F3rny --Sig_/1Y0G37drpXAHTXs5T9KlG2Q Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT7+EeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOEgEQAKRXIUiL9XLfM6/Bx6XuTnhA MV5SCibDF/zUHS7+JApQCLkuB+k76oOXClreRpbkx2yaUzliJy0150qCEY8GVEiv UFEklUEza1C+oztyKHB//7xKU1bEOww3TYH2tcHLBOtcLs/h0pisW1UjYHDimNTK gc+3aZLOxnSqcd/EHK5WJiZ+XgjeF21xfeGSkp6XTVQ+q2f7FCEtEn+daJ0O9ct7 4MOlct3E/oGIlZVPCLj6ysNxaReVyLUqDsVox+RKcwTkTmZ8yBFiK0Q1RZWCLSGz JMkfAfEazRyFUUy+Z2LZ29EaejT6LKmQ4Zp9LFbsVtoW3resr+h3DMb13umtEiYU O2eY1pPbsRm4t3uby9OYVo7g7zHrPLWbvxEvTsnaaLmlIykQcPnyeL4UWYV6QpVc DJhyW04mSkYTm4SIk837c4Bv1Uho2v3xoNo076ML7+b1K8kb55s+XonzAVyJERln ZZpV59NfQKnzHkCki0U/8ZDoAeN+33kCmczqROrksJf2/plOJ/eVpzZVWN5jyGOu 0lXvRvXG7l9/90kgZYP+9XHCgufLQpMqA0qKWGRMkel/IzQeYFD0TNfAji7VpBJs 7mZhH8pDLTp9OL2Eoa3TrSnrDUMHQYovQQikgv2/9XZAjAQ3BtoLQGfvqD03tWaa uS5DEugqnyOXWgCNM5Lx =fdfv -----END PGP SIGNATURE----- --Sig_/1Y0G37drpXAHTXs5T9KlG2Q--