On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote: > 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
There's a caveat here; imagine one of the current PM's processing an EAPI=4 (or whatever) ebuild that uses elib- specifically there will be a global scope function invocation of a function that doesn't exist. In the past, a minority of folk have raised complaints about this- it was never stated as best I know, but my assumption looking back is that it was due primarily to paludis getting pissy about ebuilds outputing anything during metadata sourcing (paludis at this point isn't pissy about it- mainly sinc eclasses can invoke die after all). Managers should implementat that functionality; orthogonal to it, we've got a few options for how to deal with an EAPI=4 ebuild being metadata sourced by a <=EAPI3 PM (meaning, there will be a "command not found" spat to stderr during sourcing): 1) if 'elib' isn't defined, define it as a no-op w/in a profile.bashrc. This doesn't work for paludis (they don't do profile bashrc at all), but works for pkgcore/portage- would silence the output in the majority basically. This address gentoo-x86, but cleanly for stand alone repositories. 2) variation of #1, require consuming ebuilds to inherit an eclass that has the fallback no-op in it, rather than profile. This would work for paludis, although again, it's gentoo-x86 specific and would be limited to overlays. All standalone tree's would have to bundle their own eclass w/ the no-op. 3) glep55; note that I'm purely listing out options here, will leave the people pushing that glep to advocate it. 4) I should've thought of this a few years back, but frankly another option is to fix the @!#*ing package managers. They should collect stdout/stderr output during sourcing, but only output it if the metadata sourcing resulted in an EAPI the PM supported. If it's an EAPI the PM doesn't support, it wouldn't know how to write the cache for the ebuild anyways. 5) ignore that their may be output, and get on with our lives and implementing features. From where I'm sitting, #4 should be implemented regardless of what solution is choosen. Personally, I prefer #1, but #2 is easy enough to jam in if people really are bother by a couple of overlays making noise for people running a stale package manager. Either way, this particular naggle needs a decision. > (2) extend repoman to handle new style elibs and eclass signing/checking > (3) profit ;) I'd suggest breaking this up- specifically try to get elibs in, but do not bind their timelines/existance to eclass refactoring. > 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? Talk to vapier- he had some abuses of SLOT rewriting during merging (nasty hack that only works for portage) last time I knew. Php had something similar at the time this glep was written, although that's since been removed. > (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. The env saving part of that section is no longer relevant, and the question of how long to keep eclasses around was addressed in the last council meeting: http://www.gentoo.org/proj/en/council/meeting-logs/20100726-summary.txt Now, if eclasses2 went forward, how long to keep the old eclass directory around is a seperate question. > Instead of all the backwards-compatibility issues the GLEP deals with, > we could just sneak the implementation into EAPI4 and be done with it. Exempting tweaking the inherit mechanism to use a new eclass location, a lot of the env saving bits of that glep are no longer relevant. My suggestion? Split this into two, elibs, and eclass refactoring. ~brian
pgpXAFChcB47d.pgp
Description: PGP signature
