| 1 |
On 08/12/2017 12:22 AM, Michael Palimaka wrote: |
| 2 |
> |
| 3 |
>> Q. But what if I maintain firefox, and I need to change IUSE? |
| 4 |
>> |
| 5 |
>> If the IUSE change isn't important, just make the new revision in a |
| 6 |
>> branch and wait to commit it later when there are more changes |
| 7 |
>> piled up. If it is important (like if its default value changes |
| 8 |
>> RDEPEND), then it would have required a revision anyway. |
| 9 |
> |
| 10 |
> Please stop trying to force workflows on people. Using that same logic, |
| 11 |
> I can make the IUSE change in-place and it would be propagated in the |
| 12 |
> next version bump. |
| 13 |
> |
| 14 |
|
| 15 |
I'm not trying to force anything on anyone, I'm just asking for |
| 16 |
feedback. If it turns out to be a stupid idea, then so be it. |
| 17 |
|
| 18 |
If it's understood that you can make IUSE changes but that they'll only |
| 19 |
be propagated on the next version bump, then there would be no problem. |
| 20 |
But we're about to document a policy that says it's OK to do things that |
| 21 |
wouldn't normally be OK, because --changed-use is there to save us: |
| 22 |
|
| 23 |
The examples of changes that can be done without a revision bump are: |
| 24 |
|
| 25 |
... |
| 26 |
|
| 27 |
* adding a new USE flag or removing an existing one (since change |
| 28 |
in USE flags is going to trigger --changed-use rebuild), |
| 29 |
|
| 30 |
If developers operate under that assumption and if you don't use |
| 31 |
--changed-use, you're going to run into problems eventually. |
| 32 |
|
| 33 |
|
| 34 |
>> * emerge runs a bit faster. |
| 35 |
> |
| 36 |
> Why will it run faster? |
| 37 |
|
| 38 |
The developer now indicates that IUSE has changed, so portage doesn't |
| 39 |
have to figure it out on its own. |
Archives