On 08/12/2017 08:16 PM, Michael Orlitzky wrote: > On 08/12/2017 12:22 AM, Michael Palimaka wrote: >> >>> Q. But what if I maintain firefox, and I need to change IUSE? >>> >>> If the IUSE change isn't important, just make the new revision in a >>> branch and wait to commit it later when there are more changes >>> piled up. If it is important (like if its default value changes >>> RDEPEND), then it would have required a revision anyway. >> >> Please stop trying to force workflows on people. Using that same logic, >> I can make the IUSE change in-place and it would be propagated in the >> next version bump. >> > > I'm not trying to force anything on anyone, I'm just asking for > feedback. If it turns out to be a stupid idea, then so be it. > > If it's understood that you can make IUSE changes but that they'll only > be propagated on the next version bump, then there would be no problem. > But we're about to document a policy that says it's OK to do things that > wouldn't normally be OK, because --changed-use is there to save us: > > The examples of changes that can be done without a revision bump are: > > ... > > * adding a new USE flag or removing an existing one (since change > in USE flags is going to trigger --changed-use rebuild), > > If developers operate under that assumption and if you don't use > --changed-use, you're going to run into problems eventually.
--changed-use is an optional flag and portage works just as well without it. Please provide examples of such problems. > > >>> * emerge runs a bit faster. >> >> Why will it run faster? > > The developer now indicates that IUSE has changed, so portage doesn't > have to figure it out on its own. Please provide some numbers to back up this claim. Even if we assume portage will run faster because we can remove --changed-use (which we can't, because as pointed out in other posts we still need this flag), surely any time savings gained there will be lost by pointless rebuilds?
