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?

Reply via email to