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 
from 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 
sourcing- pkgcore specifically does _not_ set that var to catch ebuild 
screwups.  This is why mips-sources has their eblits loadup w/in 
pkg_setup.

Honestly I'm not much for turning down this particularly pkgcore 
protection since it's caught some screwy access in the past.  The 
problem here is your eblit-php-metadata function- the function is 
executed in the global scope which means it will be validly blocked 
under pkgcore.

Please flip through glep33- the usage of eblits doesn't match their 
original intention there, the intention was to move non metadata 
functionality into libraries to be loaded up after sourcing.  
Basically a compliment to eclasses.  However you're using eblits for 
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 date.

In looking through your usage of eblits, I'm not actually seeing any 
reason this technique *must* be used.  Could you please clarify if 
there is some edge case I'm missing requiring eblits?

The reason I ask is that I'd rather see elibs resurrected/finished 
(I'll do the work if no one else will) than have the eblits hackery 
used.

~harring