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
pgpufJdRrt98z.pgp
Description: PGP signature
