| 1 |
On Mon, 02 Aug 2010 11:56:08 +0200 |
| 2 |
Matti Bickel <mabi@g.o> wrote: |
| 3 |
> I've been told that my use of eblits in dev-lang/php is something I |
| 4 |
> should get rid of as soon as possible. Suggested alternative by |
| 5 |
> ferring: use elibs. |
| 6 |
> |
| 7 |
> So here goes: I want to see GLEP33[1] implemented in portage, so I can |
| 8 |
> shift the eblits core and currently global functions into elibs and |
| 9 |
> probably push the eblits I use for php into the same structure. |
| 10 |
|
| 11 |
Aren't you really after per-package eclasses, not elibs? Now that |
| 12 |
eclasses for installed packages are handled sanely, elibs are just a way |
| 13 |
to reduce the metadata generation impact of changing a widely used |
| 14 |
eclass, and processors are getting faster faster than the tree is |
| 15 |
growing. |
| 16 |
|
| 17 |
> Instead of all the backwards-compatibility issues the GLEP deals with, |
| 18 |
> we could just sneak the implementation into EAPI4 and be done with it. |
| 19 |
|
| 20 |
No, you can't make global scope changes just in an EAPI without |
| 21 |
screwing up user systems. You have to do the whole "wait several years" |
| 22 |
thing for them. If you don't want to screw things up for users, the |
| 23 |
only way of avoiding a huge wait for all of this would be to adopt GLEP |
| 24 |
55, and of course GLEP 55 won't ever be adopted without years of noise |
| 25 |
anyway, so this whole discussion is purely academic. |
| 26 |
|
| 27 |
-- |
| 28 |
Ciaran McCreesh |
Archives