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 421DC13877A for ; Sun, 17 Aug 2014 12:24:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 40367E0917; Sun, 17 Aug 2014 12:24:08 +0000 (UTC) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 457F5E08E2 for ; Sun, 17 Aug 2014 12:24:07 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id lf12so4727358vcb.12 for ; Sun, 17 Aug 2014 05:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=aT6opuguZBLr/a2HBnRMYoSnthN8FDyiXo0Jkucg/qA=; b=u9BsxZN3rPjPNzNQ4bMhxHm1oVptCNtElTHWBXuFLZ7S/ZBat+ygdTR+eLSd+C56bh JpZs7bvCucUN/SUgu6EsxDjw7Tmeg1dJITvFPomPKBx7+hZBSKkCJMN6oR4Gf+fnDb3Y CuZiFjKge4H+9Clr6LaKsxITPdeHyjaXzby+Cbx0sltmSTAfMMgVgsvAqmsUN7XSKQJ1 AEoSvcIe4vd2yvytyOLjQHuVq7v/i87OjS/DQWe0Nc8jzlgWboYyThhWdC3Kx1c6ka/Q 4K+ZFJ4tIgRGmognhJA9ubo2sz32igGfpQsRJdFnxlaLhe5p833qVlSpDgY8QX+nIRas AVNA== 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 X-Received: by 10.221.5.137 with SMTP id og9mr20001040vcb.18.1408278246171; Sun, 17 Aug 2014 05:24:06 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Sun, 17 Aug 2014 05:24:06 -0700 (PDT) In-Reply-To: <21488.20888.756820.509440@a1i15.kph.uni-mainz.de> References: <20140816215428.GA6773@linux1> <21488.20888.756820.509440@a1i15.kph.uni-mainz.de> Date: Sun, 17 Aug 2014 08:24:06 -0400 X-Google-Sender-Auth: L12Z7rSaaoKlFxgI2GCXWYxPnp4 Message-ID: Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 0c039786-0fcc-46f6-868b-29e4fec8853f X-Archives-Hash: 4c518c4a25fac982031cc2b6671a1eb2 On Sun, Aug 17, 2014 at 2:54 AM, Ulrich Mueller wrote: >>>>>> On Sat, 16 Aug 2014, William Hubbs wrote: > >> 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. > > I'm strongly opposed against this proposal, too. Our current system > essentially works. Also, already now you can suppress automatic > calling of phase functions at the eclass level (by not exporting them) > and at the ebuild level (by defining explicit phase functions). > Honestly, I'm not sure that the status quo a great solution. I think we're much better off if eclasses are designed with the need to call them explicitly kept in mind. Rather than one big phase override that does 5 things, they should have 5 separate calls to do each of those things in turn, and perhaps one convenience function that calls all 5 in sequence. Then if you want to use two eclasses that each expect to do 5 things in the same phase you have a hope of being able to call them in a way that makes sense, and not have things break anytime either of the eclasses change. Sure, you CAN work around many of these issues today, but the current practice encourages eclass developers to build their eclasses with the assumption that they are the only eclass around, and to avoid educating their consumers about the need to call functions, little documentation, etc. The thinking is that there is no need for the foo eclass maintainers to warn developers about the need to trigger their new phase function, because it will happen automatically. The problem is that some percentage of the time, this won't actually happen. It is just infrequent enough that we tolerate it. Thinking about it a bit more, the one case where the status quo might be helpful is for eclasses that aren't general-consumption. For example, there are a million kde packages in the tree, and if it makes sense to have each of those just set a few variables in the package and inherit phase functions from a master kde eclass that makes maintenance far simpler. This tends not to cause problems because all the ebuilds that use the eclass are maintained by the same project and are closely related (and I don't think it is a good idea to use this behavior for a kde eclass that anything that links to libkde is intended to use - just for packages that are part of kde-meta and so on). Unfortunately, with our current design we can't exclude inheritance for some eclasses and not others. Possible options to get around this include having different types of eclasses controlled by some setting in the eclass file, something other than eclasses like meta-ebuilds which can be inherited by other ebuilds perhaps with some kind of namespace isolation (like private classes in most programming languages), and two different inherit statements that behave differently (which is basically the same as two kinds of eclasses, but it gives control to the ebuild maintainers instead of the eclass maintainers so that when things change there is a different kind of pain). Ok, I realize I'm thinking out loud here so I'll just leave it at that. I'm open to arguments - I just don't think the current state is as clean as it could be so we really should consider any reasonable proposals for change. Rich