| 1 |
>>>>> On Tue, 3 Oct 2017, Rich Freeman wrote: |
| 2 |
|
| 3 |
> If the behavior of portage doesn't match the specification in PMS that |
| 4 |
> is reason enough to change one or the other. The purpose of PMS is to |
| 5 |
> document how package managers are supposed to behave. |
| 6 |
|
| 7 |
> You could: |
| 8 |
|
| 9 |
> 1. Change portage to behave as PMS specifies. |
| 10 |
> 2. Change PMS to specify portage's behavior. |
| 11 |
> 3. Change PMS to make the behavior explicitly undefined. |
| 12 |
|
| 13 |
> Sure, this might be a lower-priority bug but this seems like a valid |
| 14 |
> one. What is the point in having a specification if we don't actually |
| 15 |
> specify what we're doing? |
| 16 |
|
| 17 |
I believe I am aware of the options. :-) The goal is indeed that PMS |
| 18 |
and Portage behaviour should match, which isn't the case since 2011. |
| 19 |
So the normal course of action would be to change Portage. There are |
| 20 |
two aspects that make me believe that changing PMS would be a better |
| 21 |
choice, though: First, the feature is of questionable usefulness and |
| 22 |
hasn't seen any use in the tree. And second, if we implement GLEP 73 |
| 23 |
(which is in the list for EAPI 7) we are likely to tighten the rules |
| 24 |
in any case. So if we go for your option 1 or 3 above, the spec (and |
| 25 |
package managers as well) will end up with EAPI dependent behaviour, |
| 26 |
for a feature that isn't used. The proposed retroactive change would |
| 27 |
avoid that, and for existing EAPIs there is no practical difference. |
| 28 |
|
| 29 |
Ulrich |
Archives