From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6AFDB139694 for ; Sun, 21 May 2017 18:19:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 623C0E0DDD; Sun, 21 May 2017 18:19:13 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 04F75E0DC0 for ; Sun, 21 May 2017 18:19:12 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dCVRX-0006qO-R8 for gentoo-dev@lists.gentoo.org; Sun, 21 May 2017 20:19:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Martin Vaeth Subject: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ Date: Sun, 21 May 2017 18:18:56 +0000 (UTC) Message-ID: References: <1494961831.d1b05bcf81e5058c20615179fb83a90c45daa487.vapier@gentoo> <1494962401.1591.11.camel@gentoo.org> <20170516193615.GK1486@gentoo.org> <20170522020200.2b4954da@katipo2.lan> <20170521162930.GA23146@linux1> <1495388066.4186.0.camel@gentoo.org> 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@blaine.gmane.org User-Agent: slrn/pre1.0.0-26 (Linux) X-Archives-Salt: 164e7be1-2087-408b-b050-725516542383 X-Archives-Hash: 565fe35ee7a1b2a14a6fefdf52614396 Michał Górny wrote: >> If this is such a big problem, maybe we should be discussing how to >> redesign things to improve it? > > Like, by not using eclasses and instead inlining all the stuff? There are other ways. One way to mitigate the problem might be to require that eclasses contain some # @VERSION: major.minor-revision line and that the metadata cache of an ebuild contains that version number (or at least the major component of it) instead of an md5 sum. Then the commiter of the eclass has full control whether a metadata regeneration will happen or not: For trivial changes (see below), the committer simply does not increase that version number (or increase only minor-revision), and one could agree that a rebuild of the metadata only happens if the major version number of an eclass changes. By "trivial changes" I mean in this connection not only changes in comments but also minor changes in functionality or even in the API: The only strict requirement is that the major version has to increase if the eclass change can induce a change in the metadata of some ebuild using it (e.g. if a value printed by some function changes which might involve IUSE, REQUIRED_USE, DEPEND, ...)