| Summary: | sys-apps/portage: rebuild triggered by dependency upgrade has incorrect merge order, caused by circular dependencies (affects slot-operator/sub-slot rebuilds and --rebuild-* options) | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Roman Žilka <roman.zilka> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | alexander, awilfox.gentoo, esigra, kentnl, kilgorephotoshop, kingjon3377, pacho, perl, peter, sam, toralf |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=468052 https://bugs.gentoo.org/show_bug.cgi?id=596664 https://bugs.gentoo.org/show_bug.cgi?id=629952 https://bugs.gentoo.org/show_bug.cgi?id=686838 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 155723, 689644 | ||
| Attachments: |
Debug output of the original emerge command
emerge --info |
||
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 567552 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 |
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