| 1 |
On Sat, Aug 12, 2017 at 7:05 AM, Michael Palimaka <kensington@g.o> wrote: |
| 2 |
> On 08/12/2017 08:29 PM, Rich Freeman wrote: |
| 3 |
>> On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky <mjo@g.o> wrote: |
| 4 |
>>> On 08/12/2017 03:03 AM, Michał Górny wrote: |
| 5 |
>>>> |
| 6 |
>>>> Please provide some examples of recent in-place USE changes that benefit |
| 7 |
>>>> from revbumps. |
| 8 |
>>>> |
| 9 |
>>> |
| 10 |
>>> There is no single example. Things only get simpler if *all* USE changes |
| 11 |
>>> come with a new revision. |
| 12 |
>>> |
| 13 |
>> This policy change would make my life easier, because for big packages |
| 14 |
>> it would encourage maintainers to not make IUSE changes until they do |
| 15 |
>> revbumps, which would save me a build. I'm running on relatively old |
| 16 |
>> hardware at this point so these rebuilds actually do cost me quite a |
| 17 |
>> bit of time. I'm not sure that not using --changed-use is a great |
| 18 |
>> option though as it will make it that much harder to keep things |
| 19 |
>> consistent when I do modify my package.use/make.conf. |
| 20 |
>> |
| 21 |
> |
| 22 |
> At least now you have the option to run without --changed-use if you |
| 23 |
> want. If inline IUSE changes are completely banned, you will definitely |
| 24 |
> see more pointless rebuilds on your old hardware. |
| 25 |
|
| 26 |
True, since we now have --changed-use (I think this is a relatively |
| 27 |
recent portage feature - before there was only --newuse). |
| 28 |
|
| 29 |
Obviously if I stopped using --changed-use then my installed |
| 30 |
configuration would drift out of sync with the settings in |
| 31 |
/etc/portage. I'm not sure that this causes any other issues in this |
| 32 |
case - there certainly have been issues historically in these |
| 33 |
situations but I think most of them have been eliminated. Changed |
| 34 |
dependencies can definitely cause problems, but I'm less certain that |
| 35 |
changed IUSE does. |
| 36 |
|
| 37 |
> In my experience most |
| 38 |
> developers make a change when there's a change to be made, and don't |
| 39 |
> "save up" changes until some arbitrary delta is reached. We've already |
| 40 |
> an increase in revbumps like this in other areas where inline changes |
| 41 |
> are being discouraged. |
| 42 |
> |
| 43 |
|
| 44 |
I imagine that such practices vary. I know I personally tend to save |
| 45 |
up minor changes for major revisions to reduce the need for testing. |
| 46 |
|
| 47 |
Ultimately though I think the real question is whether not revbumping |
| 48 |
has the potential to break things. I does for dependency changes |
| 49 |
which is why that policy change was made (and I still run with |
| 50 |
--changed-deps anyway because I don't trust devs to not mess this up). |
| 51 |
I think we do need to have more clear evidence that IUSE changes break |
| 52 |
things before we should consider requiring revbumps for this. |
| 53 |
|
| 54 |
It would be nice if big packages waited for revbumps to make IUSE |
| 55 |
changes, but honestly the occassional chromium rebuild doesn't bother |
| 56 |
me that much. Most of it happens with cron anyway. |
| 57 |
|
| 58 |
-- |
| 59 |
Rich |
Archives