1 |
On 08/05/2010 05:27 AM, Brian Harring wrote: |
2 |
> If a PM encounters an EAPI it doesn't understand/support, by |
3 |
> definition the metadata it tried generating is not usable- the PM |
4 |
> doesn't support that new EAPI thus it has zero clue how to |
5 |
> generate/store metadata appropriately for that EAPI. |
6 |
|
7 |
I guess the point here is that we need a stable version of PMs for a |
8 |
reasonable time before we switch tree ebuilds to it. |
9 |
People will hate me if I use EAPI4 functionality in php ebuilds as soon |
10 |
as councils approves EAPI4. Security might want a word with me if it's a |
11 |
fast-stable security release. |
12 |
|
13 |
But this is orthogonal to GLEP55, afaik. |
14 |
|
15 |
>> Bad. So I guess it's back to ferring's "use a new directory not readable |
16 |
>> by old PMs" idea. GLEP55++, but having to wait several months for that |
17 |
>> and GLEP33 *on top* is not very motivation for me. |
18 |
> |
19 |
> The reason for a new directory was to enforce a new structuring that |
20 |
> was more friendly to changelogs and manifests- due to ECLASSDIR being |
21 |
> documented in PMS (and annoyingly eclass-manpagers being the sole |
22 |
> consumer of it) adding a new eclasses directory should require a EAPI |
23 |
> bump. |
24 |
|
25 |
I'm not going to argue that PMS doesn't seem to say anything about the |
26 |
content of ECLASSDIR other than that eclasses are stored inside it. |
27 |
A new dir is fine with me. Can we have that in EAPI4 or is that already |
28 |
being finalized? |
29 |
|
30 |
> As for per package eclasses, I'd personally require accessing the |
31 |
> package eclass being done via a new inherit function- this avoids some |
32 |
> annoying gotchas. That said, I don't see a reason right now that it |
33 |
> couldn't be added into an EAPI, per the reasons I laid out earlier in |
34 |
> this email. |
35 |
|
36 |
Okay, so how can I, as somebody not familiar with PM dev process and |
37 |
roadmaps, help in getting this done? |