From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1O0ot6-00039N-Gy for garchives@archives.gentoo.org; Sun, 11 Apr 2010 04:35:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 10DA0E07BB; Sun, 11 Apr 2010 04:35:06 +0000 (UTC) Received: from mail-pv0-f181.google.com (mail-pv0-f181.google.com [74.125.83.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 2054BE07A5 for ; Sun, 11 Apr 2010 04:34:22 +0000 (UTC) Received: by pvg16 with SMTP id 16so2433731pvg.40 for ; Sat, 10 Apr 2010 21:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=+WhAKgIV84+lSw4lw1ho4jmw2KK6wnVl2Q0AvCKdHGQ=; b=SlIVdhZrxG/KEPdmlOc3xZ5j7VLjS8jpqXJqzqWzjIiJwQbjxzoG5rgacG1j+dMuYY LDh8gnDN4ENTEEaJhlz+Vzbp+qkBq8Bt8xFPcItLGpmf9iKy1JIQFnugwixXnewjyZoF aYf2lDK4+RK9s0Mex5tyf4vRVDhHJnfGIGuJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=dgh7sGBSRPi9y9+XX2+IrH4FQGdsN/6kkrNs67SmLKFpRNL2ZLBucGDVzI9AayJNLB lQhLQ1apd88CiF+7nYeiJffxxZwcv9Lg3uAwbr3T8EWNdg5thzlOyW278f09nsk4Laau BGDHDhz78kNaTxYVYUxevvCC2pfZ/M4sD7lj0= Received: by 10.114.187.19 with SMTP id k19mr2011429waf.20.1270960461571; Sat, 10 Apr 2010 21:34:21 -0700 (PDT) Received: from smtp.gmail.com (c-67-171-128-62.hsd1.wa.comcast.net [67.171.128.62]) by mx.google.com with ESMTPS id 22sm2637765pzk.13.2010.04.10.21.32.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Apr 2010 21:32:41 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Sat, 10 Apr 2010 21:30:45 -0700 Date: Sat, 10 Apr 2010 21:30:45 -0700 From: Brian Harring To: mabi@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: eblits.eclass Message-ID: <20100411043045.GA6208@hrair> References: <4BC0F659.7000506@gentoo.org> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <4BC0F659.7000506@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: cf494a83-3493-48d1-9352-3a96243401ab X-Archives-Hash: 6abb6642c57baf2867b9e9db5cd31d40 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 11, 2010 at 12:06:17AM +0200, Matti Bickel wrote: > I propose to add eblits.eclass[2] (attached to this message) with the > purpose and author comments from [1]. Counter proposal; finish off the remaining steps of elib related steps=20 =66rom glep33 and integrate it into an EAPI. > So please enlighten me of any problems you can think of that adding > eblits.eclass as proposed above would cause. I'd be more than happy if > we can get an update on elibs progress, too. Please note that FILESDIR access isn't guranteed during metadata=20 sourcing- pkgcore specifically does _not_ set that var to catch ebuild=20 screwups. This is why mips-sources has their eblits loadup w/in=20 pkg_setup. Honestly I'm not much for turning down this particularly pkgcore=20 protection since it's caught some screwy access in the past. The=20 problem here is your eblit-php-metadata function- the function is=20 executed in the global scope which means it will be validly blocked=20 under pkgcore. Please flip through glep33- the usage of eblits doesn't match their=20 original intention there, the intention was to move non metadata=20 functionality into libraries to be loaded up after sourcing. =20 Basically a compliment to eclasses. However you're using eblits for=20 metadata purposes which is contrary to that intention. > As the need for such an eclass is very real (we really, really want > php-5.3 in the tree!), I want to limit discussion to one week, ending > April 18th. If there are no objections, I'll add the eclass after that da= te. In looking through your usage of eblits, I'm not actually seeing any=20 reason this technique *must* be used. Could you please clarify if=20 there is some edge case I'm missing requiring eblits? The reason I ask is that I'd rather see elibs resurrected/finished=20 (I'll do the work if no one else will) than have the eblits hackery=20 used. ~harring --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkvBUHUACgkQsiLx3HvNzgeT7QCglRRAa9hfmZvg0aPnohsKeGpt xnEAn2CcPxluKG5KxvMUbDUOFzdiiLKW =1lRE -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm--