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 483C1139694 for ; Mon, 20 Mar 2017 21:19:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9803B21C1CF; Mon, 20 Mar 2017 21:19:36 +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 3D86D21C09C for ; Mon, 20 Mar 2017 21:19:36 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id C0E7334071C; Mon, 20 Mar 2017 21:19:34 +0000 (UTC) Message-ID: <1490044756.1400.4.camel@gentoo.org> Subject: Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424 From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Mon, 20 Mar 2017 22:19:16 +0100 In-Reply-To: <20170320221234.7fd142ad@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> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-vjRWwTL5RJV8tzPbClF8" X-Mailer: Evolution 3.22.6 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-Archives-Salt: 666122c5-f7ac-4337-82dd-d444304ab739 X-Archives-Hash: df9cf510772ea5d565f37f7caa6cbfb8 --=-vjRWwTL5RJV8tzPbClF8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: > > > 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. =46rom 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. ...oh wait, we already have that! > 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'. Especially when it ends up with users reporting things like 'pkg_* phases are not being called'. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-vjRWwTL5RJV8tzPbClF8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAljQR1VfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQoXLxAAixm3MN4IOGpHwfX/D9Q+8rnMRi7dVXMMxndAHOCsTOjmY7mDGyFJZch5 gqr+oliM/2Rndvt98wDH68lFwC2Ji2M7n8iycr6f+BhUS285h++cKU1FaD/NsiaY iOCMWjtkpmO8u/kniz54SbzItdfRLvmpP29rYknTBlu0Ly+lFyvfl0i7M55J61Ab rBxfC908DQRrBsbOyeKOqT1S8CAh7WzmF3l3UB/C2qXyu3RSsaWrpO7JiMgC9cV+ MoqbW7AaolgBRwXPsSxa7gZjWgOJgMWbA6fLl7WKOgsYaHPWKl6a3GdOlmDx+yTg VdCYcfFrnGEeqMAscD1c0CLyEtd6vMSxWo5Jnc9L1+wb1kUZ//5Ex/NEDvZpa02f oKDP5yoiWxImCV73WxhfjkoH4uHl4c8mCF6yK/rvYt078TJuMh+nn18kPJnVBiOK rCzD+ShcOwfbbx1PG1w/C0r6RDH6nXEaOBU+/rA5Tm6nqXXh1xfPPSOP/eyAhU1i xFLr6jqBamstELeRbFOolQsxEjE4YUoiJO84GGqCkJceNUrnN4rnZ+CDwNOjYxMl fhtEicknRT1Pcuo4kXxrKESENHf7Az5qMxWHW/xQOhjmRTA75blrN4l8DnVyTYY0 p8SL3Vaf8j9ZAc30IecjLAg7hkwhb+rRSk5mSxDBeHvoFtmDngA= =Uba1 -----END PGP SIGNATURE----- --=-vjRWwTL5RJV8tzPbClF8--