From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 152BD138010 for ; Thu, 6 Sep 2012 00:02:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 98568E073B for ; Thu, 6 Sep 2012 00:02:34 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 7F5F321C014; Wed, 5 Sep 2012 21:30:39 +0000 (UTC) Received: from pomiocik.lan (213-238-104-238.adsl.inetia.pl [213.238.104.238]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 3479233D759; Wed, 5 Sep 2012 21:30:36 +0000 (UTC) Date: Wed, 5 Sep 2012 23:31:40 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-project@lists.gentoo.org Cc: ulm@gentoo.org, gentoo-dev-announce@lists.gentoo.org Subject: Re: [gentoo-project] Council meeting: Tuesday 11 September 2012, 19:00 UTC Message-ID: <20120905233140.1a9d3625@pomiocik.lan> In-Reply-To: <20549.54500.967226.363097@a1i15.kph.uni-mainz.de> References: <20549.54500.967226.363097@a1i15.kph.uni-mainz.de> Organization: Gentoo X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.11; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA256; boundary="Sig_//ov5c+EUiQdKW52nIqepL1X"; protocol="application/pgp-signature" X-Archives-Salt: cbf1c863-2c5c-4d37-8ec3-4cfdada903eb X-Archives-Hash: 07e26dd74b55ce441ba3eb8f05fc4b04 --Sig_//ov5c+EUiQdKW52nIqepL1X Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 4 Sep 2012 12:16:04 +0200 Ulrich Mueller wrote: > 4. Open floor (10 minutes) I would have one small conflict/issue to resolve if it fits the 'open floor' time, or otherwise for the next meeting. It is the inclusion of dointo() and newinto() functions into eutils.eclass. The implementation of these functions would look like: dointo() { ( insinto "$1" doins "${@:2}" ) } so it's simply insinto+*ins in a subshell to avoid altering the ebuild- defined insinto target. This is how various eclasses implement functions like domenu(), doicon()... I wanted to add those functions to eutils.eclass so that the functions defined other and other eclasses wouldn't have to repeat the same code. However, Diego Petteno was strongly opposed to this and I wasn't able to convince him so I'd like to put it to debate by the Council. The alternative proposed by Diego is to include those helpers in EAPI 5. However, that would mean that the beneficial eclass functions will have to use them conditionally to EAPI, so it wouldn't benefit at all functions in eclasses supporting EAPI<5 (and the affected eclasses have no reason to drop support for older EAPIs). Effectively, if introduced in a future EAPI, the helpers will be not used at all for a long time. I would like to especially note that these functions are meant for internal use by eclasses and not by ebuilds. Ebuilds can and should use insinto directly which is more optimal; eclasses need the subshelling to allow ebuilds to do things like: insinto /foo doins bar doicon bar.xpm doins something_else Ebuilds obviously can control their use of insinto. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_//ov5c+EUiQdKW52nIqepL1X Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlBHxLwACgkQfXuS5UK5QB0x5QP/cLDq+YIox/uvc8fM63JqHsNj Xzt+/6wn0LGBwaCscpf2YLEO8KjcL1Oweis5j37VpQtu5eAN+LqTOgiYD0Tri5zV HlptcyPJrVNgdw0vih02BcXP7R8jK4Ssd/iz77a/a+y6Ddw/ldoUhBme45h9TvXM wazHF9QtlbFihjtYSA0= =3IQ4 -----END PGP SIGNATURE----- --Sig_//ov5c+EUiQdKW52nIqepL1X--