| 1 |
On Saturday 22 August 2009, Maciej Mrozowski wrote: |
| 2 |
> It's true, but being able to modularize profile may outweights the |
| 3 |
> need to be strict-with-the-book here - it's a matter of usefulness. I |
| 4 |
> think it should be decided by those who actually do the work in |
| 5 |
> profile, whether it's worthy to push this now instead of waiting for |
| 6 |
> EAPI approval. |
| 7 |
> |
| 8 |
> So, can profile developers share their view? |
| 9 |
|
| 10 |
We have kept SLOT dependencies and other >EAPI-0 features out of the |
| 11 |
tree profiles, introduced profile EAPI versioning to foster |
| 12 |
interoperability. Now what you propose is to break this deliberate |
| 13 |
upgrade process to introduce a feature no one proposed for the profiles |
| 14 |
directory in the last years? |
| 15 |
|
| 16 |
I wonder what the value of the PMS specification is if every time an |
| 17 |
inconsistency comes up the argument is raised that it should document |
| 18 |
portage behavior. EAPI 1, 2 and 3 have been agreed by the council and |
| 19 |
PMS is in a stage where Portage should obey its definitions and not the |
| 20 |
other way around. |
| 21 |
I am not saying that this is the *fastest* way to innovate (although in |
| 22 |
my opinion it is a good way to keep interoperability). |
| 23 |
However this PMS process is what council has chosen for Gentoo, and |
| 24 |
either you follow it, or you try to improve it (working with the PMS |
| 25 |
subproject people), or you bring up a proposal to redefine how we |
| 26 |
handle standards within the tree. |
| 27 |
|
| 28 |
Trying to ignore the fact this standard exists is a way to breakage. |
| 29 |
|
| 30 |
|
| 31 |
Robert |
Archives