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 9DBF1139694 for ; Thu, 16 Mar 2017 18:42:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 94BFD21C0E1; Thu, 16 Mar 2017 18:42:18 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 4791C21C0B2 for ; Thu, 16 Mar 2017 18:42:18 +0000 (UTC) Received: from localhost (dra13-4-78-234-166-189.fbx.proxad.net [78.234.166.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id C7CA7341616 for ; Thu, 16 Mar 2017 18:42:16 +0000 (UTC) Date: Thu, 16 Mar 2017 19:42:09 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424 Message-ID: <20170316194209.62bdc737@gentoo.org> In-Reply-To: <22730.35784.80741.247631@a1i15.kph.uni-mainz.de> References: <20170316093806.31977-1-mgorny@gentoo.org> <22730.25568.382258.703491@a1i15.kph.uni-mainz.de> <20170316131911.25e49c7d@gentoo.org> <22730.35784.80741.247631@a1i15.kph.uni-mainz.de> Organization: Gentoo X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 5f8ef9eb-b04e-4260-95c7-569a6e483535 X-Archives-Hash: 0033a35cff92805ab827d97058216e04 On Thu, 16 Mar 2017 13:57:44 +0100 Ulrich Mueller wrote: > >>>>> On Thu, 16 Mar 2017, Alexis Ballier wrote: > > > Indeed, but that eclass fails to follow devmanual eclass 101 [1]: > > An eclass is a collection of code which can be used by more than one > > ebuild. > > Which is the case here: > > sys-devel/autoconf/autoconf-2.13.ebuild | 10 +--- > sys-devel/autoconf/autoconf-2.59-r7.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.61-r2.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.62-r1.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.63-r1.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.64.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.65-r1.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.67.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.68.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.69-r2.ebuild | 11 +--- > sys-devel/autoconf/autoconf-9999.ebuild | 15 ++--- You're trying to find loopholes in the wording here, aren't you ? :) > > While this eclass might be a good temporary solution, I find it a > > rather convincing argument for per-package eclasses :) > > Yes, if there was sufficient demand for such a feature, and it would > therefore reduce the number of global eclasses significantly. IMHO it > wouldn't be worth it for only a handful of packages. What do you consider demand ? A handful of packages that have to write a hundred lines of boilerplate code to make it work isn't representative of any demand at all. I've already written in some bug some usecases I foresee for even a trivial 'include'.