It's common to have USE flags that only have an effect on the build under certain conditions like other USE flags being enabled, etc. Recently, gcc had an awt flag added so we can disable the largely antiquated (and originally rather crappy) awt library from gcc. This flag only matters if USE="gcj" is enabled. However, when the flag was added, the dependency calculation determined a change in the flags and triggered a rebuild of all 9 slots of gcc that I have installed, even though most of them have gcj disabled. [ebuild R ] sys-devel/gcc-4.3.6-r1:4.3 USE="cxx doc mudflap (multilib) nls nptl openmp regression-test vanilla (-altivec) -awt% (-fixed-point) -fortran -gcj (-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++ -objc-gc (-gtk%)" 0 kB It would seem to me that we need a mechanism to specify when a USE flag matters so as to not trigger a rebuild when updating a system. Off the top of my head, I would suggest something like adding an USE_EFFECTIVE variable which is populated with each of the USE flags by default (USE_EFFECTIVE="${USE}"), but can be explicitly assigned to mark some USE flags as irrelevant in some cases. In gcc's case, if gcj is disabled, then mark awt as irrelevant. Perhaps the existing syntax for REQUIRED_USE (or something similar) can be employed: # If gcj is not set, then remove awt. USE_EFFECTIVE="${USE} !gcj ? -awt" Maybe there's a more elegant solution, but that's what comes to mind. Either way, the result would be that when the awt flag is added or otherwise toggled, but gcj is disabled, a rebuild of the package is not triggered when running emerge -u.
I'd say ebuilds should use REQUIRED_USE in such a case, i.e. "awt? ( gcj )". gcc ebuilds can't use that because of their EAPI, but they couldn't use such a new thing for the same reason either.
(In reply to Sebastian Luther (few) from comment #1) basically. unless Daniel has other examples in mind, this is a WORKSFORME since the functionality already exists.
I think a better solution may be to add a "flagmove" command to the updates directory. So that when a USE flag needs to be renamed, as was the case for gcc (gtk renamed to awt), vdb can be trivially updated without forcing heavyweight packages to be rebuilt in order to satisfy changed dependencies and/or portage's --newuse logic.
(In reply to Alexandre Rostovtsev from comment #3) ahh, so this was caused by gtk being renamed to awt? I wasn't aware of that. (In reply to SpanKY from comment #2) If you need some more examples, I actually archive my portage logs and I'm sure I can come up with many more cases where a rebuild was triggered due to a change in the USE flags that had a zero net impact on the actual build & resulting binaries. Mind you, I have no problem with these changes at all! I love seeing portage grow, adapt and mature. I would just like for these changes to occur more fluidly (Especially with 9 slots of gcc, which I use mostly or kernel testing and another 3 crossdev toolchains of various flavors).
(In reply to Daniel Santos from comment #4) generally having flags get added/removed is not the same thing as described originally -- a USE flag that is dependent upon another USE flag
(In reply to SpanKY from comment #5) > (In reply to Daniel Santos from comment #4) > > generally having flags get added/removed is not the same thing as described > originally -- a USE flag that is dependent upon another USE flag ah hah! well that works for me, thanks!
