On Mon, 14 Jul 2008 03:13:44 +0200 Jeroen Roovers <[EMAIL PROTECTED]> wrote: > On Mon, 14 Jul 2008 00:43:06 +0100 > Ciaran McCreesh <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
