| 1 |
2009/8/21 Robert Buchholz <rbu@g.o>: |
| 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 |
|
| 35 |
When the PMS "subproject" is overwhelmingly ruled by a single person |
| 36 |
who doesn't have official Gentoo developer status and yet it is |
| 37 |
allowed to remove features from portage (the reference implementation) |
| 38 |
that predated PMS at the direction of this same non-dev, you start to |
| 39 |
have a very big problem. |
| 40 |
|
| 41 |
If you were building a house, and the blueprints had been signed off |
| 42 |
on calling for 1 meter high doors, but the builder had built in 2 |
| 43 |
meter high doors, would you then go back to the builder and require |
| 44 |
him to do something that makes those doors unusable for the vast |
| 45 |
majority of people entering the house? |
| 46 |
|
| 47 |
If this feature, which HAD been documented (in bugzilla and |
| 48 |
commitlogs) prior to the first RFC for PMS, had instead been added |
| 49 |
yesterday, I would completely agree that we should revert it and it |
| 50 |
should be part of a future specification. Since this is instead a |
| 51 |
situation where the blueprints were wrong and the builder was correct, |
| 52 |
let's not go throwing away our "normal sized" doors. |
| 53 |
|
| 54 |
Since I, as well as the only person who's loudly having an issue with |
| 55 |
portage and PMS not matching up in this respect, are both USERS and |
| 56 |
NOT Gentoo developers, it's my opinion that portage should be left |
| 57 |
alone and PMS should be corrected to align with the spirit, if not the |
| 58 |
letter of what was documented WELL after the initial commit that added |
| 59 |
the feature. And, since I and the main contributor to PMS are both |
| 60 |
users, it's also my opinion that NEITHER of us should have anything to |
| 61 |
do with the policy/specification defining package manager behavior for |
| 62 |
the most prolific package manager in use today. |
Archives