On 08/05/2010 05:27 AM, Brian Harring wrote:
> 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.

I guess the point here is that we need a stable version of PMs for a
reasonable time before we switch tree ebuilds to it.
People will hate me if I use EAPI4 functionality in php ebuilds as soon
as councils approves EAPI4. Security might want a word with me if it's a
fast-stable security release.

But this is orthogonal to GLEP55, afaik.

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

I'm not going to argue that PMS doesn't seem to say anything about the
content of ECLASSDIR other than that eclasses are stored inside it.
A new dir is fine with me. Can we have that in EAPI4 or is that already
being finalized?

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

Okay, so how can I, as somebody not familiar with PM dev process and
roadmaps, help in getting this done?