public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Re: Revisions for USE flag changes
Date: Sat, 12 Aug 2017 07:18:01 -0400	[thread overview]
Message-ID: <CAGfcS_ktCzXdWcNj-SEwgN69Hdxn-JSNPbbg51N5kB=aQP=qfw@mail.gmail.com> (raw)
In-Reply-To: <9a9b48c9-db50-f4e5-d4bb-cb4e0ebe8858@gentoo.org>

On Sat, Aug 12, 2017 at 7:05 AM, Michael Palimaka <kensington@gentoo.org> wrote:
> On 08/12/2017 08:29 PM, Rich Freeman wrote:
>> On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky <mjo@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.

-- 
Rich


  reply	other threads:[~2017-08-12 11:18 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11 23:50 [gentoo-dev] Revisions for USE flag changes Michael Orlitzky
2017-08-12  0:45 ` Brian Evans
2017-08-12  0:59   ` Michael Orlitzky
2017-08-12  1:04     ` Michael Orlitzky
2017-08-12  1:11     ` Brian Evans
2017-08-12  8:39       ` Paweł Hajdan, Jr.
2017-08-12  9:58         ` Michael Orlitzky
2017-08-13  2:52           ` [gentoo-dev] " Duncan
2017-08-13 10:11             ` Michael Orlitzky
2017-08-13 10:18               ` M. J. Everitt
2017-08-14  1:34                 ` Duncan
2017-08-16 20:12               ` Daniel Campbell
2017-08-18 14:50             ` Duncan
2017-08-13  5:01           ` [gentoo-dev] " Hans de Graaff
2017-08-13 10:38             ` Michael Orlitzky
     [not found]               ` <CAJ0EP42EaW8=dm0c26Gaij9gEAmTVHxiyp5+Hc_CYGzEypudsA@mail.gmail.com>
     [not found]                 ` <CAJ0EP40yVVpLqHL5qVixxgvMmJc7ezRsn42qLoe621wS0KF-VA@mail.gmail.com>
     [not found]                   ` <CAJ0EP43YbX-vA5cWcFm_Etin4H31Nq2s_xYsrTwuOK6LVyW+9A@mail.gmail.com>
     [not found]                     ` <CAJ0EP42HkoYEkL1vt=Lyt-Dw-1XkdAXed8DrBp4oYB9j01+PKQ@mail.gmail.com>
2017-08-13 17:28                       ` Mike Gilbert
2017-08-12  4:22 ` [gentoo-dev] " Michael Palimaka
2017-08-12 10:16   ` Michael Orlitzky
2017-08-12 10:58     ` Michael Palimaka
2017-08-12 10:32   ` Rich Freeman
2017-08-12  5:02 ` [gentoo-dev] " Hans de Graaff
2017-08-12  7:03 ` Michał Górny
2017-08-12  9:57   ` Michael Orlitzky
2017-08-12 10:04     ` Toralf Förster
2017-08-12 10:29     ` Rich Freeman
2017-08-12 11:05       ` [gentoo-dev] " Michael Palimaka
2017-08-12 11:18         ` Rich Freeman [this message]
2017-08-14 12:01         ` Jason Zaman
2017-08-16  3:22           ` Michael Orlitzky
2017-08-16 15:56             ` Duncan
2017-08-16 16:09               ` Rich Freeman
2017-08-17  4:27             ` Jason Zaman
2017-08-12 14:14       ` [gentoo-dev] " Michael Orlitzky
2017-08-13  2:32         ` [gentoo-dev] " Duncan
2017-08-13 10:08           ` Michael Orlitzky
2017-08-13 16:06 ` [gentoo-dev] " William Hubbs
2017-08-13 16:12   ` Michael Orlitzky
2017-08-14 16:29     ` William L. Thomson Jr.
2017-08-14 16:21 ` William L. Thomson Jr.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGfcS_ktCzXdWcNj-SEwgN69Hdxn-JSNPbbg51N5kB=aQP=qfw@mail.gmail.com' \
    --to=rich0@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox