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 256B1138A2F for ; Sun, 17 Aug 2014 03:11:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5F7E7E095F; Sun, 17 Aug 2014 03:11:35 +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 24E53E0941 for ; Sun, 17 Aug 2014 03:11:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id DD35233FEB1 for ; Sun, 17 Aug 2014 03:11:31 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5.5 tests=[AWL=-0.461, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD8xkXU5ejGS for ; Sun, 17 Aug 2014 03:11:26 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 2169F34029A for ; Sun, 17 Aug 2014 03:11:25 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XIqsF-0006gT-DE for gentoo-dev@gentoo.org; Sun, 17 Aug 2014 05:11:15 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Aug 2014 05:11:15 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Aug 2014 05:11:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: rfc: calling all eclass phase functions by default Date: Sun, 17 Aug 2014 03:11:03 +0000 (UTC) Message-ID: References: <20140816215428.GA6773@linux1> <20140816230108.GA11181@linux1> 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT d447f7c /m/p/portage/src/egit-src/pan2) X-Archives-Salt: 1d4f44c8-6e1c-47a5-b867-6f7dce1cb7db X-Archives-Hash: 44ef72c74d26aed58d993106c8e4b21d William Hubbs posted on Sat, 16 Aug 2014 18:01:08 -0500 as excerpted: > My concern about reverse logic like excludes is this: > > -- code start -- > > # foo and bas provide src_unpack, but you don't want the PMS default > # src_unpack to run them, and bar does not provide src_unpack: > # You want the rest of the PMS default src_unpack actions to run, so you > # don't write src_unpack. > > ECLASS_EXCLUDE="foo_src_unpack bas_src_unpack" > inherit foo bar bas > > -- code stop -- > > This works fine until the eclass maintainer for bar.eclass decides to > add bar_src_unpack. > > As soon as that happens, your ebuild is broken. Of course that can be foreseen since the eclass is directly inherited and an ebuild writer could do... ECLASS_EXCLUDE="foo_src_unpack bas_src_unpack bar_src_unpack" ... even if there isn't one, since an ebuild writer can be presumed to know what his inherit line is. But what about Nth generation inherits? Suppose the foo eclass maintainer decides to inherit raz, and there's a raz_src_unpack, what then? So with reverse-logic excludes, to be sure he gets what he intended in the default_src_unpack wanted scenario above, an ebuild writer will have to create a src_unpack that simply calls default_src_unpack. Of course that's the way it is today too, but it's much more of a trap with reverse- logic as now you pretty-much have to do your src_unpack simply calling default_src_unpack from the get-go, while with reverse-logic, it might be fine from the get-go, and only break in some rather hidden and non- intuitive Nth-level inheritance case much later. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman