On 07/05/2011 12:23 AM, Neil Bothwick wrote:
On Mon, 4 Jul 2011 16:57:55 +0200, Daniel Pielmeier wrote:
use --changed-use to avoid a rebuild
instead of --new-use like Neil suggested.
This only works if you *permanently* switch to --changed-use, otherwise
you'll just postpone things to next time you use --new-use.
I haven't used --new-use for years. What's the point of rebuilding
packages just because irrelevant USE flags have changed?
I know I am not a fan of --changed-use myself
Why not? I see no downside to it but I'm willing to be educated.
Imagine this: A package is built by default with Gtk as well as with Qt
support. There is no USE flag which would omit building with one of
those. Then, the ebuild developer introduces those USE flags.
--changed-use will not catch this, so you will continue having both Gtk
and Qt support in the package, even though you're interested only in one
of them (Gnome vs KDE user, for example).
Or, imagine another scenario. A package offers multithreading support,
resulting in a huge speed-up on machines with more than one core or CPU.
But the ebuild configures and builds the package without
multithreading, and there's no USE flag. When the ebuild dev puts a USE
flag in there (and probably turns it on by default), --changed-use will
also not catch this, because it's not a USE flag that changed, but
instead a new one that wasn't there before. So you will continue
running the package in its slow built, missing out on the big
performance gain.
I guess this is why people don't use --changed-use. It won't catch
cases like the above.
