On Mon, 02 Aug 2010 11:56:08 +0200 Matti Bickel <m...@gentoo.org> wrote: > 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. > > So here goes: I want to see GLEP33[1] implemented in portage, so I can > shift the eblits core and currently global functions into elibs and > probably push the eblits I use for php into the same structure.
Aren't you really after per-package eclasses, not elibs? Now that eclasses for installed packages are handled sanely, elibs are just a way to reduce the metadata generation impact of changing a widely used eclass, and processors are getting faster faster than the tree is growing. > Instead of all the backwards-compatibility issues the GLEP deals with, > we could just sneak the implementation into EAPI4 and be done with it. No, you can't make global scope changes just in an EAPI without screwing up user systems. You have to do the whole "wait several years" thing for them. If you don't want to screw things up for users, the only way of avoiding a huge wait for all of this would be to adopt GLEP 55, and of course GLEP 55 won't ever be adopted without years of noise anyway, so this whole discussion is purely academic. -- Ciaran McCreesh
signature.asc
Description: PGP signature
