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 BF503138A2F for ; Tue, 19 Aug 2014 07:02:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6DA8FE0942; Tue, 19 Aug 2014 07:02:36 +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 7C75AE08CD for ; Tue, 19 Aug 2014 07:02:35 +0000 (UTC) Received: from [91.220.220.251] (pinkbyte.micronet-rostov.ru [91.220.220.251]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pinkbyte) by smtp.gentoo.org (Postfix) with ESMTPSA id E1C0234006B for ; Tue, 19 Aug 2014 07:02:33 +0000 (UTC) Message-ID: <53F2F685.5010302@gentoo.org> Date: Tue, 19 Aug 2014 11:02:29 +0400 From: Sergey Popov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default 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> <53F260C7.30302@gentoo.org> In-Reply-To: <53F260C7.30302@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BuTpVdJRuepgqsqQ9wPvRh9SJ4Dshu8Wt" X-Archives-Salt: 2fa57964-acbd-4aec-8d90-d6c23e2ec41d X-Archives-Hash: e4ef42aa6e18baf167e400adb43c9aed This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BuTpVdJRuepgqsqQ9wPvRh9SJ4Dshu8Wt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 19.08.2014 00:23, hasufell =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Chris Reffett: >> >> >> On August 18, 2014 11:11:56 AM EDT, "Micha=C5=82 G=C3=B3rny" wrote: >>> Dnia 2014-08-18, o godz. 09:22:46 >>> Chris Reffett napisa=C5=82(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 >>>>> >>>>> as well as >>>>> inherit unpacker base games >>>>> >>>>> however >>>>> inherit games unpacker base >>>>> >>>>> will work. >>>>> >>>>> 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. >>>>> >>>>> 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. >>>>> >>>> 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.= =2E. >> >> I was thinking more ebuild-side. Example: my ebuild inherits both cmak= e-utils and games eclasses, and I don't explicitly define src_compile, re= poman full could pop up a warning like "src_compile is ambiguous between = cmake-utils_src_compile and games_src_compile, please explicitly define t= his phase and call the appropriate eclass function." I imagine that this = would pop up a lot of warnings, but I feel like it would improve readabil= ity and make it explicit what should be going on where. I concede that it= could make a lot more boilerplate code in ebuilds, so that's a potential= issue, mostly just throwing out an idea here. >> >> Chris Reffett >> >=20 > I don't want to code against warning tools, but against a reliable API.= >=20 > That said, EXPORT_FUNCTIONS in eclasses should be definite and > non-recursive. Currently, people have to track down the actual exported= > functions themselves through the endless list of indirect inheritance > which may: > * randomly change > * be highly dependant on the inherit order in the eclass and of those > indirectly inheriting others... >=20 > So to pick up the proposal again, I think this could make sense: > * disable exported functions from indirectly inherited eclasses > * have eclass authors do these things explicitly, so they have to expor= t > ALL functions themselves and may have to adjust their eclasses, as in: > games_src_prepare() { base_src_prepare ; } (I know that base.eclass is > deprecated, this is an example) > * include the exported functions automatically in the generated eclass > manpages >=20 That's proposal make more sense. Even if it will bring such short and wrapper functions, it may be more compliant and ease things for PM itself= =2E Usually i do not agree with your proposals, but that's one in it's current definition is really get +1 from me! --=20 Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Proxy maintainers project lead --BuTpVdJRuepgqsqQ9wPvRh9SJ4Dshu8Wt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT8vaGAAoJECo/aRed9267sP4IAK8YQ2mmp6mxdebEATFKoC7F KeFFqkjEytNjyOrfFEY56B01Hhp4EMMXzp4cNVfyyFQ5OU0P8v7hpZ78VuYD171W K+vroZupSmrYb5igfRw2Oplmd4P5S/xWB8q+YuxFx64TthrDMRDpPT/9Dmpqq41e 0Zj6ljetEs23CdlDhoZYX8+Mxv2hlH73qSviI2achjPtjnkVQ2Ea3kgU80pt1WgI 9/gbG3Ru9/A0f+lY0H2FkK6MjQkhBsypVu/pifITzY4zyiINz8l3taCDES7v+rVJ XHmH8wy9LKDncsXnCodLmBqvHMG+SNXvN/1PR10WS7gVb0Lz/ivImN18lHvfcLc= =6HZy -----END PGP SIGNATURE----- --BuTpVdJRuepgqsqQ9wPvRh9SJ4Dshu8Wt--