1 |
On Thu, Aug 05, 2010 at 07:22:20PM +0200, Matti Bickel wrote: |
2 |
> On 08/05/2010 05:27 AM, Brian Harring wrote: |
3 |
> > If a PM encounters an EAPI it doesn't understand/support, by |
4 |
> > definition the metadata it tried generating is not usable- the PM |
5 |
> > doesn't support that new EAPI thus it has zero clue how to |
6 |
> > generate/store metadata appropriately for that EAPI. |
7 |
> |
8 |
> I guess the point here is that we need a stable version of PMs for a |
9 |
> reasonable time before we switch tree ebuilds to it. |
10 |
> People will hate me if I use EAPI4 functionality in php ebuilds as soon |
11 |
> as councils approves EAPI4. Security might want a word with me if it's a |
12 |
> fast-stable security release. |
13 |
> |
14 |
> But this is orthogonal to GLEP55, afaik. |
15 |
|
16 |
Glep55 suffers the same, rather than being orthogonal. |
17 |
|
18 |
Alternatively phrased, you can't start using a new feature until |
19 |
support is out there. So after an EAPI is defined, you've got a month |
20 |
or so realistically, and that's assuming portage/friends support the |
21 |
EAPI at the time it's minted as official. |
22 |
|
23 |
|
24 |
> >> Bad. So I guess it's back to ferring's "use a new directory not readable |
25 |
> >> by old PMs" idea. GLEP55++, but having to wait several months for that |
26 |
> >> and GLEP33 *on top* is not very motivation for me. |
27 |
> > |
28 |
> > The reason for a new directory was to enforce a new structuring that |
29 |
> > was more friendly to changelogs and manifests- due to ECLASSDIR being |
30 |
> > documented in PMS (and annoyingly eclass-manpagers being the sole |
31 |
> > consumer of it) adding a new eclasses directory should require a EAPI |
32 |
> > bump. |
33 |
> |
34 |
> I'm not going to argue that PMS doesn't seem to say anything about the |
35 |
> content of ECLASSDIR other than that eclasses are stored inside it. |
36 |
> A new dir is fine with me. Can we have that in EAPI4 or is that already |
37 |
> being finalized? |
38 |
|
39 |
EAPI4 is a bit up in the air from where I'm sitting. Write up |
40 |
a proposal (or clean up the g33 glep) and push it- even if you miss |
41 |
eapi4 (doubtful), it'll be in the next eapi. |
42 |
|
43 |
|
44 |
> > As for per package eclasses, I'd personally require accessing the |
45 |
> > package eclass being done via a new inherit function- this avoids some |
46 |
> > annoying gotchas. That said, I don't see a reason right now that it |
47 |
> > couldn't be added into an EAPI, per the reasons I laid out earlier in |
48 |
> > this email. |
49 |
> |
50 |
> Okay, so how can I, as somebody not familiar with PM dev process and |
51 |
> roadmaps, help in getting this done? |
52 |
|
53 |
I'd suggest roughly the following- |
54 |
|
55 |
pkg-inherit ['the per pkg-name'] ; specifically, pkg-inherit |
56 |
automatically grabs some commonly named package eclass- or you can |
57 |
optionally override the per package eclass to use. |
58 |
|
59 |
The reason for the option is in transitioning away from an old eclass |
60 |
implementation, or having an eclass per major version (assuming the |
61 |
major versions warrant a seperate eclass). |
62 |
|
63 |
Note that '/' and friends should be banned from the invocation, to |
64 |
prevent a pkg-inherit from trying to reach into another packages |
65 |
eclasses. |
66 |
~brian |