1 |
Robert Buchholz wrote: |
2 |
> On Saturday 22 August 2009, Maciej Mrozowski wrote: |
3 |
>> It's true, but being able to modularize profile may outweights the |
4 |
>> need to be strict-with-the-book here - it's a matter of usefulness. I |
5 |
>> think it should be decided by those who actually do the work in |
6 |
>> profile, whether it's worthy to push this now instead of waiting for |
7 |
>> EAPI approval. |
8 |
>> |
9 |
>> So, can profile developers share their view? |
10 |
> |
11 |
> We have kept SLOT dependencies and other >EAPI-0 features out of the |
12 |
> tree profiles, introduced profile EAPI versioning to foster |
13 |
> interoperability. Now what you propose is to break this deliberate |
14 |
> upgrade process to introduce a feature no one proposed for the profiles |
15 |
> directory in the last years? |
16 |
> |
17 |
> I wonder what the value of the PMS specification is if every time an |
18 |
> inconsistency comes up the argument is raised that it should document |
19 |
> portage behavior. EAPI 1, 2 and 3 have been agreed by the council and |
20 |
> PMS is in a stage where Portage should obey its definitions and not the |
21 |
> other way around. |
22 |
> I am not saying that this is the *fastest* way to innovate (although in |
23 |
> my opinion it is a good way to keep interoperability). |
24 |
> However this PMS process is what council has chosen for Gentoo, and |
25 |
> either you follow it, or you try to improve it (working with the PMS |
26 |
> subproject people), or you bring up a proposal to redefine how we |
27 |
> handle standards within the tree. |
28 |
> |
29 |
> Trying to ignore the fact this standard exists is a way to breakage. |
30 |
> |
31 |
> |
32 |
> Robert |
33 |
|
34 |
From what I've seen here, at least part of the problem here stems from |
35 |
the fact that this feature won't be considered until EAPI-4, and that |
36 |
means it might be a long way off yet. This, in my mind, raises the |
37 |
question of whether the current PMS/EAPI process is too slow in certain |
38 |
circumstances and could it be modified to speed things up when deemed |
39 |
necessary? |
40 |
|
41 |
Could there be room for "fast track" EAPI's to be considered on some |
42 |
occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with the |
43 |
"package.* as directory in profiles" feature included? |
44 |
|
45 |
If this is a matter of what the council has decided, would a simple |
46 |
solution be to have a motion for amendment / fast-track of EAPI2.1 (or |
47 |
alternative solution) brought up and voted on by the council? |
48 |
|
49 |
AllenJB |