Re: [gentoo-dev] RFC: Reviving GLEP33

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4877 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]