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?
signature.asc
Description: OpenPGP digital signature
