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 5272613877A for ; Mon, 18 Aug 2014 12:42:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 432EDE0B06; Mon, 18 Aug 2014 12:42:06 +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 46D98E0ACF for ; Mon, 18 Aug 2014 12:42:05 +0000 (UTC) Received: from 127.0.0.1 (2.shulgin.nl.torexit.haema.co.uk [93.174.90.30]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id EB9EE33FD18 for ; Mon, 18 Aug 2014 12:41:56 +0000 (UTC) Message-ID: <53F1F467.80508@gentoo.org> Date: Mon, 18 Aug 2014 12:41:11 +0000 From: hasufell 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> In-Reply-To: <53F1F1EB.6030601@gentoo.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: ebc8497b-4bd8-4a94-a352-053007c827a1 X-Archives-Hash: 3c432c18bff68e482d0196688220f263 hasufell: > Sergey Popov: >> 18.08.2014 16:04, hasufell пишет: >>>> You have my strong opposition on such change as well. It will turn >>>> ebuilds into unreadable and undpredictable mess, please do not do that >>>> >>> >>> They are already fairly unreadable and unpredictable. >>> >> >> For you - maybe. But not for me. >> >> I am NOT talking about hacks like putting additional *.as files through >> echo(hello Boost ebuild) or doing something crazy with subshells. >> >> But most of the eclass and ebuilds are readable quite simple if you read >> devmanual, PMS and have a brain. >> >> Of course, there are sometimes non-trivial stuff that is hard to read. >> >> But majority of ebuilds and eclasses are fine to understand and predict. >> >> So, without examples from you, this discussion will lead to nowhere, so, >> please let's stop it. >> > > From my time as a sunrise dev I strongly disagree. People have problems > with understanding the mess, including actual programmers. They have > enough technical understanding, but not the time or motivation to go > through all those funny pitfalls which are NOT properly documented in > devmanual. > > The most popular example is what we are talking about right now: > indirect inheritance for example via games.eclass which inherits > base.eclass but does not export src_unpack so stuff like unpacker.eclass > and git-2.eclass will likely just do nothing if you inherit them before > games.eclass (which is required by games herd policy)... uhm. I doubt > you would have guessed this one if you saw the plain ebuild. I know the > pitfall, so I see it just from looking at the inherit line. But it is > far from being obvious. > Even more interesting... you can work around this by inheriting base.eclass explicitly before e.g. unpacker.eclass, something like inherit base unpacker games => unpacker_src_unpack() is carried out by default (and the ebuild breaks if someone thinks the base.eclass is useless and removes it) inherit unpacker games => unpacker_src_unpack is not carried out by default although games.eclass does not directly overwrite it If you think any of this is sensible...