| 1 |
On 08/12/2017 08:29 PM, Rich Freeman wrote: |
| 2 |
> On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky <mjo@g.o> wrote: |
| 3 |
>> On 08/12/2017 03:03 AM, Michał Górny wrote: |
| 4 |
>>> |
| 5 |
>>> Please provide some examples of recent in-place USE changes that benefit |
| 6 |
>>> from revbumps. |
| 7 |
>>> |
| 8 |
>> |
| 9 |
>> There is no single example. Things only get simpler if *all* USE changes |
| 10 |
>> come with a new revision. |
| 11 |
>> |
| 12 |
> This policy change would make my life easier, because for big packages |
| 13 |
> it would encourage maintainers to not make IUSE changes until they do |
| 14 |
> revbumps, which would save me a build. I'm running on relatively old |
| 15 |
> hardware at this point so these rebuilds actually do cost me quite a |
| 16 |
> bit of time. I'm not sure that not using --changed-use is a great |
| 17 |
> option though as it will make it that much harder to keep things |
| 18 |
> consistent when I do modify my package.use/make.conf. |
| 19 |
> |
| 20 |
|
| 21 |
At least now you have the option to run without --changed-use if you |
| 22 |
want. If inline IUSE changes are completely banned, you will definitely |
| 23 |
see more pointless rebuilds on your old hardware. In my experience most |
| 24 |
developers make a change when there's a change to be made, and don't |
| 25 |
"save up" changes until some arbitrary delta is reached. We've already |
| 26 |
an increase in revbumps like this in other areas where inline changes |
| 27 |
are being discouraged. |
Archives