On Sat, Aug 12, 2017 at 7:05 AM, Michael Palimaka <kensing...@gentoo.org> wrote:
> On 08/12/2017 08:29 PM, Rich Freeman wrote:
>> On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky <m...@gentoo.org> wrote:
>>> On 08/12/2017 03:03 AM, Michał Górny wrote:
>>>> Please provide some examples of recent in-place USE changes that benefit
>>>> from revbumps.
>>> There is no single example. Things only get simpler if *all* USE changes
>>> come with a new revision.
>> This policy change would make my life easier, because for big packages
>> it would encourage maintainers to not make IUSE changes until they do
>> revbumps, which would save me a build.  I'm running on relatively old
>> hardware at this point so these rebuilds actually do cost me quite a
>> bit of time.  I'm not sure that not using --changed-use is a great
>> option though as it will make it that much harder to keep things
>> consistent when I do modify my package.use/make.conf.
> At least now you have the option to run without --changed-use if you
> want. If inline IUSE changes are completely banned, you will definitely
> see more pointless rebuilds on your old hardware.

True, since we now have --changed-use (I think this is a relatively
recent portage feature - before there was only --newuse).

Obviously if I stopped using --changed-use then my installed
configuration would drift out of sync with the settings in
/etc/portage.  I'm not sure that this causes any other issues in this
case - there certainly have been issues historically in these
situations but I think most of them have been eliminated.  Changed
dependencies can definitely cause problems, but I'm less certain that
changed IUSE does.

> In my experience most
> developers make a change when there's a change to be made, and don't
> "save up" changes until some arbitrary delta is reached. We've already
> an increase in revbumps like this in other areas where inline changes
> are being discouraged.

I imagine that such practices vary.  I know I personally tend to save
up minor changes for major revisions to reduce the need for testing.

Ultimately though I think the real question is whether not revbumping
has the potential to break things.  I does for dependency changes
which is why that policy change was made (and I still run with
--changed-deps anyway because I don't trust devs to not mess this up).
I think we do need to have more clear evidence that IUSE changes break
things before we should consider requiring revbumps for this.

It would be nice if big packages waited for revbumps to make IUSE
changes, but honestly the occassional chromium rebuild doesn't bother
me that much.  Most of it happens with cron anyway.


Reply via email to