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 7BF4C13877A for ; Mon, 18 Aug 2014 20:08:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7452EE08E8; Mon, 18 Aug 2014 20:08:13 +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 46174E085E for ; Mon, 18 Aug 2014 20:08:12 +0000 (UTC) Received: from pomiot.lan (77-253-136-53.adsl.inetia.pl [77.253.136.53]) (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 736E633FCC2; Mon, 18 Aug 2014 20:08:10 +0000 (UTC) Date: Mon, 18 Aug 2014 22:08:46 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Chris Reffett Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default Message-ID: <20140818220846.43149208@pomiot.lan> In-Reply-To: References: <20140816215428.GA6773@linux1> <53F1BF3C.9060902@gentoo.org> <53F1EBE7.6090700@gentoo.org> <53F1EF49.9030503@gentoo.org> <53F1F1EB.6030601@gentoo.org> <53F1F467.80508@gentoo.org> <53F1F7E5.4000309@gentoo.org> <53F1FE26.4030507@gentoo.org> <20140818171156.182dd644@pomiot.lan> 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_/MyKys2M7=zFps5OTBApXkk5"; protocol="application/pgp-signature" X-Archives-Salt: 29e59bc0-3c7c-4234-810a-1fb531f5df98 X-Archives-Hash: 0ba0418735d23a20c3e7d6c7d4a02be3 --Sig_/MyKys2M7=zFps5OTBApXkk5 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-08-18, o godz. 15:37:26 Chris Reffett napisa=B3(a): >=20 >=20 > On August 18, 2014 11:11:56 AM EDT, "Micha=B3 G=F3rny" wrote: > >Dnia 2014-08-18, o godz. 09:22:46 > >Chris Reffett napisa=B3(a): > > > >> On 8/18/2014 8:56 AM, hasufell wrote: > >> > Almost forgot, of course this does not work if you expect > >> > unpacker_src_unpacker() to run: > >> > inherit unpacker games base > >> >=20 > >> > as well as > >> > inherit unpacker base games > >> >=20 > >> > however > >> > inherit games unpacker base > >> >=20 > >> > will work. > >> >=20 > >> > And now... guess why the games herd made it a policy to always > >inherit > >> > games.eclass last. Because of the unpredictability of eclasses and > >that > >> > they may randomly add exported phase functions. It's a bit > >paranoid, but > >> > understandable, since we don't have any real rules here. > >> >=20 > >> > So in the end 3 eclasses all tell you "inherit me last! really!". > >Good > >> > luck with figuring out how to make a gnome game with python and > >multilib > >> > support work together. I can predict the days such a review would > >take > >> > in #gentoo-sunrise. Not less than 3. > >> >=20 > >> Would it be feasible to add a repoman check for situations like this, > >> where the behavior of a phase is dependent on inherit order? If so, > >it > >> seems reasonable to me to require explicit calls to eclass functions > >in > >> these cases to make it clear what's being called when. > > > >Right now, we have no kind of repoman for eclasses. If you have time to > >work on such a thing, please do. Otherwise, all we can do is put more > >checks in ebuilds but that triggers the warning for the wrong people... >=20 > I was thinking more ebuild-side. Example: my ebuild inherits both cmake-u= tils and games eclasses, and I don't explicitly define src_compile, repoman= full could pop up a warning like "src_compile is ambiguous between cmake-u= tils_src_compile and games_src_compile, please explicitly define this phase= and call the appropriate eclass function." I imagine that this would pop u= p a lot of warnings, but I feel like it would improve readability and make = it explicit what should be going on where. I concede that it could make a l= ot more boilerplate code in ebuilds, so that's a potential issue, mostly ju= st throwing out an idea here. People will be unhappy about it. Well, I will be unhappy about it. Maybe if we had different eclasses... but with what we have now, I'd rather order eclasses properly than redefine each phase. Maybe we could agree on something lighter, say, that src_configure() through src_install() should come from the same eclass. Also, please wrap your mails. --=20 Best regards, Micha=B3 G=F3rny --Sig_/MyKys2M7=zFps5OTBApXkk5 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT8l1TXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZONwcP/0tcsUxVn2UuyFTOYlGq4rML lqYqH3P8MjXQA86QWNRA35LU8S5ve+e9KIy4p3Af9N8m12bIz6dTjuoUphuAGZW5 UhU0vsFvpGIgsK/LmPOxANtJIcpjMeE3IVTcPoSZ+NUN1rPdQclWpIzz6uYkU9Ye +234kLOgjHxY5r295lXsWQgqgAi60Zr0+rvTQMrXQMWHHBvEyt0w8WGI8yVnX1xJ oZ/lj/9++Sqpx/zwA5wQZoKe0iECYNqXt/nFBdZXjtEvrMo9ZjYSx+p2dvl4oT0R feciKD9MMICBsOzkHEf1HawlatCmjrE9HN/qchvseUxv8WgGltCyK61d6ebWGGKL O7/DNLLgftIiI/Ids9TGrx2MVzYfrXIF2FeVsuMXFqvXd8KHAQWBV3gUDjtzTB2C HXOdyZ36rHpqy6P8/Pc/ntwf9mr7RCnePDl0wloyJLuKRLJcJk3TUZaUs3k9C8lE gpugbTimnweCiLNC0Nk9ym4lVdlbQCZ3OpdzJTEaQ8LjmmrSoRolmRVGIbgRpP+L 4Ovi3ojPyjobbyWrvz6DRnRCjp2NwAIS7eaLi0qVKxZaxyk/e6YD7UhnGLDyClVJ mWIPP1lT77gPBCVvNIQ92qKrQAQcMzn6YoFmYmgLf4OKwjtZHyk69hgvedUDm8ac zMafw/yLlYAKETXPdGh+ =1Vh/ -----END PGP SIGNATURE----- --Sig_/MyKys2M7=zFps5OTBApXkk5--