Today I got this: # emerge -pvuDN --complete-graph y --with-bdeps y --rebuild-if-new-rev y world [ebuild rR ] sys-apps/util-linux-2.22.2 USE="cramfs crypt ncurses nls {test} udev unicode -ddate -old-linux -perl (-selinux) -slang -static-libs -suid" 0 kB [ebuild U ] sys-fs/udev-init-scripts-25 [23] 0 kB [ebuild U ] sys-apps/hwids-20130329 [20130302] USE="udev" 0 kB [ebuild N ] app-text/build-docbook-catalog-1.19.1 0 kB [ebuild N ] app-text/docbook-xsl-stylesheets-1.78.0 USE="-ruby" 0 kB [ebuild U ] sys-fs/udev-200 [197-r8] USE="firmware-loader%* kmod openrc -acl -doc -gudev -hwdb -introspection -keymap (-selinux) -static-libs" 0 kB [ebuild rR ] x11-base/xorg-server-1.13.1 USE="minimal nptl udev xorg xvfb -dmx -doc -ipv6 -kdrive (-selinux) -static-libs -suid -tslib -xnest" 0 kB I can't seem to find out what triggered the rebuild of util-linux, but whatever it is, it makes no sense to rR-rebuild something before everything else. Maybe it's the dependency on virtual/udev that's somehow tied to sys-fs/udev, but wrongly processed by rebuild-if-new-rev. Reproducible: Always
Created attachment 343816 [details] Debug output of the original emerge command
Created attachment 343818 [details] emerge --info
The --rebuild-if-new-rev code "sees through" virtuals, so that explains why a virtual/udev dependency and sys-fs/udev upgrade would trigger a rebuild of util-linux. The odd build order is probably due to circular dependencies, which is common in system packages. If so, then I don't think there's any good way to fix this, other than to stop using --rebuild-if-new-rev. Ideally, we'd be able to automatically trigger all desirable rebuilds without using options like --rebuild-if-new-rev. For example, with EAPI 5, we have automatic rebuilds triggered by slot-operators and sub-slots: http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators
First off, I looked at the wiki article and I must say that if this strategy is adopted by all/most ebuilds, the tree will be a better place. But as of now, I suppose the circular deps situation can cause trouble with revdep-if-new-rev in case pkgX and pkgY are to be upgraded while depending on each other. But that's not the case here with udev and util-linux. Only udev needs to be upgraded, so why not merge udev first and util-linux afterwards? rebuild-if-unbuilt cannot be satisfied, but rebuild-if-new-* can be, it seems. And even if both udev and util-linux were in need of upgrade while depending on each other, rebuild-if-new-* can function: one of the two packages is upgraded, then the other and finally the first one is re-compiled. I suppose that would require implementing multiple builds of a single package in a single emerge run. Alternatively, one of the two packages is upgraded, then the other and the next call of "emerge --deep --rebuild-if-new-* world" (or something similar) knows to rR-merge the former package. Actually, this feature would be a nice thing to have even outside any circular deps matters. I mean, the feature of the unfinished, but necessary rR builds being remembered and included in the merge set next time emerge is run with rebuild-if-new-*. I wonder, though, what kind of amount of people use rebuild-if-new-* at all.
This also reminds me that the stable sys-fs/udev is now -200, while virtual/udev stays at -197. I have no idea if that's any kind of problem at all; just FYI.
(In reply to comment #4) Yeah, it seems like we could handle this better. Also, it's possible for the same issue to affect rebuilds involving slot-operators and sub-slots.
*** Bug 569938 has been marked as a duplicate of this bug. ***
*** Bug 567552 has been marked as a duplicate of this bug. ***
*** Bug 575960 has been marked as a duplicate of this bug. ***
*** Bug 685280 has been marked as a duplicate of this bug. ***
*** Bug 787806 has been marked as a duplicate of this bug. ***
*** Bug 789966 has been marked as a duplicate of this bug. ***
I'm not sure why but this seems to be hit more often right now on fresh installs. bug 787806, bug 789966
