Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 463976 - 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)
Summary: sys-apps/portage: rebuild triggered by dependency upgrade has incorrect merge...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
: 567552 569938 685280 (view as bug list)
Depends on:
Blocks: 155723 build-order
  Show dependency tree
Reported: 2013-03-31 10:42 UTC by Roman Žilka
Modified: 2019-07-11 05:37 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---

Debug output of the original emerge command (emerge-d.out.xz,60.12 KB, application/x-xz)
2013-03-31 10:43 UTC, Roman Žilka
emerge --info (emerge--info.out,5.80 KB, text/plain)
2013-03-31 10:46 UTC, Roman Žilka

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Žilka 2013-03-31 10:42:21 UTC
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
Comment 1 Roman Žilka 2013-03-31 10:43:27 UTC
Created attachment 343816 [details]
Debug output of the original emerge command
Comment 2 Roman Žilka 2013-03-31 10:46:18 UTC
Created attachment 343818 [details]
emerge --info
Comment 3 Zac Medico gentoo-dev 2013-03-31 17:59:18 UTC
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:
Comment 4 Roman Žilka 2013-03-31 22:08:49 UTC
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.
Comment 5 Roman Žilka 2013-03-31 22:12:52 UTC
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.
Comment 6 Zac Medico gentoo-dev 2013-04-01 01:52:22 UTC
(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.
Comment 7 Zac Medico gentoo-dev 2015-12-29 17:32:09 UTC
*** Bug 569938 has been marked as a duplicate of this bug. ***
Comment 8 Andreas K. Hüttel gentoo-dev 2016-02-29 13:50:23 UTC
*** Bug 567552 has been marked as a duplicate of this bug. ***
Comment 9 Andreas K. Hüttel gentoo-dev 2016-02-29 13:50:48 UTC
*** Bug 575960 has been marked as a duplicate of this bug. ***
Comment 10 Andreas K. Hüttel gentoo-dev 2016-05-24 21:40:38 UTC
*** Bug 567552 has been marked as a duplicate of this bug. ***
Comment 11 Zac Medico gentoo-dev 2019-05-08 17:13:33 UTC
*** Bug 685280 has been marked as a duplicate of this bug. ***