On 08/02/2010 08:16 PM, David Leverton wrote: > On 2 August 2010 12:11, Brian Harring <ferri...@gmail.com> wrote: >> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote: >>> Hi folks, >>> >>> I've been told that my use of eblits in dev-lang/php is something >>> I should get rid of as soon as possible. Suggested alternative by >>> ferring: use elibs. > > There's a couple of hundred lines of repeated metadata between > php-5.3.2 and php-5.3.3 - not identical, but similar enough that > there would be gains from factoring it out, and elibs won't help with > that.
Sure. I was thinking of providing php.eclass with the common metadata for php-5*, including patchset code, core DEPEND and the like. With the php team rather stretched nowadays, it will take a few days before that'll happen. I'm still trying to cope with the complexity of the whole php eco-system. > Am I understanding correctly in that you didn't use an eclass to > avoid cluttering up the main eclass directory with something specific > to this one package? Yes. Actually, that was hoffie's goal, when he decided to use eblits. I continued this and actually made php5_2-sapi.eclass obsolete by using eblits in php-5.2.14. Interesting sidenote: I only needed one more eblit for this - the amount of code shared went through the ceiling. > If so, it sounds like what you really want is per-package eclasses > (maybe with elibs as well to hold the non-metadata code), which > aren't covered by GLEP33 but ought to be easy enough to add. It's actually covered by GLEP33: http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring And yes, it's one of it's most obvious advantages. I hate the clutter of php-* eclasses with passion (I'm aware most of them serve a good purpose). >> My suggestion? Split this into two, elibs, and eclass >> refactoring. > > Per-package eclasses would be beneficial IMHO regardless of the > other eclass stuff from 33, might be worth thinking about those as > another item (consistent with the existing design plans of course) if > the rest isn't going to happen soon. If we can get that going asap without waiting, I'm all for it.
signature.asc
Description: OpenPGP digital signature
