On 08/02/2010 08:16 PM, David Leverton wrote:
> On 2 August 2010 12:11, Brian Harring <ferringb@...> 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.