Re: [gentoo-dev] RFC: Reviving GLEP33

[Brian Harring]

On Mon, Aug 02, 2010 at 11:55:07PM +0200, Matti Bickel wrote:
> On 08/02/2010 10:15 PM, Ciaran McCreesh wrote:
> > Aren't you really after per-package eclasses, not elibs?
>
> Yes. I don't care whether the snippets may affect metadata. They already
> don't (at one time they did, but we got warned that that's illegal -
> that's why php-5.3 ebuilds have their metadata folded back into them).
>
> >> Instead of all the backwards-compatibility issues the GLEP deals with,
> >> we could just sneak the implementation into EAPI4 and be done with it.
> >
> > No, you can't make global scope changes just in an EAPI without
> > screwing up user systems. You have to do the whole "wait several years"
> > thing for them.

While it's been repeated many, many time, this statement is provably 
false.  What _is_ true is that you cannot have new global scope 
functionality that influences/sets EAPI.  That is _accurate_ truth of 
the matter.

If a PM encounters an EAPI it doesn't understand/support, by 
definition the metadata it tried generating is not usable- the PM 
doesn't support that new EAPI thus it has zero clue how to 
generate/store metadata appropriately for that EAPI.

Note that since policy forbids EAPI being set in eclasses _anyways_, 
there isn't a conflict here despite ciaran's claims.

If an EAPI adds a new global function that cannot set/influence EAPI, 
PM's that don't support that EAPI will spit complaints about 'missing 
command' during sourcing- however the PM will still see the EAPI value 
is one it knows it doesn't support, and act accordingly.

Basically, the only real issue here is that PMs invalidly output 
stdout/stderr for EAPIs they don't support- this gives the perception 
that there is an issue, when in reality it's just the PM being 
slightly user unfriendly.


> Bad. So I guess it's back to ferring's "use a new directory not readable
> by old PMs" idea. GLEP55++, but having to wait several months for that
> and GLEP33 *on top* is not very motivation for me.

The reason for a new directory was to enforce a new structuring that 
was more friendly to changelogs and manifests- due to ECLASSDIR being 
documented in PMS (and annoyingly eclass-manpagers being the sole 
consumer of it) adding a new eclasses directory should require a EAPI 
bump.


As for per package eclasses, I'd personally require accessing the 
package eclass being done via a new inherit function- this avoids some 
annoying gotchas.  That said, I don't see a reason right now that it 
couldn't be added into an EAPI, per the reasons I laid out earlier in 
this email.
~brian