List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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:
So here goes: I want to see GLEP33 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
(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-188.8.131.52
Instead of all the backwards-compatibility issues the GLEP deals with,
we could just sneak the implementation into EAPI4 and be done with it.