On Tue, 05 Jul 2011 00:47:07 +0300, Nikos Chantziaras wrote: > > 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.
changed-use also acts on added/removed flags, it just doesn't recompile when the added/removed flag is not in use. So if my KDE system has -gtk to use your first example, you are right in that adding a gtk USE flag will not rebuild it until the next update and my program will continue to work as it did. However, adding an enabled multithreading USE flag as your second example will force a rebuild. It seems that the trade off here is that I have may have cruft that was previously compulsory but is now optional for a couple of weeks, but I won't have to rebuild libreoffice or xulrunner every time a dev tweaks a USE flag that doesn't affect me. That seems a reasonable trade to me, but I still have an open mind. -- Neil Bothwick Top Oxymorons Number 2: Exact estimate
signature.asc
Description: PGP signature
