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 DF113139694 for ; Mon, 20 Mar 2017 21:12:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7A26B21C13B; Mon, 20 Mar 2017 21:12:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 2F0F621C054 for ; Mon, 20 Mar 2017 21:12:42 +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 22E2134071C for ; Mon, 20 Mar 2017 21:12:39 +0000 (UTC) Date: Mon, 20 Mar 2017 22:12:34 +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: <20170320221234.7fd142ad@gentoo.org> In-Reply-To: <1490034298.1270.1.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> 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: 2202948a-7050-4774-9efa-eeee9dce3571 X-Archives-Hash: 72d71c25fb047f4e226b14a1289db26a On Mon, 20 Mar 2017 19:24:58 +0100 Micha=C5=82 G=C3=B3rny wrote: > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote: > > 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 First, I don't oppose committing an eclass for a single package, I consider it out of scope of eclasses, that's all. 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. And finally, ebuild code for the libc used by 99% of our users, supporting cross-compilers, canadian crosses and what else wouldn't be something I'd call a 'half-working hack'. Alexis.