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 2C93E139694 for ; Mon, 20 Mar 2017 21:31:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4077021C1AA; Mon, 20 Mar 2017 21:31:06 +0000 (UTC) Received: from smtp.gentoo.org (dev.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 DD77F21C054 for ; Mon, 20 Mar 2017 21:31:05 +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 1B57C340A23 for ; Mon, 20 Mar 2017 21:31:03 +0000 (UTC) Date: Mon, 20 Mar 2017 22:30:58 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424 Message-ID: <20170320223025.6dff82f8@gentoo.org> In-Reply-To: <1490044756.1400.4.camel@gentoo.org> References: <20170316093806.31977-1-mgorny@gentoo.org> <20170320083544.GZ24205@vapier> <22735.42420.523393.768428@a1i15.kph.uni-mainz.de> <20170320121937.7fc31770@gentoo.org> <22735.58203.928628.654288@a1i15.kph.uni-mainz.de> <20170320180140.66dbef67@gentoo.org> <1490034298.1270.1.camel@gentoo.org> <20170320221234.7fd142ad@gentoo.org> <1490044756.1400.4.camel@gentoo.org> 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 644ba164-2dac-422b-9c8b-165f44aee569 X-Archives-Hash: 63a2bad25e4422e276681daffff8b9f2 On Mon, 20 Mar 2017 22:19:16 +0100 Micha=C5=82 G=C3=B3rny wrote: > On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote: > > On Mon, 20 Mar 2017 19:24:58 +0100 > > Micha=C5=82 G=C3=B3rny wrote: > > =20 > > > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote: =20 > > > > What makes me wonder more are the proposed solutions: So far the > > > > only proposals I've seen are either inlining *all* the code or > > > > moving *all* the code into an eclass. Having a quick look at > > > > autoconf, it seems to me an intermediate solution would work > > > > perfectly fine for the above goals/rules: Put main.eblit into an > > > > eclass. The loading code then would access $FILESDIR only in > > > > src_* phases. This would likely work better for all parties and > > > > would allow to focus on better specifying this gray area of PMS > > > > instead. =20 > > >=20 > > > Don't you find it a bad hypocritical that at the same time you > > > oppose committing an eclass for a single package and you support > > > committing an eclass to support half-working hack for a single > > > package?=20 > >=20 > > First, I don't oppose committing an eclass for a single package, I > > consider it out of scope of eclasses, that's all. > >=20 > > But even if I had stronger positions, this one looks like a win-win > > situation to me: From a code reuse POV, it is an aberration to have > > packages reinvent eblit include logic, each of them having or having > > had its different flaws. Still from a code reuse POV, the eclass > > being able to export functions would reduce ebuild boilerplate > > code, an eblit eclass could test the presence of eblit code and > > call default if absent. From a QA POV, eblit functions can die > > horribly if called outside of src_* phases, ensuring PMS > > assumptions hold and making everyone happy. =20 >=20 > From a code reuse POV, it is an aberration to have an eclass that > reinvents eclass include logic, having or having had flaws. Still from > a code reuse POV, the package manager being able to export functions > would reduce eclass boilterplate code, a package manager could look > for EXPORT_FUNCTIONS and call default if absent. From a QA POV, > eclass can work properly if called outside of src_* phases, ensuring > PMS assumptions hold and making everyone happy. >=20 > ...oh wait, we already have that! Since you still seem to fail to understand the difference, there's nothing I can do for you there. Feel free to convince maintainers, get them kicked if you fail to persuade them, or fork gentoo if you can't get them kicked. Nice team work.