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 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
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
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
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.