On Sun, 26 Sep 2010 16:59:22 +0200
Matti Bickel wrote:
> On 09/26/2010 03:22 PM, Ciaran McCreesh wrote:
> > Isn't the amount of work to get per-package eclasses basically the
> > same as the amount of work to get per-(package and category)
> > eclasses?
>
> Actually, I don't know. Tell me. I've n
On 09/26/2010 03:22 PM, Ciaran McCreesh wrote:
> Isn't the amount of work to get per-package eclasses basically the same
> as the amount of work to get per-(package and category) eclasses?
Actually, I don't know. Tell me. I've no clue how much PM implementation
effort this will be, yet.
signat
On Sun, 26 Sep 2010 15:07:33 +0200
Matti Bickel wrote:
> On 09/19/2010 10:49 PM, Andreas K. Huettel
> > Wouldn't it also make sense to have "per-category eclasses"? This
> > seems much more useful for me.
>
> Yes, probably. But it'll be enough getting per-package eclasses in,
> right now. I'll r
On 09/19/2010 10:49 PM, Andreas K. Huettel wrote:
>
> Wouldn't it also make sense to have "per-category eclasses"? This
> seems much more useful for me.
Yes, probably. But it'll be enough getting per-package eclasses in,
right now. I'll revisit this when we finally merge dev-php5 and dev-php.
If
On 9/20/10 7:30 PM, Alec Warner wrote:
> How does it provide more code sharing than the existing system?
>
> Previously I could put code I wanted shared:
> 1) In a global eclass, which means any ebuild in the tree can likely use it
A global eclass is quite heavyweight. It requires a review on
gen
On 09/20/2010 07:30 PM, Alec Warner wrote:
> Under the new system I can put the code:
>
> 1) In a global eclass, any ebuild can likely use it
> 2) In a per-package eclass, only one package can use it
> 3) In a pkg eblit, only one package can use it
Per package eclasses are pretty much eblits with
On Mon, Sep 20, 2010 at 5:19 AM, "Paweł Hajdan, Jr."
wrote:
> On 9/19/10 9:14 PM, Matti Bickel wrote:
>> So, yeah, what do you think? Is it worth it?
>
> I second this GLEP. It seems like it will cleanly replace our hacked
> eblits implementations from packages like php, glibc, and possibly more.
On 9/19/10 9:14 PM, Matti Bickel wrote:
> So, yeah, what do you think? Is it worth it?
I second this GLEP. It seems like it will cleanly replace our hacked
eblits implementations from packages like php, glibc, and possibly more.
Also, it will allow more code sharing between ebuilds, which is good
On Sun, Sep 19, 2010 at 12:14 PM, Matti Bickel wrote:
> I'm a couple weeks late with this, but here goes:
> from my failed attempts at reviving GLEP33 grow a discussion with
> ferringb on IRC about how to get what I wanted anyway :)
I've placed my immediate feedback in CVS:
http://sources.gentoo
Wouldn't it also make sense to have "per-category eclasses"? This seems much
more useful for me.
Examples where this would already make sense today: kde-meta, latex-package, ...
Best, Andreas
On Sunday 19 September 2010 21:14:56 Matti Bickel wrote:
> I'm a couple weeks late with this, but her
I'm a couple weeks late with this, but here goes:
from my failed attempts at reviving GLEP33 grow a discussion with
ferringb on IRC about how to get what I wanted anyway :)
We agreed that having eclasses specific to a package located someplace
near the actual ebuilds was beneficial and should be s
11 matches
Mail list logo
