On Mon, 14 Jul 2008 03:13:44 +0200
Jeroen Roovers <jer@g.o> wrote:
> On Mon, 14 Jul 2008 00:43:06 +0100
> Ciaran McCreesh <ciaran.mccreesh@...> wrote:
> > People are already doing those other things, and doing them badly,
> > because there's currently no other option. This isn't some
> > hypothetical future requirement.
> 
> When you wrote "doing them badly", did you mean to imply doing
> something else than GLEP 55, or were you just slagging off whoever
> implemented eblits in sys-libs/glibc?

As much as you like to try to find some way of taking offence at
everything I write, no, there's no slagging off in there.

As you know fine well, implementing what clearly should be package
manager provided functionality as hacks in an ebuild is never going to
give a nice, elegant solution. However, if package manager
functionality isn't available and can't become available quickly, it
might be the only solution until such functionality can come along. And
making sure such functionality can come along is at least partly the
Council's responsibility.

> In other words perhaps, is it your opinion that GLEP 55 needs to be
> implemented because sys-libs/glibc requires an immediate rewrite? Are
> there any bug reports that would be good examples of why this new
> implementation is warranted?

GLEP 55 wouldn't even allow an immediate rewrite of glibc because new
EAPIs can't easily be used on system packages. So no. Instead, GLEP 55
would allow a future EAPI to introduce a proper per-package eclass-like
solution at the package manager level, which could then over time be
phased into glibc, and over less time be phased into other packages
that would make use of it. That's the nice thing about the GLEP -- it
allows the phased introduction of a larger class improvements without
major upheaval.

-- 
Ciaran McCreesh