Hi folks, 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. Basic question: what needs to be done to get this GLEP accepted and implemented (it's current status is moribound)? I extracted a list of things we (or rather the portage and all other PM teams) need to do: (1) create elibs() function to enable importing elibs (2) extend repoman to handle new style elibs and eclass signing/checking (3) profit ;) Also, there're some question I have: (1) The GLEP (under "The reduced role of Eclasses,[...]") speaks of "Cases where the constant [metadata] requirement is violated are known" - who exactly are the current offenders? (2) What's the dev community feeling on "The end of backwards compatibility..." section in the GLEP? Personal opinion: when the council reached consensus that old eclasses can be removed with due last-rites, this section became obsolete. Just putting new-style eclasses in their own dirs in eclass/ might again be an option. Please discuss. (3) Continuing with (2) do you feel we still need to provide a eclass compat build (tarball) to users *still* not using a sane portage version? If no, section "The start of a different phase of backwards compatibility" can probably be stripped from the GLEP. I silently assumed that our infra servers are running >=portage-2.1.4.4 here. Instead of all the backwards-compatibility issues the GLEP deals with, we could just sneak the implementation into EAPI4 and be done with it. [1] http://www.gentoo.org/proj/en/glep/glep-0033.html
signature.asc
Description: OpenPGP digital signature
